linux-stable.git/drivers/pci, branch linux-5.10.y

Revert "PCI: Enable ACS after configuring IOMMU for OF platforms"

2026-04-18T08:31:17+00:00

This reverts commit 573497f350b3cdb526c8c38955ddd287c5d4cc53 which is
commit c41e2fb67e26b04d919257875fa954aa5f6e392e upstream.

The original commit attempted to enable ACS in pci_dma_configure() prior
to IOMMU group assignment in iommu_init_device() to fix the ACS enablement
issue for OF platforms. But that assumption doesn't hold true for kernel
versions prior to v6.15, because on these older kernels,
pci_dma_configure() is called *after* iommu_init_device(). So the IOMMU
groups are already created before the ACS gets enabled. This causes the
devices that should have been split into separate groups by ACS, getting
merged into one group, thereby breaking the IOMMU isolation as reported on
the AMD machines.

So revert the offending commit to restore the IOMMU group assignment on
those affected machines. It should be noted that ACS has never really
worked on kernel versions prior to v6.15, so the revert doesn't make any
difference for OF platforms.

Reported-by: John Hancock 
Reported-by: bjorn.forsman@gmail.com
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221234
Fixes: b20b659c2c6a ("PCI: Enable ACS after configuring IOMMU for OF platforms")
Cc: Linux kernel regressions list 
Link: https://lore.kernel.org/regressions/2c30f181-ffc6-4d63-a64e-763cf4528f48@leemhuis.info
Signed-off-by: Manivannan Sadhasivam 
Signed-off-by: Greg Kroah-Hartman

PCI: Fix pci_slot_trylock() error handling

2026-03-04T12:20:22+00:00

[ Upstream commit 9368d1ee62829b08aa31836b3ca003803caf0b72 ]

Commit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()")
delegates the bridge device's pci_dev_trylock() to pci_bus_trylock() in
pci_slot_trylock(), but it forgets to remove the corresponding
pci_dev_unlock() when pci_bus_trylock() fails.

Before a4e772898f8b, the code did:

  if (!pci_dev_trylock(dev)) /* <- lock bridge device */
    goto unlock;
  if (dev->subordinate) {
    if (!pci_bus_trylock(dev->subordinate)) {
      pci_dev_unlock(dev);   /* <- unlock bridge device */
      goto unlock;
    }
  }

After a4e772898f8b the bridge-device lock is no longer taken, but the
pci_dev_unlock(dev) on the failure path was left in place, leading to the
bug.

This yields one of two errors:

  1. A warning that the lock is being unlocked when no one holds it.
  2. An incorrect unlock of a lock that belongs to another thread.

Fix it by removing the now-redundant pci_dev_unlock(dev) on the failure
path.

[Same patch later posted by Keith at
https://patch.msgid.link/20260116184150.3013258-1-kbusch@meta.com]

Fixes: a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()")
Signed-off-by: Jinhui Guo 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Dan Williams 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20251212145528.2555-1-guojinhui.liam@bytedance.com
Signed-off-by: Sasha Levin

PCI/IOV: Fix race between SR-IOV enable/disable and hotplug

2026-03-04T12:20:21+00:00

[ Upstream commit a5338e365c4559d7b4d7356116b0eb95b12e08d5 ]

Commit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when
enabling/disabling SR-IOV") tried to fix a race between the VF removal
inside sriov_del_vfs() and concurrent hot unplug by taking the PCI
rescan/remove lock in sriov_del_vfs(). Similarly the PCI rescan/remove lock
was also taken in sriov_add_vfs() to protect addition of VFs.

This approach however causes deadlock on trying to remove PFs with SR-IOV
enabled because PFs disable SR-IOV during removal and this removal happens
under the PCI rescan/remove lock. So the original fix had to be reverted.

Instead of taking the PCI rescan/remove lock in sriov_add_vfs() and
sriov_del_vfs(), fix the race that occurs with SR-IOV enable and disable vs
hotplug higher up in the callchain by taking the lock in
sriov_numvfs_store() before calling into the driver's sriov_configure()
callback.

Fixes: 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV")
Reported-by: Benjamin Block 
Signed-off-by: Niklas Schnelle 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Benjamin Block 
Reviewed-by: Gerd Bayer 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20251216-revert_sriov_lock-v3-2-dac4925a7621@linux.ibm.com
Signed-off-by: Sasha Levin

Revert "PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV"

2026-03-04T12:20:21+00:00

[ Upstream commit 2fa119c0e5e528453ebae9e70740e8d2d8c0ed5a ]

This reverts commit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking
when enabling/disabling SR-IOV"), which causes a deadlock by recursively
taking pci_rescan_remove_lock when sriov_del_vfs() is called as part of
pci_stop_and_remove_bus_device(). For example with the following sequence
of commands:

  $ echo  > /sys/bus/pci/devices//sriov_numvfs
  $ echo 1 > /sys/bus/pci/devices//remove

A trimmed trace of the deadlock on a mlx5 device is as below:

  zsh/5715 is trying to acquire lock:
  000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: sriov_disable+0x34/0x140

  but task is already holding lock:
  000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_stop_and_remove_bus_device_locked+0x24/0x80
  ...
  Call Trace:
   [<00000259778c4f90>] dump_stack_lvl+0xc0/0x110
   [<00000259779c844e>] print_deadlock_bug+0x31e/0x330
   [<00000259779c1908>] __lock_acquire+0x16c8/0x32f0
   [<00000259779bffac>] lock_acquire+0x14c/0x350
   [<00000259789643a6>] __mutex_lock_common+0xe6/0x1520
   [<000002597896413c>] mutex_lock_nested+0x3c/0x50
   [<00000259784a07e4>] sriov_disable+0x34/0x140
   [<00000258f7d6dd80>] mlx5_sriov_disable+0x50/0x80 [mlx5_core]
   [<00000258f7d5745e>] remove_one+0x5e/0xf0 [mlx5_core]
   [<00000259784857fc>] pci_device_remove+0x3c/0xa0
   [<000002597851012e>] device_release_driver_internal+0x18e/0x280
   [<000002597847ae22>] pci_stop_bus_device+0x82/0xa0
   [<000002597847afce>] pci_stop_and_remove_bus_device_locked+0x5e/0x80
   [<00000259784972c2>] remove_store+0x72/0x90
   [<0000025977e6661a>] kernfs_fop_write_iter+0x15a/0x200
   [<0000025977d7241c>] vfs_write+0x24c/0x300
   [<0000025977d72696>] ksys_write+0x86/0x110
   [<000002597895b61c>] __do_syscall+0x14c/0x400
   [<000002597896e0ee>] system_call+0x6e/0x90

This alone is not a complete fix as it restores the issue the cited commit
tried to solve. A new fix will be provided as a follow on.

Fixes: 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV")
Reported-by: Benjamin Block 
Signed-off-by: Niklas Schnelle 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Benjamin Block 
Acked-by: Gerd Bayer 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20251216-revert_sriov_lock-v3-1-dac4925a7621@linux.ibm.com
Signed-off-by: Sasha Levin

PCI: Mark Nvidia GB10 to avoid bus reset

2026-03-04T12:20:04+00:00

[ Upstream commit c81a2ce6b6a844d1a57d2a69833a9d0f00403f00 ]

After asserting Secondary Bus Reset to downstream devices via a GB10 Root
Port, the link may not retrain correctly, e.g., the link may retrain with a
lower lane count or config accesses to downstream devices may fail.

Prevent use of Secondary Bus Reset for devices below GB10.

Signed-off-by: Johnny-CC Chang 
[bhelgaas: drop pci_ids.h update (only used once), update commit log]
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Manivannan Sadhasivam 
Link: https://patch.msgid.link/20251113084441.2124737-1-Johnny-CC.Chang@mediatek.com
Signed-off-by: Sasha Levin

PCI: Add ACS quirk for Qualcomm Hamoa & Glymur

2026-03-04T12:20:04+00:00

[ Upstream commit 44d2f70b1fd72c339c72983fcffa181beae3e113 ]

The Qualcomm Hamoa & Glymur Root Ports don't advertise an ACS capability,
but they do provide ACS-like features to disable peer transactions and
validate bus numbers in requests.

Add an ACS quirk for Hamoa & Glymur.

Signed-off-by: Krishna Chaitanya Chundru 
Signed-off-by: Bjorn Helgaas 
Link: https://patch.msgid.link/20260109-acs_quirk-v1-1-82adf95a89ae@oss.qualcomm.com
Signed-off-by: Sasha Levin

PCI: Enable ACS after configuring IOMMU for OF platforms

2026-03-04T12:20:04+00:00

[ Upstream commit c41e2fb67e26b04d919257875fa954aa5f6e392e ]

Platform, ACPI, or IOMMU drivers call pci_request_acs(), which sets
'pci_acs_enable' to request that ACS be enabled for any devices enumerated
in the future.

OF platforms called pci_enable_acs() for the first device before
of_iommu_configure() called pci_request_acs(), so ACS was never enabled for
that device (typically a Root Port).

Call pci_enable_acs() later, from pci_dma_configure(), after
of_dma_configure() has had a chance to call pci_request_acs().

Here's the call path, showing the move of pci_enable_acs() from
pci_acs_init() to pci_dma_configure(), where it always happens after
pci_request_acs():

    pci_device_add
      pci_init_capabilities
        pci_acs_init
 -        pci_enable_acs
 -          if (pci_acs_enable)                <-- previous test
 -            ...
      device_add
        bus_notify(BUS_NOTIFY_ADD_DEVICE)
          iommu_bus_notifier
            iommu_probe_device
              iommu_init_device
                dev->bus->dma_configure
                  pci_dma_configure            # pci_bus_type.dma_configure
                    of_dma_configure
                      of_iommu_configure
                        pci_request_acs
                          pci_acs_enable = 1   <-- set
 +                  pci_enable_acs
 +                    if (pci_acs_enable)      <-- new test
 +                      ...
        bus_probe_device
          device_initial_probe
            ...
              really_probe
                dev->bus->dma_configure
                  pci_dma_configure            # pci_bus_type.dma_configure
                    ...
                      pci_enable_acs

Note that we will now call pci_enable_acs() twice for every device, first
from the iommu_probe_device() path and again from the really_probe() path.
Presumably that's not an issue since we also call dev->bus->dma_configure()
twice.

For the ACPI platforms, pci_request_acs() is called during ACPI
initialization time itself, independent of the IOMMU framework.

Signed-off-by: Manivannan Sadhasivam 
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas 
Tested-by: Marek Szyprowski 
Tested-by: Naresh Kamboju 
Link: https://patch.msgid.link/20260102-pci_acs-v3-1-72280b94d288@oss.qualcomm.com
Signed-off-by: Sasha Levin

PCI: Fix pci_slot_lock () device locking

2026-03-04T12:20:04+00:00

[ Upstream commit 1f5e57c622b4dc9b8e7d291d560138d92cfbe5bf ]

Like pci_bus_lock(), pci_slot_lock() needs to lock the bridge device to
prevent warnings like:

  pcieport 0000:e2:05.0: unlocked secondary bus reset via: pciehp_reset_slot+0x55/0xa0

Take and release the lock for the bridge providing the slot for the
lock/trylock and unlock routines.

Signed-off-by: Keith Busch 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Dan Williams 
Link: https://patch.msgid.link/20260130165953.751063-3-kbusch@meta.com
Signed-off-by: Sasha Levin

PCI: Mark ASM1164 SATA controller to avoid bus reset

2026-03-04T12:20:04+00:00

[ Upstream commit beb2f81792a8a619e5122b6b24a374861309c54b ]

User forums report issues when assigning ASM1164 SATA controllers to VMs,
especially in configurations with multiple controllers.  Logs show the
device fails to retrain after bus reset.  Reports suggest this is an issue
across multiple platforms.  The device indicates support for PM reset,
therefore the device still has a viable function level reset mechanism.
The reporting user confirms the device is well behaved in this use case
with bus reset disabled.

Reported-by: Patrick Bianchi 
Link: https://forum.proxmox.com/threads/problems-with-pcie-passthrough-with-two-identical-devices.149003/
Signed-off-by: Alex Williamson 
Signed-off-by: Bjorn Helgaas 
Link: https://patch.msgid.link/20260109000211.398300-1-alex.williamson@nvidia.com
Signed-off-by: Sasha Levin

PCI: Initialize RCB from pci_configure_device()

2026-03-04T12:19:35+00:00

[ Upstream commit 1a6845aaa6de81f95959b380b45de8f10d6a8502 ]

Commit e42010d8207f ("PCI: Set Read Completion Boundary to 128 iff Root
Port supports it (_HPX)") worked around a bogus _HPX type 2 record, which
caused program_hpx_type2() to set the RCB in an endpoint even though the
Root Port did not have the RCB bit set.

e42010d8207f fixed that by setting the RCB in the endpoint only when it was
set in the Root Port.

In retrospect, program_hpx_type2() is intended for AER-related settings,
and the RCB should be configured elsewhere so it doesn't depend on the
presence or contents of an _HPX record.

Explicitly program the RCB from pci_configure_device() so it matches the
Root Port's RCB.  The Root Port may not be visible to virtualized guests;
in that case, leave RCB alone.

Fixes: e42010d8207f ("PCI: Set Read Completion Boundary to 128 iff Root Port supports it (_HPX)")
Signed-off-by: Håkon Bugge 
Signed-off-by: Bjorn Helgaas 
Link: https://patch.msgid.link/20260129175237.727059-2-haakon.bugge@oracle.com
Signed-off-by: Sasha Levin