u-boot.git/drivers/pci, branch v2025.07

pci: zynqmp: Fix the pcireg base

2025-06-02T07:13:48Z

The pcireg base is not assigned to any address, reading the pcireg base with PS_LINKUP_OFFSET which is incorrect and giving random values. So update the pcireg base from devicetree so that we can read the valid PCIE link status and PHY ready status. Signed-off-by: Venkatesh Yadav Abbarapu Reviewed-by: Stefan Roese Link: https://lore.kernel.org/r/20250516092314.939424-1-venkatesh.abbarapu@amd.com Signed-off-by: Michal Simek

Merge patch series "Add PCIe support for TI AM64 SoC"

2025-04-24T16:46:17Z

Hrushikesh Salunke says: TI's AM64 SoC has a single instance of Cadence PCIe Controller. This series enables support for PCIe in AM64 SoC and to configure it in Root-Complex mode of operation. Link: https://lore.kernel.org/r/20250416120830.138965-1-h-salunke@ti.com

pci: pcie_cdns_ti: Enable PCIe root-complex mode in AM64 SoC

2025-04-24T16:45:49Z

TI's AM64 SoC has single instance of PCIe Controller namely PCIe0 which is Cadence PCIe Controller. Add support to configure PCIe0 in Root- Complex mode of operation. Signed-off-by: Hrushikesh Salunke Reviewed-by: Siddharth Vadapalli

pci: pcie_cdns_ti: Include linux/sizes.h header

2025-04-24T16:45:49Z

Driver uses macro SZ_4G to configure inbound base address register. The macro is used without including the header file in which it is defined. Fix this. Fixes: 59ad5480098 ("pci: Add TI K3 Cadence PCIe Controller") Signed-off-by: Hrushikesh Salunke Reviewed-by: Siddharth Vadapalli

Merge patch series "MIPS: Boston: Various enhancements"

2025-04-22T21:13:21Z

Jiaxun Yang says: This is a huge series which promoted MIPS/Boston target into a usable state, with fixes to drivers and general framework issues I found in this process. I also converted the target to OF_UPSTREAM. This target is covered by QEMU, to test on QEMU: ``` make boston64r6el_defconfig make qemu-system-mips64el -M boston -cpu I6500 -bios ./u-boot.bin -nographic ``` Link: https://lore.kernel.org/r/20240517-boston-v3-0-1ea7d23f4a1d@flygoat.com

pci: Enable PCI_MAP_SYSTEM_MEMORY when ARCH_MAP_SYSMEM is not set

2025-04-22T21:08:47Z

For MIPS we are always looking gd->dram in virtual address so PCI_MAP_SYSTEM_MEMORY should always be enabled. If in future we ever want to make it physical we have to set ARCH_MAP_SYSMEM. Signed-off-by: Jiaxun Yang Reviewed-by: Daniel Schwierzeck

pci: auto: Reduce bridge mem alignment boundary for boston

2025-04-22T21:08:47Z

Boston has a very limited memory range for PCI controllers, where 1MB can't easily fit into it. Make alignment boundary of PCI memory resource allocation a Kconfig option and default to 0x10000 for boston. Signed-off-by: Jiaxun Yang Reviewed-by: Daniel Schwierzeck

pci: xilinx: Handle size of ecam region properly

2025-04-22T21:08:47Z

Probe size of ecam from devicetree properly and cap accessible bus number accorading to ecam region size to ensure we don't go beyond hardware address space. Also disable all interrupts to ensure errors are handled silently. Signed-off-by: Jiaxun Yang Reviewed-by: Daniel Schwierzeck

pci_auto: Downgrade prefetch if necessary

2025-03-12T16:23:59Z

Legacy PCI devices, like qemu's Bochs VGA device, are allowed to have prefetchable 32-bit BARs, while PCIe devices are not allowed to have 32-bit prefetchable BARs. Typically prefetchable BARs are 64-bit and typically the prefetch MMIO window is also 64-bit and placed above 4GiB, as it's the case on qemu sbsa-ref. Currently the U-Boot code assumes that prefetchable BARs are 64-bit BARs and always tries to assign them into the prefetch MMIO window. When a 32-bit BAR is marked as prefetch, but the prefetch area is not within the first 4GiB of the address space, then downgrade the BAR and place it in the non-prefetch MMIO window. For prefetch BARs there's no downside on being placed in non prefetch MMIO areas, besides the possible slower performance when a driver tries to map it Write-Combine. TEST: Fixes pci_auto on QEMU sbsa-ref fails to autoconfigure BAR0. Signed-off-by: Patrick Rudolph

pci: mediatek: add support for multiple ports in mediatek pcie gen3 driver

2025-01-23T18:11:49Z

One MediaTek PCIe Gen3 controller has only one port, where PCI bus 0 on this port represents the controller itself and bus 1 represents the external PCIe device. If multiple PCIe controllers are probed in U-Boot, U-Boot will use bus numbers greater than 2 as input parameters. Therefore, we should convert the BDF bus number to either 0 or 1 by subtracting the offset by controller->seq_. Signed-off-by: Sam Shih Signed-off-by: Weijie Gao