[PATCH AUTOSEL 6.19-5.10] PCI: Mark ASM1164 SATA controller to avoid bus reset

[Sasha Levin <sashal@kernel.org>]

From: Alex Williamson <alex.williamson@nvidia.com>

[ 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 <patrick.w.bianchi@gmail.com>
Link: https://forum.proxmox.com/threads/problems-with-pcie-passthrough-with-two-identical-devices.149003/
Signed-off-by: Alex Williamson <alex.williamson@nvidia.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260109000211.398300-1-alex.williamson@nvidia.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of PCI: Mark ASM1164 SATA controller to avoid bus reset

### Commit Message Analysis

The commit adds a PCI quirk for the ASMedia ASM1164 SATA controller to
disable bus reset. The problem is clearly described: when assigning
these controllers to VMs via VFIO/PCI passthrough, the device fails to
retrain after a bus reset. This is particularly problematic in
configurations with multiple controllers. The device still supports PM
reset (power management reset) as an alternative reset mechanism, so
disabling bus reset doesn't leave the device without any reset
capability.

Key indicators:
- **Reported-by** tag from a real user (Patrick Bianchi)
- **Link** to a Proxmox forum thread documenting the issue across
  multiple platforms
- Author is Alex Williamson, the VFIO maintainer at NVIDIA — a highly
  authoritative source for PCI passthrough quirks
- Reviewed/committed by Bjorn Helgaas, the PCI subsystem maintainer

### Code Change Analysis

The change is a single `DECLARE_PCI_FIXUP_HEADER` macro invocation with
an accompanying comment:

```c
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ASMEDIA, 0x1164,
quirk_no_bus_reset);
```

This calls the existing `quirk_no_bus_reset()` function, which sets the
`PCI_DEV_FLAGS_NO_BUS_RESET` flag on the device. The function already
exists and is used by multiple other devices (Atheros, Cavium, TI
KeyStone) in the same file. This is purely a data addition — matching a
specific vendor:device ID pair to an existing quirk handler.

### Classification: Hardware Quirk

This falls squarely into the **PCI Quirks** exception category for
stable backporting:

- It's a hardware-specific workaround for a broken/buggy device
- It uses an existing, well-tested mechanism (`quirk_no_bus_reset`)
- It only affects the specific ASMedia ASM1164 device (vendor ID
  ASMEDIA, device ID 0x1164)
- Zero risk to any other hardware or code path

### Scope and Risk Assessment

- **Lines changed**: ~10 (comment + 1 functional line)
- **Files touched**: 1 (`drivers/pci/quirks.c`)
- **Risk**: Extremely low — this only affects the specific PCI device
  ID, and only when bus reset is attempted (primarily VFIO passthrough
  scenarios)
- **Dependencies**: None — `PCI_VENDOR_ID_ASMEDIA` and
  `quirk_no_bus_reset` already exist in stable kernels

### User Impact

- **Who is affected**: Users doing PCI passthrough of ASM1164 SATA
  controllers to VMs (Proxmox, QEMU/KVM, etc.)
- **Severity without fix**: Device fails to retrain after bus reset,
  making VM assignment of these controllers unreliable or non-
  functional, especially with multiple controllers
- **The forum thread** indicates this affects multiple users across
  multiple platforms — it's a real, reproducible issue
- ASMedia SATA controllers are very common consumer/prosumer hardware

### Stability Indicators

- Alex Williamson (VFIO maintainer) authored it — he's the authority on
  PCI passthrough issues
- Bjorn Helgaas (PCI maintainer) committed it — reviewed and approved by
  the subsystem maintainer
- The pattern is identical to existing quirks for Atheros, Cavium, and
  TI devices that are already in stable trees
- User confirmed the fix resolves the issue

### Dependency Check

No dependencies. The `quirk_no_bus_reset` function,
`DECLARE_PCI_FIXUP_HEADER` macro, and `PCI_VENDOR_ID_ASMEDIA` all exist
in stable kernels. This will apply cleanly to any stable tree.

### Conclusion

This is a textbook example of a PCI quirk that belongs in stable trees.
It's a minimal, zero-risk, single-device-ID addition that uses an
existing well-tested mechanism to fix a real hardware issue reported by
real users. It was authored and reviewed by the relevant subsystem
maintainers. The pattern is identical to many existing quirks already in
stable.

**YES**

 drivers/pci/quirks.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 280cd50d693bd..9100fd133a7ff 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3791,6 +3791,16 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_CAVIUM, 0xa100, quirk_no_bus_reset);
  */
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TI, 0xb005, quirk_no_bus_reset);
 
+/*
+ * Reports from users making use of PCI device assignment with ASM1164
+ * controllers indicate an issue with bus reset where the device fails to
+ * retrain.  The issue appears more common in configurations with multiple
+ * controllers.  The device does indicate PM reset support (NoSoftRst-),
+ * therefore this still leaves a viable reset method.
+ * https://forum.proxmox.com/threads/problems-with-pcie-passthrough-with-two-identical-devices.149003/
+ */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ASMEDIA, 0x1164, quirk_no_bus_reset);
+
 static void quirk_no_pm_reset(struct pci_dev *dev)
 {
 	/*
-- 
2.51.0