summaryrefslogtreecommitdiff
path: root/drivers/pci
AgeCommit message (Collapse)Author
2026-03-26PCI: imx6: Separate PERST# assertion from core reset functionsSherry Sun
The imx_pcie_assert_core_reset() and imx_pcie_deassert_core_reset() functions are primarily intended to reset the RC controller itself, not the remote PCIe endpoint devices. However, the PERST# GPIO control was previously embedded within these functions, which conflates two distinct reset operations. Move the PERST# GPIO handling into a dedicated function imx_pcie_assert_perst(). This makes the code more maintainable and prepares for parsing the reset-gpios property according to the new Root Port DT binding in subsequent patches. No functional change is intended. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com> Link: https://patch.msgid.link/20260306030456.1032815-1-sherry.sun@nxp.com
2026-03-26PCI: imx6: Change imx_pcie_deassert_core_reset() return type to voidSherry Sun
The function imx_pcie_deassert_core_reset() always returns 0 and the return value is not used meaningfully by its callers. Change the return type from int to void to simplify the code and remove unnecessary error handling paths. No functional change intended. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Richard Zhu <hongxing.zhu@nxp.com> Link: https://patch.msgid.link/20260306021247.991976-1-sherry.sun@nxp.com
2026-03-26PCI: endpoint: Improve error messagesManivannan Sadhasivam
Include errno in the error prints and also use dev_err() where applicable. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260305071236.23792-2-mani@kernel.org
2026-03-26PCI: endpoint: Print the EPF name in the error log of pci_epf_make()Manivannan Sadhasivam
Merely printing the error log without the actual EPF name will not give much clue to the users about the failure. Hence, print the EPF name also. Suggested-by: Bjorn Helgaas <helgaas@kernel.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260305071236.23792-1-mani@kernel.org
2026-03-26PCI: imx6: Skip waiting for L2/L3 Ready on i.MX6SXRichard Zhu
On i.MX6SX, the LTSSM registers become inaccessible after the PME_Turn_Off message is sent to the link. So there is no way to verify whether the link has entered L2/L3 Ready state or not. Hence, set IMX_PCIE_FLAG_SKIP_L23_READY flag for i.MX6SX SoC to skip the L2/L3 Ready state polling and let the DWC core wait for 10ms after sending the PME_Turn_Off message as per the PCIe spec r6.0, sec 5.3.3.2.1. Fixes: a528d1a72597 ("PCI: imx6: Use DWC common suspend resume method") Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> [mani: commit log] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260228080925.1558395-1-hongxing.zhu@nxp.com
2026-03-25PCI: mediatek-gen3: Integrate new pwrctrl APIChen-Yu Tsai
With the new PCI pwrctrl API and PCI slot binding and power drivers, we now have a way to describe and power up WiFi/BT adapters connected through a PCIe or M.2 slot, or populated onto the mainboard itself. The latter case has the adapter layout or design copied verbatim, replacing the slot with direct connections. Integrate the PCI pwrctrl API into the PCIe driver, so that power is properly enabled before PCIe link training is done, allowing the card to successfully be detected. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260324052002.4072430-8-wenst@chromium.org
2026-03-25PCI: mediatek-gen3: Disable device if further setup failsChen-Yu Tsai
If further setup fails after the device is powered on and link training succeeds, we want to place the device back in a quiescence state to avoid unintended activity and save power. This also helps with power state tracking and balancing once pwrctrl API is integrated. Power down the device in the error paths of mtk_pcie_startup_port() and mtk_pcie_probe(). Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260324052002.4072430-7-wenst@chromium.org
2026-03-25PCI: mediatek-gen3: Split out device power helpersChen-Yu Tsai
In preparation for adding full power on/off control with the pwrctrl API, split out the existing code that only partially deals with device power sequencing into separate helper functions. The existing code only handles PERST#. This is purely moving code around, and brings no functional changes. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> [mani: moved the 'err' variable to next commit] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260324052002.4072430-6-wenst@chromium.org
2026-03-25PCI: mediatek-gen3: Add error path for resume driver callbacksChen-Yu Tsai
The resume callback currently does teardown in the conditional block directly. This is going to get ugly when the pwrctrl calls are added. Move the teardown to a proper error cleanup path. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260324052002.4072430-5-wenst@chromium.org
2026-03-25PCI: mediatek-gen3: Move controller setup steps before PERST# controlChen-Yu Tsai
Setting up the translation windows and enabling MSI involve only the controller, not the link or any downstream device. These can be done before the device is enabled. Move these steps before the existing PERST# control and waiting for the link to come up. This provides a cleaner separation of controller vs device setup. This also allows the later commits that split out PERST# control and add device power control to have cleaner teardown. This change only moves code. No functional change is expected. Suggested-by: Bjorn Helgaas <helgaas@kernel.org> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260324052002.4072430-4-wenst@chromium.org
2026-03-25PCI: mediatek-gen3: Move mtk_pcie_setup_irq() out of mtk_pcie_setup()Chen-Yu Tsai
mtk_pcie_setup_irq() sets up the IRQ domains for PCI INTx and MSI, and chains them to the controller's interrupt. It doesn't touch the PCIe controller itself. Move mtk_pcie_setup_irq() out of mtk_pcie_setup(), do it earlier so there's nothing to clean up if it fails, and add an error message if it does fail. Reorder mtk_pcie_irq_teardown() in the remove callback to follow. Also create an error path in the probe function. Suggested-by: Bjorn Helgaas <helgaas@kernel.org> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260324052002.4072430-3-wenst@chromium.org
2026-03-25PCI: mediatek-gen3: Clean up mtk_pcie_parse_port() with dev_err_probe()Chen-Yu Tsai
mtk_pcie_parse_port() in the pcie-mediatek-gen driver has a bunch of if (err) { dev_err(dev, "error message\n"); return err; # or goto } patterns. Simplify these with dev_err_probe(). The system also gains proper deferred probe messages that can be seen in: /sys/kernel/debug/devices_deferred Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260324052002.4072430-2-wenst@chromium.org
2026-03-25PCI/VGA: Pass errors from pci_set_vga_state() upSimon Richter
pci_set_vga_state() returns an error code, which so far has been ignored by the only caller, __vga_tryget(), so forward it to the caller. As the return type of __vga_tryget() is a pointer, wrap the error in ERR_PTR(). Signed-off-by: Simon Richter <Simon.Richter@hogyros.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260307173538.763188-3-Simon.Richter@hogyros.de
2026-03-25PCI/VGA: Pass vga_get_uninterruptible() errors to userspaceSimon Richter
If VGA routing cannot be established, vga_get_uninterruptible() returns an error and does not increment the lock count. Return the error to the caller. Return before incrementing uc->io_cnt/mem_cnt so vga_arb_release() won't call vga_put() when userspace closes the handle. Signed-off-by: Simon Richter <Simon.Richter@hogyros.de> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260307173538.763188-2-Simon.Richter@hogyros.de
2026-03-25PCI: hv: Set default NUMA node to 0 for devices without affinity infoLong Li
When hv_pci_assign_numa_node() processes a device that does not have HV_PCI_DEVICE_FLAG_NUMA_AFFINITY set or has an out-of-range virtual_numa_node, the device NUMA node is left unset. On x86_64, the uninitialized default happens to be 0, but on ARM64 it is NUMA_NO_NODE (-1). Tests show that when no NUMA information is available from the Hyper-V host, devices perform best when assigned to node 0. With NUMA_NO_NODE the kernel may spread work across NUMA nodes, which degrades performance on Hyper-V, particularly for high-throughput devices like MANA. Always set the device NUMA node to 0 before the conditional NUMA affinity check, so that devices get a performant default when the host provides no NUMA information, and behavior is consistent on both x86_64 and ARM64. Fixes: 999dd956d838 ("PCI: hv: Add support for protocol 1.3 and support PCI_BUS_RELATIONS2") Signed-off-by: Long Li <longli@microsoft.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: Wei Liu <wei.liu@kernel.org>
2026-03-24PCI: sky1: Fix missing cleanup of ECAM config on probe failureFelix Gu
When devm_kzalloc() for reg_off fails, the code returns -ENOMEM without freeing pcie->cfg, which was allocated earlier by pci_ecam_create(). Add the missing pci_ecam_free() call to properly release the allocated ECAM configuration window on this error path. Fixes: a0d9f2c08f45 ("PCI: sky1: Add PCIe host support for CIX Sky1") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Hans Zhang <18255117159@163.com> Link: https://patch.msgid.link/20260324-sky1-v1-1-6a00cb2776b6@gmail.com
2026-03-23PCI/pwrctrl: Fix pci_pwrctrl_is_required() device node leakFelix Gu
The for_each_endpoint_of_node() macro requires calling of_node_put() on the endpoint node when breaking out of the loop early. Add of_node_put(endpoint) before the early return to release the reference. Fixes: cf3287fb2c1f ("PCI/pwrctrl: Ensure that remote endpoint node parent has supply requirement") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260323-pwctrl-v1-1-f5c03a2df7fb@gmail.com
2026-03-23PCI/pwrctrl: Do not power off on pwrctrl device removalChen-Yu Tsai
With the move to explicit pwrctrl power on/off APIs, the caller, i.e., the PCI controller driver, should manage the power state. The pwrctrl drivers should not try to clean up or power off when they are removed, as this might end up disabling an already disabled regulator, causing a big warning. This can be triggered if a PCI controller driver's .remove() callback calls pci_pwrctrl_destroy_devices() after pci_pwrctrl_power_off_devices(). Drop the devm cleanup parts that turn off regulators from the pwrctrl drivers. Fixes: b921aa3f8dec ("PCI/pwrctrl: Switch to pwrctrl create, power on/off, destroy APIs") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260226092234.3859740-1-wenst@chromium.org
2026-03-23PCI: dwc: rcar-gen4: Change EPC BAR alignment to 4K as per the documentationKoichiro Den
R-Car S4 Series (R8A779F[4-7]*) EP controller uses a 4K minimum iATU region size (CX_ATU_MIN_REGION_SIZE = 4K) as per R19UH0161EJ0130 Rev.1.30. Also, the controller itself can only be configured in the range 4 KB to 64 KB, so the current 1 MB alignment requirement is incorrect. Hence, change the alignment to the min size 4K as per the documentation. This also fixes needless unusability of BAR4 on this platform when the target address is fixed, such as for doorbell targets. Fixes: e311b3834dfa ("PCI: rcar-gen4: Add endpoint mode support") Signed-off-by: Koichiro Den <den@valinux.co.jp> [mani: commit log] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Niklas Cassel <cassel@kernel.org> Link: https://patch.msgid.link/20260305151050.1834007-1-den@valinux.co.jp
2026-03-21PCI: dwc: rcar-gen4: Mark BAR0 and BAR2 as Resizable BARs in endpoint modeKoichiro Den
R-Car Gen4 (S4) endpoint controller implements the PCIe Resizable BAR capability for BAR0 and BAR2. Advertise them as BAR_RESIZABLE so that EPF requested BAR sizes are reflected to the host. Signed-off-by: Koichiro Den <den@valinux.co.jp> [commit log] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Niklas Cassel <cassel@kernel.org> Link: https://patch.msgid.link/20260210160315.2272930-1-den@valinux.co.jp
2026-03-21PCI: mediatek: Fix possible truncation in mtk_pcie_parse_port()Ryder Lee
As reported by the W=1 warning below, content of the 'name' variable might get truncated with the existing size of 10 bytes. Though it is not practically possible to exceed the 10 bytes size, increase it to 20 to silence the warning for a clean W=1 build: $ make W=1 drivers/pci/controller/pcie-mediatek.o CALL scripts/checksyscalls.sh DESCEND objtool INSTALL libsubcmd_headers CC drivers/pci/controller/pcie-mediatek.o drivers/pci/controller/pcie-mediatek.c: In function ‘mtk_pcie_parse_port’: drivers/pci/controller/pcie-mediatek.c:963:43: error: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 6 [-Werror=format-truncation=] 963 | snprintf(name, sizeof(name), "port%d", slot); | ^~ drivers/pci/controller/pcie-mediatek.c:963:38: note: directive argument in the range [0, 2147483647] 963 | snprintf(name, sizeof(name), "port%d", slot); | ^~~~~~~~ drivers/pci/controller/pcie-mediatek.c:963:9: note: ‘snprintf’ output between 6 and 15 bytes into a destination of size 10 963 | snprintf(name, sizeof(name), "port%d", slot); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> [mani: commit log] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/b835e360b42c5e0994f9301a34dbdf140a8d3ef5.1772493898.git.ryder.lee@mediatek.com
2026-03-19Merge tag 'pci-v7.0-fixes-4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull pci fixes from Bjorn Helgaas: - Create pwrctrl devices only for DT nodes below a PCI controller that describe PCI devices and are related to a power supply; this prevents waiting indefinitely for pwrctrl drivers that will never probe (Manivannan Sadhasivam) - Restore endpoint BAR mapping on subrange setup failure to make selftest reliable (Koichiro Den) * tag 'pci-v7.0-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails PCI/pwrctrl: Create pwrctrl devices only for PCI device nodes PCI/pwrctrl: Ensure that remote endpoint node parent has supply requirement
2026-03-19PCI: eswin: Add ESWIN PCIe Root Complex driverSenchuan Zhang
Add driver for the ESWIN PCIe Root Complex based on the DesignWare PCIe core, IP revision 5.96a. The PCIe Gen.3 Root Complex supports data rate of 8 GT/s and x4 lanes, with INTx and MSI interrupt capability. Signed-off-by: Yu Ning <ningyu@eswincomputing.com> Signed-off-by: Yanghui Ou <ouyanghui@eswincomputing.com> Signed-off-by: Senchuan Zhang <zhangsenchuan@eswincomputing.com> [mani: renamed "EIC7700" to "ESWIN", added maintainers entry, removed async probe] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> [bhelgaas: add driver tag in subject] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260227111808.1996-1-zhangsenchuan@eswincomputing.com
2026-03-18PCI/pwrctrl: generic: Add UPD720201/UPD720202 USB 3.0 xHCI Host Controller ↵Neil Armstrong
support Enable the generic pwrctrl driver to control power of PCIe UPD720201/UPD720202 USB 3.0 xHCI Host Controller. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260220-topic-sm8650-ayaneo-pocket-s2-base-v5-4-1ad79caa1efa@linaro.org
2026-03-18PCI/pwrctrl: generic: Simplify dev_err_probe() usageNeil Armstrong
dev_err_probe() returns the error code passed to it, so this: dev_err_probe(dev, ret, "Failed to get slot regulators\n"); return ret; is equivalent to this: return dev_err_probe(dev, ret, "Failed to get slot regulators\n"); Simplify by using the latter. Suggested-by: Bartosz Golaszewski <brgl@kernel.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260220-topic-sm8650-ayaneo-pocket-s2-base-v5-2-1ad79caa1efa@linaro.org
2026-03-18PCI/pwrctrl: generic: Rename pci-pwrctrl-slot as genericNeil Armstrong
The driver is pretty generic and would fit for either PCI Slots or endpoints connected to PCI ports, so rename the driver and module as pci-pwrctrl-generic. Suggested-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260220-topic-sm8650-ayaneo-pocket-s2-base-v5-3-1ad79caa1efa@linaro.org
2026-03-17PCI: rpaphp: Simplify with scoped for each OF child loopKrzysztof Kozlowski
Use scoped for-each loop when iterating over device nodes to make code a bit simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://patch.msgid.link/20260317133322.266102-8-krzysztof.kozlowski@oss.qualcomm.com
2026-03-17PCI: pnv_php: Simplify with scoped for each OF child loopKrzysztof Kozlowski
Use scoped for-each loop when iterating over device nodes to make code a bit simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://patch.msgid.link/20260317133322.266102-7-krzysztof.kozlowski@oss.qualcomm.com
2026-03-17PCI/CXL: Hide SBR from reset_methods if masked by CXLVidya Sagar
Per CXL r3.1, sec 8.1.5.2, the Secondary Bus Reset (SBR) bit in the Bridge Control register of a CXL port has no effect unless the "Unmask SBR" bit in the Port Control Extensions Register is set. After b1956e2d0713 ("PCI/CXL: Fail bus reset if upstream CXL Port has SBR masked"), Linux checks the "Unmask SBR" bit in pci_reset_bus_function(). But when probe==true, it previously returned 0, incorrectly indicating that SBR is a viable reset method for the device. As a result, "bus" is listed in the device's "reset_method" attribute even though the hardware is incapable of performing it. If a user writes "bus" to "reset_method" or triggers a reset that falls back to SBR, the operation fails with "write error: Inappropriate ioctl for device". If the link is operating in CXL mode (pcie_is_cxl()), return -ENOTTY immediately unless "Unmask SBR" is set, regardless of the probe argument. This ensures that "bus" is not advertised in "reset_methods" when the hardware prevents it, improving clarity for users and aligning the sysfs capability report with actual hardware behavior. Signed-off-by: Vidya Sagar <vidyas@nvidia.com> [bhelgaas: commit log, use pcie_is_cxl()] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260225133801.30231-1-vidyas@nvidia.com
2026-03-17PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup failsKoichiro Den
When the BAR subrange mapping test on DWC-based platforms fails due to insufficient free inbound iATU regions, pci_epf_test_bar_subrange_setup() returns an error (-ENOSPC) but does not restore the original BAR mapping. This causes subsequent test runs to become confusing, since the failure may leave room for the next subrange mapping test to pass. Fix this by restoring the original BAR mapping when preparation of the subrange mapping fails, so that no side effect remains regardless of the test success or failure. Fixes: 6c5e6101423b ("PCI: endpoint: pci-epf-test: Add BAR subrange mapping test support") Reported-by: Christian Bruel <christian.bruel@foss.st.com> Closes: https://lore.kernel.org/linux-pci/b2b03ebe-9482-4a13-b22f-7b44da096eed@foss.st.com/ Signed-off-by: Koichiro Den <den@valinux.co.jp> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Christian Bruel <christian.bruel@foss.st.com> Reviewed-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260316140225.1481658-1-den@valinux.co.jp
2026-03-16PCI/pwrctrl: Create pwrctrl devices only for PCI device nodesManivannan Sadhasivam
A PCI host bridge node can have non-PCI child nodes (OPP tables, USB hub, etc.) as well as PCI device child nodes. Ensure that pwrctrl devices are only created for PCI device nodes by checking for the 'pci' prefix in the compatible property. Fixes: 4c4132489201 ("PCI/pwrctrl: Add APIs to create, destroy pwrctrl devices") Reported-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Closes: https://lore.kernel.org/all/20260212-rb3gen2-upd-gl3590-v1-1-18fb04bb32b0@oss.qualcomm.com Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260223-pwrctrl-fixes-7-0-v2-2-97566dfb1809@oss.qualcomm.com
2026-03-16PCI/pwrctrl: Ensure that remote endpoint node parent has supply requirementManivannan Sadhasivam
If OF graph is used in the PCI device node, the pwrctrl core creates a pwrctrl device even if the remote endpoint doesn't have power supply requirements. Since the device doesn't have any power supply requirements, there was no pwrctrl driver to probe, leading to PCI controller driver probe deferral as it waits for all pwrctrl drivers to probe before starting bus scan. This issue happens with Qcom ath12k devices with WSI interface attached to the Qcom IPQ platforms. Fix this issue by checking for the existence of at least one power supply property in the remote endpoint parent node. To consolidate all the checks, create a new helper pci_pwrctrl_is_required() and move all the checks there. Fixes: 9db826206f9b ("PCI/pwrctrl: Create pwrctrl device if graph port is found") Reported-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Reviewed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260223-pwrctrl-fixes-7-0-v2-1-97566dfb1809@oss.qualcomm.com
2026-03-16PCI/DPC: Hold pci_dev reference during error recoverySizhe Liu
The AER and EDR error handling paths hold a reference on the pci_dev during recovery. Hold a reference during the DPC recovery path as well. Signed-off-by: Sizhe Liu <liusizhe5@huawei.com> [bhelgaas: split to separate patch] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> https://patch.msgid.link/20260214081130.1878424-1-liusizhe5@huawei.com
2026-03-15PCI: endpoint: pci-epf-test: Advertise reserved BARsNiklas Cassel
Advertise reserved BARs as reserved in the Capabilities register, such that the host side driver will be able to skip reserved BARs. Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Koichiro Den <den@valinux.co.jp> Tested-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Reviewed-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260312130229.2282001-20-cassel@kernel.org
2026-03-15PCI: dwc: Disable BARs in common code instead of in each glue driverNiklas Cassel
The current EPC core design relies on an EPC driver disabling all BARs by default. An EPF driver will then enable the BARs that it wants to enabled. This design is there because there is no epc->ops->disable_bar(). (There is a epc->ops->clear_bar(), but that is only to disable a BAR that has been enabled using epc->ops->set_bar() first.) By default, an EPF driver will not be able to get/enable BARs that are marked as BAR_RESERVED or BAR_DISABLED (see pci_epc_get_next_free_bar()). Since the current EPC code design requires an EPC driver to disable all BARs by default, move this to DWC common code from each glue driver. BAR_RESERVED BARs are not disabled by default because these BARs are hardware backed, and should only be disabled explicitly by an EPF driver if absolutely necessary for the EPF driver to function correctly. (This is similar to how e.g. NVMe may have vendor specific BARs outside of the mandatory BAR0 which contains the NVMe registers.) Note that there is currently no EPC operation to disable a BAR that has not first been programmed using pci_epc_set_bar(). If an EPF driver ever wants to disable a BAR marked as BAR_RESERVED, a disable_bar() operation would have to be added first. No functional changes intended. Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Tested-by: Koichiro Den <den@valinux.co.jp> Reviewed-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260312130229.2282001-19-cassel@kernel.org
2026-03-15PCI: dwc: Replace certain BAR_RESERVED with BAR_DISABLED in glue driversNiklas Cassel
Most DWC based EPC glue drivers that have BARs marked as BAR_RESERVED in epc_features also call dw_pcie_ep_reset_bar() for these reserved BARs in ep->ops->init(). (The only exception is pci-keystone.c.) An EPF driver will be able to get/enable BARs that have been disabled/reset using dw_pcie_ep_reset_bar(), except if the BAR is marked as BAR_RESERVED (see pci_epc_get_next_free_bar()). Thus, all EPC drivers that have BARs marked as BAR_RESERVED in epc_features and call dw_pcie_ep_reset_bar(), should really have these BARs marked as BAR_DISABLED. If dw_pcie_ep_reset_bar() is not called by the glue driver, the BARs are kept as BAR_RESERVED. No EPC drivers outside drivers/pci/controllers/dwc mark their BARs as BAR_RESERVED, so there is nothing to do in non-DWC based EPC drivers. Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Tested-by: Koichiro Den <den@valinux.co.jp> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260312130229.2282001-18-cassel@kernel.org
2026-03-15PCI: endpoint: Introduce pci_epc_bar_type BAR_DISABLEDNiklas Cassel
Add a pci_epc_bar_type BAR_DISABLED to more clearly differentiate from BAR_RESERVED. This BAR type will only be used to describe a BAR that the EPC driver should disable, and will thus never be available to an EPF driver. (Unlike BAR_RESERVED, which will never be disabled by default by an EPC driver.) Co-developed-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Koichiro Den <den@valinux.co.jp> Tested-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Link: https://patch.msgid.link/20260312130229.2282001-17-cassel@kernel.org
2026-03-15PCI: dw-rockchip: Describe RK3588 BAR4 DMA ctrl windowKoichiro Den
On RK3588 PCIe3_4L in EP mode, the integrated DMA controller registers are permanently mapped to BAR4 and must not be repurposed by EPF drivers. When the remote peer needs to access these registers, it must use the fixed BAR4 window instead of creating another inbound mapping in a different BAR. Mixing the fixed window with an additional mapping can lead to incorrect behavior. Advertise the DMA controller MMIO window as a reserved BAR subregion so EPF drivers can reuse it safely. Signed-off-by: Koichiro Den <den@valinux.co.jp> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Koichiro Den <den@valinux.co.jp> Reviewed-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260312130229.2282001-16-cassel@kernel.org
2026-03-15PCI: endpoint: Do not mark the BAR succeeding a 64-bit BAR as BAR_RESERVEDNiklas Cassel
A BAR that can only be configured as a 64-bit BAR by an EPC driver is marked as such using the "only_64bit" flag. Currently, the documentation says that an EPC driver should explicitly mark the BAR succeeding an "only_64bit" BAR as BAR_RESERVED. However, a 64-bit BAR will always take up two BARs. It is thus redundant to mark both BARs. pci_epc_get_next_free_bar() already skips the BAR succeeding a "only_64bit" BAR, regardless if the succeeding BAR is marked as BAR_RESERVED or not. Thus, drop the BAR_RESERVED for a BAR succeeding a "only_64bit" BAR. No functional changes. Suggested-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260312130229.2282001-13-cassel@kernel.org
2026-03-15PCI: rzg3s-host: Add support for RZ/G3E PCIe controllerJohn Madieu
Add support for the PCIe controller found in RZ/G3E SoCs to the existing RZ/G3S PCIe host controller driver. The RZ/G3E PCIe controller is similar to the RZ/G3S, with the following key differences: - Supports PCIe Gen3 (8.0 GT/s) link speeds alongside Gen2 (5.0 GT/s) - Uses a different reset control mechanism via AXI registers instead of the Linux reset framework - Requires specific SYSC configuration for link state control and Root Complex mode selection Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> [mani: added a readl_relaxed() before fsleep() to flush previous write] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # RZ/V2N EVK Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20260306143423.19562-13-john.madieu.xa@bp.renesas.com
2026-03-15PCI: rzg3s-host: Add PCIe Gen3 (8.0 GT/s) link speed supportJohn Madieu
Extend the link speed configuration to support Gen3 (8.0 GT/s) in addition to Gen2 (5.0 GT/s). This is required for RZ/G3E PCIe host support, which is Gen3 capable. Instead of relying on DT max-link-speed for configuration, read the hardware capabilities from the PCI_EXP_LNKCAP register to determine the maximum supported speed. The DT max-link-speed property is now only used as an optional limit when explicitly specified, which aligns with PCIe subsystem expectations. Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # RZ/V2N EVK Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20260306143423.19562-12-john.madieu.xa@bp.renesas.com
2026-03-15PCI: rzg3s-host: Explicitly set class code for RZ/G3E compatibilityJohn Madieu
Program the class code register explicitly during PCIe configuration initialization. RZ/G3E requires this register to be set, while RZ/G3S has these values as hardware defaults. This configuration is harmless for RZ/G3S where these match the hardware defaults, and necessary for RZ/G3E to properly identify the device as a PCI bridge. Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # RZ/V2N EVK Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20260306143423.19562-11-john.madieu.xa@bp.renesas.com
2026-03-15PCI: rzg3s-host: Add SoC-specific configuration and initialization callbacksJohn Madieu
Add optional cfg_pre_init, cfg_post_init, and cfg_deinit callbacks to handle SoC-specific configuration methods. While RZ/G3S uses the Linux reset framework with dedicated reset lines, other SoC variants like RZ/G3E control configuration resets through PCIe AXI registers. As Linux reset bulk API gracefully handles optional NULL reset lines (num_cfg_resets = 0 for RZ/G3E), the driver continues to use the standard reset framework when reset lines are available, while custom callbacks are only invoked when provided. This provides a balanced pattern where: - RZ/G3S: Uses callbacks that fall back to the reset framework - RZ/G3E: Sets num_cfg_resets=0, provides cfg_pre_init/cfg_post_init/cfg_deinit Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # RZ/V2N EVK Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20260306143423.19562-10-john.madieu.xa@bp.renesas.com
2026-03-15PCI: rzg3s-host: Make configuration reset lines optionalJohn Madieu
Some SoC variants such as RZ/G3E handle configuration reset control through PCIe AXI registers instead of dedicated reset lines. Make cfg_resets optional by using devm_reset_control_bulk_get_optional_exclusive() to allow SoCs to use alternative or complementary reset control mechanisms. Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # RZ/V2N EVK Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20260306143423.19562-9-john.madieu.xa@bp.renesas.com
2026-03-15PCI: rzg3s-host: Make SYSC register offsets SoC-specificJohn Madieu
In preparation for adding RZ/G3E support, move the RST_RSM_B register offset and mask into a SoC-specific data structure. Compared with RZ/G3S, the RZ/G3E SYSC controls different functionalities for the PCIe controller. Make SYSC operations conditional on the presence of register offset information, allowing the driver to handle SoCs that don't use the RST_RSM_B signal. Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # RZ/V2N EVK Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20260306143423.19562-8-john.madieu.xa@bp.renesas.com
2026-03-15PCI: rzg3s-host: Rework inbound window algorithm for supporting RZ/G3E SoCJohn Madieu
The existing inbound window configuration algorithm has two issues that prevent proper operation on RZ/G3E: 1. Over-mapping: Using roundup_pow_of_two() on the remaining region size can result in windows that extend beyond the intended memory region. 2. Alignment violation: Addresses are only aligned to 4K regardless of the actual window size. According to the RZ/G3S HW manual (Rev.1.10, section 34.6.6.7) and RZ/G3E HW manual (Rev.1.15, section 6.6.7.6), bit carry must not occur when adding AXI Window Base and AXI Window Mask registers. This effectively requires the base address to be aligned to the window size. RZ/G3E strictly enforces these constraints and requires precise window boundaries with properly aligned addresses. Rework the algorithm to properly handle arbitrary region sizes and alignment constraints by splitting non-power-of-2 regions into multiple windows. The new approach iteratively selects the largest power-of-2 size that: - Fits within the remaining region (__fls of remaining size) - Does not exceed the natural alignment of the CPU address (__ffs) - Does not exceed the natural alignment of the PCI address (__ffs) This ensures windows never over-map beyond the intended region and satisfies the hardware requirement that base address + mask must not cause bit carry, while maintaining the 4K * 2^N byte window size constraint. The reworked algorithm is required for RZ/G3E support and remains fully compatible with RZ/G3S. Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # RZ/V2N EVK Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20260306143423.19562-4-john.madieu.xa@bp.renesas.com
2026-03-15PCI: rzg3s-host: Reorder reset assertion during suspendJohn Madieu
Reorder the reset assertion sequence during suspend from power_resets -> cfg_resets to cfg_resets -> power_resets. This change ensures the suspend sequence follows the reverse order of the probe/init sequence, where power_resets are deasserted first followed by cfg_resets. Additionally, this ordering is required for RZ/G3E support where cfg resets are controlled through PCIe AXI registers (offset 0x310h). According to the RZ/G3E hardware manual (Rev.1.15, section 6.6.6.1.1 "Changing the Initial Values of the Registers"), AXI register access requires ARESETn to be de-asserted and the clock to be supplied. Since ARESETn is part of power_resets, cfg_resets must be asserted before power_resets, otherwise the AXI registers become inaccessible. Fixes: 7ef502fb35b2 ("PCI: Add Renesas RZ/G3S host controller driver") Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # RZ/V2N EVK Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20260306143423.19562-3-john.madieu.xa@bp.renesas.com
2026-03-15PCI: rzg3s-host: Fix reset handling in probe error pathJohn Madieu
Fix incorrect reset_control_bulk_deassert() call in the probe error path. When unwinding from a failed pci_host_probe(), the configuration resets should be asserted to restore the hardware to its initial state, not deasserted again. Fixes: 7ef502fb35b2 ("PCI: Add Renesas RZ/G3S host controller driver") Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> # RZ/V2N EVK Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20260306143423.19562-2-john.madieu.xa@bp.renesas.com
2026-03-12PCI: Use pr_warn_once() for ACS parameter parse failureRichard Cheng
When the ACS command line parameter cannot be parsed, the kernel skips applying the requested ACS override. This indicates an invalid boot parameter and should not be logged at informational level. Use pr_warn_once() so the message is surfaced as a warning while still avoiding repeated log spam during device enumeration. Signed-off-by: Richard Cheng <icheng@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Tushar Dave <tdave@nvidia.com> Link: https://patch.msgid.link/20260312115441.8168-1-icheng@nvidia.com
2026-03-09PCI: of: Reduce severity of missing of_root error messageJeremy Linton
Arm64 kernels are frequently built dual ACPI/DT, and then boot in ACPI mode. In this case, there won't be an of_root, except for rare DT described PCIe boards. As a result, users in the common case see this high priority worrying message, despite the machine working as expected. Reduce this message to pr_debug() to avoid unnecessary noise. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260309045930.21531-1-jeremy.linton@arm.com
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-23 04:38:05 +0000