drivers/pci/controller/dwc/pci-keystone.c

File Facts

System

Linux kernel

Corpus path

drivers/pci/controller/dwc/pci-keystone.c

Extension

.c

Size

35364 bytes

Lines

1410

Domain

Representative Device Path

Bucket

PCIe NVMe Storage Path

Inferred role

Representative Device Path: exported/initcall integration point

Status

integration implementation candidate

Why This File Exists

Part of the selected hardware vertical slice: PCI discovery, driver binding, NVMe queues, block requests, DMA, interrupts, and completion.

• Part of the selected hardware vertical slice: PCI discovery, driver binding, NVMe queues, block requests, DMA, interrupts, and completion.
• Exports symbols or registers init work; inspect boot/module ordering and who consumes the exported contract.
• Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
• Touches IRQ or DMA behavior; this matters for the representative real-device path.
• 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/clk.h
• linux/delay.h
• linux/gpio/consumer.h
• linux/init.h
• linux/interrupt.h
• linux/irqchip/chained_irq.h
• linux/irqdomain.h
• linux/mfd/syscon.h
• linux/module.h
• linux/msi.h
• linux/of.h
• linux/of_irq.h
• linux/of_pci.h
• linux/phy/phy.h
• linux/platform_device.h
• linux/regmap.h
• linux/resource.h
• linux/signal.h
• ../../pci.h
• pcie-designware.h

Detected Declarations

• struct ks_pcie_of_data
• struct keystone_pcie
• function ks_pcie_app_readl
• function ks_pcie_app_writel
• function ks_pcie_msi_irq_ack
• function ks_pcie_compose_msi_msg
• function ks_pcie_msi_mask
• function ks_pcie_msi_unmask
• function ks_pcie_set_dbi_mode
• function ks_pcie_clear_dbi_mode
• function ks_pcie_msi_host_init
• function ks_pcie_handle_intx_irq
• function ks_pcie_enable_error_irq
• function ks_pcie_handle_error_irq
• function ks_pcie_ack_intx_irq
• function ks_pcie_init_intx_irq_map
• function ks_pcie_setup_rc_app_regs
• function ks_pcie_link_up
• function ks_pcie_stop_link
• function ks_pcie_start_link
• function ks_pcie_quirk
• function ks_pcie_msi_irq_handler
• function ks_pcie_intx_irq_handler
• function ks_pcie_config_msi_irq
• function ks_pcie_config_intx_irq
• function ks_pcie_init_id
• function ks_pcie_host_init
• function ks_pcie_err_irq_handler
• function ks_pcie_am654_write_dbi2
• function ks_pcie_am654_ep_init
• function ks_pcie_am654_raise_intx_irq
• function ks_pcie_am654_raise_irq
• function ks_pcie_am654_get_features
• function ks_pcie_disable_phy
• function ks_pcie_enable_phy
• function ks_pcie_set_mode
• function ks_pcie_am654_set_mode
• function ks_pcie_probe
• function ks_pcie_remove
• function ks_pcie_fault
• function ks_pcie_init
• module init ks_pcie_init

Annotated Snippet

device_initcall(ks_pcie_init);
#else
builtin_platform_driver(ks_pcie_driver);
#endif

MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("PCIe controller driver for Texas Instruments Keystone SoCs");
MODULE_AUTHOR("Murali Karicheri <m-karicheri2@ti.com>");

Annotation

• Immediate include surface: `linux/clk.h`, `linux/delay.h`, `linux/gpio/consumer.h`, `linux/init.h`, `linux/interrupt.h`, `linux/irqchip/chained_irq.h`, `linux/irqdomain.h`, `linux/mfd/syscon.h`.
• Detected declarations: `struct ks_pcie_of_data`, `struct keystone_pcie`, `function ks_pcie_app_readl`, `function ks_pcie_app_writel`, `function ks_pcie_msi_irq_ack`, `function ks_pcie_compose_msi_msg`, `function ks_pcie_msi_mask`, `function ks_pcie_msi_unmask`, `function ks_pcie_set_dbi_mode`, `function ks_pcie_clear_dbi_mode`.
• Atlas domain: Representative Device Path / PCIe NVMe Storage Path.
• Implementation status: integration implementation candidate.
• Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
• IRQ or DMA behavior appears here, which is relevant to the selected PCIe/NVMe device path.

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.