kernel/git/stable/linux-stable.git/drivers/pci, branch linux-rolling-stable

PCI: Allow per function PCI slots to fix slot reset on s390

2026-09-11T09:51:25+00:00

[ Upstream commit dcc5bec09e23bbc4f9de055a11fce9937244f2c8 ] On s390 systems, which use a machine level hypervisor, PCI devices are always accessed through a form of PCI pass-through which fundamentally operates on a per PCI function granularity. This is also reflected in the s390 PCI hotplug driver which creates hotplug slots for individual PCI functions. Its reset_slot() function, which is a wrapper for zpci_hot_reset_device(), thus also resets individual functions. Currently, the pci_create_slot() assigns the same pci_slot object to multifunction devices. This approach worked fine on s390 systems that only exposed virtual functions as individual PCI domains to the operating system. Since commit 44510d6fa0c0 ("s390/pci: Handling multifunctions") s390 supports exposing the topology of multifunction PCI devices by grouping them in a shared PCI domain. This creates a problem when resetting a function through the hotplug driver's slot_reset() interface. When attempting to reset a function through the hotplug driver, the shared slot assignment causes the wrong function to be reset instead of the intended one. It also leaks memory as we do create a pci_slot object for the function, but don't correctly free it in pci_slot_release(). Add a flag for struct pci_slot to allow per function PCI slots for functions managed through a hypervisor, which exposes individual PCI functions while retaining the topology. Since we can use all 8 bits for slot 'number' (for ARI devices), change slot 'number' u16 to account for special values PCI_SLOT_PLACEHOLDER and PCI_SLOT_ALL_DEVICES. Fixes: 44510d6fa0c0 ("s390/pci: Handling multifunctions") Suggested-by: Niklas Schnelle Signed-off-by: Farhan Ali Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Schnelle Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260805165518.794-3-alifm@linux.ibm.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

PCI: Introduce PCI_SLOT_PLACEHOLDER constant for slot_nr placeholder value

2026-09-11T09:51:25+00:00

[ Upstream commit c243e6c470c4695965cc8287767925bc1d9a7867 ] Introduce a constant for placeholder value and update the kerneldoc for pci_create_slot() to reference PCI_SLOT_PLACEHOLDER instead of -1 throughout. No functional change. Suggested-by: Bjorn Helgaas Signed-off-by: Farhan Ali Signed-off-by: Bjorn Helgaas Cc: Madhavan Srinivasan Cc: Tyrel Datwyler Cc: linuxppc-dev@lists.ozlabs.org Link: https://patch.msgid.link/20260805165518.794-2-alifm@linux.ibm.com Stable-dep-of: dcc5bec09e23 ("PCI: Allow per function PCI slots to fix slot reset on s390") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

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

2026-09-07T15:37:13+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-07T15:37:13+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-07T15:37:13+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-07T15:37:13+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/ASPM: Avoid L0s for Realtek RTS525A

2026-09-07T15:37:13+00:00

commit ec3d987fcaf92516d13ee18c305c82281557046d upstream. The Realtek RTS525A PCIe card reader reports an AER Correctable Replay Timer Timeout storm when ASPM L0s is enabled on its link. On an affected HP ZBook Power 16 inch G11, the Root Port received tens of millions of AER interrupts from the RTS525A even when the rtsx_pci driver was blacklisted and the endpoint was not enabled by a driver. For example: pcieport 0000:00:1c.6: AER: Multiple Correctable error message received from 0000:58:00.0 rtsx_pci 0000:58:00.0: PCIe Bus Error: severity=Correctable, type=Data Link Layer, (Transmitter ID) rtsx_pci 0000:58:00.0: device [10ec:525a] error status/mask=00001000/00006000 rtsx_pci 0000:58:00.0: [12] Timeout pcieport 0000:00:1c.6: AER: Correctable error message received from 0000:58:00.0 Testing with OS-native AER control showed that disabling only L0s on the RTS525A link stops new AER interrupt and counter growth while leaving L1 enabled. Disabling L1, L1 substates, or Clock PM alone did not stop the storm. Prevent the broken L0s configuration by removing L0s from the RTS525A advertised ASPM capability. This avoids enabling the non-working ASPM state instead of masking the resulting AER Replay Timer Timeout reports. Signed-off-by: Max Lee Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Reviewed-by: Manivannan Sadhasivam Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260707021527.639611-1-max.lee@canonical.com Signed-off-by: Greg Kroah-Hartman

PCI/AER: Fix mapping of errors to agent & layer

2026-09-07T15:37:13+00:00

commit 1017599755b8b578a671f8fac175bce56189d01c upstream. PCIe r7.0 sec 6.2.7 documents the agent and layer of each Correctable and Uncorrectable Error. Based on this spec section, the AER driver maps detected errors to an agent and layer using a set of macros and logs them. Most errors listed in sec 6.2.7 map to the "Receiver" agent and "Transaction Layer", so the macros use these as defaults unless an error maps to something else. However the macros have not been amended since their introduction in 2006 with commit 6c2b374d7485 ("PCI-Express AER implemetation: AER core and aerdriver"). They are still based on PCIe r1.0 sec 7.2.5 (renumbered to 6.2.7 in PCIe r1.1 and newer). Amend the macros to map errors introduced since then to the appropriate agent and layer. PCIe r2.1 introduced a new "Component" agent and "General" layer for Internal Errors and Header Log Overflow. Add them to the macros. Unsupported Request is currently mapped to the "Requester" agent, even though it is reported by the "Receiver". Fix the incorrect mapping. Sec 6.2.7 neglects to list an agent for Data Link Protocol Error and Surprise Down Error. Map the latter to "Component" because PCIe r7.0 sec 3.2.1 states that the error is "associated with the detecting Port". Map the former to "Receiver" because every occurrence of Data Link Protocol Error in the spec refers to it being logged in the Receiving Port. I have had these errata reported to the PCI-SIG Protocol Working Group. (There's also a layout erratum in the REPLAY_NUM Rollover row wherein columns are shifted to the left, but that's already corrected in the PCIe r7.1 draft as of 2026-04-07.) Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/aec4820a75e949b332585a08cb1808fda7f40ea4.1784905909.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman

PCI/AER: Emit TLP Log only for unmasked errors

2026-09-07T15:37:13+00:00

commit a8bf2dd750de7d682fdaa2127f4e3217ce9c4a82 upstream. Per PCIe r7.0 sec 6.2.5, the prefix and header of an offending TLP is only recorded for unmasked Uncorrectable Errors. Yet when the AER driver determines whether a prefix and header has been logged, it does not take the Uncorrectable Error Mask Register into account. Fix it. Fixes: 6c2b374d7485 ("PCI-Express AER implemetation: AER core and aerdriver") Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org # v2.6.19+ Link: https://patch.msgid.link/2e712b96ba5bfc729d78bfc23f7fb7d285aa3d6d.1784905909.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman

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

2026-09-07T15:37:13+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