public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Johnny-CC Chang <Johnny-CC.Chang@mediatek.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Manivannan Sadhasivam <mani@kernel.org>,
	Sasha Levin <sashal@kernel.org>,
	matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org
Subject: [PATCH AUTOSEL 6.19-5.10] PCI: Mark Nvidia GB10 to avoid bus reset
Date: Sat, 14 Feb 2026 16:23:02 -0500	[thread overview]
Message-ID: <20260214212452.782265-37-sashal@kernel.org> (raw)
In-Reply-To: <20260214212452.782265-1-sashal@kernel.org>

From: Johnny-CC Chang <Johnny-CC.Chang@mediatek.com>

[ 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 <Johnny-CC.Chang@mediatek.com>
[bhelgaas: drop pci_ids.h update (only used once), update commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20251113084441.2124737-1-Johnny-CC.Chang@mediatek.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis of PCI Quirk for Nvidia GB10 Bus Reset

### Commit Message Analysis

The commit adds a PCI quirk to prevent Secondary Bus Reset (SBR) for
devices behind Nvidia GB10 Root Ports. The problem is clearly stated:
after asserting SBR, the link may not retrain correctly — leading to
reduced lane count or complete failure of config accesses to downstream
devices. This is a real hardware bug with concrete symptoms (link
degradation, device inaccessibility).

### Code Change Analysis

The change is minimal and surgical:
- Two `DECLARE_PCI_FIXUP_HEADER` lines are added for two specific Nvidia
  device IDs (`0x22CE` and `0x22D0`)
- Both call the existing `quirk_no_bus_reset()` function, which simply
  sets `PCI_DEV_FLAGS_NO_BUS_RESET` on the device
- A comment block explains why the quirk is needed, with a link to the
  mailing list discussion

The diff also shows context that there's already a similar quirk pattern
for other Nvidia GPU devices (`quirk_nvidia_no_bus_reset` matching
`0x2340` range), as well as Atheros devices. This is a well-established
pattern in the kernel.

### Classification: Hardware Quirk

This falls squarely into the **hardware quirk** category, which is
explicitly listed as a strong YES signal for stable backporting.
Hardware quirks:
- Fix real-world hardware issues
- Are trivial additions to existing infrastructure
- Have near-zero risk of regression (they only affect the specific
  hardware identified by the PCI IDs)

### Scope and Risk Assessment

- **Lines changed**: ~8 lines (2 macro invocations + comment block)
- **Files touched**: 1 (`drivers/pci/quirks.c`)
- **Complexity**: Minimal — uses existing `quirk_no_bus_reset()`
  function
- **Risk**: Extremely low — only affects devices with vendor ID
  `PCI_VENDOR_ID_NVIDIA` and device IDs `0x22CE` or `0x22D0`
- **No dependencies**: The `quirk_no_bus_reset()` function and
  `DECLARE_PCI_FIXUP_HEADER` macro have existed in the kernel for a very
  long time

### User Impact

- **Who is affected**: Users with Nvidia GB10 Root Ports (likely
  MediaTek platforms given the author's affiliation)
- **Severity without fix**: Bus reset can cause downstream devices to
  become inaccessible (config accesses fail) or degrade link performance
  (lower lane count). This can manifest as device failures, system
  hangs, or degraded performance
- **Severity with fix**: Bus reset is avoided for these specific root
  ports, preventing the link training failure

### Stability Indicators

- **Reviewed-by**: Manivannan Sadhasivam (PCI subsystem reviewer)
- **Committed by**: Bjorn Helgaas (PCI subsystem maintainer), who also
  edited the commit log
- **Mailing list link**: Provided for traceability
- The pattern is identical to many existing quirks in the same file

### Dependency Check

No dependencies. The `quirk_no_bus_reset()` function exists in all
stable trees. `DECLARE_PCI_FIXUP_HEADER` and `PCI_VENDOR_ID_NVIDIA` are
long-established. This will apply cleanly to any stable tree.

### Conclusion

This is a textbook hardware quirk addition — small, self-contained, zero
regression risk, fixes a real hardware issue (bus reset failure causing
device inaccessibility), uses existing well-tested infrastructure,
reviewed and committed by the PCI subsystem maintainer. It meets all
stable kernel criteria.

**YES**

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

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 54c76ba9a767e..5782dfb863cad 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3748,6 +3748,14 @@ static void quirk_no_bus_reset(struct pci_dev *dev)
 	dev->dev_flags |= PCI_DEV_FLAGS_NO_BUS_RESET;
 }
 
+/*
+ * After asserting Secondary Bus Reset to downstream devices via a GB10
+ * Root Port, the link may not retrain correctly.
+ * https://lore.kernel.org/r/20251113084441.2124737-1-Johnny-CC.Chang@mediatek.com
+ */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x22CE, quirk_no_bus_reset);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x22D0, quirk_no_bus_reset);
+
 /*
  * Some NVIDIA GPU devices do not work with bus reset, SBR needs to be
  * prevented for those affected devices.
-- 
2.51.0



       reply	other threads:[~2026-02-14 21:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260214212452.782265-1-sashal@kernel.org>
2026-02-14 21:23 ` Sasha Levin [this message]
2026-02-14 21:23 ` [PATCH AUTOSEL 6.19-6.1] PCI: dw-rockchip: Disable BAR 0 and BAR 1 for Root Port Sasha Levin
2026-02-14 21:23 ` [PATCH AUTOSEL 6.19-6.18] PCI: imx6: Add CLKREQ# override to enable REFCLK for i.MX95 PCIe Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260214212452.782265-37-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=Johnny-CC.Chang@mediatek.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=bhelgaas@google.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mani@kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=patches@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox