kernel/git/stable/linux-stable.git/drivers/pci, branch linux-6.17.y

PCI: dwc: Fix wrong PORT_LOGIC_LTSSM_STATE_MASK definition

2025-12-18T12:59:55+00:00

[ Upstream commit bcc9a4a0bca3aee4303fa4a20302e57b24ac8f68 ] As per DesignWare Cores PCI Express Controller Databook, section 5.50, SII: Debug Signals, cxpl_debug_info[63:0]: [5:0] smlh_ltssm_state: LTSSM current state. Encoding is same as the dedicated smlh_ltssm_state output. The mask should be 6 bits, from 0 to 5. Hence, fix the mask definition. Fixes: 23fe5bd4be90 ("PCI: keystone: Cleanup ks_pcie_link_up()") Signed-off-by: Shawn Lin [mani: reworded description] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/1763122140-203068-1-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Sasha Levin

PCI: Prevent resource tree corruption when BAR resize fails

2025-12-18T12:59:43+00:00

[ Upstream commit 91c4c89db41499eea1b29c56655f79c3bae66e93 ] pbus_reassign_bridge_resources() saves bridge windows into the saved list before attempting to adjust resource assignments to perform a BAR resize operation. If resource adjustments cannot be completed fully, rollback is attempted by restoring the resource from the saved list. The rollback, however, does not check whether the resources it restores were assigned by the partial resize attempt. If restore changes addresses of the resource, it can result in corrupting the resource tree. An example of a corrupted resource tree with overlapping addresses: 6200000000000-6203fbfffffff : pciex@620c3c0000000 6200000000000-6203fbff0ffff : PCI Bus 0030:01 6200020000000-62000207fffff : 0030:01:00.0 6200000000000-6203fbff0ffff : PCI Bus 0030:02 A resource that are assigned into the resource tree must remain unchanged. Thus, release such a resource before attempting to restore and claim it back. For simplicity, always do the release and claim back for the resource even in the cases where it is restored to the same address range. Note: this fix may "break" some cases where devices "worked" because the resource tree corruption allowed address space double counting to fit more resource than what can now be assigned without double counting. The upcoming changes to BAR resizing should address those scenarios (to the extent possible). Fixes: 8bb705e3e79d ("PCI: Add pci_resize_resource() for resizing BARs") Reported-by: Simon Richter Link: https://lore.kernel.org/linux-pci/67840a16-99b4-4d8c-9b5c-4721ab0970a2@hogyros.de/ Reported-by: Alex Bennée Link: https://lore.kernel.org/linux-pci/874irqop6b.fsf@draig.linaro.org/ Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Tested-by: Alex Bennée # AVA, AMD GPU Link: https://patch.msgid.link/20251113162628.5946-2-ilpo.jarvinen@linux.intel.com Signed-off-by: Sasha Levin

PCI: keystone: Exit ks_pcie_probe() for invalid mode

2025-12-18T12:59:41+00:00

[ Upstream commit 95d9c3f0e4546eaec0977f3b387549a8463cd49f ] Commit under Fixes introduced support for PCIe EP mode on AM654x platforms. When the mode happens to be either "DW_PCIE_RC_TYPE" or "DW_PCIE_EP_TYPE", the PCIe Controller is configured accordingly. However, when the mode is neither of them, an error message is displayed, but the driver probe succeeds. Since this "invalid" mode is not associated with a functional PCIe Controller, the probe should fail. Fix the behavior by exiting "ks_pcie_probe()" with the return value of "-EINVAL" in addition to displaying the existing error message when the mode is invalid. Fixes: 23284ad677a9 ("PCI: keystone: Add support for PCIe EP in AM654x Platforms") Signed-off-by: Siddharth Vadapalli Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20251029080547.1253757-4-s-vadapalli@ti.com Signed-off-by: Sasha Levin

PCI: endpoint: pci-epf-test: Fix sleeping function being called from atomic context

2025-12-18T12:59:23+00:00

[ Upstream commit 25423cda145f9ed6ee4a72d9f2603ac2a4685e74 ] When Root Complex (RC) triggers a Doorbell interrupt to Endpoint (EP), it triggers the below warning in the EP: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:271 Call trace: __might_resched+0x130/0x158 __might_sleep+0x70/0x88 mutex_lock+0x2c/0x80 pci_epc_get_msi+0x78/0xd8 pci_epf_test_raise_irq.isra.0+0x74/0x138 pci_epf_test_doorbell_handler+0x34/0x50 The BUG arises because the EP's pci_epf_test_doorbell_handler() which is running in the hard IRQ context is making an indirect call to pci_epc_get_msi(), which uses mutex inside. To fix the issue, convert the hard IRQ handler to a threaded IRQ handler to allow it to call functions that can sleep during bottom half execution. Also, register the threaded IRQ handler with IRQF_ONESHOT to keep the interrupt line disabled until the threaded IRQ handler completes execution. Fixes: eff0c286aa91 ("PCI: endpoint: pci-epf-test: Add doorbell test support") Signed-off-by: Bhanu Seshu Kumar Valluri [mani: reworded description a bit] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Niklas Cassel Reviewed-by: Frank Li Link: https://patch.msgid.link/20251014024109.42287-1-bhanuseshukumar@gmail.com Signed-off-by: Sasha Levin

PCI: rcar-gen2: Drop ARM dependency from PCI_RCAR_GEN2

2025-12-18T12:59:21+00:00

[ Upstream commit d312742f686582e6457070bcfd24bee8acfdf213 ] Since the reliance on ARM-specific struct pci_sys_data was removed, this driver can be compile-tested on other architectures. While at it, make the help text a bit more generic, as some members of the R-Car Gen2 family have a different number of internal PCI controllers. Fixes: 4a957563fe0231e0 ("PCI: rcar-gen2: Convert to use modern host bridge probe functions") Suggested-by: Ilpo Jarvinen Signed-off-by: Geert Uytterhoeven Signed-off-by: Manivannan Sadhasivam [bhelgaas: add rcar-gen2 to subject] Signed-off-by: Bjorn Helgaas Reviewed-by: Ilpo Järvinen Link: https://patch.msgid.link/00f75d6732eacce93f04ffaeedc415d2db714cd6.1759480426.git.geert+renesas@glider.be Signed-off-by: Sasha Levin

PCI/PM: Skip resuming to D0 if device is disconnected

2025-11-13T20:37:28+00:00

[ Upstream commit 299fad4133677b845ce962f78c9cf75bded63f61 ] When a device is surprise-removed (e.g., due to a dock unplug), the PCI core unconfigures all downstream devices and sets their error state to pci_channel_io_perm_failure. This marks them as disconnected via pci_dev_is_disconnected(). During device removal, the runtime PM framework may attempt to resume the device to D0 via pm_runtime_get_sync(), which calls into pci_power_up(). Since the device is already disconnected, this resume attempt is unnecessary and results in a predictable errors like this, typically when undocking from a TBT3 or USB4 dock with PCIe tunneling: pci 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible Avoid powering up disconnected devices by checking their status early in pci_power_up() and returning -EIO. Suggested-by: Lukas Wunner Signed-off-by: Mario Limonciello [bhelgaas: add typical message] Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Reviewed-by: Ilpo Järvinen Acked-by: Rafael J. Wysocki Link: https://patch.msgid.link/20250909031916.4143121-1-superm1@kernel.org Signed-off-by: Sasha Levin

PCI: cadence: Check for the existence of cdns_pcie::ops before using it

2025-11-13T20:37:28+00:00

[ Upstream commit 49a6c160ad4812476f8ae1a8f4ed6d15adfa6c09 ] cdns_pcie::ops might not be populated by all the Cadence glue drivers. This is going to be true for the upcoming Sophgo platform which doesn't set the ops. Hence, add a check to prevent NULL pointer dereference. Signed-off-by: Chen Wang [mani: reworded subject and description] Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/35182ee1d972dfcd093a964e11205efcebbdc044.1757643388.git.unicorn_wang@outlook.com Signed-off-by: Sasha Levin

PCI: dwc: Verify the single eDMA IRQ in dw_pcie_edma_irq_verify()

2025-11-13T20:37:21+00:00

[ Upstream commit 09fefb24ed5e15f3b112f6c04b21a90ea23eaf8b ] dw_pcie_edma_irq_verify() is supposed to verify the eDMA IRQs in devicetree by fetching them using either 'dma' or 'dmaX' IRQ names. Former is used when the platform uses a single IRQ for all eDMA channels and latter is used when the platform uses separate IRQ per channel. But currently, dw_pcie_edma_irq_verify() bails out early if edma::nr_irqs is 1, i.e., when a single IRQ is used. This gives an impression that the driver could work with any single IRQ in devicetree, not necessarily with name 'dma'. But dw_pcie_edma_irq_vector(), which actually requests the IRQ, does require the single IRQ to be named as 'dma'. So this creates inconsistency between dw_pcie_edma_irq_verify() and dw_pcie_edma_irq_vector(). Thus, to fix this inconsistency, make sure dw_pcie_edma_irq_verify() also verifies the single IRQ name by removing the bail out code. Signed-off-by: Niklas Cassel [mani: reworded subject and description] Signed-off-by: Manivannan Sadhasivam [bhelgaas: fix typos] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20250908165914.547002-3-cassel@kernel.org Signed-off-by: Sasha Levin

PCI/AER: Fix NULL pointer access by aer_info

2025-11-13T20:37:20+00:00

[ Upstream commit 0a27bdb14b028fed30a10cec2f945c38cb5ca4fa ] The kzalloc(GFP_KERNEL) may return NULL, so all accesses to aer_info->xxx will result in kernel panic. Fix it. Signed-off-by: Vernon Yang Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20250904182527.67371-1-vernon2gm@gmail.com Signed-off-by: Sasha Levin

PCI: endpoint: pci-epf-test: Limit PCIe BAR size for fixed BARs

2025-11-13T20:37:16+00:00

[ Upstream commit d5f6bd3ee3f5048f272182dc91675c082773999e ] Currently, the test allocates BAR sizes according to fixed table bar_size. This does not work with controllers which have fixed size BARs that are smaller than the requested BAR size. One such controller is Renesas R-Car V4H PCIe controller, which has BAR4 size limited to 256 bytes, which is much less than one of the BAR size, 131072 currently requested by this test. A lot of controllers drivers in-tree have fixed size BARs, and they do work perfectly fine, but it is only because their fixed size is larger than the size requested by pci-epf-test.c Adjust the test such that in case a fixed size BAR is detected, the fixed BAR size is used, as that is the only possible option. This helps with test failures reported as follows: pci_epf_test pci_epf_test.0: requested BAR size is larger than fixed size pci_epf_test pci_epf_test.0: Failed to allocate space for BAR4 Signed-off-by: Marek Vasut [mani: reworded description] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Cassel Link: https://patch.msgid.link/20250905184240.144431-1-marek.vasut+renesas@mailbox.org Signed-off-by: Sasha Levin