laptop-kernel/drivers/pci, branch master

Merge tag 'pci-v7.3-fixes-6' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci

2026-10-17T00:51:21Z

Pull PCI fixes from Bjorn Helgaas: - Ignore Immediate Readiness on Samsung 990 PRO and 990 EVO Plus NVMe, which falsely advertise it; removal of unrelated delays in v7.2 caused post-FLR state restoration to fail, resulting in a VFIO passthrough regression (Alexander Gruhlke) -Don't treat ~0 as 'device is ready' in pci_dev_wait(); with RRS SV, a device may respond with RRS (resulting in data of 0x0001) or may not respond at all (typically resulting in ~0 data). A v6.12 change treated ~0 as 'ready', resulting in a regression with Intel and Samsung NVMe SSDs (Alexander Gruhlke) * tag 'pci-v7.3-fixes-6' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: PCI: Don't treat ~0 as ready in pci_dev_wait() with RRS SV PCI: Ignore Immediate Readiness on Samsung 990 PRO and 990 EVO Plus NVMe

PCI: Don't treat ~0 as ready in pci_dev_wait() with RRS SV

2026-10-16T17:11:15Z

With RRS Software Visibility, pci_dev_wait() considers a device ready as soon as reading the Vendor ID doesn't return the RRS value. Devices aren't required to respond with RRS while they aren't ready, so the read may return ~0 and pci_dev_wait() stops waiting too early. This was seen with Intel [8086:0a54] and Samsung [144d:a80c] NVMe SSDs. Also wait while the Vendor ID reads ~0. A VF's Vendor ID always reads ~0, so check its Command register instead, as is done without RRS SV. Fixes: d591f6804e7e ("PCI: Wait for device readiness with Configuration RRS") Link: https://lore.kernel.org/r/20250611101442.387378-1-hui.wang@canonical.com Suggested-by: Lukas Wunner Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Alexander Gruhlke Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Link: https://patch.msgid.link/20261011190145.23621-3-gruhlke@mailbox.org

PCI: Ignore Immediate Readiness on Samsung 990 PRO and 990 EVO Plus NVMe

2026-10-16T17:05:18Z

The Samsung 990 PRO [144d:a80c] advertises Immediate Readiness, so pcie_flr() doesn't wait after FLR, but the drive returns ~0 for up to 7 ms. Since commit 10baa9b4df40 ("PCI: Drop unnecessary retries when restoring BARs"), the config restore after FLR is lost, which breaks VFIO passthrough of the drive. Firmware 8B2QJXD7 responds right after FLR, but older firmware such as 1B2QJXD7 doesn't, and the firmware version isn't visible here. [bhelgaas: The Samsung 990 EVO Plus [144d:a80d] with 2B2QKXG7 firmware seems to have the same problem.] Ignore Immediate Readiness on these devices, so pcie_flr() waits. Fixes: 10baa9b4df40 ("PCI: Drop unnecessary retries when restoring BARs") Link: https://bbs.archlinux.org/viewtopic.php?id=314833 Link: https://bbs.archlinux.org/viewtopic.php?pid=2312085#p2312085 Suggested-by: Lukas Wunner Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Alexander Gruhlke [bhelgaas: squashed in Samsung 990 EVO Plus from https://lore.kernel.org/all/20261016102042.641801-1-gruhlke@mailbox.org] Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Link: https://patch.msgid.link/20261011190145.23621-2-gruhlke@mailbox.org Link: https://patch.msgid.link/20261016102042.641801-1-gruhlke@mailbox.org

Merge tag 'hyperv-fixes-signed-20261015' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux

2026-10-15T15:06:26Z

Pull Hyper-V fixes from Wei Liu: - Typo and comment fixes (Hemanth Selam, Jiangshan Yi) - Update maintainers list (Wei Liu, Long Li) - Two Hyper-V PCI driver fixes (Naman Jain, Sahil Chandna) - Small fixes for core Hyper-V code (Hardik Garg, Michael Kelley, Waiman Long) * tag 'hyperv-fixes-signed-20261015' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux: MAINTAINERS: drop KY from Hyper-V maintainers list PCI: hv: Warn when wait_for_response() waits indefinitely PCI: hv: Probe vPCI buses asynchronously MAINTAINERS: remove myself from the Hyper-V entries mshv_vtl: Check per-CPU register page before mmap tools/hv: fix typo "retrive" in comment Drivers: hv: vmbus: fix typo "substract" in comment Drivers: hv: Don't reset VMBus connection state on error/exit paths x86/hyperv: Avoid using per-cpu output page in hv_apicid_to_vp_index() x86/hyperv: Fix stale comments after stimer message mode removal Drivers: hv: Avoid infinite retry loop in init_vp_index()

Merge tag 'pci-v7.3-fixes-5' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci

2026-10-14T22:50:48Z

Pull PCI fixes from Bjorn Helgaas: - Leave ANFE masked on Apple T2 Secure Enclave, which fixes spontaneous poweroff regressions on MacBookPro16,1 and likely other models with the T2 caused by new Advisory Non-Fatal Error support (Jason Perlow) - Move dw-rockchip INTx IRQ setup from rockchip_pcie_host_init(), where it runs after every reset, to the rockchip_pcie_probe() path to avoid installing new IRQ handler (which causes INTx IRQs to be lost) and leaking an IRQ domain on every reset; fixes a regression added this cycle (Shawn Lin) * tag 'pci-v7.3-fixes-5' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: PCI: dw-rockchip: Move INTx IRQ setup to probe PCI/AER: Keep ANFE masked on Apple T2 Secure Enclave

PCI: dw-rockchip: Move INTx IRQ setup to probe

2026-10-12T22:01:54Z

Since commit b376b3ff9cb0 ("PCI: dw-rockchip: Implement .reset_root_port() and use for link down"), .reset_root_port() re-runs the host ops .init() callback to reprogram the Root Complex after a controller reset. That works for the register programming, but .init() is not re-entrant: it also creates the INTx IRQ domain and installs the chained INTx handler. Every Root Port reset therefore ends up with a second IRQ domain registered for the same fwnode: the previous one is leaked, as it is never removed, and worse, the INTx virqs of the downstream PCI devices were allocated in the previous IRQ domain and are never re-mapped, while the chained handler now looks up virqs in the new, empty domain. After a link down recovery, INTx interrupts are silently lost. Fix it by moving the of_irq_get_byname() lookup, the INTx IRQ domain creation and the chained handler installation out of .init() and into rockchip_pcie_configure_rc(), just before dw_pcie_host_init(). The lookup has to happen before the host is initialized, because dw_pcie_host_init() enumerates the bus and probes the downstream devices, and pci_assign_irq() maps their INTx interrupts at that point: if the domain does not exist yet, the mapping fails and the devices end up without a usable INTx. This also mirrors how the qcom driver requests its global IRQ, and leaves .init() with nothing but idempotent register programming, so both .reset_root_port() and dw_pcie_resume_noirq() can safely re-run it. Re-running of_irq_get_byname() on every resume is also gone. Fixes: b376b3ff9cb0 ("PCI: dw-rockchip: Implement .reset_root_port() and use for link down") Suggested-by: Niklas Cassel Signed-off-by: Shawn Lin Signed-off-by: Bjorn Helgaas Tested-by: Diederik de Haas # NanoPC-T6 Plus Reviewed-by: Niklas Cassel Link: https://patch.msgid.link/1790222793-77182-1-git-send-email-shawn.lin@rock-chips.com

PCI/AER: Keep ANFE masked on Apple T2 Secure Enclave

2026-10-12T20:11:35Z

Commit eddba19b8b5f ("PCI/AER: Support Advisory Non-Fatal Errors") unmasks Advisory Non-Fatal Errors on devices which support Role-Based Error Reporting. On a MacBookPro16,1, enabling ANFE on the Apple T2 Secure Enclave Processor [106b:1802] causes spontaneous power loss. Leave the Secure Enclave's ANFE mask unchanged. Set a per-device flag with an EARLY fixup, before pci_aer_init() can unmask ANFE; a FINAL fixup would run too late. Keep the advertised RBER capability and all other AER initialization and reporting unchanged. Other Apple T2 functions and non-Apple devices retain the existing ANFE behavior. Setting the flag repeatedly and skipping the ANFE unmask operation are idempotent. The underlying device or firmware failure is not understood. [bhelgaas: Aditya posted essentially the same patch soon after: https://lore.kernel.org/all/20261010172301.12764-1-aditya.garg@linux.dev] Fixes: eddba19b8b5f ("PCI/AER: Support Advisory Non-Fatal Errors") Reported-by: Jason Perlow Closes: https://lore.kernel.org/linux-pci/CABZrw2HcaOh3DHTJtxU5dXrb3Vg19scr6+qR-xe_+R7rME35_Q@mail.gmail.com/ Assisted-by: LLM Signed-off-by: Jason Perlow Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/CABZrw2H+3yt2Y7xiq6OyAWaJM7P9ox-2nJxoQuJMwoJHLgi+YQ@mail.gmail.com/

Merge tag 'pci-v7.3-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci

2026-10-09T23:30:04Z

Pull PCI fix from Bjorn Helgaas: "This fixes some GPU initialization regressions caused by eddba19b8b5f ("PCI/AER: Support Advisory Non-Fatal Errors"), which appeared in v7.3-rc1. That commit also caused a MacBookPro16,1 spontaneous power-off regression; I expect a fix for that next week" * tag 'pci-v7.3-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: PCI/AER: Skip error recovery on false alarms

PCI/AER: Skip error recovery on false alarms

2026-10-08T19:33:04Z

Alex is seeing a probe failure of the amdgpu driver after the Root Port above an AMD Navi10 GPU has been reset. The reset was performed to recover from a Firmware First reported Fatal Error. However all status registers in the Root Port's AER Extended Capability are blank, so apparently the platform firmware raised a false alarm. The issue is only occurring since commit eddba19b8b5f ("PCI/AER: Support Advisory Non-Fatal Errors"). It looks like enabling Advisory Non-Fatal Errors causes code paths to be exercised in platform firmware which were never validated before. Skip error recovery on false alarms, i.e. if no unmasked errors were actually signaled. Note that this will also skip recovery if both the Status and Mask registers are "all ones", as would be the case for inaccessible devices. However that seems justified because it would imply either a hot-unplug event or a Surprise Down Error further up in the hierarchy. Interfering with recovery from that seems uncalled for. Fixes: eddba19b8b5f ("PCI/AER: Support Advisory Non-Fatal Errors") Reported-by: Alex Deucher Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222095 Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Tested-by: Alex Deucher Acked-by: Alex Deucher Link: https://patch.msgid.link/0552ed277e40a288e0157af799257ee6ec722534.1791460615.git.lukas@wunner.de

Merge tag 'pci-v7.3-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci

2026-10-02T19:45:08Z

Pull PCI fix from Bjorn Helgaas: - Allow driver to use AtomicOps if already enabled by hypervisor; fixes regression when Root Port is not visible in a guest (Nikola Prica) * tag 'pci-v7.3-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: PCI: Accept AtomicOps already enabled by the hypervisor