drivers/reset/reset-raspberrypi.c
Source file repositories/reference/linux-study-clean/drivers/reset/reset-raspberrypi.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/reset/reset-raspberrypi.c- Extension
.c- Size
- 3152 bytes
- Lines
- 123
- Domain
- Driver Families
- Bucket
- drivers/reset
- Inferred role
- Driver Families: implementation source
- Status
- source implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Allocates kernel memory; connect allocation flags and lifetime to context constraints.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/delay.hlinux/device.hlinux/module.hlinux/of.hlinux/platform_device.hlinux/reset-controller.hsoc/bcm2835/raspberrypi-firmware.hdt-bindings/reset/raspberrypi,firmware-reset.h
Detected Declarations
struct rpi_resetfunction rpi_reset_resetfunction rpi_reset_probe
Annotated Snippet
struct rpi_reset {
struct reset_controller_dev rcdev;
struct rpi_firmware *fw;
};
static inline struct rpi_reset *to_rpi(struct reset_controller_dev *rcdev)
{
return container_of(rcdev, struct rpi_reset, rcdev);
}
static int rpi_reset_reset(struct reset_controller_dev *rcdev, unsigned long id)
{
struct rpi_reset *priv = to_rpi(rcdev);
u32 dev_addr;
int ret;
switch (id) {
case RASPBERRYPI_FIRMWARE_RESET_ID_USB:
/*
* The Raspberry Pi 4 gets its USB functionality from VL805, a
* PCIe chip that implements xHCI. After a PCI reset, VL805's
* firmware may either be loaded directly from an EEPROM or, if
* not present, by the SoC's co-processor, VideoCore. rpi's
* VideoCore OS contains both the non public firmware load
* logic and the VL805 firmware blob. This triggers the
* aforementioned process.
*
* The pci device address is expected is expected by the
* firmware encoded like this:
*
* PCI_BUS << 20 | PCI_SLOT << 15 | PCI_FUNC << 12
*
* But since rpi's PCIe is hardwired, we know the address in
* advance.
*/
dev_addr = 0x100000;
ret = rpi_firmware_property(priv->fw, RPI_FIRMWARE_NOTIFY_XHCI_RESET,
&dev_addr, sizeof(dev_addr));
if (ret)
return ret;
/* Wait for vl805 to startup */
usleep_range(200, 1000);
break;
default:
return -EINVAL;
}
return 0;
}
static const struct reset_control_ops rpi_reset_ops = {
.reset = rpi_reset_reset,
};
static int rpi_reset_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct rpi_firmware *fw;
struct device_node *np;
struct rpi_reset *priv;
np = of_get_parent(dev->of_node);
if (!np) {
dev_err(dev, "Missing firmware node\n");
return -ENOENT;
}
fw = devm_rpi_firmware_get(&pdev->dev, np);
of_node_put(np);
if (!fw)
return -EPROBE_DEFER;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
dev_set_drvdata(dev, priv);
priv->fw = fw;
priv->rcdev.owner = THIS_MODULE;
priv->rcdev.nr_resets = RASPBERRYPI_FIRMWARE_RESET_NUM_IDS;
priv->rcdev.ops = &rpi_reset_ops;
priv->rcdev.of_node = dev->of_node;
return devm_reset_controller_register(dev, &priv->rcdev);
}
static const struct of_device_id rpi_reset_of_match[] = {
Annotation
- Immediate include surface: `linux/delay.h`, `linux/device.h`, `linux/module.h`, `linux/of.h`, `linux/platform_device.h`, `linux/reset-controller.h`, `soc/bcm2835/raspberrypi-firmware.h`, `dt-bindings/reset/raspberrypi,firmware-reset.h`.
- Detected declarations: `struct rpi_reset`, `function rpi_reset_reset`, `function rpi_reset_probe`.
- Atlas domain: Driver Families / drivers/reset.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.