u-boot.git/drivers/pci/Kconfig, branch master Unnamed repository; edit this file 'description' to name the repository. pci: Add AMD Versal2 DW PCIe host controller driver 2026-04-23T09:49:48+00:00 Pranav Sanwal pranav.sanwal@amd.com 2026-03-27T12:10:13+00:00 3ac0ecb42f9f59c80e34ed1f4f1e340902501a55 Add support for the DesignWare-based PCIe host controller found in AMD Versal2 SoCs. This enables PCIe functionality (e.g. NVMe storage) on boards such as the VEK385. The driver builds on the existing pcie_dw_common infrastructure and adds Versal2-specific handling: it maps the SLCR register region to mask and clear TLP interrupt status bits, parses dbi/config/atu/slcr register regions from device tree, and supports an optional PERST# GPIO on child nodes for endpoint reset sequencing. The outbound iATU is programmed for the non-prefetchable memory window from device tree ranges. Signed-off-by: Pranav Sanwal <pranav.sanwal@amd.com> Link: https://lore.kernel.org/r/20260327121015.996806-2-pranav.sanwal@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com> 
Add support for the DesignWare-based PCIe host controller found in
AMD Versal2 SoCs. This enables PCIe functionality (e.g. NVMe storage)
on boards such as the VEK385.

The driver builds on the existing pcie_dw_common infrastructure and
adds Versal2-specific handling: it maps the SLCR register region to
mask and clear TLP interrupt status bits, parses dbi/config/atu/slcr
register regions from device tree, and supports an optional PERST#
GPIO on child nodes for endpoint reset sequencing. The outbound iATU
is programmed for the non-prefetchable memory window from device tree
ranges.

Signed-off-by: Pranav Sanwal <pranav.sanwal@amd.com>
Link: https://lore.kernel.org/r/20260327121015.996806-2-pranav.sanwal@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
dm: core: Default to using DEVRES outside of xPL 2026-01-09T15:08:14+00:00 Tom Rini trini@konsulko.com 2025-12-27T22:37:11+00:00 217cf656e249f698d390a7d8eaf255eb1a6c0230 The devm alloc functions that we have may follow the Linux kernel model where allocations are (almost always) automatically free()'d. However, quite often we don't enable, in full U-Boot, the tracking and free()'ing functionality. This in turn leads to memory leaks because the driver author expects that since the functions have the same name as in the Linux Kernel they have the same behavior. In turn we then get functionally correct commits such as commit 00e1fed93c8c ("firmware: ti_sci: Fix memory leaks in devm_ti_sci_get_of_resource") that manually add these calls. Rather than manually tracking allocations and implementing free()s, rework things so that we follow expectations by enabling the DEVRES functionality (outside of xPL phases). This turns DEVRES from a prompted symbol to a symbol that must be select'd, and we now remove our non-managed alloc/free functions from outside of xPL builds. Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Tom Rini <trini@konsulko.com> 
The devm alloc functions that we have may follow the Linux kernel model
where allocations are (almost always) automatically free()'d. However,
quite often we don't enable, in full U-Boot, the tracking and free()'ing
functionality. This in turn leads to memory leaks because the driver
author expects that since the functions have the same name as in the
Linux Kernel they have the same behavior. In turn we then get
functionally correct commits such as commit 00e1fed93c8c ("firmware:
ti_sci: Fix memory leaks in devm_ti_sci_get_of_resource") that manually
add these calls. Rather than manually tracking allocations and
implementing free()s, rework things so that we follow expectations by
enabling the DEVRES functionality (outside of xPL phases).

This turns DEVRES from a prompted symbol to a symbol that must be
select'd, and we now remove our non-managed alloc/free functions from
outside of xPL builds.

Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
pci: Remove pcie_intel_fpga driver 2025-10-08T19:54:58+00:00 Tom Rini trini@konsulko.com 2025-09-25T20:43:14+00:00 d40eae0e270f50e6e9b99d7bca334bb87bc28f70 This driver has never been enabled by a platform since introduction and does not currently compile. Remove it. Signed-off-by: Tom Rini <trini@konsulko.com> 
This driver has never been enabled by a platform since introduction and
does not currently compile. Remove it.

Signed-off-by: Tom Rini <trini@konsulko.com>
pci: pcie_dw_imx: Add iMX9 support to the driver 2025-09-20T20:46:15+00:00 Ye Li ye.li@nxp.com 2025-09-11T10:56:05+00:00 f8b188350815df2e0436eb113e7c9300ca9cd02e Adding iMX95/iMX94 support to the dw driver. Follow kernel driver stype to use flags to distinguish the characteristic of different platforms. Signed-off-by: Ye Li <ye.li@nxp.com> 
Adding iMX95/iMX94 support to the dw driver. Follow kernel driver
stype to use flags to distinguish the characteristic of different
platforms.

Signed-off-by: Ye Li <ye.li@nxp.com>
pci: Tighten some PCI controller dependencies 2025-08-11T21:00:28+00:00 Tom Rini trini@konsulko.com 2025-07-18T01:15:26+00:00 cb8e5727089b6069f314a2f232e105f7c2127dbb A large number of PCI controllers cannot build without access to some platform specific header files. Express those requirements in Kconfig as well. Signed-off-by: Tom Rini <trini@konsulko.com> 
A large number of PCI controllers cannot build without access to some
platform specific header files. Express those requirements in Kconfig as
well.

Signed-off-by: Tom Rini <trini@konsulko.com>
pci: pcie-rcar-gen4: Add Renesas R-Car Gen4 DW PCIe controller driver 2025-06-27T14:25:56+00:00 Marek Vasut marek.vasut+renesas@mailbox.org 2025-06-17T08:16:31+00:00 be3dd0dc2fd9020fa19cd96ea82753315f4084b0 Add R-Car Gen4 PCIe controller support for host mode. This controller is based on Synopsys DesignWare PCIe. However, this particular controller has a number of vendor-specific registers, and as such, requires initialization code, including PHY firmware loading. The PHY firmware loading is implemented in an entirely generic manner, by calling a firmware loading script, which the user can configure in a way they require. This provides the user with flexibility of loading the PCIe firmware from whichever storage device they need to load it from. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> 
Add R-Car Gen4 PCIe controller support for host mode.

This controller is based on Synopsys DesignWare PCIe. However, this
particular controller has a number of vendor-specific registers, and as
such, requires initialization code, including PHY firmware loading.

The PHY firmware loading is implemented in an entirely generic manner,
by calling a firmware loading script, which the user can configure in
a way they require. This provides the user with flexibility of loading
the PCIe firmware from whichever storage device they need to load it
from.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Merge patch series "MIPS: Boston: Various enhancements" 2025-04-22T21:13:21+00:00 Tom Rini trini@konsulko.com 2025-04-22T21:13:21+00:00 20fcb6305eef553a94eeed6efb1a60ee3ccd9db7 Jiaxun Yang <jiaxun.yang@flygoat.com> 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 
Jiaxun Yang <jiaxun.yang@flygoat.com> 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:47+00:00 Jiaxun Yang jiaxun.yang@flygoat.com 2024-05-17T18:14:51+00:00 1864dfb1c457e090d2e84d14ee56d9579a898e7f 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 <jiaxun.yang@flygoat.com> Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> 
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 <jiaxun.yang@flygoat.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
pci: auto: Reduce bridge mem alignment boundary for boston 2025-04-22T21:08:47+00:00 Jiaxun Yang jiaxun.yang@flygoat.com 2024-05-17T18:14:50+00:00 fc25cd0e1a1d5bea59c651782b93e70289d68c1f 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 <jiaxun.yang@flygoat.com> Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> 
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 <jiaxun.yang@flygoat.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
pci: Add support for Qualcomm PCIe controller 2025-01-22T15:43:54+00:00 Neil Armstrong neil.armstrong@linaro.org 2024-11-25T09:46:17+00:00 5b7ec7fb4437e3e9b50127114a59796a90c1681a Add support for the PCIe busses on Qualcomm platforms, by using the pcie_dw_common infrastructure. The driver is based on the Linux driver but only supporting the "1_9_0" and compatible platforms like: - sa8540p - sc7280 - sc8180x - sc8280xp - sdm845 - sdx55 - sm8150 - sm8250 - sm8350 - sm8450 - sm8550 - sm8650 - x1e80100 But it has only been tested on: - sc7280 - sm8550 - sm8650 - x1e80100 It supports setting the IOMMU SID table for supported platforms. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20241125-topic-pcie-controller-v1-2-45c20070dd53@linaro.org Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org> 
Add support for the PCIe busses on Qualcomm platforms,
by using the pcie_dw_common infrastructure.

The driver is based on the Linux driver but only supporting
the "1_9_0" and compatible platforms like:
- sa8540p
- sc7280
- sc8180x
- sc8280xp
- sdm845
- sdx55
- sm8150
- sm8250
- sm8350
- sm8450
- sm8550
- sm8650
- x1e80100

But it has only been tested on:
- sc7280
- sm8550
- sm8650
- x1e80100

It supports setting the IOMMU SID table for supported platforms.

Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20241125-topic-pcie-controller-v1-2-45c20070dd53@linaro.org
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>