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

PCI: j721e: Fix incorrect max_lanes for J7200

2026-09-14T11:29:17+00:00

[ Upstream commit 7147a7bfce47acd48c3738130bf0bd692bfd80de ] The PCIe Controller in the J7200 SoC supports a 4-lane configuration. However, j7200_pcie_rc_data and j7200_pcie_ep_data incorrectly set .max_lanes = 2, limiting operation to fewer lanes than the hardware supports. Set .max_lanes = 4 for both j7200_pcie_rc_data and j7200_pcie_ep_data to match the hardware capability. See J7200 Technical Reference Manual (SPRUIU1D), section 12.2.3.1.1 for further details: https://www.ti.com/lit/pdf/spruiu1d Fixes: 3ac7f14084f5 ("PCI: j721e: Add per platform maximum lane settings") Signed-off-by: Takuma Fujiwara Signed-off-by: Manivannan Sadhasivam Reviewed-by: Siddharth Vadapalli Link: https://patch.msgid.link/20260721155743.3347659-1-t-fujiwara1@ti.com Signed-off-by: Sasha Levin

PCI: xgene: Drop unnecessary OF node reference

2026-09-14T11:29:12+00:00

[ Upstream commit 4869db344e76c9adfb1d9654df442db5371fac71 ] xgene_pcie_probe() stores dev->of_node in port->node with of_node_get(), but the cached node is only used during probe by xgene_pcie_parse_map_dma_ranges(). The driver never releases the extra reference, so the node reference is leaked. There is no need for private OF node ownership here. Use the device's existing of_node directly in xgene_pcie_parse_map_dma_ranges() and remove the cached port->node pointer. Fixes: 5f6b6ccdbe1c ("PCI: xgene: Add APM X-Gene PCIe driver") Signed-off-by: Yuho Choi Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260630195234.1871951-1-dbgh9129@gmail.com Signed-off-by: Sasha Levin

PCI: xgene: Drop XGENE_PCIE_IP_VER_UNKN

2026-09-14T11:29:12+00:00

[ Upstream commit fddf72ed7b52c91da37fe5f1d4faed11251b714f ] XGENE_PCIE_IP_VER_UNKN is only refered to when probing for the original XGene PCIe implementation, and get immediately overridden if the device has the "apm,xgene-pcie" compatible string. Given that the only way to get there is by finding this very string in the DT, it is obvious that we will always overwrite the version with XGENE_PCIE_IP_VER_1. Drop the whole thing. Signed-off-by: Marc Zyngier Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Link: https://lore.kernel.org/r/20250708173404.1278635-5-maz@kernel.org Stable-dep-of: 4869db344e76 ("PCI: xgene: Drop unnecessary OF node reference") Signed-off-by: Sasha Levin

PCI: hv: Set irq_retrigger callback for the Hyper-V PCI MSI irqchip

2026-09-14T11:28:36+00:00

[ Upstream commit 86bdd16e8f390d51bae9e77a4bc4164ca2f580fe ] The Hyper-V vPCI MSI irqchip never installs an irq_retrigger() callback. On CPU hot-unplug fixup_irqs() migrates the interrupts which are affine to the outgoing CPU to a new target. If an interrupt still has its pending bit set in the outgoing CPU's IRR at that point, fixup_irqs() resends it on the new target through the irqchip's irq_retrigger() callback. As the Hyper-V PCI/MSI chip does not provide that callback, the pending interrupt is silently dropped, which can result in lost interrupts, stalls and "No irq handler for vector" messages during CPU hotplug. Install irq_chip_retrigger_hierarchy() as the irq_retrigger() callback for the Hyper-V PCI/MSI irqchip, so that a pending interrupt is resent on its new target CPU via the parent x86 vector domain. Fixes: 4daace0d8ce85 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs") Cc: stable@vger.kernel.org Suggested-by: Long Li Suggested-by: Thomas Gleixner Reviewed-by: Aditya Garg Reviewed-by: Shradha Gupta Signed-off-by: Naman Jain Reviewed-by: Michael Kelley Signed-off-by: Wei Liu Signed-off-by: Sasha Levin

PCI/proc: Warn on writes to kernel-exclusive config space regions

2026-09-14T11:28:29+00:00

commit 3359e044d597dd5344f17613e4be6b6e12067f60 upstream. Currently, a driver can claim a region of a device's config space as exclusive using pci_request_config_region_exclusive(), after which a write to that region originating from user space is expected to emit a warning and taint the kernel. The check is advisory only, as the write itself is still allowed to proceed. Since commit 278294798ac9 ("PCI: Allow drivers to request exclusive config regions"), the sysfs config space attribute performs this check in pci_write_config(), but the procfs interface was never updated. A write performed through /proc/bus/pci/BB/DD.F therefore bypasses the detection entirely, even though both interfaces offer the same level of access. Add the same resource_is_exclusive() check to proc_bus_pci_write(). Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260729075413.1215821-1-kwilczynski@kernel.org Signed-off-by: Greg Kroah-Hartman

PCI/proc: Use file_ns_capable() when checking config space read access

2026-09-14T11:28:29+00:00

commit f82f53e75eff382fc8f56b73279b54f7cf5a5c65 upstream. proc_bus_pci_read() decides how much of the config space is readable based on capable(CAP_SYS_ADMIN), which checks the credentials of the task calling read(), not the credentials of the process that opened the file. The sysfs equivalent, pci_read_config(), has checked the credentials of the opening process since commit de139a339395 ("pci: check caps from sysfs file open to read device dependent config space"), so a privileged process can open the config space file and pass the file descriptor to an unprivileged process (for example, a process running a KVM guest with an assigned device), which can then read the entire config space. The check was subsequently routed through the LSM framework in commit 47970b1b2aa6 ("pci: use security_capable() when checking capablities during config space read") and converted to the dedicated helper in commit ab0fa82b2df9 ("pci-sysfs: use proper file capability helper function"). Thus, the two interfaces check the same capability against different credentials. Checking the credentials of the task calling read() makes the outcome depend on who reads rather than who opened, so the restriction is bypassed whenever a more privileged process reads through the descriptor. Checking the credentials recorded in file->f_cred settles the decision at open() time and ties it to the file, where it cannot change with the caller. Use file_ns_capable() to check CAP_SYS_ADMIN against the credentials in effect when the file was opened, bringing the procfs interface in line with the sysfs behaviour. As a result, a file descriptor opened by a privileged process and passed to an unprivileged one now allows the entire config space to be read through procfs, matching sysfs. Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260720204145.1500105-1-kwilczynski@kernel.org Signed-off-by: Greg Kroah-Hartman

PCI/proc: Avoid spurious runtime PM wakeup on config space accesses

2026-09-14T11:28:29+00:00

commit 4ff664a81d729b37f2eb65de80a670abfb61c9a0 upstream. Currently, proc_bus_pci_read() and proc_bus_pci_write() do not return early for zero-length configuration space accesses at valid offsets. Such an access invokes pci_config_pm_runtime_get() and pci_config_pm_runtime_put() around transfer blocks that do nothing. This is a problem because pci_config_pm_runtime_get() synchronously resumes the upstream bridge through pm_runtime_get_sync(), and resumes the device itself through pm_runtime_resume() when it is in D3cold, only for the handler to return zero immediately afterwards. Such a spurious wakeup wastes power and adds needless resume latency. The sysfs core already returns early for in-range zero-length binary attribute accesses before pci_read_config() or pci_write_config() is invoked. In contrast, the VFS forwards zero-length requests to the procfs callbacks, where they continue into runtime PM handling. Return early from proc_bus_pci_read() and proc_bus_pci_write() when nbytes is zero, before any runtime PM involvement. The value returned to userspace at these offsets remains zero, so the change is not visible to userspace. Signed-off-by: Krzysztof Wilczyński [bhelgaas: order tags] Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260729075909.1219906-1-kwilczynski@kernel.org Signed-off-by: Greg Kroah-Hartman

PCI/MSI: Enable memory decoding before restoring MSI-X messages

2026-09-14T11:28:29+00:00

commit 231c7a57d19304beb0931e6cbe3a4929daf49747 upstream. The current MSI-X restoration path assumes the Command register Memory bit is enabled when writing MSI-X messages. But it's possible the last saved and restored state of a device may not have the Memory bit enabled, even if a device driver later enables Memory bit and MSI-X. Attempting to access Memory space without Memory bit enabled can lead to Unsupported Request (UR) from the device. Fix this by enabling Memory bit and restore it afterwards. Fixes: 41017f0cac92 ("[PATCH] PCI: MSI(X) save/restore for suspend/resume") Signed-off-by: Farhan Ali [bhelgaas: comment] Signed-off-by: Bjorn Helgaas Reviewed-by: Thomas Gleixner Reviewed-by: Niklas Schnelle Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260805165518.794-6-alifm@linux.ibm.com Signed-off-by: Greg Kroah-Hartman

PCI/sysfs: Avoid spurious runtime PM wakeup on config space accesses

2026-09-14T11:28:29+00:00

commit b14b2bab88d7099ab4447560cbe4b40945e5c069 upstream. Currently, the boundary checks in pci_read_config() and pci_write_config() reject only offsets beyond the effective configuration space size. An access at an offset exactly equal to that size passes the check, has its length clamped to zero, and then invokes pci_config_pm_runtime_get() and pci_config_pm_runtime_put() around transfer blocks that do nothing. This is a problem because pci_config_pm_runtime_get() synchronously resumes the upstream bridge through pm_runtime_get_sync() and resumes the device itself through pm_runtime_resume() when it is in D3cold, only for the handler to return zero immediately afterwards. Such a spurious wakeup wastes power and adds needless resume latency. The sysfs core already clamps accesses against the attribute size set through the bin_size() callback, which reports either 256 or 4096 bytes. As such, the affected accesses are reads at offset 64 (or 128 for CardBus devices) through files opened without CAP_SYS_ADMIN, and reads and writes at the exact configuration space size on devices where a quirk sets a non-standard size. Reject accesses at the boundary offset as well, so they return early before any runtime PM involvement, matching the procfs implementations in proc_bus_pci_read() and proc_bus_pci_write(). The value returned to userspace at these offsets remains zero, so the change is not visible to userspace. Signed-off-by: Krzysztof Wilczyński [bhelgaas: tweak commit log, order tags] Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260720204356.1501749-1-kwilczynski@kernel.org Signed-off-by: Greg Kroah-Hartman

PCI: Add ACS quirk for Pericom PI7C9X2G608 switches [12d8:2608]

2026-09-14T11:28:29+00:00

commit 062fb7f816439da6bf3860386889343482a66bd4 upstream. The Pericom PI7C9X2G608 6-port Gen2 PCIe switch is also affected by the PI7C9X2G errata per the errata document: E2: ACS P2P Request Redirect Is Not Functional Apply the same quirk to this PCI ID as well to apply the workaround required if using ACS. Fixes: acd61ffb2f16 ("PCI: Add ACS quirk for Pericom PI7C9X2G switches") Signed-off-by: Tim Harvey Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260720215718.2139510-1-tharvey@gateworks.com Signed-off-by: Greg Kroah-Hartman