[PATCH AUTOSEL 6.18-6.1] PCI: switchtec: Add Microchip PCI1008 to NTB DMA alias quirk

[PATCH AUTOSEL 6.18-6.1] PCI: switchtec: Add Microchip PCI1008 to NTB DMA alias quirk

[Sasha Levin]

From: Logan Gunthorpe <logang@deltatee.com>

[ Upstream commit 00a479ba1d01249d43ca5e453380d1ed60946f8a ]

Add the PCI1008 device ID to the quirk_switchtec_ntb_dma_alias PCI fixup
table. Without it, DMA transactions from a PCI1008 switch's NTB function
are not given the correct requester ID alias, which can misdirect them
under an IOMMU.

Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260714212010.230606-4-logang@deltatee.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

This is a one-line PCI ID addition to an existing NTB DMA-alias quirk.
The local tree is **v7.3-rc4** (`7.3.0-rc4`, HEAD `f0100363d8c37`). The
`SWITCHTEC_PCI100X_QUIRK` table is present, so the change belongs here.

===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================

**Step 1.1: PARSE THE SUBJECT LINE**

Record: `[PCI: switchtec:] [Add] [PCI1008 device ID to the existing NTB
DMA alias quirk table]`

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**

Record:
- `Fixes:` — none (expected)
- `Reported-by:` — none
- `Tested-by:` — none
- `Reviewed-by:` — none
- `Acked-by:` — none on this patch; Vinod Koul acked series patch 1/3
  (dmaengine ID)
- `Link:`
  https://patch.msgid.link/20260714212010.230606-4-logang@deltatee.com
  (series 3/3)
- `Cc: stable@vger.kernel.org` — none (expected)
- `Signed-off-by: Logan Gunthorpe <logang@deltatee.com>` (author;
  SWITCHTEC DMA maintainer)
- `Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>` (PCI subsystem
  maintainer)

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**

Record:
- **Bug:** PCI1008 is missing from `quirk_switchtec_ntb_dma_alias`.
  Switchtec NTB replaces the original requester ID with a hardware proxy
  ID. Without an IOMMU alias, those TLPs are not attributed to the NTB
  device.
- **Symptom:** DMA from a PCI1008 NTB function can be misdirected or
  blocked when an IOMMU is on (IOMMU faults / failed peer DMA).
- **Versions:** none named. Series cover letter says the patches were
  based on v7.2-rc3; Bjorn applied them for v7.3.
- **Root cause:** the PCI100X quirk table lists 0x1001–0x1006 only;
  PCI1008 (0x1008) was never added.

**Step 1.4: DETECT HIDDEN BUG FIXES**

Record: Not hidden. It is an explicit hardware-quirk / device-ID
addition. That is a documented stable exception, not cleanup.

===============================================================
PHASE 2: DIFF ANALYSIS - LINE BY LINE
===============================================================

**Step 2.1: INVENTORY THE CHANGES**

Record:
- File: `drivers/pci/quirks.c` — **+1 / −0**
- Function: none changed; one `SWITCHTEC_PCI100X_QUIRK(0x1008)` entry
  added next to 0x1001–0x1006
- Scope: single-file, one-line surgical fix

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**

Record:
- **Before:** `DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_EFAR, 0x1008,
  PCI_CLASS_BRIDGE_OTHER, 8, quirk_switchtec_ntb_dma_alias)` is not
  registered. A PCI1008 NTB function never runs the quirk.
- **After:** the same FINAL-class fixup used for PCI1001–PCI1006 is
  registered for 0x1008. Enumeration of a matching device calls
  `quirk_switchtec_ntb_dma_alias()`, which reads the NTB proxy-ID tables
  and calls `pci_add_dma_alias()`.
- Path: PCI enumeration / class fixup FINAL (init), not a hot path.

**Step 2.3: IDENTIFY THE BUG MECHANISM**

Record:
- **Category:** (h) Hardware workaround — PCI ID added to an existing
  quirk table
- **Mechanism:** Switchtec NTB DMA uses proxy requester IDs. IOMMU
  groups are built from those aliases. Missing 0x1008 means PCI1008
  proxy IDs are not aliased, so IOMMU policy does not match the
  requester ID on the wire.

**Step 2.4: ASSESS THE FIX QUALITY**

Record:
- Obviously correct: same macro and comment style as PCI1001–PCI1006.
- Minimal: one line, no API or structure change.
- Regression risk: very low. The new fixup only matches vendor EFAR +
  device 0x1008 + class `PCI_CLASS_BRIDGE_OTHER`. Other devices are
  unchanged. `quirk_switchtec_ntb_dma_alias()` already bounds `table_sz`
  (skip 0, reject >512).
- Red flags: none. A pre-existing `ep_map + 4` pointer-arithmetic issue
  in the quirk function was flagged on the list; it is not introduced by
  this line.

===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================

**Step 3.1: BLAME THE CHANGED LINES**

Record:
- Surrounding `SWITCHTEC_PCI100X_QUIRK` entries: `a3282f84b2151` (“PCI:
  switchtec: Add Microchip PCI100X device IDs”, 2025-01-21). Present in
  v6.14, not in v6.13.
- Original Switchtec NTB DMA alias quirk: `ad281ecf1c7d4` (“PCI: Add DMA
  alias quirk for Microsemi Switchtec NTB”, 2018-06-29). Present in this
  tree.
- The 0x1008 line itself is this commit (`00a479ba1d012`).

**Step 3.2: FOLLOW THE FIXES: TAG**

Record: No `Fixes:` tag. The omission is the PCI1008 ID never being
added when PCI100X support landed in `a3282f84b2151` (six SKUs
1001–1006). PCI1008 is a later part.

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**

Record:
- Same series (msgid `20260714212010.230606-*`, based on v7.2-rc3,
  applied to pci/switchtec for v7.3):
  1. `8b326de3cc02c` dmaengine: switchtec-dma: Add PCI1008 device ID
     (`-2`)
  2. `0d8a6306c680e` PCI: switchtec: Add Microchip PCI1008 device ID
     (`-3`)
  3. `00a479ba1d012` this patch (`-4`, submitted as 3/3)
- This patch is standalone. The quirk is a PCI fixup, not a driver ID
  table. It does not need the switchtec or switchtec-dma ID additions.

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**

Record: Logan Gunthorpe is listed maintainer of SWITCHTEC DMA
(`MAINTAINERS`) and a long-time switchtec contributor. Bjorn Helgaas
(PCI maintainer) signed off and applied the series.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**

Record:
- Prerequisite in this tree: `SWITCHTEC_PCI100X_QUIRK` /
  `PCI_VENDOR_ID_EFAR` table from `a3282f84b2151` — present.
- `quirk_switchtec_ntb_dma_alias()` and `pci_add_dma_alias()` — present.
- No other structural dependency. Can apply standalone.

===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**

Record:
- `b4 dig -c 00a479ba1d012` →
  https://patch.msgid.link/20260714212010.230606-4-logang@deltatee.com
- Subject on list: `[PATCH v1 3/3] PCI: Add PCI1008 to switchtec NTB DMA
  alias quirk`
- `b4 dig -a`: only v1. Cover letter `[PATCH v1 0/3] switchtec: add new
  device IDs`.
- Direct lore.kernel.org HTTP fetch returned 403/Anubis; the thread was
  recovered via `b4 dig -m`.
- Review: no NAKs. Sashiko noted a pre-existing `ep_map + 4` pointer
  issue; Logan said it is unrelated and should not gate the series.
  Bjorn: “Applied to pci/switchtec for v7.3, thanks!”
- No reviewer asked for `Cc: stable`.

**Step 4.2: CHECK WHO REVIEWED THE PATCH**

Record (`b4 dig -w`): Logan Gunthorpe, linux-pci, linux-kernel,
dmaengine, Vinod Koul, Bjorn Helgaas, Frank Li, Kelvin Cao (Microchip /
SWITCHTEC DMA co-maintainer). PCI and dmaengine maintainers were on the
original To/Cc.

**Step 4.3: SEARCH FOR THE BUG REPORT**

Record: No bugzilla/syzbot link. Cover letter: Logan originally had only
the dmaengine ID; Sashiko reminded him to add the management ID and the
NTB quirk, then he sent this 3-patch series. Hardware impact is
described in the patch, not in a separate user report.

**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**

Record: Three independent 1-line ID additions (dmaengine, switchtec
management, NTB quirk). This quirk patch is self-contained. The other
two enable management/NTB userspace and the DMA engine; they are not
required for the IOMMU alias.

**Step 4.5: CHECK STABLE MAILING LIST HISTORY**

Record: lore.kernel.org/stable search for PCI1008 returned HTTP 403. No
stable discussion in the linux-pci mbox. UNVERIFIED whether anyone
requested this on stable@ after merge.

===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================

**Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF**

Record: No function body edited. New fixup entry invokes existing
`quirk_switchtec_ntb_dma_alias()`.

**Step 5.2: TRACE CALLERS**

Record: Not called in C. Registered with
`DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_EFAR, 0x1008,
PCI_CLASS_BRIDGE_OTHER, 8, ...)`. PCI core runs class FINAL fixups
during device setup, before typical driver probe. Context: boot/hotplug
enumeration, not IRQ.

**Step 5.3: TRACE CALLEES**

Record: `quirk_switchtec_ntb_dma_alias()` uses `pci_enable_device`,
`pci_iomap`, MMIO reads of NTB partition/proxy tables,
`pci_add_dma_alias()`, then unmap/disable. `pci_add_dma_alias()` sets
`dma_alias_mask` bits used to program IOMMU source IDs.

**Step 5.4: FOLLOW THE CALL CHAIN**

Record: PCI enumeration → class FINAL fixup → alias programming → IOMMU
group creation. Reachable only with PCI1008 hardware present.
Unprivileged userspace cannot trigger the quirk directly; a user of that
NTB/IOMMU path sees DMA failures if it is missing.

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**

Record: Same pattern as PCI1001–PCI1006 in this file, and as many other
`pci_add_dma_alias` quirks (PLX NTB, Ricoh, Marvell, etc.). Adding
0x1008 is consistent with how every prior Switchtec/PCI100X ID was
handled.

===============================================================
PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE
===============================================================

**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**

Record: Yes. `drivers/pci/quirks.c` has `SWITCHTEC_PCI100X_QUIRK` for
0x1001–0x1006. Without 0x1008, a PCI1008 NTB function would not get
aliases. `a3282f84b2151` (v6.14) added the table; this tree is 7.3-rc4,
so the table is present. `git merge-base --is-ancestor 00a479ba1d012
HEAD` is true (commit is already in 7.3-rc1); that is not treated as
“already selected for stable.”

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**

Record: Expected apply: **clean**. Context is the existing PCI100X quirk
block, unchanged except for the new line. No refactor of this table
since it was added.

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**

Record: No alternate PCI1008 NTB alias fix. Companion IDs in
`switchtec.c` and `switchtec_dma.c` are the sibling series patches, not
substitutes for this quirk.

===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================

**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**

Record: `[PCI quirks / Switchtec NTB DMA alias] [IMPORTANT]` — not core
mm/scheduler, but PCI IOMMU correctness for NTB. Affects systems with
this Microchip switch and IOMMU enabled.

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**

Record: PCI quirks and switchtec are actively maintained (recent
pci/switchtec and pci/virtualization merges on this tree). The quirk
function itself has been stable since 2018; PCI100X IDs since v6.14.

===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================

**Step 8.1: DETERMINE WHO IS AFFECTED**

Record: Driver/hardware-specific: Microchip PCI1008 (vendor EFAR 0x1055,
device 0x1008) with NTB and IOMMU. Not universal.

**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**

Record: Present whenever that device is enumerated with IOMMU on. Not a
race. Not triggerable by an unprivileged syscall on machines without the
hardware. Common for any PCI1008 NTB + IOMMU deployment.

**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**

Record: IOMMU rejects or mis-groups DMA from NTB proxy IDs → DMA
failures, IOMMU faults, broken peer NTB DMA. **HIGH** for that hardware;
not a generic panic.

**Step 8.4: CALCULATE RISK-BENEFIT RATIO**

Record:
- **Benefit:** HIGH for PCI1008+IOMMU users (device works correctly
  under IOMMU). Classic device-ID/quirk enablement.
- **Risk:** VERY LOW (1 line, existing macro, match is device-specific).
- **Ratio:** strongly favors backporting.

===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================

**Step 9.1: COMPILE THE EVIDENCE**

FOR:
- PCI ID / hardware quirk on an existing table (stable exception).
- Real IOMMU DMA misdirection without the alias.
- 1 line, obviously correct, same pattern as PCI1001–1006.
- Prerequisite table exists in this 7.3 tree.
- Author is switchtec maintainer; PCI maintainer applied it.
- Standalone; no API change.

AGAINST:
- No `Reported-by` / production crash log (typical for ID additions).
- Audience is PCI1008 NTB + IOMMU, not all machines.
- Unrelated pre-existing `ep_map` pointer issue in the quirk function
  (not caused by this line).
- Stable@ discussion could not be fetched (403).

UNRESOLVED:
- Whether stable@ discussed this after merge (lore.kernel.org/stable
  403).
- Whether Logan later sent an `ep_map` fix (explicitly out of scope).

**Step 9.2: APPLY THE STABLE RULES CHECKLIST**

1. Obviously correct and tested? **PASS** — one-line ID, applied by PCI
   maintainer after list review.
2. Fixes a real bug that affects users? **PASS** — PCI1008 NTB DMA under
   IOMMU is wrong without the alias.
3. Important issue? **PASS** — IOMMU DMA correctness (faults /
   misdirected DMA), HIGH for that hardware.
4. Small and contained? **PASS** — +1 line in `drivers/pci/quirks.c`.
5. No new features or APIs? **PASS** — device ID on an existing quirk;
   allowed exception.
6. Can apply to the local tree? **PASS** — `SWITCHTEC_PCI100X_QUIRK` is
   present; apply is clean.

**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**

Record: **Device ID addition** and **hardware quirk/workaround** (PCI
DMA alias quirk). These are listed as YES for stable.

**Step 9.4: MAKE YOUR DECISION**

This tree has the PCI100X quirk table. Adding PCI1008 is the same class
of change already used for PCI1001–1006. Without it, PCI1008 NTB DMA can
be misdirected under an IOMMU. The patch is one line, applies cleanly,
and does not need the rest of the series.

Verification:
- [Phase 1] `git describe HEAD` → `v7.3-rc4-27-gf0100363d8c37`; `make
  kernelversion` → `7.3.0-rc4`. Tags: SOB Logan + Bjorn; Link to patch
  3/3; no Fixes/stable/Reported-by.
- [Phase 2] `git show 00a479ba1d012`: +1 line
  `SWITCHTEC_PCI100X_QUIRK(0x1008)` in `drivers/pci/quirks.c`.
- [Phase 2] Read `quirk_switchtec_ntb_dma_alias()`: enable, iomap, read
  proxy IDs, `pci_add_dma_alias()`, table_sz 0/512 guards.
- [Phase 3] `git blame -L 6087,6096`: table from `a3282f84b2151`
  (v6.14); 0x1008 from this commit.
- [Phase 3] `git merge-base --is-ancestor a3282f84b2151 v6.14` true; not
  ancestor of v6.13. Original quirk `ad281ecf1c7d4` (2018) is in HEAD.
- [Phase 3] `git merge-base --is-ancestor 00a479ba1d012 v7.2` false;
  ancestor of v7.3-rc1/rc4.
- [Phase 3] Series patches `8b326de3cc02c`, `0d8a6306c680e` are sibling
  ID adds, not prerequisites of this quirk.
- [Phase 4] `b4 dig -c 00a479ba1d012` / `-a` / `-w` / `-m`: v1-only
  3-patch series; Bjorn applied for v7.3; Vinod acked 1/3; no NAK;
  Sashiko `ep_map` note treated as unrelated.
- [Phase 4] lore.kernel.org HTTP 403/Anubis; thread recovered via b4
  mbox. stable@ search 403 — UNVERIFIED.
- [Phase 5] No C callers; `DECLARE_PCI_FIXUP_CLASS_FINAL` in
  `include/linux/pci.h`; `pci_add_dma_alias` in `drivers/pci/pci.c`.
- [Phase 6] Local `quirks.c` has PCI100X table and (in this checkout)
  the 0x1008 line. Companion IDs exist in `switchtec.c:1877` and
  `switchtec_dma.c:1426`.
- [Phase 7] PCI subsystem maintainer Bjorn Helgaas; Logan maintains
  SWITCHTEC DMA.
- [Phase 8] Failure mode: IOMMU DMA misdirection for PCI1008 NTB — HIGH
  for that hardware; patch risk very low.

The change is a one-line PCI quirk ID. That is the standard stable
exception, it is obviously correct, and this tree already has the table
it extends.

**YES**

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

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index e8067ff59e2a5..e03a3831bcc00 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -6045,6 +6045,7 @@ SWITCHTEC_PCI100X_QUIRK(0x1003);  /* PCI1003XG4 */
 SWITCHTEC_PCI100X_QUIRK(0x1004);  /* PCI1004XG4 */
 SWITCHTEC_PCI100X_QUIRK(0x1005);  /* PCI1005XG4 */
 SWITCHTEC_PCI100X_QUIRK(0x1006);  /* PCI1006XG4 */
+SWITCHTEC_PCI100X_QUIRK(0x1008);  /* PCI1008XG4 */
 
 
 /*
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-6.1] PCI: switchtec: Add Microchip PCI1008 to NTB DMA alias quirk

[sashiko-bot]

> From: Logan Gunthorpe <logang@deltatee.com>
> 
> [ Upstream commit 00a479ba1d01249d43ca5e453380d1ed60946f8a ]
> 
> Add the PCI1008 device ID to the quirk_switchtec_ntb_dma_alias PCI fixup
> table. Without it, DMA transactions from a PCI1008 switch's NTB function
> are not given the correct requester ID alias, which can misdirect them
> under an IOMMU.
> 
> Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> Link: https://patch.msgid.link/20260714212010.230606-4-logang@deltatee.com
> Signed-off-by: Sasha Levin <sashal@kernel.org>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261019135441.1420968-46-sashal@kernel.org?part=1

[PATCH AUTOSEL 6.18-5.10] PCI: cadence: Add missing MODULE_DEVICE_TABLE()

[Sasha Levin]

From: Pengpeng Hou <pengpeng@iscas.ac.cn>

[ Upstream commit 93aac16f1eb9a181f9bdde620b464f6cc5fa8369 ]

The driver has an OF match table wired to .of_match_table, but does
not export the table with MODULE_DEVICE_TABLE().

Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias
information is generated for OF based module autoloading.

Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Aksh Garg <a-garg7@ti.com>
Link: https://patch.msgid.link/20260704122835.14277-1-pengpeng@iscas.ac.cn
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable backport analysis: `PCI: cadence: Add missing
MODULE_DEVICE_TABLE()`

Local tree: **Linux 7.3.0-rc4** (`v7.3-rc4-27-gf0100363d8c37`). Verdict
is for this checkout only.

Candidate: `93aac16f1eb9a181f9bdde620b464f6cc5fa8369`

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1 — Subject line**
Record: `[PCI/cadence] [Add] missing MODULE_DEVICE_TABLE() so OF module
aliases are generated`

**Step 1.2 — Tags**
Record:
- `Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>` (author)
- `Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>` (PCI
  controller maintainer; applied the patch)
- `Reviewed-by: Aksh Garg <a-garg7@ti.com>`
- `Link:
  https://patch.msgid.link/20260704122835.14277-1-pengpeng@iscas.ac.cn`
- No `Fixes:`, no `Reported-by:`, no `Cc: stable` (absence is expected
  for this review)
- No syzbot / KASAN / crash report

**Step 1.3 — Body**
Record:
[Bug] OF match table is wired to `.of_match_table` but not exported via
`MODULE_DEVICE_TABLE()`.
[Symptom] `depmod` / udev / `modprobe` do not get `of:N*T*Ccdns,cdns-
pcie-host` / `cdns,cdns-pcie-ep` aliases, so the module does not
autoload.
[Version info] None in the message.
[Root cause] Missing alias publication, not a runtime logic error. The
mailing-list body (mbox) states this is a source-level fix with no
hardware reproducer.

**Step 1.4 — Hidden bug fix?**
Record: Not disguised. It is an explicit autoload/modalias fix. Same
class as `PCI: j721e: Fix module autoloading`.

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1 — Inventory**
Record:
[Files] `drivers/pci/controller/cadence/pcie-cadence-plat.c` (+1 / −0)
[Functions] none changed; one statement added after
`cdns_plat_pcie_of_match[]`
[Scope] single-file, one-line surgical change

**Step 2.2 — Code flow**
Record: Before: match table exists and is used for probe matching, but
`scripts/mod/file2alias.c` never sees it, so the `.ko` has no OF
aliases. After: `MODULE_DEVICE_TABLE(of, cdns_plat_pcie_of_match)`
creates the `__mod_of__cdns_plat_pcie_of_match` alias
(`include/linux/module.h`). Normal module-build path only; no
probe/runtime behavior change.

**Step 2.3 — Bug mechanism**
Record: [Category] logic/correctness for modular OF drivers (missing
userspace alias). [Mechanism] without the macro, a modular `pcie-
cadence-plat` never autoloads from DT. Sibling Cadence drivers already
export tables (`pci-j721e.c`, `pci-sky1.c`, `pcie-sg2042.c`).

**Step 2.4 — Fix quality**
Record: Obviously correct and minimal. Regression risk is effectively
none: it only adds module metadata. Does not change locking, probe, or
APIs. Reviewer AI notes about probe `return 0` and drvdata type mismatch
are **pre-existing** and not introduced here.

---

## PHASE 3: GIT HISTORY

**Step 3.1 — Blame**
Record: Match table introduced in `bd22885aa188f` (“PCI: cadence:
Refactor driver to use as a core library”, 2019). Driver was
`builtin_platform_driver` + `bool` Kconfig until `611627a4e5e4a` (“PCI:
cadence: Add module support for platform controller driver”,
2025-11-14). That commit is in **v6.19**. Bug (missing table export for
a loadable module) starts there.

**Step 3.2 — Fixes: tag**
Record: No `Fixes:` tag. The introducing commit is `611627a4e5e4a`
(module support). It **is** an ancestor of this tree.

**Step 3.3 — File history**
Record: Recent: HPA support, module support, then this one-liner.
Standalone; not `patch X/Y`. No later revert on this file.

**Step 3.4 — Author**
Record: Pengpeng Hou also did `e145af8c14474` `PCI: spacemit: Add
missing MODULE_DEVICE_TABLE()` the same day. Applied by Manivannan
Sadhasivam (PCI controller maintainer).

**Step 3.5 — Dependencies**
Record: Needs `module_platform_driver` + tristate Kconfig from
`611627a4e5e4a`. Both are in this 7.3 tree. Applies standalone here.

---

## PHASE 4: MAILING LIST / EXTERNAL

**Step 4.1 — Original discussion**
Record: `b4 dig -c 93aac16f1eb9a` →
https://patch.msgid.link/20260704122835.14277-1-pengpeng@iscas.ac.cn
`b4 dig -a`: **v1 only**, 2026-07-04.
Thread (mbox): Aksh Garg Reviewed-by; Manivannan “Applied, thanks!” to
`93aac16f1eb9a`. No NAK, no stable nomination, no concern about this
line.

**Step 4.2 — Recipients (`b4 dig -w`)**
Record: PCI maintainers (Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Bjorn Helgaas), Rob Herring, linux-pci, linux-
kernel.

**Step 4.3 — Bug report**
Record: None. Author did not claim a hardware reproducer.

**Step 4.4 — Related series**
Record: Same-day sibling `PCI: spacemit: Add missing
MODULE_DEVICE_TABLE()`. Precedent in-tree: `9a7f144e18dc5` `PCI: j721e:
Fix module autoloading` (`Fixes:` + `Cc: stable`) — same one-line OF
table export.

**Step 4.5 — Stable list**
Record: UNVERIFIED. lore.kernel.org returned a bot-check page; WebFetch
of the msgid URL returned 403. No stable-list discussion was retrieved.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1 — Functions**
Record: No function bodies changed. Data: `cdns_plat_pcie_of_match[]`.
Driver: `cdns_plat_pcie_driver` / `cdns_plat_pcie_probe`.

**Step 5.2 — Callers**
Record: Probe is the platform-driver callback. Match table used only in
this file. Triggered when DT has `cdns,cdns-pcie-host` or `cdns,cdns-
pcie-ep`.

**Step 5.3 — Callees**
Record: Unchanged. `MODULE_DEVICE_TABLE` is a compile-time alias for
`file2alias.c`.

**Step 5.4 — Reachability**
Record: Reachable on OF platforms that describe Cadence PCIe with those
compatibles and build `CONFIG_PCIE_CADENCE_PLAT=m`. No in-tree
`.dts`/`.dtsi` uses those strings (only DT binding examples). So the in-
tree user set is small; out-of-tree / FPGA / IP reference boards may
still use the generic compatible.

**Step 5.5 — Similar patterns**
Record: Same missing-table pattern already fixed for j721e, mvebu, qcom-
ep, spacemit, and the other Cadence glue drivers in this directory.

---

## PHASE 6: LOCAL TREE CROSS-CHECK

**Step 6.1 — Does the buggy code exist here?**
Record: Yes. This tree has tristate `PCIE_CADENCE_PLAT`,
`module_platform_driver`, and the OF table. Module support is in v6.19+.
Without `MODULE_DEVICE_TABLE`, modular autoload is broken. (The one-line
fix is present at line 166 of the current file; that is not used as
“already selected” circular reasoning — it confirms the surrounding code
matches the patch.)

**Step 6.2 — Backport difficulty**
Record: Clean apply on this tree: one line next to the existing table.

**Step 6.3 — Related fixes already here?**
Record: j721e/sky1/sg2042 already have `MODULE_DEVICE_TABLE`. Nothing
else replaces this plat-driver export.

---

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1**
Record: `[drivers/pci/controller/cadence] [IMPORTANT for Cadence-IP
SoCs; PERIPHERAL vs core mm/net]`. PCIe host not coming up is serious
for those boards, not universal.

**Step 7.2**
Record: Active PCI controller area (HPA, module support, several glue
drivers). Plat driver itself is mature (2019) with occasional fixes.

---

## PHASE 8: IMPACT AND RISK

**Step 8.1 — Who is affected**
Record: Driver-specific / config-specific: `CONFIG_PCIE_CADENCE_PLAT=m`
plus DT compatible `cdns,cdns-pcie-*`. Built-in builds are unaffected.
No in-tree board DTS match; population is reference/FPGA/out-of-tree DT.

**Step 8.2 — Trigger**
Record: Boot (or coldplug) on matching DT with the driver as a module.
Common for modular embedded images. Unprivileged users cannot trigger a
crash; they just never get the controller unless something else loads
the module.

**Step 8.3 — Failure mode**
Record: [Failure] module not autoloaded → PCIe host/endpoint never
probes → downstream devices missing. [Severity] **MEDIUM** (functional
miss, not oops/corruption). Workaround: `modprobe` or `=y`.

**Step 8.4 — Risk vs benefit**
Record: Benefit: hardware actually binds on modular kernels. Risk: very
low (modinfo aliases only). Ratio: favorable. Same class as device-ID /
autoload fixes that stable already takes (j721e was `Cc: stable`).

---

## PHASE 9: SYNTHESIS

**Step 9.1 — Evidence**

For:
- Real autoload bug on a driver this tree can build as a module
- One line, obviously correct, maintainer-applied, reviewed
- Sibling Cadence drivers already export tables; j721e’s identical fix
  was stable-tagged
- Zero runtime regression surface
- Fits “device ID / make existing hardware work” exception more than a
  feature

Against:
- No user report, no `Fixes:`/`Cc: stable` on this patch
- Author stated no hardware reproduction
- No in-tree DTS uses these compatibles
- Not a crash, UAF, or data-corruption bug
- Stable mailing-list history UNVERIFIED

Unresolved: whether anyone on stable@ already rejected or requested this
(lore blocked).

**Step 9.2 — Stable rules (this tree)**
1. Obviously correct and tested? **PASS** — one documented macro; v1
   applied as-is after Reviewed-by.
2. Real bug that affects users? **PASS** — modular OF autoload fails;
   users who `=m` this controller do not get PCIe without a manual load.
3. Important (crash/security/corruption/deadlock)? **PASS** at “oh,
   that’s not good” / device-ID-class — PCIe does not come up. Not
   CRITICAL.
4. Small and contained? **PASS** — +1 line, one file.
5. No new features or APIs? **PASS** — metadata for IDs that already
   exist.
6. Can apply to this tree? **PASS** — table, `module_platform_driver`,
   and tristate Kconfig are all here.

**Step 9.3 — Exception category**
Record: Closest to **device ID / hardware enablement**: publishing
existing OF IDs for autoload, not a new driver.

**Step 9.4 — Decision**
This 7.3 tree can build the Cadence platform controller as a module.
Without `MODULE_DEVICE_TABLE(of, ...)`, userspace never sees the aliases
and the host/endpoint driver does not autoload. That is a real, user-
visible functional bug, a one-line contained fix, and the same pattern
already sent to stable for `pci-j721e`. Risk is negligible. It should be
included in this tree.

---

## What the commit solves (for stable users)

On kernels where `CONFIG_PCIE_CADENCE_PLAT=m`, udev/modprobe cannot
match DT nodes `cdns,cdns-pcie-host` / `cdns,cdns-pcie-ep` to `pcie-
cadence-plat.ko`. The controller never probes unless the module is
loaded by hand. The patch only emits the standard OF aliases. No new
ABI, no probe-path change.

Risk vs benefit: benefit is “PCIe works on modular images”; risk is
alias-only. Backport on this tree is a clean one-line apply;
prerequisite module support (`611627a4e5e4a`, v6.19) is already present.

---

## Verification

- [Phase 1] Parsed tags: author Hou, SOB+apply Manivannan Sadhasivam,
  Reviewed-by Aksh Garg, Link msgid; no Fixes/Reported-by/Cc:stable
- [Phase 2] Diff: +1 line `MODULE_DEVICE_TABLE(of,
  cdns_plat_pcie_of_match)` in `pcie-cadence-plat.c`
- [Phase 2] Confirmed macro in `include/linux/module.h` creates
  `file2alias` alias
- [Phase 3] `git describe HEAD` / `make kernelversion`: **7.3.0-rc4**
- [Phase 3] `git blame`: table from `bd22885aa188f` (2019);
  `MODULE_DEVICE_TABLE` line from `93aac16f1eb9a`
- [Phase 3] Introducer of modular bug: `611627a4e5e4a` (bool→tristate,
  `builtin_platform_driver`→`module_platform_driver`); first tag
  **v6.19**; `git merge-base --is-ancestor 611627a4e5e4a HEAD` true
- [Phase 3] `git merge-base --is-ancestor 93aac16f1eb9a HEAD` true (used
  only to confirm context, not as “already selected”)
- [Phase 3] No revert of this commit on the file after it
- [Phase 4] `b4 dig -c/-a/-w/-m`: v1 only; lore msgid above; PCI
  maintainers on To; Reviewed-by + Applied; no NAK
- [Phase 4] WebFetch lore URL: 403; lore search: bot wall. Stable-list
  discussion **UNVERIFIED**
- [Phase 5] `git grep cdns_plat_pcie`: confined to plat driver + header
  + sky1 using the of_data struct
- [Phase 5] `git grep` of compatibles in `arch/`: **no** dts/dtsi users;
  only DT binding examples
- [Phase 5] Sibling `MODULE_DEVICE_TABLE` already in j721e, sky1, sg2042
- [Phase 6] Local file has match table + `module_platform_driver` +
  tristate Kconfig; patch applies as a single added line
- [Phase 6] Precedent `9a7f144e18dc5` j721e autoload fix has `Fixes:` +
  `Cc: stable`
- [Phase 8] Failure mode: no autoload → PCIe missing; severity MEDIUM,
  not oops
- UNVERIFIED: whether this was discussed on stable@ (lore blocked)

**YES**

 drivers/pci/controller/cadence/pcie-cadence-plat.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/controller/cadence/pcie-cadence-plat.c b/drivers/pci/controller/cadence/pcie-cadence-plat.c
index 0456845dabb96..0f9cf2a9f0034 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-plat.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-plat.c
@@ -167,6 +167,7 @@ static const struct of_device_id cdns_plat_pcie_of_match[] = {
 	},
 	{},
 };
+MODULE_DEVICE_TABLE(of, cdns_plat_pcie_of_match);
 
 static struct platform_driver cdns_plat_pcie_driver = {
 	.driver = {
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-5.10] PCI: cadence: Add missing MODULE_DEVICE_TABLE()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] PCI: cadence: MODULE_DEVICE_TABLE() added to non-modular built-in driver
--

commit 47a5cb89a268b5f62186006942f7b1da4567a7f3
Author: Pengpeng Hou <pengpeng@iscas.ac.cn>

PCI: cadence: Add missing MODULE_DEVICE_TABLE()

This commit adds MODULE_DEVICE_TABLE(of, cdns_plat_pcie_of_match) to
pcie-cadence-plat.c so that module alias information is generated for
OF-based module autoloading.

Link: https://patch.msgid.link/20260704122835.14277-1-pengpeng@iscas.ac.cn

> diff --git a/drivers/pci/controller/cadence/pcie-cadence-plat.c b/drivers/pci/controller/cadence/pcie-cadence-plat.c
> index 0456845dabb96..0f9cf2a9f0034 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence-plat.c
> +++ b/drivers/pci/controller/cadence/pcie-cadence-plat.c
> @@ -167,6 +167,7 @@ static const struct of_device_id cdns_plat_pcie_of_match[] = {
>  	},
>  	{},
>  };
> +MODULE_DEVICE_TABLE(of, cdns_plat_pcie_of_match);
>  
>  static struct platform_driver cdns_plat_pcie_driver = {
>  	.driver = {

[Severity: Medium]
Can this driver actually be built as a loadable module in this tree?

Upstream commit 611627a4e5e4a ("PCI: cadence: Add module support for
platform controller driver", merged in v6.19) converted the Kconfig symbols
from bool to tristate and switched the driver to module_platform_driver(),
but that prerequisite commit is not present in this v6.18 baseline.

In this tree, drivers/pci/controller/cadence/Kconfig defines the symbols as
bool:

config PCIE_CADENCE_PLAT
	bool

config PCIE_CADENCE_PLAT_HOST
	bool "Cadence platform PCIe controller (host mode)"

config PCIE_CADENCE_PLAT_EP
	bool "Cadence platform PCIe controller (endpoint mode)"

And drivers/pci/controller/cadence/pcie-cadence-plat.c registers
cdns_plat_pcie_driver as a built-in driver without including
linux/module.h, defining a .remove callback, or setting MODULE_LICENSE():

static struct platform_driver cdns_plat_pcie_driver = {
	.driver = {
		.name = "cdns-pcie",
		.of_match_table = cdns_plat_pcie_of_match,
		.pm	= &cdns_pcie_pm_ops,
	},
	.probe = cdns_plat_pcie_probe,
	.shutdown = cdns_plat_pcie_shutdown,
};
builtin_platform_driver(cdns_plat_pcie_driver);

Since pcie-cadence-plat can only be compiled built-in (never with -DMODULE),
MODULE_DEVICE_TABLE(of, cdns_plat_pcie_of_match) preprocesses to nothing
under !MODULE and relies on transitive inclusion of linux/module.h. Should
this backport be dropped from this branch, or is commit 611627a4e5e4a also
intended to be backported?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261019135441.1420968-74-sashal@kernel.org?part=1

[PATCH AUTOSEL 6.18-6.1] PCI: switchtec: Add Microchip PCI1008 device ID

[Sasha Levin]

From: Logan Gunthorpe <logang@deltatee.com>

[ Upstream commit 0d8a6306c680ee534be131e360f0cafa2bada7be ]

Add the Microchip PCI1008 device ID to the core switchtec management
driver's PCI ID table. Without it, the management endpoint on a PCI1008
switch is not bound by this driver, preventing userspace tools from
configuring or monitoring the switch and leaving NTB functionality
unavailable.

Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260714212010.230606-3-logang@deltatee.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

This is a one-line PCI ID addition to an existing Switchtec driver. The
local tree is **7.3.0-rc4** (`v7.3-rc4-27-gf0100363d8c37`).
`SWITCHTEC_PCI100X_DEVICE` and the PCI1001–PCI1006 IDs are already here,
so the patch is applicable.

===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================

**Step 1.1: PARSE THE SUBJECT LINE**
Record: [PCI: switchtec] [Add] [Microchip PCI1008 device ID to the
existing switchtec management driver’s PCI ID table]

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
Record:
- Signed-off-by: Logan Gunthorpe <logang@deltatee.com> (author; listed
  maintainer of PCI DRIVER FOR MICROSEMI SWITCHTEC)
- Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> (PCI maintainer)
- Link:
  https://patch.msgid.link/20260714212010.230606-3-logang@deltatee.com
- No Fixes: tag (expected)
- No Reported-by / Tested-by / Reviewed-by / Acked-by / Cc: stable on
  this commit
- Ignore any Sasha Levin SOB (none on the real commit)

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
Record:
- Bug: PCI1008 management endpoint is not bound because 0x1008 is
  missing from `switchtec_pci_tbl`.
- Symptom: userspace cannot configure/monitor the switch via
  `/dev/switchtecX`; NTB is unavailable (probe requests
  `ntb_hw_switchtec` only after this driver binds).
- Version info: series was based on v7.2-rc3; applied by Helgaas for
  v7.3.
- Root cause: incomplete ID table for a new PCI100x SKU, not a logic
  bug.

**Step 1.4: DETECT HIDDEN BUG FIXES**
Record: Not a hidden cleanup. It is an explicit device-ID enablement.
Stable rules treat “just add a device ID” as an accepted class.

===============================================================
PHASE 2: DIFF ANALYSIS
===============================================================

**Step 2.1: INVENTORY THE CHANGES**
Record:
- File: `drivers/pci/switch/switchtec.c` (+1 / −0)
- Function/data: `switchtec_pci_tbl[]` (static PCI ID table)
- Scope: single-file, one-line surgical change

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
Record:
- Before: PCI1001–PCI1006 (vendor `PCI_VENDOR_ID_EFAR` / 0x1055) match
  via `SWITCHTEC_PCI100X_DEVICE`; 0x1008 does not.
- After: 0x1008 matches the same way as 0x1001–0x1006, with `driver_data
  = SWITCHTEC_GEN4`.
- Path: PCI enumeration → `pci_driver.id_table` match →
  `switchtec_pci_probe()`.

**Step 2.3: IDENTIFY THE BUG MECHANISM**
Record:
- Category: hardware enablement / device ID addition
- Mechanism: without the ID, the management function is unbound. Probe
  also does `request_module_nowait("ntb_hw_switchtec")` for
  `PCI_CLASS_BRIDGE_OTHER`, so NTB never attaches.

**Step 2.4: ASSESS THE FIX QUALITY**
Record:
- Obviously correct: same macro and generation as sibling PCI100x IDs.
- Minimal: one table line, no API/behavior change for other devices.
- Regression risk: very low; only PCI1008 (vendor 0x1055, device 0x1008)
  is newly bound.
- Red flags: none.

===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================

**Step 3.1: BLAME THE CHANGED LINES**
Record:
- PCI1001–PCI1006: `a3282f84b2151` (“PCI: switchtec: Add Microchip
  PCI100X device IDs”, 2025-01-20), first described as
  `v6.13-rc1-1-ga3282f84b2151`.
- Sentinel `{0}`: original driver from 2017 (`080b47def5e5e2`).
- PCI1008 line: this commit `0d8a6306c680e`.

**Step 3.2: FOLLOW THE FIXES: TAG**
Record: No Fixes: tag. Not applicable.

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**
Record:
- `a3282f84b2151` added the PCI100X macro, IDs 0x1001–0x1006, and
  matching `SWITCHTEC_PCI100X_QUIRK` entries.
- Series companions (same author/date):
  - `8b326de3cc02c` dmaengine: switchtec-dma: Add PCI1008 device ID
    (msgid -2)
  - `00a479ba1d012` PCI: switchtec: Add Microchip PCI1008 to NTB DMA
    alias quirk (msgid -4)
- This commit is standalone for the management driver. The quirk is
  needed for NTB DMA under IOMMU; DMA ID is a different PCI function.

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**
Record: Logan Gunthorpe is a listed maintainer (`MAINTAINERS`: PCI
DRIVER FOR MICROSEMI SWITCHTEC). He authored the original switchtec
driver and this ID series.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**
Record:
- Needs `SWITCHTEC_PCI100X_DEVICE` and `SWITCHTEC_GEN4` — both present
  here.
- Does not need the dmaengine or quirk commits to compile or bind the
  management device.
- Applies standalone.

===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**
Record:
- `b4 dig -c 0d8a6306c680e`:
  https://patch.msgid.link/20260714212010.230606-3-logang@deltatee.com
- Series: v1 only, `[PATCH v1 0/3] switchtec: add new device IDs`
  (2026-07-14)
- Cover: IDs for PCI driver, DMA driver, and NTB quirk; based on
  v7.2-rc3; intended for the PCI tree
- Sashiko: “found no issues” on this patch
- Bjorn Helgaas (2026-07-17): “Applied to pci/switchtec for v7.3,
  thanks!”
- No NAKs. Unrelated Sashiko note on `quirk_switchtec_ntb_dma_alias()`
  pointer arithmetic was explicitly not a blocker.
- No Cc: stable in the thread.

**Step 4.2: CHECK WHO REVIEWED THE PATCH**
Record (`b4 dig -w`):
- To: linux-pci, dmaengine, Vinod Koul, Bjorn Helgaas
- Cc: Frank Li, Kelvin Cao (Microchip)
- Vinod Acked-by on the dmaengine ID
- PCI maintainer applied the series

**Step 4.3: SEARCH FOR THE BUG REPORT**
Record: No bugzilla/syzbot. Author is the subsystem maintainer adding a
new SKU. Cover letter says Sashiko reminded him the management ID and
NTB quirk were also required.

**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**
Record: 3 independent one-line ID/quirk additions. This patch is 2/3 and
self-contained. Companion quirk is valuable for PCI1008 NTB+IOMMU but is
a separate candidate.

**Step 4.5: CHECK STABLE MAILING LIST HISTORY**
Record: lore.kernel.org/stable search returned HTTP 403. Thread mbox has
no “stable” mentions. UNVERIFIED: whether -stable already discussed this
ID.

===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================

**Step 5.1: IDENTIFY KEY FUNCTIONS**
Record: No function body changed. Data: `switchtec_pci_tbl[]`.
Consumers: `switchtec_pci_driver.id_table`, `MODULE_DEVICE_TABLE(pci,
...)`. Probe: `switchtec_pci_probe()`.

**Step 5.2: TRACE CALLERS**
Record: PCI core matches `id_table` at enumeration/hotplug. Probe
creates `/dev/switchtecX`, enables MRPC, and may load
`ntb_hw_switchtec`. NTB uses `class_interface` on `switchtec_class` (no
second PCI ID table).

**Step 5.3: TRACE CALLEES**
Record: Probe calls `stdev_create`, `switchtec_init_pci`,
`switchtec_init_isr`, `cdev_device_add`. Existing paths; ID only selects
them for this device.

**Step 5.4: FOLLOW THE CALL CHAIN**
Record: Reachable when a PCI1008 is present (`CONFIG_PCI_SW_SWITCHTEC`).
Unprivileged users do not enumerate PCI IDs; impact is hardware owners
of this switch.

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**
Record: Same family already lists 0x1001–0x1006. DMA driver has 0x1008.
`quirks.c` has `SWITCHTEC_PCI100X_QUIRK(0x1008)` from the companion
commit.

===============================================================
PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE
===============================================================

**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**
Record: Yes. `drivers/pci/switch/switchtec.c` has
`SWITCHTEC_PCI100X_DEVICE` and PCI1001–PCI1006. Without 0x1008, PCI1008
would not bind. Prerequisite `a3282f84b2151` is an ancestor (`git merge-
base --is-ancestor` succeeded). PCI100X support dates to v6.13-rc1.

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**
Record: Clean apply. Adjacent lines are the existing PCI100x block. No
refactor conflicts in this checkout.

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**
Record: No alternate PCI1008 ID in switchtec.c besides this line.
Companion DMA ID and NTB quirk are also present here as separate
commits.

===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================

**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**
Record: [PCI switch management driver `drivers/pci/switch/`] [PERIPHERAL
— specific Microchip/Microsemi Switchtec hardware; NTB/management users]

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**
Record: Mature (driver since 2017). Recent work is mostly new IDs (Gen5,
Gen6, PCI100x). Typical stable ID-table churn.

===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================

**Step 8.1: DETERMINE WHO IS AFFECTED**
Record: Driver-specific / config-specific (`CONFIG_PCI_SW_SWITCHTEC`).
Only PCI1008 (0x1055:0x1008). Other Switchtec IDs unchanged.

**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**
Record: Trigger is plugging/booting with a PCI1008. Common for that
hardware; impossible otherwise. Not a userspace-triggerable crash.

**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**
Record: Device not bound → no `/dev/switchtecX`, no NTB. Severity MEDIUM
for those systems (hardware unusable for management/NTB), LOW for
everyone else. Not a panic/UAF.

**Step 8.4: CALCULATE RISK-BENEFIT RATIO**
Record:
- Benefit: high for PCI1008 owners (management + NTB enablement);
  documented stable exception.
- Risk: very low (one ID line, existing macro).
- Ratio: strongly favors backport.

===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================

**Step 9.1: COMPILE THE EVIDENCE**

FOR:
- Stable rules: “fix a real bug … or just add a device ID”
  (`Documentation/process/stable-kernel-rules.rst`).
- Existing driver + PCI100X macro in this tree.
- One line, same pattern as PCI1001–PCI1006.
- Maintainer-authored, PCI maintainer applied, no NAKs.
- Real user impact: management chardev and NTB never attach without the
  ID.

AGAINST:
- Not a crash/security fix; new SKU enablement only.
- Affects a niche PCIe switch.
- Companion quirk is a separate patch (NTB DMA under IOMMU still
  incomplete without it). That does not make this ID wrong or unsafe.

UNRESOLVED:
- lore.kernel.org HTTP 403; stable@ discussion not verified beyond the
  saved thread (no “stable” hits there).

**Step 9.2: APPLY THE STABLE RULES CHECKLIST**
1. Obviously correct and tested? **PASS** — identical to existing
   PCI100x entries; applied by PCI maintainer.
2. Fixes a real bug that affects users? **PASS** — PCI1008 otherwise
   unbound (or qualifies as a device ID addition).
3. Important issue? **PASS** under the device-ID exception (not a
   panic).
4. Small and contained? **PASS** — +1 line, one file.
5. No new features or APIs? **PASS** — ID only; no new ioctls/sysfs.
6. Can apply to the local tree? **PASS** — `SWITCHTEC_PCI100X_DEVICE`
   and sibling IDs present.

**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**
Record: Device ID addition to an existing driver.

**Step 9.4: DECISION**
This is the standard stable device-ID case. The driver and PCI100x
helper exist in this tree, the change is one table line, and without it
PCI1008 management/NTB never bind. Risk is negligible.

The companion NTB DMA alias quirk is a separate one-line candidate; this
ID patch does not depend on it.

Verification:
- [Phase 1] Parsed tags: Logan Gunthorpe SOB, Bjorn Helgaas SOB, lore
  Link; no Fixes/Reported-by/Cc: stable
- [Phase 1] `git describe HEAD` / Makefile: local tree is 7.3.0-rc4
  (`v7.3-rc4-27-gf0100363d8c37`)
- [Phase 2] Diff: +1 line in `switchtec_pci_tbl[]` —
  `SWITCHTEC_PCI100X_DEVICE(0x1008, SWITCHTEC_GEN4)`
- [Phase 2] Confirmed probe uses `id_table` and requests
  `ntb_hw_switchtec` for bridge class
- [Phase 3] `git blame`: PCI1001–1006 from `a3282f84b2151` (v6.13-rc1);
  PCI1008 from `0d8a6306c680e`
- [Phase 3] `git merge-base --is-ancestor a3282f84b2151 HEAD` succeeded
- [Phase 3] Series companions: `8b326de3cc02c` (DMA ID), `00a479ba1d012`
  (NTB quirk)
- [Phase 4] `b4 dig -c 0d8a6306c680e`: lore URL found; v1-only 3-patch
  series
- [Phase 4] `b4 dig -w`: linux-pci, Bjorn Helgaas, Vinod Koul, Microchip
  Cc
- [Phase 4] mbox: Helgaas applied for v7.3; Sashiko clean on this patch;
  Vinod Acked DMA ID; no NAK
- [Phase 4] UNVERIFIED: stable@ mailing list (lore HTTP 403)
- [Phase 5] NTB binds via `switchtec_class` class_interface; this ID is
  required for NTB attach
- [Phase 6] File in tree has PCI100x macro and IDs; patch applies
  cleanly
- [Phase 7] Maintainer entry: Logan Gunthorpe for Switchtec
- [Phase 8] Failure: device unbound, not a kernel crash; device-ID
  exception applies
- [Phase 9] stable-kernel-rules.rst line 15 explicitly allows device ID
  additions

**YES**

 drivers/pci/switch/switchtec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index f32ddfa79da99..30566c2d9f806 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -1874,6 +1874,7 @@ static const struct pci_device_id switchtec_pci_tbl[] = {
 	SWITCHTEC_PCI100X_DEVICE(0x1004, SWITCHTEC_GEN4),  /* PCI1004 16XG4 */
 	SWITCHTEC_PCI100X_DEVICE(0x1005, SWITCHTEC_GEN4),  /* PCI1005 16XG4 */
 	SWITCHTEC_PCI100X_DEVICE(0x1006, SWITCHTEC_GEN4),  /* PCI1006 16XG4 */
+	SWITCHTEC_PCI100X_DEVICE(0x1008, SWITCHTEC_GEN4),  /* PCI1008 16XG4 */
 	{0}
 };
 MODULE_DEVICE_TABLE(pci, switchtec_pci_tbl);
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-6.1] PCI: switchtec: Add Microchip PCI1008 device ID

[sashiko-bot]

> From: Logan Gunthorpe <logang@deltatee.com>
> 
> [ Upstream commit 0d8a6306c680ee534be131e360f0cafa2bada7be ]
> 
> Add the Microchip PCI1008 device ID to the core switchtec management
> driver's PCI ID table. Without it, the management endpoint on a PCI1008
> switch is not bound by this driver, preventing userspace tools from
> configuring or monitoring the switch and leaving NTB functionality
> unavailable.
> 
> Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> Link: https://patch.msgid.link/20260714212010.230606-3-logang@deltatee.com
> Signed-off-by: Sasha Levin <sashal@kernel.org>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261019135441.1420968-78-sashal@kernel.org?part=1

[PATCH AUTOSEL 6.18] PCI: vmd: Add Nova Lake (NVL) and Dunlow (DNL) Device IDs

[Sasha Levin]

From: Szymon Durawa <szymon.durawa@linux.intel.com>

[ Upstream commit 55aa45154fe48b7d8e96bc031ad27d5b0edfcdb8 ]

Add VMD Device ID Support for Intel NVL/DNL processors.

Suggested-by: Nirmal Patel <nirmal.patel@linux.intel.com>
Signed-off-by: Szymon Durawa <szymon.durawa@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Nirmal Patel <nirmal.patel@linux.intel.com>
Cc: Jonathan Derrick <jonathan.derrick@linux.dev>
Link: https://patch.msgid.link/20260819130523.398493-1-szymon.durawa@linux.intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

This tree is **6.12.111** (`p-6.12-3-gc504cf0baa3d8`). The commit is a
PCI ID table update for the existing Intel VMD driver, and that driver
plus `VMD_FEATS_CLIENT` are already here.

===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================

**Step 1.1:** Record: `[PCI: vmd] [Add] Add Nova Lake (NVL) and Dunlow
(DNL) Device IDs`

**Step 1.2:** Tags (ignoring pipeline `Signed-off-by: Sasha Levin` /
`[Upstream commit ...]`):
- Suggested-by: Nirmal Patel (Intel VMD maintainer)
- Signed-off-by: Szymon Durawa (author, Intel)
- Signed-off-by: Bjorn Helgaas (PCI maintainer; applied it)
- Cc: Nirmal Patel, Jonathan Derrick
- Link: https://patch.msgid.link/20260819130523.398493-1-
  szymon.durawa@linux.intel.com
- No Fixes:, Reported-by, Tested-by, Reviewed-by in the committed
  message (Reviewed-by: Nirmal Patel was given on v1 but not copied into
  the commit)
- No Cc: stable (expected for this review)

**Step 1.3:** Record: Bug description: none as a crash/leak. The body is
one sentence: add VMD Device IDs for Intel NVL/DNL. Failure mode without
the patch: `vmd` does not bind to 8086:d70b / 8086:d73b, so NVMe/PCIe
devices under Intel RST/VMD stay hidden. No version range in the
message. Root cause: missing PCI IDs in `vmd_ids[]`.

**Step 1.4:** Record: Not a hidden bug fix. It is a hardware-ID
enablement patch, which is an explicit stable exception.

===============================================================
PHASE 2: DIFF ANALYSIS
===============================================================

**Step 2.1:** Record: `drivers/pci/controller/vmd.c` only; +4 / -0.
Function/data: `vmd_ids[]`. Scope: single-file surgical ID add.

**Step 2.2:** Record: Before: table ends at 0xb07f (mainline) / 0xb06f
(this 6.12 tree). After: 0xd70b and 0xd73b appended with `.driver_data =
VMD_FEATS_CLIENT`. Probe path for those IDs then runs `vmd_probe()` →
`vmd_enable_domain()`.

**Step 2.3:** Record: Category **h) hardware workarounds / device ID
additions**. Mechanism: PCI core matches the ID table; without the
entries the driver never probes.

**Step 2.4:** Record: Obviously correct; same pattern as existing client
SKUs (0x7d0b, 0xad0b, 0xb60b, 0xb06f). No locking/API/data-structure
change. Regression risk is very low: only systems with those two IDs are
affected, and they currently have no VMD driver at all.

===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================

**Step 3.1:** Record: `vmd_ids[]` dates to 2016 (`185a383ada2e`).
`VMD_FEATS_CLIENT` grouping is `14d2079af6483` (2023, in this tree).
Last IDs in this tree are 0xb60b/0xb06f from `34883c93bd330` (already
backported to 6.12.y). 0xd70b/0xd73b are absent here. 0xb07f is in the
parent context of the mainline commit but **not** in this tree; it is a
sibling ID, not a functional prerequisite.

**Step 3.2:** Record: No Fixes: tag. Not applicable.

**Step 3.3:** Record: Same-file history includes several prior DID adds
that followed this exact pattern:
- `57a128acaba02` PCI: vmd: Add DID 8086:7D0B and 8086:AD0B for Intel
  MTL SKUs
- `34883c93bd330` PCI: vmd: Add DID 8086:B06F and 8086:B60B for Intel
  client SKUs (already in this 6.12 tree)
Standalone; not patch X/Y of a series that this commit depends on.

**Step 3.4:** Record: Author Szymon Durawa has no other VMD commits in
this tree. Suggested/reviewed by Nirmal Patel, who authored the previous
client DID add in this file.

**Step 3.5:** Record: Uses existing `PCI_VDEVICE` and
`VMD_FEATS_CLIENT`. Does not use later v7.3 features
(`VMD_FEAT_USE_BIOS_INFO`, BUS_RESTRICT_CFG=3). Those other v7.3 VMD
patches target different IDs (0x28C1 / Arrow Lake-HX). Can apply
standalone.

===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================

**Step 4.1:** Record: Mainline SHA
`55aa45154fe48b7d8e96bc031ad27d5b0edfcdb8` (not an ancestor of this
HEAD).
- b4 dig: https://patch.msgid.link/20260819130523.398493-1-
  szymon.durawa@linux.intel.com
- v1: 2026-07-08 (duplicate subject, missing CCs)
- v2: 2026-07-29 (CCs added)
- v3: 2026-08-19 (description added) — this is what was applied
- No NAKs. Manivannan asked for a changelog body and full maintainer CC.
  Nirmal Patel Reviewed-by on v1. Bjorn: “Applied to pci/controller/vmd
  for v7.3”. No reviewer asked for Cc: stable.

**Step 4.2:** Record: Recipients included linux-pci, Bjorn Helgaas,
Nirmal Patel, Jonathan Derrick, Dan Williams, Lukas Wunner, Lorenzo
Pieralisi, Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring.
Right maintainers were on the thread by v2/v3.

**Step 4.3:** Record: No syzbot/bugzilla report. This is Intel
enablement, not a fuzzer crash.

**Step 4.4:** Record: Standalone 1-patch series. Same v7.3 VMD merge
also had BIOS-info / BUS_RESTRICT_CFG=3 / _OSC patches; this ID add does
not depend on them.

**Step 4.5:** Record: No stable-list discussion found
(lore.kernel.org/stable returned 403; web search did not show a stable
thread for this subject). Absence is not a negative signal.

===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================

**Step 5.1:** Record: Modified `vmd_ids[]` only. Consumers:
`vmd_drv.id_table` → PCI core → `vmd_probe()`.

**Step 5.2:** Record: Callers of `vmd_probe()`: PCI bus match on VMD
devices. Context: driver probe during enumeration (boot / module load),
not IRQ/hot path. Impact surface: only 8086:d70b and 8086:d73b.

**Step 5.3:** Record: `vmd_probe()` uses `id->driver_data` as feature
flags, then `vmd_enable_domain()`. `VMD_FEATS_CLIENT` already includes
membar shadow VSCAP, bus restrictions, first-vector offset, BIOS PM
quirk.

**Step 5.4:** Record: Reachable whenever firmware presents those PCI IDs
(Intel RST/VMD mode on NVL/DNL). Userspace cannot invent the IDs;
missing IDs mean missing NVMe.

**Step 5.5:** Record: Same pattern as every recent client VMD DID add.
`34883c93bd330` is the direct precedent already in this tree.

===============================================================
PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE
===============================================================

**Step 6.1:** Record: VMD driver exists (`drivers/pci/controller/vmd.c`,
`CONFIG_VMD`). `VMD_FEATS_CLIENT` exists at lines 83–86. Current table
ends at 0xb06f (lines 1109–1132). 0xd70b and 0xd73b are **not** present.
Hardware is new; the *driver* has been here for years.

**Step 6.2:** Record: Backport difficulty: **minor context tweak**. Hunk
context mentions 0xb07f, which this tree lacks. Insert the two entries
after 0xb06f. No semantic rework.

**Step 6.3:** Record: No equivalent NVL/DNL IDs already here. `git
merge-base --is-ancestor 55aa45154fe48b7d8e96bc031ad27d5b0edfcdb8 HEAD`
failed (not in this tree).

===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================

**Step 7.1:** Record: Subsystem PCI host controller / Intel VMD.
Criticality: **IMPORTANT** for Intel client systems using RST/VMD
(common laptop default); not core mm/fs, but storage disappearance is
user-visible.

**Step 7.2:** Record: Mature driver (since ~2016). Recent 6.12 VMD work
is bugfixes plus prior DID adds. This is the same mature ID-table
pattern.

===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================

**Step 8.1:** Record: Affected users: Intel Nova Lake / Dunlow systems
with VMD enabled (`CONFIG_VMD`, x86_64). Not universal.

**Step 8.2:** Record: Trigger: boot/enumeration on that hardware. Common
on those SKUs if BIOS leaves RST/VMD on. Not a race; not unprivileged-
exploit.

**Step 8.3:** Record: Failure mode: VMD and child NVMe never bind →
missing system/data disks. Severity: **HIGH** for those platforms
(storage unavailable), not a kernel oops.

**Step 8.4:** Record: Benefit high for NVL/DNL on 6.12.y (LTS still
receiving updates at 6.12.111). Risk very low: 4 lines, existing flags,
existing probe path. Precedent: 0xb06f/0xb60b already backported here.

===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================

**Step 9.1:** FOR:
- Stable exception: PCI ID add to an existing driver
- Driver, `VMD_FEATS_CLIENT`, and probe path all present in 6.12.111
- Same pattern already backported (`34883c93bd330`)
- 4 lines, no new APIs, no new features beyond matching two IDs
- Suggested/reviewed by VMD maintainer; applied by PCI maintainer
- Without it, NVMe behind VMD is invisible on those CPUs

AGAINST:
- Not a crash/UAF/security fix
- Context mentions 0xb07f, absent here (trivial adjust)
- NVL/DNL are newer than 6.12’s original release; other platform bits
  may still be missing on a given machine — but that is true of every
  DID backport and is not a reason to omit the IDs

UNRESOLVED:
- Could not read lore.kernel.org/stable (403). No evidence of a
  deliberate stable skip.

**Step 9.2:** Stable rules:
1. Obviously correct and tested? **PASS** (standard ID table; maintainer
   review + applied)
2. Fixes a real bug that affects users? **PASS** (devices never bind
   without the IDs)
3. Important issue? **PASS** under the device-ID exception; storage non-
   enumeration is serious for affected hardware
4. Small and contained? **PASS** (4 lines, one table)
5. No new features or APIs? **PASS** (IDs only; existing feature flags)
6. Can apply to this tree? **PASS** (minor context conflict only)

**Step 9.3:** Record: Exception category: **NEW DEVICE IDs** on an
existing driver.

**Step 9.4:** Backport. The local tree has the driver and the client
feature set; this is the same class of change already taken for earlier
Intel client VMD IDs.

Verification:
- [Phase 1] Parsed tags: Suggested-by Nirmal Patel; SOB Durawa +
  Helgaas; Link msgid 20260819130523.398493-1; no Fixes/syzbot
- [Phase 2] Diff: +4 lines in `vmd_ids[]` for 0xd70b and 0xd73b with
  `VMD_FEATS_CLIENT`
- [Phase 3] blame: table from 2016; `VMD_FEATS_CLIENT` from
  `14d2079af6483` (in tree); last IDs `34883c93bd330` (in tree)
- [Phase 3] No Fixes: tag
- [Phase 3] `git merge-base --is-ancestor
  55aa45154fe48b7d8e96bc031ad27d5b0edfcdb8 HEAD` → not in this tree
- [Phase 4] `b4 dig -c 55aa45154fe48b7d8e96bc031ad27d5b0edfcdb8`:
  matched v1/v2/v3; v3 applied
- [Phase 4] `b4 dig -w`: linux-pci + Helgaas + Patel on original To/Cc
- [Phase 4] v1 mbox: Manivannan requested description/CCs; Nirmal Patel
  Reviewed-by; no NAK
- [Phase 4] v3 mbox: Helgaas applied for v7.3
- [Phase 4] lore.kernel.org/stable fetch: 403, UNVERIFIED whether it was
  discussed on stable@
- [Phase 5] `vmd_probe()` reads `id->driver_data`; `CONFIG_VMD` in
  `drivers/pci/controller/Kconfig`
- [Phase 6] `git describe HEAD` / Makefile: 6.12.111; IDs
  0xd70b/0xd73b/0xb07f absent from local `vmd.c`
- [Phase 6] `VMD_FEATS_CLIENT` present at lines 83–86 of local `vmd.c`
- [Phase 8] Failure mode: VMD/NVMe not enumerated on NVL/DNL, not a
  panic

This is a four-line PCI ID addition to a driver that already exists in
6.12.y, using feature flags already used by other client SKUs. That is
exactly the stable device-ID exception.

**YES**

 drivers/pci/controller/vmd.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
index 5d3e6cc7e4feb..aa6d4f56f612a 100644
--- a/drivers/pci/controller/vmd.c
+++ b/drivers/pci/controller/vmd.c
@@ -1141,6 +1141,10 @@ static const struct pci_device_id vmd_ids[] = {
                 .driver_data = VMD_FEATS_CLIENT,},
 	{PCI_VDEVICE(INTEL, 0xb07f),
                 .driver_data = VMD_FEATS_CLIENT,},
+	{PCI_VDEVICE(INTEL, 0xd70b),
+		.driver_data = VMD_FEATS_CLIENT,},
+	{PCI_VDEVICE(INTEL, 0xd73b),
+		.driver_data = VMD_FEATS_CLIENT,},
 	{0,}
 };
 MODULE_DEVICE_TABLE(pci, vmd_ids);
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18] PCI: vmd: Add Nova Lake (NVL) and Dunlow (DNL) Device IDs

[sashiko-bot]

> From: Szymon Durawa <szymon.durawa@linux.intel.com>
> 
> [ Upstream commit 55aa45154fe48b7d8e96bc031ad27d5b0edfcdb8 ]
> 
> Add VMD Device ID Support for Intel NVL/DNL processors.
> 
> Suggested-by: Nirmal Patel <nirmal.patel@linux.intel.com>
> Signed-off-by: Szymon Durawa <szymon.durawa@linux.intel.com>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Nirmal Patel <nirmal.patel@linux.intel.com>
> Cc: Jonathan Derrick <jonathan.derrick@linux.dev>
> Link: https://patch.msgid.link/20260819130523.398493-1-szymon.durawa@linux.intel.com
> Signed-off-by: Sasha Levin <sashal@kernel.org>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261019135441.1420968-115-sashal@kernel.org?part=1

[PATCH AUTOSEL 6.18-6.1] PCI: Avoid saving config space state if inaccessible

[Sasha Levin]

From: Farhan Ali <alifm@linux.ibm.com>

[ Upstream commit e18d1abc3bff0a24a5299f3c150ab9546e9439aa ]

The current reset process saves the device's config space state before
reset and restores it afterward. However errors may occur unexpectedly and
it may then be impossible to save config space because the device may be
inaccessible (e.g. DPC). This results in saving invalid values that get
written back to the device during state restoration.

With a reset we want to recover/restore the device into a functional state.
So avoid saving the state of the config space when the device config space
is inaccessible.

Signed-off-by: Farhan Ali <alifm@linux.ibm.com>
[bhelgaas: comment]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260805165518.794-4-alifm@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The local tree is **6.12.111**. The buggy reset-time save path is
present here; this is a small, self-contained PCI error-recovery fix for
that path.

===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================

**Step 1.1: PARSE THE SUBJECT LINE**
Record: **[PCI]** **[Avoid]** Avoid saving config space state if
inaccessible. “Avoid” here is a bug-fix verb: skip a save that would
capture invalid `~0` values.

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
Record:
- Signed-off-by: Farhan Ali \<alifm@linux.ibm.com\> (author)
- Signed-off-by: Bjorn Helgaas \<bhelgaas@google.com\> (PCI maintainer;
  also `[bhelgaas: comment]`)
- Reviewed-by: Niklas Schnelle \<schnelle@linux.ibm.com\>
- Reviewed-by: Bjorn Helgaas \<bhelgaas@google.com\>
- Link:
  https://patch.msgid.link/20260805165518.794-4-alifm@linux.ibm.com
- No Fixes:, Reported-by:, Tested-by:, or Cc: stable (absence expected
  for this review)
- Ignore pipeline markers (none in the provided message except the
  evaluation context)

Notable: PCI maintainer both reviewed and applied it. The msgid is **v23
3/5** of “Error recovery for vfio-pci devices on s390x” (cover is `-1`,
so `-4` is patch 3/5).

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
Record:
- **Bug:** Reset saves config space, then restores it. If the device is
  inaccessible (example given: DPC), reads return `~0`. Those invalid
  values are saved and later written back.
- **Symptom:** After reset/error recovery the device is programmed with
  garbage (invalid BARs / Command register), so it does not come back
  functional.
- **Root cause:** Unconditional `pci_save_state()` in the reset path
  while config space may already be gone.
- **Fix:** Do not save (or disable via Command) when config space is
  inaccessible.
- **Versions:** None stated; DPC/AER reset is long-standing.

**Step 1.4: DETECT HIDDEN BUG FIXES**
Record: Not hidden. This is an explicit correctness fix for invalid
save/restore during error recovery.

===============================================================
PHASE 2: DIFF ANALYSIS - LINE BY LINE
===============================================================

**Step 2.1: INVENTORY THE CHANGES**
Record:
- File: `drivers/pci/pci.c` only (~+24 lines, 0 removed)
- New helper: `pci_dev_config_accessible()`
- Modified: `pci_dev_save_and_disable()`
- Scope: single-file surgical fix

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
Record:
- **Helper:** Read dword at `PCI_COMMAND` (Command + Status). If
  `PCI_POSSIBLE_ERROR(val)` (`== ~0`), warn and return false. Uses
  Command/Status rather than Vendor/Device ID because VFs can
  legitimately read as `~0` there.
- **`pci_dev_save_and_disable` before:** After
  `pci_set_power_state(D0)`, always `pci_save_state()` then write
  `PCI_COMMAND_INTX_DISABLE`.
- **After:** If config is inaccessible, return without saving or writing
  Command. `reset_prepare` and D0 wake still run.
- Path: reset / error-recovery, not probe or normal PM suspend.

**Step 2.3: IDENTIFY THE BUG MECHANISM**
Record: **Logic / correctness** in error recovery.
- Broken: inaccessible config → `pci_save_state()` fills
  `saved_config_space[]` with `~0` and sets `state_saved`.
  `pci_restore_state()` later writes that back (BARs `0xFFFFFFFF`,
  Command `0xFFFF`).
- Fix: skip that overwrite so restore uses the last good snapshot
  (enumeration-time save in this tree, or a driver’s later
  `pci_save_state()`).

**Step 2.4: ASSESS THE FIX QUALITY**
Record:
- Obviously correct: same `PCI_POSSIBLE_ERROR` heuristic already used
  across PCI.
- Minimal: one check, no API change.
- Residual race is documented (device can disappear between check and
  save); that is pre-existing, not introduced.
- False positive (`Command|Status` actually `0xFFFFFFFF` on a live
  device) is vanishingly unlikely; Status reserved bits typically read
  0.
- Skipping the Command disable when inaccessible is a no-op: that write
  would not land anyway.
- Regression risk: **low**. Healthy reset path is unchanged.

===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================

**Step 3.1: BLAME THE CHANGED LINES**
Record:
- Unconditional `pci_save_state()` in `pci_dev_save_and_disable()` comes
  from Alex Williamson, 2013 (`77cb985ad4acbe` / `a6cbaadea0af9`).
- Function itself dates to Keith Busch 2014 / Christoph Hellwig 2017.
- Bug is old; it became more important after enumeration-time save +
  always-restore.

**Step 3.2: FOLLOW THE FIXES: TAG**
Record: No Fixes: tag. Related in-tree commit **`58130e7ce6cb6`**
(`PCI/ERR: Ensure error recoverability at all times`, upstream
`a2f1e22390ac`) is an ancestor of HEAD. It:
- Calls `pci_save_state()` at device add (`drivers/pci/bus.c`)
- Removes the `if (!dev->state_saved) return;` in `pci_restore_state()`

Verified in this checkout: `pci_save_state(dev)` at
`pci_bus_add_device()` (placement later adjusted by `f8f55a226aab4`).
Restore no longer bails on `state_saved`. So a garbage reset-time save
**will** be restored. This patch is what keeps that snapshot valid when
DPC has already isolated the device.

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**
Record:
- Same series, already in this tree: **`1872805e97043`** `PCI/MSI:
  Enable memory decoding before restoring MSI-X messages` (v23 5/5, `Cc:
  stable`).
- Not in this tree: v23 1/5 slot placeholder, 2/5 s390 per-function
  slots, **this 3/5**, 4/5 “Fail FLR when config space inaccessible”.
- Recent `pci.c` churn is unrelated (D3hot wait, ASPM, ACS, slot
  locking).

This patch is **standalone**. 1/5 and 2/5 are s390 slot work. 4/5 *uses*
`pci_dev_config_accessible()` but is not required for the save-garbage
fix. 5/5 already landed independently.

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**
Record: Farhan Ali (IBM) works on s390 PCI / vfio. In this tree the
related MSI-X restore fix is already present. Helgaas (subsystem
maintainer) reviewed and applied.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**
Record:
- Needs `PCI_POSSIBLE_ERROR` — present in `include/linux/pci.h`.
- Needs `pci_find_dvsec_capability` only as an insertion landmark —
  present at `drivers/pci/pci.c:762`.
- Needs `pci_dev_save_and_disable` / `pci_save_state` — present.
- `device_lock_assert` / `pci_warn(..., "resetting")` in the *upstream
  context* are **not** in 6.12; they are context-only, not part of this
  change. Insertion is after `pci_set_power_state(dev, PCI_D0)`, which
  matches this tree.
- Can apply standalone: **yes**.

===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**
Record:
- `b4 dig -c 5e14afc4aa192` failed (that string is a **blob** hash from
  the candidate diff, not a commit).
- `b4 mbox` on msgid `20260805165518.794-4-alifm@linux.ibm.com`:
  23-message thread saved.
- Lore/cover: v23 0/5 “Error recovery for vfio-pci devices on s390x”;
  this is **3/5**.
- Earlier revisions (v9) tried to **never** save at reset (rely only on
  enumeration save). Reviewers (Helgaas / Alex Williamson) rejected that
  because normal resets must capture current driver-programmed state.
  v22/v23 compromise: skip save **only** when config reads as `~0`.
- Helgaas rewrote the comment on apply (`[bhelgaas: comment]`).
  Functional code matches v23.
- Sashiko: low `const char *msg` nit only. No NAK on this patch.
- No reviewer asked for Cc: stable on **this** patch (unlike 2/5 and
  5/5). That is not a negative for this evaluation.

**Step 4.2: CHECK WHO REVIEWED THE PATCH**
Record: linux-pci via Helgaas; Niklas Schnelle (s390 PCI). Right
maintainers.

**Step 4.3: SEARCH FOR THE BUG REPORT**
Record: No syzbot/bugzilla. Motivated by s390 vfio-pci DPC/error
recovery (IBM). Mechanism is generic for any AER/DPC isolation, not
s390-only.

**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**
Record: v23 1–5 as above. 4/5 adds the same helper use in `pcie_flr()`;
Helgaas was lukewarm on that racy FLR-only check but still merged this
save-path patch. 5/5 already in 6.12.111.

**Step 4.5: CHECK STABLE MAILING LIST HISTORY**
Record: lore.kernel.org/stable WebFetch returned 403. **UNVERIFIED**
whether stable@ discussed this exact subject. 5/5 from the same series
*was* explicitly Cc: stable and is already here.

===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================

**Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF**
Record: `pci_dev_config_accessible()` (new),
`pci_dev_save_and_disable()` (modified).

**Step 5.2: TRACE CALLERS**
Record: `pci_dev_save_and_disable()` is static; callers in this tree:
- `pci_reset_function()` — sysfs/`EXPORT` function reset
- `pci_reset_function_locked()`
- `pci_try_reset_function()`
- `pci_bus_save_and_disable_locked()` ← `__pci_reset_bus()`
- `pci_slot_save_and_disable_locked()` ← `__pci_reset_slot()`

AER uses `pci_bus_error_reset()` → slot reset or bus reset, which
save/disable then restore. Userspace can also hit this via
`/sys/bus/pci/devices/.../reset`.

**Step 5.3: TRACE CALLEES**
Record: `pci_read_config_dword`, `PCI_POSSIBLE_ERROR`, `pci_warn`; then
existing `pci_save_state` / Command write.

**Step 5.4: FOLLOW THE CALL CHAIN**
Record: User-reachable via sysfs reset and via AER/DPC error IRQs. DPC
is the cited case: config reads `~0` while containment is active, then
reset+restore. **Yes, reachable.**

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**
Record: `PCI_POSSIBLE_ERROR` already used in `pci.c` PM paths, DPC,
probe, hotplug. 4/5 of this series reuses the new helper for FLR; not in
this tree yet and not required for this verdict.

===============================================================
PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE
===============================================================

**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**
Record: **Yes.** `pci_dev_save_and_disable()` at
`drivers/pci/pci.c:5047` still does unconditional `pci_save_state()`
after D0. `pci_dev_config_accessible()` does **not** exist. `make
kernelversion` / Makefile: **6.12.111**. Bug introduced with 2013 reset
save/disable; still here.

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**
Record: **Clean apply / trivial context.** Helper can sit after existing
`pci_find_dvsec_capability()`. The three-line guard goes after
`pci_set_power_state(dev, PCI_D0)` before `pci_save_state(dev)` —
identical here. Upstream context lines (`device_lock_assert`,
`"resetting"` warn) are later mainline-only and are not part of this
patch.

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**
Record: Enumeration save + always-restore (**`58130e7ce6cb6`**) is here;
without this patch it can restore **poisoned** `~0` state after DPC.
MSI-X Memory-enable restore (**`1872805e97043`**) is here. No substitute
for this skip-save check.

===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================

**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**
Record: **PCI core** (`drivers/pci/pci.c`). **IMPORTANT** (all PCI
devices; error recovery and function reset). Not staging.

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**
Record: Mature core with ongoing AER/DPC/reset work. This is a targeted
recovery fix, not a refactor.

===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================

**Step 8.1: DETERMINE WHO IS AFFECTED**
Record: PCI error recovery (AER/DPC) and anyone resetting a device whose
config is gone. Originally s390 vfio-pci passthrough; same path is
generic. Config-specific: PCI + AER/DPC/reset users (common on servers).

**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**
Record: DPC/containment or other inaccessible config during reset. Not
every boot; when it hits, recovery is the path that should restore the
device. Unprivileged users can trigger sysfs reset only with privilege;
AER/DPC is hardware-driven.

**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**
Record: Restore of `~0` → invalid BARs, Command all-ones (I/O, MMIO, bus
master, SERR). Device stays broken after “recovery”; possible further
URs / bad DMA. **Severity: HIGH** (failed recovery, device unusable;
bus-master with junk BARs is worse than a leak).

**Step 8.4: CALCULATE RISK-BENEFIT RATIO**
Record:
- **Benefit: HIGH** — preserves last good config through DPC/reset;
  completes recoverability that `58130e7ce6cb6` already shipped in this
  tree.
- **Risk: LOW** — ~24 lines, established heuristic, healthy devices
  unchanged.
- **Ratio:** strongly favors backport.

===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================

**Step 9.1: COMPILE THE EVIDENCE**

FOR:
- Real bug: save/restore of `~0` config during inaccessible reset (DPC).
- Failure is failed PCI recovery and a device left misprogrammed.
- Small, obviously correct, reviewed by Helgaas and Schnelle.
- Buggy code and insertion points exist in 6.12.111.
- Enumeration-time save already in this tree; this patch prevents
  clobbering it.
- Same series’ 5/5 already backported here.
- Standalone vs s390 slot patches.

AGAINST:
- No Cc: stable / Fixes: on this commit (expected; not a veto).
- Trigger is error recovery, not the hot path.
- Check is racy (documented); Helgaas still merged it.
- 4/5 (fail FLR) not included; incomplete vs full series, but this hunk
  still fixes the save-poisoning bug on its own.

UNRESOLVED:
- Stable-list thread 403; could not confirm prior stable@ discussion.

**Step 9.2: APPLY THE STABLE RULES CHECKLIST**
1. Obviously correct and tested? **PASS** — Helgaas+Schnelle Reviewed-
   by; heuristic already in-tree.
2. Fixes a real bug that affects users? **PASS** — DPC/error recovery
   restores garbage config.
3. Important issue? **PASS** — HIGH: recovery failure / device left with
   invalid BARs and Command.
4. Small and contained? **PASS** — one file, ~24 lines.
5. No new features or APIs? **PASS** — static helper + guard.
6. Can apply to the local tree? **PASS** — same functions and insertion
   point in 6.12.111.

**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**
Record: Not an ID/quirk/DT/build/docs exception. Ordinary important bug
fix.

**Step 9.4: MAKE YOUR DECISION**
Backport. It prevents writing invalid `~0` config back after reset when
the device is already inaccessible, which is exactly the DPC/AER
recovery case this 6.12 tree already tries to support via enumeration-
time save.

------------------------------------------------
What the commit solves for this tree
------------------------------------------------
On 6.12.111, reset still always calls `pci_save_state()` in
`pci_dev_save_and_disable()`. If config reads as `~0` (DPC), that
poisons `saved_config_space`. `pci_restore_state()` no longer refuses
restore (`58130e7ce6cb6`), so those values get programmed back. Skipping
the save keeps the enumeration (or last good) snapshot.

Risk vs benefit: low risk, high benefit. No new API. Apply is clean
aside from unrelated later context around `device_lock_assert`.

------------------------------------------------
Verification
------------------------------------------------
- [Phase 1] Subject/tags parsed from the candidate message; Link msgid
  is v23 3/5.
- [Phase 2] Diff: helper + 3-line guard in `pci_dev_save_and_disable`;
  `pci_save_state()` in this tree writes `saved_config_space[]` and sets
  `state_saved` with no accessibility check.
- [Phase 3] `git describe` / `make kernelversion`: p-6.12-3 /
  **6.12.111**.
- [Phase 3] `git blame -L 5047,5076 drivers/pci/pci.c`: unconditional
  save from 2013 Williamson commits.
- [Phase 3] `git merge-base --is-ancestor 58130e7ce6cb6 HEAD`: yes;
  enumeration save + restore-always.
- [Phase 3] `git merge-base --is-ancestor 1872805e97043 HEAD`: yes;
  series 5/5 already here.
- [Phase 3] `git log --grep='Avoid saving config'` on `drivers/pci/`:
  this fix **not** present.
- [Phase 4] `b4 mbox` msgid 20260805165518.794-4: 23 msgs; Helgaas
  Reviewed-by; no NAK on 3/5.
- [Phase 4] Cover letter: PCI slice of vfio-pci s390 error recovery; v9
  “never save at reset” was rejected.
- [Phase 4] lore.kernel.org/stable: **UNVERIFIED** (HTTP 403).
- [Phase 5] Callers of `pci_dev_save_and_disable` traced in `pci.c`; AER
  `pci_bus_error_reset` → slot/bus reset save/restore.
- [Phase 6] `pci_find_dvsec_capability` at line 762;
  `PCI_POSSIBLE_ERROR` in `include/linux/pci.h`; `PCI_COMMAND` is 0x04.
- [Phase 6] `pcie_flr()` in this tree has no accessibility check (4/5
  not required for this verdict).
- UNVERIFIED: whether Command+Status can be legitimate `0xFFFFFFFF` on
  some broken device (kernel-wide heuristic already accepts that risk).

**YES**

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

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 264213aa7630b..16942779e6ebd 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -725,6 +725,28 @@ u16 pci_find_dvsec_capability(struct pci_dev *dev, u16 vendor, u16 dvsec)
 }
 EXPORT_SYMBOL_GPL(pci_find_dvsec_capability);
 
+static bool pci_dev_config_accessible(struct pci_dev *dev, char *msg)
+{
+	u32 val;
+
+	/*
+	 * If a device's config space is inaccessible, reads typically
+	 * return ~0.  Since Device and Vendor ID are always ~0 for VFs,
+	 * check the Command and Status registers instead.
+	 *
+	 * N.B. This is racy because the device may become inaccessible
+	 * before the next access.
+	 */
+	pci_read_config_dword(dev, PCI_COMMAND, &val);
+	if (PCI_POSSIBLE_ERROR(val)) {
+		pci_warn(dev, "Device config space inaccessible; unable to %s\n",
+				msg);
+		return false;
+	}
+
+	return true;
+}
+
 /**
  * pci_find_parent_resource - return resource region of parent bus of given
  *			      region
@@ -5009,6 +5031,9 @@ static void pci_dev_save_and_disable(struct pci_dev *dev)
 	 */
 	pci_set_power_state(dev, PCI_D0);
 
+	if (!pci_dev_config_accessible(dev, "save state"))
+		return;
+
 	pci_save_state(dev);
 	/*
 	 * Disable the device by clearing the Command register, except for
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-6.1] PCI: Avoid saving config space state if inaccessible

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] pci: skipping pci_save_state() in pci_dev_save_and_disable() breaks restore
--

commit 4874b436f59a1ea615f5afac75821d16d1d67918
Author: Farhan Ali <alifm@linux.ibm.com>

PCI: Avoid saving config space state if inaccessible

This commit adds a helper to check whether PCI config space is accessible
before saving state during device reset, skipping pci_save_state() when
reads return an error response.

Link: https://patch.msgid.link/20260805165518.794-4-alifm@linux.ibm.com

> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b14dd064006cc..78048bce859d4 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c

[ ... ]

> @@ -5127,6 +5149,9 @@ static void pci_dev_save_and_disable(struct pci_dev *dev)
>  	 */
>  	pci_set_power_state(dev, PCI_D0);
>  
> +	if (!pci_dev_config_accessible(dev, "save state"))
> +		return;
> +
>  	pci_save_state(dev);
>  	/*
>  	 * Disable the device by clearing the Command register, except for

[Severity: High]
Does skipping pci_save_state() in pci_dev_save_and_disable() prevent
pci_dev_restore() -> pci_restore_state() from restoring config space after
the reset completes?

Upstream commit e18d1abc3bff0a24a5299f3c150ab9546e9439aa relies on
prerequisite commit a2f1e22390ac ("PCI/ERR: Ensure error recoverability at
all times"), which added pci_save_state(dev) to pci_bus_add_device() during
enumeration and removed the dev->state_saved check from
pci_restore_state().

In this tree, commit a2f1e22390ac is not present.  In drivers/pci/probe.c,
pci_device_add() initializes dev->state_saved = false, and in
drivers/pci/bus.c, pci_bus_add_device() does not call pci_save_state(dev):

drivers/pci/probe.c:pci_device_add() {
	...
	dev->state_saved = false;

	pci_init_capabilities(dev);
	...
}

Furthermore, in drivers/pci/pci.c, pci_restore_state() still checks
dev->state_saved at entry and clears it on every restore:

drivers/pci/pci.c:pci_restore_state() {
	if (!dev->state_saved)
		return;
	...
	dev->state_saved = false;
}

When config space is inaccessible prior to a reset (such as during DPC
containment or link-down error recovery via pci_reset_function(),
pci_reset_function_locked(), pci_try_reset_function(), __pci_reset_bus(),
or __pci_reset_slot()) and dev->state_saved is false — either because no
driver saved state at probe or because a prior reset or PM transition
(such as vfio_pci_ioctl_reset(), pci_reset_bus(), vfio_pci_set_power_state(),
or pci_pm_runtime_resume()) already called pci_restore_state() and cleared
dev->state_saved = false — returning early in pci_dev_save_and_disable()
leaves dev->state_saved as false.

When the reset finishes and pci_dev_restore() calls pci_restore_state(dev):

drivers/pci/pci.c:pci_dev_restore() {
	const struct pci_error_handlers *err_handler =
			dev->driver ? dev->driver->err_handler : NULL;

	pci_restore_state(dev);
	...
}

won't pci_restore_state() bail out immediately without restoring BARs,
PCI_COMMAND, MSI/MSI-X, or PCIe capabilities, leaving the device at its
unconfigured post-reset register defaults?

Should prerequisite commit a2f1e22390ac ("PCI/ERR: Ensure error
recoverability at all times") be backported along with this change?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261019135441.1420968-191-sashal@kernel.org?part=1

[PATCH AUTOSEL 6.18-5.10] PCI/portdrv: Allow probing even without child services

[Sasha Levin]

From: Brian Norris <briannorris@chromium.org>

[ Upstream commit 834171efeefffb1a0f2136f32e76669bbc11db86 ]

The PCIe port driver fails to probe if it finds no child services,
presumably under the assumption that the driver is not useful in that case.
However, the driver *can* still be useful for power management support --
namely, it still configures the port for runtime PM / D3, which may be
important for allowing a bridge to enter low power modes.

Thus, allow probe to succeed even if no IRQs and no child services are
available. This also mirrors existing behavior for ports that don't support
any portdrv services (PCIe hotplug, AER, DPC, PME, bwctrl), where we'd also
probe successfully.

This change is a bit more important after commit f5cd8a929c82 ("PCI: dwc:
Remove MSI/MSIX capability for Root Port if iMSI-RX is used as MSI
controller"), because it's common for some DWC-based systems to:

  1. have only the "aer" and "pcie_pme" port services available and

  2. not define legacy INTx interrupts properly in their device tree.

After commit f5cd8a929c82, such systems may fail pcie_init_service_irqs()
and so exit with -ENODEV.

Link: https://lore.kernel.org/all/nyada24tqwlkzdceyoxbzitzygvp4elvj5oajnqdwb33xkcdwk@76vnrx45fsfd/
Signed-off-by: Brian Norris <briannorris@chromium.org>
[bhelgaas: reorder pcie_port_device_register() decls per Lukas]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Lukas Wunner <lukas@wunner.de>
Link: https://patch.msgid.link/20260722160942.v4.1.I5fd5d83f518681b3949d8ab2f16ba8244fd3e774@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

I have enough to judge this against 7.3-rc4: the probe-fail path, the
DWC IRQ regression, and the mailing-list review are all in this tree.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: PARSE THE SUBJECT LINE**

Record: `[PCI/portdrv] [Allow] [succeed probe when no child port
services can be registered, so runtime PM/D3 still works]`

- Subsystem: `PCI/portdrv` (PCIe port bus driver)
- Action verb: **Allow** — relaxing an overly strict probe failure, not
  adding an API
- Claimed intent: keep `pcieport` bound even with no
  AER/PME/hotplug/DPC/bwctrl children

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**

Record:
- `Link: https://lore.kernel.org/all/nyada24tqwlkzdceyoxbzitzygvp4elvj5o
  ajnqdwb33xkcdwk@76vnrx45fsfd/` — DWC iMSI-RX discussion where the
  probe-fail side effect was first identified
- `Signed-off-by: Brian Norris <briannorris@chromium.org>` (author)
- `[bhelgaas: reorder pcie_port_device_register() decls per Lukas]`
- `Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>` (PCI maintainer)
- `Reviewed-by: Lukas Wunner <lukas@wunner.de>` (PCI PM reviewer)
- `Link: https://patch.msgid.link/20260722160942.v4.1.I5fd5d83f518681b39
  49d8ab2f16ba8244fd3e774@changeid` (v4 submission)

Absent (expected): `Fixes:`, `Cc: stable@vger.kernel.org`, `Reported-
by:`, `Tested-by:`

Notable: maintainer SOB + expert Reviewed-by; no syzbot; Chrome OS
author implies real hardware.

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**

Record:
- **Bug:** `pcie_port_device_register()` returns an error (`-ENODEV` or
  IRQ-init errno) if no child services register, so `pcieport` does not
  bind.
- **Symptom:** Root/downstream ports never get portdrv runtime PM
  (`pm_runtime_allow` / autosuspend), so the bridge may never enter D3.
- **Root cause:** Probe treated “no child services” as “driver is
  useless.” That is wrong: PM lives on the parent `pcieport` driver, not
  on AER/PME children. It is also inconsistent with the existing `if
  (!capabilities) return 0` path.
- **Version info:** Called out as more important after `f5cd8a929c82`
  (DWC: strip RP MSI/MSI-X when iMSI-RX is the MSI controller). On DWC
  boards with only AER+PME and no working INTx in DT,
  `pcie_init_service_irqs()` fails and the whole port driver exits.
- **Author’s mechanism:** Always succeed after `pci_enable_device()`;
  drop failed services from the capability mask; if none remain, free
  IRQ vectors and `pci_clear_master()`, but do not
  `pci_disable_device()` / return error.

**Step 1.4: DETECT HIDDEN BUG FIXES**

Record: **Yes, a real probe/PM failure framed as “allow.”** It is not
style cleanup. “Allow probing” here means “stop returning `-ENODEV` when
the driver still has a job (runtime PM).” That is a functional fix,
especially as a follow-on to `f5cd8a929c82`.

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1: INVENTORY THE CHANGES**

Record:
- File: `drivers/pci/pcie/portdrv.c` — **+14 / −14** (net 0)
- Function: `pcie_port_device_register()` only
- Scope: **single-file surgical fix**

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**

Record (before → after), all in `pcie_port_device_register()`:

1. IRQ init fails and no hotplug left: `goto error_disable` →
   `pci_disable_device()` + return error → **`goto out`, still return
   0**.
2. Service loop: count successes in `nr_service`; if zero, `goto
   error_cleanup_irqs` → **on `pcie_device_init()` failure, clear that
   service bit; never fail the whole register**.
3. Success path: return 0 with bus-master + IRQs kept even if unused →
   **`out:` if `!capabilities`, `pci_free_irq_vectors()` +
   `pci_clear_master()`**.
4. Error path `pci_disable_device()` + `return status` **removed**.
   Probe now fails only if `pci_enable_device()` fails.
   `pcie_portdrv_remove()` still calls `pci_disable_device()`, so
   enable/disable stays balanced when probe succeeds.

Normal path with working IRQs and at least one service: unchanged (still
`return 0` with master + IRQs).

**Step 2.3: IDENTIFY THE BUG MECHANISM**

Record:
- **Category:** logic/correctness (wrong probe failure) + hardware
  workaround for DWC platforms that lose INTx after MSI cap removal
- **Mechanism:** “no child devices” was treated as fatal; that skipped
  `pcie_portdrv_probe()`’s runtime-PM setup (`pci_bridge_d3_possible()`
  → autosuspend/`pm_runtime_allow`). After `f5cd8a929c82`, that path is
  hit on common DWC RPs that only advertise AER/PME and have no usable
  INTx.

**Step 2.4: ASSESS THE FIX QUALITY**

Record:
- **Quality:** High after v4. v1 ignored `pcie_device_init()` errors and
  leaked IRQ vectors; v4 checks the return, clears failed bits, and
  frees unused vectors. Matches the long-standing `!capabilities`
  success path.
- **Regression risk:** Low–medium, contained.
  - Lukas noted they no longer `pci_disable_device()` immediately on
    IRQ-init failure; that is intentional (device stays bound). Remove
    still disables.
  - Enabling runtime D3 without a PME *service* does not newly break PME
    IRQs: those IRQs already failed, so PME children never bound before
    either.
  - LS7A bus-master caveat was called out as **pre-existing**, not
    introduced here.
- No public API / data-structure change.

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: BLAME THE CHANGED LINES**

Record:
- Fail-if-zero-services (`status = -ENODEV; nr_service`) introduced in
  **`40717c39b1e6c`** (“PCI: portdrv: minor cleanup…”, 2009).
- IRQ-fail → `error_disable` from **`075b7d363c675`** (2022 revert of
  “Do not setup IRQs if there are no users”).
- `if (!capabilities) return 0` from **`eca67315e0e0d`** (2011).
- Buggy policy has been in-tree for many years; the **acute trigger** is
  `f5cd8a929c82` (2025-12-18, in **v7.0**).

**Step 3.2: FOLLOW THE FIXES: TAG**

Record: **No `Fixes:` tag.** Related commit `f5cd8a929c82` **is** an
ancestor of this HEAD (`git merge-base --is-ancestor` exit 0). It is in
v7.0, not v6.19.

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**

Record (recent `portdrv.c`):
- `834171efeefff` — this commit (in **v7.3-rc1**)
- Later: `97ca178c899d0` PCI/DPC change — unrelated
- No follow-up fix series from Brian Norris on `drivers/pci/`
- **Standalone**, not patch N/M of a required series (subject is `[PATCH
  v4]`, single patch)

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**

Record: Brian Norris is a Chromium OS PCI contributor (Tested-
by/Reviewed-by on the DWC MSI patch). Not the PCI maintainer; **Bjorn
Helgaas applied it**, **Lukas Wunner reviewed it**. Only this portdrv
commit from him in the recent window.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**

Record: **None required.** The patch only rearranges existing
`pci_enable_device` / `pcie_init_service_irqs` / `pcie_device_init` /
`pci_free_irq_vectors` / `pci_clear_master`. It does not depend on
applying `f5cd8a929c82` first; that commit only raises the importance.
**Can apply standalone.**

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**

Record:
- **v4 (applied):** https://patch.msgid.link/20260722160942.v4.1.I5fd5d8
  3f518681b3949d8ab2f16ba8244fd3e774@changeid
- Revisions: **v1 2026-01-09 → v2 2026-02-09 → v3 2026-05-08 → v4
  2026-07-22** (applied version is latest)
- Bjorn: “Applied to pci/portdrv for v7.3”
- **No NAKs.** Review iterated on IRQ leak, `pcie_device_init()` errors,
  and `pci_set_master()` timing (v3 deferred master; v4 reverted that
  after MSI-drop concern)
- **No reviewer Cc: stable** found
- `b4 dig` lore fetch returned 503; discussion recovered from
  openwall/LKML/gnuweeb mirrors

**Step 4.2: CHECK WHO REVIEWED THE PATCH**

Record: To/Cc included **Bjorn Helgaas**, **Lukas Wunner**, **Manivannan
Sadhasivam**, `linux-pci@`. Right maintainers. Lukas **Reviewed-by** on
v4 (Christmas-tree nit; Bjorn reordered decls).

**Step 4.3: SEARCH FOR THE BUG REPORT**

Record: Origin is review of DWC patch 3/5 (`f5cd8a929c82`). Brian
Norris: platforms without INTx make `pcie_init_service_irqs()` fail,
**“the port won’t be configured for runtime PM and won’t ever enter
D3.”** Mani: **“Sounds logical”** because register already returns 0
when there are no port capabilities. **Severity:** functional PM/probe
failure on DWC/Chromium test devices, not a panic.

**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**

Record: Standalone. `b4 dig -a` also listed Qiang Yu’s DWC 5-patch
series because of the lore Link; that is the *motivation*, not a
prerequisite series for this diff.

**Step 4.5: CHECK STABLE MAILING LIST HISTORY**

Record: **No stable@ discussion found** for this subject. Not a negative
signal (no automatic `Cc: stable`).

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: IDENTIFY KEY FUNCTIONS**

Record: `pcie_port_device_register()` modified. Related:
`pcie_init_service_irqs()`, `pcie_device_init()`,
`pcie_portdrv_probe()`, `pcie_portdrv_remove()`.

**Step 5.2: TRACE CALLERS**

Record:
- `pcie_port_device_register()` ← only `pcie_portdrv_probe()`
- `pcie_portdrv_probe()` is `.probe` of `pcie_portdriver`
  (`"pcieport"`), `device_initcall`
- Context: **PCI enumeration of every Root Port / Upstream / Downstream
  / RCEC** — common boot path, not an obscure ioctl
- `semcode` not available; callers confirmed with `git grep`

**Step 5.3: TRACE CALLEES**

Record: `pci_enable_device`, `get_port_device_capability`,
`pci_set_master`, `pcie_init_service_irqs` (`pci_alloc_irq_vectors` MSI
then INTx), `pcie_device_init` (`device_register` of service devices),
`pci_free_irq_vectors`, `pci_clear_master`. After success, probe sets
DPM flags and runtime autosuspend when `pci_bridge_d3_possible()`.

**Step 5.4: FOLLOW THE CALL CHAIN**

Record: Boot/hotplug enumeration → `pcieport` probe → register services
→ PM setup. **Reachable without userspace.** Trigger on DWC: iMSI-RX MSI
controller + missing/broken INTx in DT → `pci_alloc_irq_vectors(...,
PCI_IRQ_INTX)` fails → previously whole probe failed.

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**

Record: Same file already succeeds when `get_port_device_capability()`
is 0. This change makes the IRQ-fail / all-`pcie_device_init`-fail paths
match that. No sibling drivers with the same `nr_service` pattern.

---

## PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE

**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**

Record:
- Local tree: **`v7.3-rc4-27-gf0100363d8c37`**, `VERSION=7 PATCHLEVEL=3
  SUBLEVEL=0 EXTRAVERSION=-rc4` (`make kernelversion` → `7.3.0-rc4`)
- Current `pcie_port_device_register()` **already contains this fix**
  (landed **v7.3-rc1**, `834171efeefff`; ancestor of HEAD)
- Pre-fix failure policy existed here until 7.3-rc1; **`f5cd8a929c82` is
  in this tree (v7.0)**
- Buggy path: `drivers/pci/pcie/portdrv.c` `pcie_port_device_register()`
  — fail when IRQ init fails and no HP, or when `nr_service == 0`

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**

Record: **Clean apply** on this tree’s pre-fix `portdrv.c` (single
function, same structure). No conflicting later edits that would block
it. `kzalloc_obj` in `pcie_device_init` is pre-existing, not part of
this diff.

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**

Record: This *is* the fix. No alternate/earlier version of the same
change. No follow-up reverting or tightening it.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: IDENTIFY THE SUBSYSTEM**

Record: **PCI Express port driver** (`drivers/pci/pcie/portdrv.c`).
**IMPORTANT** — not mm/core, but every PCIe Root Port uses `pcieport`
for AER/PME/hotplug **and** bridge runtime D3.

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**

Record: Actively maintained (Helgaas). Recent portdrv work besides this:
DPC on downstream ports, bus-type conversions. Mature driver; this is a
policy fix, not churn in new code.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: DETERMINE WHO IS AFFECTED**

Record: **Driver-specific / platform-specific.** All systems with PCIe
ports run this probe; the *bug* bites when services exist on paper but
IRQs cannot be allocated — especially **DWC iMSI-RX hosts without
working INTx** (Qualcomm/Chrome OS class). Also any port whose child
`device_register` all fail.

**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**

Record:
- Trigger: port has AER/PME/etc. capability bits, but
  `pcie_init_service_irqs()` fails (no MSI after cap strip, INTx
  missing), **or** every `pcie_device_init()` fails
- Common on affected DWC boards at **every boot**
- Not a userspace-triggerable security path; enumeration-time
- Not a race

**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**

Record:
- **Failure:** `pcieport` probe fails (`-ENODEV` / IRQ errno). No
  portdrv runtime PM. Bridges stay out of D3 (higher power). AER/PME
  children would not have IRQs anyway, so those services were already
  dead; the extra damage was losing **parent** PM.
- **Severity: MEDIUM** (functional probe/PM failure, not
  oops/corruption/deadlock). Still user-visible on real hardware, and a
  **regression relative to `f5cd8a929c82`** which this tree has.

**Step 8.4: CALCULATE RISK-BENEFIT RATIO**

Record:
- **Benefit:** Restores `pcieport` bind + bridge D3/runtime PM on
  affected DWC/embedded systems; removes a 15-year inconsistent failure.
  **Medium–high** for those platforms.
- **Risk:** ~14-line change in one probe function; hot path is unchanged
  when services work. Reviewed through v4. **Low.**
- **Ratio:** Benefit outweighs risk on this tree because
  **`f5cd8a929c82` is present**.

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: COMPILE THE EVIDENCE**

**FOR backporting:**
- Real probe failure, not theoretical; Chrome OS/DWC hardware, described
  on list
- Regression amplifier `f5cd8a929c82` **is in this 7.3 tree**
- Small, contained, obviously correct after v4
- PCI maintainer applied; Lukas Wunner Reviewed-by
- Aligns IRQ-fail path with existing `!capabilities` success
- No new API; `pcie_portdrv_remove()` still `pci_disable_device()`
- Frees leftover IRQ vectors (addresses Lukas’s SG2042-style vector hog)

**AGAINST:**
- Not crash/UAF/corruption/deadlock
- Verb is “Allow” — policy change vs classic sanitizer bug
- No `Fixes:` / no stable nomination in review
- Lukas noted enable/disable lifetime questions (not a NAK)
- Missing INTx is also a DT/platform gap; this is a kernel workaround

**UNRESOLVED:**
- Full lore.kernel.org threads 503/403; used mirrors (verified author,
  v1–v4, reviews)
- Exact Chromebook/SoC model list beyond “current test devices” not in
  the patch

**Step 9.2: APPLY THE STABLE RULES CHECKLIST**

1. Obviously correct and tested? **PASS** — v4, Helgaas + Wunner,
   applied to 7.3
2. Fixes a real bug that affects users? **PASS** — portdrv fails to
   bind; no RP runtime D3 on DWC without INTx
3. Important issue? **PASS** (MEDIUM, but a **probe/PM regression**
   after a commit that is in this tree — driver never attaches)
4. Small and contained? **PASS** — 14/14 lines, one function
5. No new features or APIs? **PASS** — same driver, looser failure
   condition; no sysfs/module param
6. Can apply to the local tree? **PASS** — code and trigger both exist
   here; patch is the current function body

**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**

Record: Not a device-ID/quirk table/DT/build/doc exception. It is a
**driver probe/PM correctness fix** (related to a hardware IRQ-fallback
limitation).

**Step 9.4: DECISION**

This tree is **7.3-rc4**. It contains both the DWC MSI-cap removal that
makes `pcie_init_service_irqs()` fail on some RPs and the port driver
that used to treat that as a fatal probe error. The result is a real,
boot-time `pcieport` bind failure and missing bridge D3, not a cleanup.
The change is small, reviewed, and matches behavior the driver already
had when *no* services were advertised.

That meets stable criteria for **this** tree.

---

### What the commit solves (for this tree)

After `f5cd8a929c82` (in v7.0, present here), DWC root ports using iMSI-
RX lose MSI and must use INTx. If DT does not provide INTx, IRQ init
fails. Old `pcie_port_device_register()` then disabled the device and
returned an error, so **`pcieport` never bound** and **runtime PM/D3 was
never enabled** — even though child AER/PME devices were impossible
anyway without IRQs. The parent driver is still the one that programs
autosuspend. Succeeding probe (and cleaning unused IRQs/master) restores
that.

### Risk vs benefit

Low risk (probe error path only when services cannot start; working
AER/PME/hotplug path unchanged) vs medium benefit (ports actually enter
low power; driver attaches). Reviewed caveats do not block it.

### Concerns

None that block a backport here: no missing prerequisites, no series
dependency, no API change. Lukas’s `pci_disable_device` note is handled
by `pcie_portdrv_remove()`.

---

### Verification

- **[Phase 1]** Parsed tags: two `Link:`s, SOB Norris + Helgaas,
  Reviewed-by Wunner; no Fixes/stable/syzbot
- **[Phase 1]** Body: probe `-ENODEV` vs PM; cites `f5cd8a929c82`
- **[Phase 2]** Diff: +14/−14 in `pcie_port_device_register()`; drop
  `error_disable`/`nr_service`; always return 0 after enable
- **[Phase 2]** Confirmed `pcie_portdrv_probe()` PM setup only runs if
  register succeeds (lines 701–720)
- **[Phase 2]** Confirmed `pcie_portdrv_remove()` still
  `pci_disable_device()` (line 736)
- **[Phase 3]** `git describe HEAD` → `v7.3-rc4-27-gf0100363d8c37`;
  Makefile 7.3.0-rc4
- **[Phase 3]** `git show 834171efeefff` — candidate SHA
  `834171efeefffb1a0f2136f32e76669bbc11db86`
- **[Phase 3]** Blame parent: `40717c39b1e6c` (2009 nr_service),
  `075b7d363c675` (IRQ fail path), `eca67315e0e0d` (no-caps return 0)
- **[Phase 3]** `git merge-base --is-ancestor f5cd8a929c82 HEAD` → 0
  (present); not in v6.19; in v7.0
- **[Phase 3]** `git merge-base --is-ancestor 834171efeefff HEAD` → 0;
  `git describe --contains` → `v7.3-rc1~71^2~30^2`
- **[Phase 3]** No later Norris PCI follow-ups; standalone
- **[Phase 4]** `b4 dig -c 834171efeefff` — v4 msgid; lore 503
- **[Phase 4]** `b4 dig -a` — v1..v4 of this patch (plus unrelated DWC
  series via Link)
- **[Phase 4]** Openwall: Bjorn applied for v7.3; Lukas v4 Reviewed-by +
  LS7A/enable caveats
- **[Phase 4]** gnuweeb: original DWC thread; Norris reports D3 loss;
  Mani agrees success-with-no-services
- **[Phase 4]** WebSearch stable@ — no hits for this subject
- **[Phase 5]** Callers: only `pcie_portdrv_probe` → `pcieport` PCI
  driver; semcode unavailable
- **[Phase 5]** `pcie_init_service_irqs()` INTx fallback returns
  `-ENODEV` if `pci_alloc_irq_vectors(..., PCI_IRQ_INTX)` fails
- **[Phase 6]** Buggy fail path existed until 7.3-rc1; trigger commit in
  this tree
- **[Phase 8]** Failure mode: probe fail + no bridge D3, severity
  MEDIUM; regression given `f5cd8a929c82`
- **UNVERIFIED:** live lore.kernel.org HTML (403/503); exact product
  names beyond “test devices”

**YES**

 drivers/pci/pcie/portdrv.c | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/pci/pcie/portdrv.c b/drivers/pci/pcie/portdrv.c
index a0991da482136..91d1482221a8c 100644
--- a/drivers/pci/pcie/portdrv.c
+++ b/drivers/pci/pcie/portdrv.c
@@ -330,8 +330,8 @@ static int pcie_device_init(struct pci_dev *pdev, int service, int irq)
  */
 static int pcie_port_device_register(struct pci_dev *dev)
 {
-	int status, capabilities, i, nr_service;
 	int irqs[PCIE_PORT_DEVICE_MAXSERVICES];
+	int status, capabilities, i;
 
 	/* Enable PCI Express port device */
 	status = pci_enable_device(dev);
@@ -355,29 +355,29 @@ static int pcie_port_device_register(struct pci_dev *dev)
 	if (status) {
 		capabilities &= PCIE_PORT_SERVICE_HP;
 		if (!capabilities)
-			goto error_disable;
+			goto out;
 	}
 
 	/* Allocate child services if any */
-	status = -ENODEV;
-	nr_service = 0;
 	for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++) {
 		int service = 1 << i;
 		if (!(capabilities & service))
 			continue;
-		if (!pcie_device_init(dev, service, irqs[i]))
-			nr_service++;
+		if (pcie_device_init(dev, service, irqs[i]))
+			capabilities &= ~service;
 	}
-	if (!nr_service)
-		goto error_cleanup_irqs;
 
-	return 0;
+out:
+	/*
+	 * With no child services, we shouldn't need bus mastering or any IRQ
+	 * vectors we allocated.
+	 */
+	if (!capabilities) {
+		pci_free_irq_vectors(dev);
+		pci_clear_master(dev);
+	}
 
-error_cleanup_irqs:
-	pci_free_irq_vectors(dev);
-error_disable:
-	pci_disable_device(dev);
-	return status;
+	return 0;
 }
 
 typedef int (*pcie_callback_t)(struct pcie_device *);
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-5.10] PCI/portdrv: Allow probing even without child services

[sashiko-bot]

> From: Brian Norris <briannorris@chromium.org>
> 
> [ Upstream commit 834171efeefffb1a0f2136f32e76669bbc11db86 ]
> 
> The PCIe port driver fails to probe if it finds no child services,
> presumably under the assumption that the driver is not useful in that case.
> However, the driver *can* still be useful for power management support --
> namely, it still configures the port for runtime PM / D3, which may be
> important for allowing a bridge to enter low power modes.
> 
> Thus, allow probe to succeed even if no IRQs and no child services are
> available. This also mirrors existing behavior for ports that don't support
> any portdrv services (PCIe hotplug, AER, DPC, PME, bwctrl), where we'd also
> probe successfully.
> 
> [ ... ]
> [bhelgaas: reorder pcie_port_device_register() decls per Lukas]
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> Reviewed-by: Lukas Wunner <lukas@wunner.de>
> Link: https://patch.msgid.link/20260722160942.v4.1.I5fd5d83f518681b3949d8ab2f16ba8244fd3e774@changeid
> Signed-off-by: Sasha Levin <sashal@kernel.org>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261019135441.1420968-203-sashal@kernel.org?part=1

[PATCH AUTOSEL 6.18-5.10] PCI: vmd: Handle BUS_RESTRICT_CFG value 3 for Arrow Lake-HX

[Sasha Levin]

From: Ali Alaei <ali.alaei.tabatabaei@gmail.com>

[ Upstream commit 72b32eccbcd591b9606edacf3bd7c455176d7660 ]

On Intel Arrow Lake-HX systems (e.g. Core Ultra 9 275HX on Acer Predator
PH16-73), the VMD controller reports BUS_RESTRICT_CFG = 3 in the VMCONFIG
register. The existing switch statement only handled values 0, 1, and 2,
causing vmd_get_bus_number_start() to return -ENODEV and aborting the
entire VMD probe. This leaves NVMe drives behind the VMD controller
invisible to the kernel.

Hardware registers (VMCAP/VMCONFIG at offsets 0x40/0x44):

  VMD 0000:00:0e.0 (8086:ad0b): VMCAP=0x000f, VMCONFIG=0x03b8
  BUS_RESTRICT_CFG(0x03b8) = (0x03b8 >> 8) & 0x3 = 3

Add cfg=3 as a fallthrough to cfg=2, setting busn_start=224, which is
the correct bus number base for this hardware.

Also add a PCI_POSSIBLE_ERROR() guard after reading VMCONFIG: a failed
config space read returns 0xFFFF, and BUS_RESTRICT_CFG(0xFFFF) = 3,
so without this guard a removed or errored device would falsely match
the new case 3 instead of being caught as an error.

Reported-by: Lin Mohan <linmhwork@outlook.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221137 # Arrow-Lake-S
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221136 # Arrow-Lake-S
Signed-off-by: Ali Alaei <ali.alaei.tabatabaei@gmail.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260628143450.92492-1-ali.alaei.tabatabaei@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The local tree is **7.3.0-rc4**. This commit is a three-line VMD
hardware workaround: Arrow Lake reports `BUS_RESTRICT_CFG=3`, probe used
to abort with `-ENODEV`, and NVMe behind VMD disappeared. That is a
real, user-visible bug and is appropriate for this tree.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: PARSE THE SUBJECT LINE**

Record: **[PCI: vmd]** **[Handle]** Handle `BUS_RESTRICT_CFG` value 3
for Arrow Lake-HX so VMD probe no longer fails.

Subsystem: PCI VMD controller (`drivers/pci/controller/vmd.c`). Verb
“Handle” is a bug-fix verb: previously-unhandled hardware encoding.

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**

Record:
- **Reported-by:** Lin Mohan `<linmhwork@outlook.com>` (real user; also
  the bugzilla reporter)
- **Closes:** https://bugzilla.kernel.org/show_bug.cgi?id=221137 (Arrow-
  Lake-S)
- **Closes:** https://bugzilla.kernel.org/show_bug.cgi?id=221136 (Arrow-
  Lake-S)
- **Signed-off-by:** Ali Alaei (author); Manivannan Sadhasivam (PCI
  host/endpoint maintainer, applied); Bjorn Helgaas (PCI subsystem
  maintainer, committed)
- **Link:** https://patch.msgid.link/20260628143450.92492-1-
  ali.alaei.tabatabaei@gmail.com
- **No Fixes:** tag (expected for this review)
- **No Cc: stable** (expected)
- Ignored pipeline SOBs if present; none from Sasha Levin on this commit

Notable: two independent Closes tags plus a Reported-by, plus PCI
maintainer SOBs.

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**

Record:
- **Bug:** On Arrow Lake-HX (Core Ultra 9 275HX, Acer Predator PH16-73),
  VMD `8086:ad0b` reports `VMCONFIG=0x03b8` so `BUS_RESTRICT_CFG =
  (0x03b8 >> 8) & 0x3 = 3`. The switch only handled 0/1/2, so
  `vmd_get_bus_number_start()` returned `-ENODEV` and probe aborted.
- **Symptom:** NVMe behind VMD is invisible.
- **Root cause:** New 2-bit encoding (value 3) treated as unknown.
  `BUS_RESTRICT_CFG` is only 2 bits, so 3 is a legal value, not
  “reserved garbage.”
- **Fix:** Treat cfg=3 like cfg=2 (`busn_start=224`). Guard
  `pci_read_config_word()` with `PCI_POSSIBLE_ERROR()` because a failed
  read is `0xFFFF` and `BUS_RESTRICT_CFG(0xFFFF)=3`, which would now
  look valid.
- **Version info in message:** none beyond Arrow Lake-HX/S hardware.

**Step 1.4: DETECT HIDDEN BUG FIXES**

Record: Not hidden. Explicit hardware-handling bug: probe fails, disks
missing. The error-read guard is a real correctness fix that became
necessary once case 3 was valid.

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1: INVENTORY THE CHANGES**

Record:
- File: `drivers/pci/controller/vmd.c` (+3 lines)
- Function: `vmd_get_bus_number_start()`
- Scope: **single-file surgical fix**

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**

Record:
- **Before:** After `pci_read_config_word(VMCONFIG)`, switch on bits
  [9:8]. 0→bus 0, 1→128, 2→224, anything else (including 3) → `pci_err`
  + `-ENODEV`.
- **After:** If the word is `0xFFFF`, return `-ENODEV`. Case 3 falls
  through to case 2 (`busn_start=224`).
- Path: VMD probe / domain setup, not a hot path and not an optional
  debug path.

**Step 2.3: IDENTIFY THE BUG MECHANISM**

Record:
- **Category:** Hardware workaround / logic correctness (unhandled
  register encoding), plus error-path guard.
- **Mechanism:** Firmware programs Dynamic Bus Offset / restriction mode
  3. Driver rejected it, so the VMD domain never came up and child NVMe
  never enumerated.
- **Secondary:** Without the `PCI_POSSIBLE_ERROR()` check, a dead device
  (`0xFFFF`) would now be accepted as mode 3.

**Step 2.4: ASSESS THE FIX QUALITY**

Record:
- **Quality:** Minimal and locally obvious. Mask is `& 0x3`, so 3 is the
  last encoding; mapping it to the existing 224–255 window matches cfg=2
  and matches the author’s dump plus tester reports.
- **Regression risk:** Low. Only devices that actually report cfg=3
  change behavior (they used to fail probe). Other encodings unchanged.
  The `0xFFFF` guard restores the old “abort on bad read” behavior for
  the new case.
- **Caveat (verified, not blocking):** An older Intel series treated
  cfg=3 as a *second* root bus (BUS0=224, BUS1=225). That series is
  **not** in this tree (`bus1_rootbus` / `VMD_FEAT_HAS_BUS1_ROOTBUS`
  absent). This 3-line mapping was tested on real Arrow Lake-HX and
  confirmed by the Arrow Lake-S bugzilla reporter. PCI maintainers
  merged it.

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: BLAME THE CHANGED LINES**

Record:
- Switch and helper: **`2e1224183b1bec`** (“PCI: vmd: Create bus offset
  configuration helper”, Jon Derrick, 2020) — first in **v5.10-rc1**.
- Even earlier, **`51f939b11cb1c`** / related bus-restriction decode
  treated case 3 as `"Unknown Bus Offset Setting"` + `-ENODEV` on
  purpose.
- Buggy “3 is unknown” behavior has been in the driver for years; it
  only bit users once Arrow Lake firmware started programming 3.

**Step 3.2: FOLLOW THE FIXES: TAG**

Record: **No Fixes: tag.** Not applicable. Introduction of the
incomplete switch is `2e1224183b1bec` (v5.10). Device ID `8086:ad0b`
added in **`57a128acaba02`** (“Add DID 8086:7D0B and 8086:AD0B for Intel
MTL SKUs”, ~v6.0). `PCI_POSSIBLE_ERROR` from **`57bdeef471668`**
(~v5.17).

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**

Record:
- Later on the same file: `2162572d34c50` (_OSC flags in guests),
  `55aa45154fe48` (Nova Lake / Dunlow IDs). Neither is a prerequisite or
  a revert.
- Parent `b030905bf5a64` (BIOS-enumerated devices) does **not** change
  this switch; this commit is standalone.
- Not a “patch X/Y” series.

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**

Record: Ali Alaei’s only commit under `drivers/pci/controller/` is this
one. Applied by Mani, committed by Bjorn. Intel VMD maintainers (Nirmal
Patel, Jonathan Derrick) were CCed on v3; no NAK in the thread.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**

Record: None required. Uses existing `vmd_get_bus_number_start()`,
existing `BUS_RESTRICT_CFG()`, existing `PCI_POSSIBLE_ERROR()`. Can
apply standalone on this tree.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**

Record:
- **Lore (via b4 dig):** https://patch.msgid.link/20260628143450.92492-
  1-ali.alaei.tabatabaei@gmail.com
- **Revisions:** v1 (2026-06-04, case 3 only) → v2 (same day, add
  `PCI_POSSIBLE_ERROR`) → **v3 applied** (changelog placement + CC VMD
  maintainers)
- v1 review (sashiko-bot) flagged exactly the `0xFFFF` → case 3 issue;
  v2/v3 addressed it.
- Mani: style/CC nits on v2; **“Applied, thanks!”** on v3.
- Bjorn: asked whether it closes bugzilla 221136, noted lack of public
  spec, wanted Intel VMD maintainers to comment; still merged and added
  Reported-by/Closes.
- **No NAK.** No reviewer asked for Cc: stable (absence expected).

**Step 4.2: CHECK WHO REVIEWED THE PATCH**

Record (b4 dig -w): linux-pci, Bjorn Helgaas, Lorenzo Pieralisi, Nirmal
Patel, Jonathan Derrick, Krzysztof Wilczyński, Manivannan Sadhasivam,
Rob Herring. Right lists and maintainers.

**Step 4.3: SEARCH FOR THE BUG REPORT**

Record:
- Bugzilla fetches returned **403**; full bug text **UNVERIFIED**.
- On-list, Lin Mohan confirmed both 221137 and 221136 are the same Mode
  3 / Dynamic Bus Offset issue, including on `8086:09ab` Arrow Lake-S,
  and asked for Closes tags after merge.
- Author tested Acer Predator PH16-73 / Core Ultra 9 275HX /
  `8086:ad0b`.
- Multiple users/platforms: **HX laptop + S desktop**.

**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**

Record: Standalone 1/1. Older Intel “second rootbus” series on spinics
is a large new feature and is **not** in this tree; not a dependency of
this 3-line workaround.

**Step 4.5: CHECK STABLE MAILING LIST HISTORY**

Record: lore.kernel.org/stable search returned **403**. **UNVERIFIED**
whether stable@ already discussed it. No evidence in the pci thread of a
reason to keep it out of stable.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: IDENTIFY KEY FUNCTIONS**

Record: `vmd_get_bus_number_start()` only.

**Step 5.2: TRACE CALLERS**

Record:
- Called from `vmd_prepare_offsets_and_bus()` when
  `VMD_FEAT_HAS_BUS_RESTRICTIONS`.
- That is called from `vmd_enable_domain()`.
- That is called from `vmd_probe()`.
- Probe path during PCI enumeration of the VMD device. Not IRQ/hot path.

`VMD_FEATS_CLIENT` includes `VMD_FEAT_HAS_BUS_RESTRICTIONS`. Device
`0xad0b` uses `VMD_FEATS_CLIENT`. Several other client IDs do too, so
any of those that firmware sets to cfg=3 hit this.

**Step 5.3: TRACE CALLEES**

Record: `pci_read_config_word()` (VMCAP 0x40, VMCONFIG 0x44),
`PCI_POSSIBLE_ERROR()`, `pci_err()` on unknown values.

**Step 5.4: FOLLOW THE CALL CHAIN**

Record: Boot / device probe. Reachable whenever VMD is enabled (RST/VMD
in firmware) on affected Intel client platforms. Unprivileged users do
not trigger it via a syscall; they just lose NVMe. **User-visible and
common on those laptops.**

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**

Record: Same `PCI_POSSIBLE_ERROR()` pattern already used in
`vmd_get_phys_offsets()` for VMLOCK. No other unhandled
`BUS_RESTRICT_CFG` sites.

---

## PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE

**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**

Record:
- `git describe HEAD` → **v7.3-rc4-27-gf0100363d8c37**
- `make kernelversion` → **7.3.0-rc4**
- `vmd_get_bus_number_start()` is present; `0xad0b` is in `vmd_ids[]`;
  `PCI_POSSIBLE_ERROR` is in `include/linux/pci.h`.
- Bug introduced with the 0/1/2-only switch (v5.10 helper); manifests on
  Arrow Lake once those IDs exist (~v6.0+).
- **Yes, the bug exists in this lineage.**

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**

Record: **Clean apply** on this tree. Hunk is isolated to the helper;
surrounding refactor (`vmd_prepare_offsets_and_bus`) does not overlap.

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**

Record: No other commit implements cfg=3. No revert. No dual-rootbus
substitute.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**

Record: **PCI controller / Intel VMD.** Criticality **IMPORTANT** (not
core mm/vfs, but VMD is how many Intel laptops expose NVMe).
`CONFIG_VMD` depends on `PCI_MSI && X86_64`.

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**

Record: Actively maintained (new device IDs, BIOS-scan feature, _OSC
guest fix). The **switch itself** has been stable since 2020; this is a
late hardware encoding, not churn in the helper.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: DETERMINE WHO IS AFFECTED**

Record: **Driver-specific / platform-specific:** x86_64 systems with
Intel VMD and firmware `BUS_RESTRICT_CFG=3` (Arrow Lake-HX confirmed;
Arrow Lake-S reporter confirmed). Not universal.

**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**

Record: Every boot on affected machines with VMD enabled. Not a race.
Not unprivileged-exploit; **storage simply missing.**

**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**

Record: VMD probe fails (`-ENODEV`); NVMe behind VMD never appears.
**HIGH** (loss of boot/root/data disks on common Intel client hardware).
Not a panic, but production-breaking.

**Step 8.4: CALCULATE RISK-BENEFIT RATIO**

Record:
- **Benefit:** High for affected users (NVMe works).
- **Risk:** Very low (3 lines, probe-only, existing mapping, error-read
  guard).
- **Ratio:** Strongly in favor of applying it on this tree.

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: COMPILE THE EVIDENCE**

**For:**
- Real bug: VMD probe abort, NVMe invisible.
- Confirmed on Arrow Lake-HX (author) and Arrow Lake-S (bugzilla
  reporter).
- 3-line, obviously correct mapping of a 2-bit field.
- Extra `PCI_POSSIBLE_ERROR()` prevents a new false-positive on
  `0xFFFF`.
- PCI maintainers applied/committed; v1 review hole fixed in v2/v3.
- Fits the stable **hardware quirk / existing-device enablement**
  exception.
- All helpers and IDs exist in **this** 7.3.0-rc4 tree; no missing
  prerequisites.

**Against:**
- Not a crash/UAF/security bug.
- No public VMD spec for mode 3; Bjorn noted a “new mode” might someday
  need more than a fallthrough (dual-rootbus series never landed here).
- Intel VMD maintainers were CCed but did not ack in the saved thread.

**Unresolved:**
- Full bugzilla pages (HTTP 403).
- stable@ archive search (HTTP 403).
- Whether every cfg=3 platform only needs bus 224 (empirically yes for
  the reported machines).

Those gaps do not outweigh the hardware reports and the size of the fix.

**Step 9.2: APPLY THE STABLE RULES CHECKLIST**

1. Obviously correct and tested? **PASS** — register dump, author test,
   reporter confirmation, v3 review.
2. Fixes a real bug that affects users? **PASS** — NVMe missing on
   shipping Arrow Lake systems.
3. Important issue? **PASS** — HIGH: boot/storage devices not enumerated
   (not a panic, but not cosmetic).
4. Small and contained? **PASS** — +3 lines, one function.
5. No new features or APIs? **PASS** — no new ABI; handles a value the
   existing 2-bit field can already produce.
6. Can apply to the local tree? **PASS** — helper, IDs, and
   `PCI_POSSIBLE_ERROR` all present; apply is clean.

**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**

Record: **Hardware quirk/workaround** (and the same class as device-ID
enablement): existing driver, existing PCI ID, firmware encoding the
driver rejected, so the device did not work.

**Step 9.4: MAKE YOUR DECISION**

This tree is 7.3.0-rc4. The VMD driver, Arrow Lake DID `0xad0b`, bus-
restriction feature flag, and the old 0/1/2-only switch all exist here.
The patch is a small, tested workaround that restores NVMe on affected
Intel VMD systems. It should be applied to this tree.

### What the commit solves
`BUS_RESTRICT_CFG` is two bits. Arrow Lake programs **3**. The driver
treated 3 as unknown, failed VMD probe, and hid NVMe. Mapping 3 to the
existing bus-224 window, and rejecting `0xFFFF` config reads, is the
correct local fix.

### Stable rules
Meets all six criteria. It is a hardware workaround, not a new API.

### Risk vs benefit
Benefit is high (disks appear). Risk is very low (three lines, probe-
only).

### Concerns
Dual-rootbus would be a large new feature and is not in this tree; it is
not required for the reported machines. `PCI_POSSIBLE_ERROR` is already
here, so no extra backport of that helper is needed on this tree.

---

## Verification
- **[Phase 1]** Parsed commit `72b32eccbcd59`: Reported-by Lin Mohan;
  Closes 221137/221136; SOB Ali Alaei, Mani, Bjorn Helgaas; Link to
  msgid 20260628143450.92492-1; no Fixes/Cc-stable.
- **[Phase 2]** Diff: +3 lines in `vmd_get_bus_number_start()`:
  `PCI_POSSIBLE_ERROR` + `case 3:` fallthrough to `busn_start=224`.
- **[Phase 2]** Confirmed `BUS_RESTRICT_CFG` is `((vmcfg >> 8) & 0x3)`
  in `vmd.c:32`; `0xFFFF` → 3.
- **[Phase 3]** `git blame`: switch from `2e1224183b1bec` (v5.10-rc1);
  case 3 lines from this commit.
- **[Phase 3]** `0xad0b` added in `57a128acaba02`; `PCI_POSSIBLE_ERROR`
  in `57bdeef471668` (~v5.17); present in `include/linux/pci.h:179`.
- **[Phase 3]** `git log --oneline -20 -- drivers/pci/controller/vmd.c`:
  no revert; later commits are IDs/_OSC only.
- **[Phase 3]** Author has no other VMD commits.
- **[Phase 4]** `b4 dig -c 72b32eccbcd59`: v3 at
  patch.msgid.link/20260628143450.92492-1-ali.alaei.tabatabaei@gmail.com
- **[Phase 4]** `b4 dig -a`: v1 → v2 → v3; v3 is what was applied.
- **[Phase 4]** `b4 dig -w`: linux-pci + Helgaas, Pieralisi, Patel,
  Derrick, Wilczyński, Sadhasivam, Herring.
- **[Phase 4]** mbox: Mani applied; Bjorn discussed bugzilla; Lin Mohan
  confirmed both bugs; sashiko-bot caught the `0xFFFF` issue on v1.
- **[Phase 4]** Bugzilla WebFetch 403 — full bug text UNVERIFIED;
  reporter confirmation verified from mbox.
- **[Phase 4]** lore.kernel.org/stable 403 — UNVERIFIED.
- **[Phase 5]** Call chain: `vmd_probe` → `vmd_enable_domain` →
  `vmd_prepare_offsets_and_bus` → `vmd_get_bus_number_start`.
- **[Phase 5]** `0xad0b` in `vmd_ids[]` with `VMD_FEATS_CLIENT`
  including `VMD_FEAT_HAS_BUS_RESTRICTIONS`.
- **[Phase 5]** No `bus1_rootbus` in this tree.
- **[Phase 6]** `git describe HEAD`: v7.3-rc4-27-gf0100363d8c37; `make
  kernelversion`: 7.3.0-rc4.
- **[Phase 6]** `git merge-base --is-ancestor 72b32eccbcd59 HEAD`: yes;
  first contained in **v7.3-rc1**; not in v7.2.
- **[Phase 7]** `CONFIG_VMD` in `drivers/pci/controller/Kconfig`;
  MAINTAINERS: Nirmal Patel / Jonathan Derrick.
- **[Phase 8]** Failure mode: VMD probe `-ENODEV` → NVMe not enumerated;
  severity HIGH.
- **UNVERIFIED:** Full bugzilla 221136/221137 bodies; any stable@
  thread; whether cfg=3 ever needs a second root bus on unreported SKUs.

**YES**

 drivers/pci/controller/vmd.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
index b4b62b9ccc45a..5d3e6cc7e4feb 100644
--- a/drivers/pci/controller/vmd.c
+++ b/drivers/pci/controller/vmd.c
@@ -656,6 +656,8 @@ static int vmd_get_bus_number_start(struct vmd_dev *vmd)
 	pci_read_config_word(dev, PCI_REG_VMCAP, &reg);
 	if (BUS_RESTRICT_CAP(reg)) {
 		pci_read_config_word(dev, PCI_REG_VMCONFIG, &reg);
+		if (PCI_POSSIBLE_ERROR(reg))
+			return -ENODEV;
 
 		switch (BUS_RESTRICT_CFG(reg)) {
 		case 0:
@@ -664,6 +666,7 @@ static int vmd_get_bus_number_start(struct vmd_dev *vmd)
 		case 1:
 			vmd->busn_start = 128;
 			break;
+		case 3:
 		case 2:
 			vmd->busn_start = 224;
 			break;
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-5.10] PCI: vmd: Handle BUS_RESTRICT_CFG value 3 for Arrow Lake-HX

[sashiko-bot]

> From: Ali Alaei <ali.alaei.tabatabaei@gmail.com>
> 
> [ Upstream commit 72b32eccbcd591b9606edacf3bd7c455176d7660 ]
> 
> On Intel Arrow Lake-HX systems (e.g. Core Ultra 9 275HX on Acer Predator
> PH16-73), the VMD controller reports BUS_RESTRICT_CFG = 3 in the VMCONFIG
> register. The existing switch statement only handled values 0, 1, and 2,
> causing vmd_get_bus_number_start() to return -ENODEV and aborting the
> entire VMD probe. This leaves NVMe drives behind the VMD controller
> invisible to the kernel.
> 
> Hardware registers (VMCAP/VMCONFIG at offsets 0x40/0x44):
> 
>   VMD 0000:00:0e.0 (8086:ad0b): VMCAP=0x000f, VMCONFIG=0x03b8
>   BUS_RESTRICT_CFG(0x03b8) = (0x03b8 >> 8) & 0x3 = 3
> [ ... ]
> Signed-off-by: Ali Alaei <ali.alaei.tabatabaei@gmail.com>
> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> Link: https://patch.msgid.link/20260628143450.92492-1-ali.alaei.tabatabaei@gmail.com
> Signed-off-by: Sasha Levin <sashal@kernel.org>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261019135441.1420968-288-sashal@kernel.org?part=1

[PATCH AUTOSEL 6.18-5.10] PCI/ATS: Ensure pci_ats_supported() is PF-aware for VFs

[Sasha Levin]

From: Pranjal Shrivastava <praan@google.com>

[ Upstream commit 4f2cd6091ac41566a7300f5a4590d20a99aaa8bc ]

Update pci_ats_supported() to additionally check the associated PF's
status when called on a VF. This ensures that PF-level quirks and
untrusted status are correctly propagated to VFs, providing a robust
support check that aligns with the kernel's PF-centric ATS configuration
model and is immune to the timing of VF-specific fixups.

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Pranjal Shrivastava <praan@google.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit message forensics

**Step 1.1: Subject line**
Record: `[PCI/ATS] [Ensure] make pci_ats_supported() PF-aware when
called on a VF`

**Step 1.2: Tags**
Record:
- Reviewed-by: Jason Gunthorpe (NVIDIA / IOMMU)
- Reviewed-by: Samiullah Khawaja (Google)
- Reviewed-by: Nicolin Chen (NVIDIA)
- Reviewed-by: Lu Baolu (Intel VT-d)
- Reviewed-by: Kevin Tian (Intel)
- Acked-by: Bjorn Helgaas (PCI maintainer)
- Signed-off-by: Pranjal Shrivastava (author)
- Signed-off-by: Joerg Roedel (IOMMU maintainer, committer)
- No Fixes:, Reported-by:, Tested-by:, Link:, or Cc: stable (absence
  expected)

**Step 1.3: Body**
Record:
- Bug: `pci_ats_supported()` on a VF only inspects that VF. PF quirks
  (`quirk_no_ats` zeros `ats_cap`) and PF `untrusted` are not applied.
- Symptom: VFs can be treated as ATS-capable when the PF is not allowed
  to use ATS; IOMMU then programs ATS and `pci_enable_ats()` can fail,
  leaving inconsistent ATS/IOMMU state.
- Cover letter (v9 0/4): seen under `iova_stress` as `pci_enable_ats()`
  failure → PCI warnings on detach. Also: “`pci_ats_supported()` did not
  account for PF-level quirked status.”
- Root cause: helper is device-local; kernel ATS policy is PF-centric
  (STU programmed on PF, VFs share it).
- Version: helper added in 2020 (`521376741b2c2`); this change landed
  for v7.3-rc1.

**Step 1.4: Hidden bug fix?**
Record: Yes. “Ensure” / “robust support check” is a real correctness
fix: VFs of quirked or untrusted PFs could be reported as ATS-capable.
Not style-only.

---

## Phase 2: Diff analysis

**Step 2.1: Inventory**
Record:
- File: `drivers/pci/ats.c` (+5 / −2)
- Function: `pci_ats_supported()`
- Scope: single-function surgical change

**Step 2.2: Control flow**
Record: Before: `false` if `!ats_cap`, else `untrusted == 0`. After:
`false` if `!ats_cap` or `untrusted`; if VF, recurse to
`pci_physfn(dev)`; else `true`. Recursion is one level (PF is not a
virtfn).

**Step 2.3: Bug mechanism**
Record:
- Category: logic/correctness + hardware quirk inheritance (security-
  adjacent ATS policy)
- Mechanism: `quirk_no_ats()` is `DECLARE_PCI_FIXUP_FINAL` and matches
  PF IDs, zeroing PF `ats_cap`. VFs have their own ATS cap and usually
  different IDs, so VF `ats_cap` stays set. FINAL quirks run in
  `pci_bus_add_device()` after `device_add()` → IOMMU probe. Checking
  the PF avoids depending on VF FINAL fixup timing.

**Step 2.4: Fix quality**
Record: Minimal and aligned with `pci_ats_required()` /
`pci_pri_supported()`, which already walk to the PF. Regression risk is
low: it only denies ATS when the PF is already denied. VF ATS without a
usable PF was already broken (`pci_enable_ats()` requires matching PF
STU).

---

## Phase 3: Git history

**Step 3.1: Blame**
Record: Helper introduced by `521376741b2c2` (“PCI/ATS: Only enable ATS
for trusted devices”, 2020-05-27, ~v5.8). The VF PF walk is
`4f2cd6091ac41` (2026-07-09).

**Step 3.2: Fixes: tag**
Record: None. Buggy code is the original helper from `521376741b2c2`,
present in this tree.

**Step 3.3: Related file history**
Record:
- `6c17c7d5936e6` (v6.12): `pci_prepare_ats()` — PF STU before VFs
- `4f2cd6091ac41`: this change (series 1/4)
- `6fd7c5c81af23`: series 2/4, STU check in `pci_prepare_ats()` —
  follow-on, not a prerequisite

**Step 3.4: Author**
Record: Pranjal Shrivastava; IOMMU/PCI ATS work. Not subsystem
maintainer. Joerg Roedel applied it; Bjorn Helgaas acked.

**Step 3.5: Dependencies**
Record: Standalone. Uses existing `pci_physfn()`, `is_virtfn`,
`ats_cap`, `untrusted`. Later series patches (SMMUv3 WARN, VT-d probe
fail) depend on this, not the reverse.

---

## Phase 4: Mailing list

**Step 4.1: Original discussion**
Record:
- Lore:
  https://patch.msgid.link/20260615235037.259909-2-praan@google.com
- Cover:
  https://patch.msgid.link/20260615235037.259909-1-praan@google.com
- Revisions: v3 (2026-05-19) through v9 (2026-06-15). Applied version is
  v9 1/4.
- No NAKs in the v9 mbox. Joerg: “Applied, thanks.”
- No reviewer Cc: stable.

**Step 4.2: Recipients (`b4 dig -w`)**
Record: iommu@lists.linux.dev, linux-pci@, Joerg Roedel, Will Deacon,
Robin Murphy, Lu Baolu, Jason Gunthorpe, Kevin Tian, Bjorn Helgaas,
Nicolin Chen, Samiullah Khawaja.

**Step 4.3: Bug report**
Record: No syzbot/bugzilla. Cover letter: `iova_stress` ATS mismatch; PF
quirk gap after David’s HEADER-phase work. UNVERIFIED: I could not open
lore via WebFetch (403); content is from `b4 dig -m`.

**Step 4.4: Series**
Record: v9 0/4 “iommu: Standardize ATS robustness and state tracking” (4
patches). This is patch 1 and is independently correct.

**Step 4.5: Stable list**
Record: No hit that this was requested or rejected for stable (curl to
lore.kernel.org/stable returned empty). UNVERIFIED beyond that.

---

## Phase 5: Code semantics

**Step 5.1: Functions**
Record: `pci_ats_supported()` only.

**Step 5.2: Callers**
Record:
- `pci_prepare_ats()` / `pci_enable_ats()` / `pci_ats_required()`
  (`drivers/pci/ats.c`)
- Intel VT-d probe / ATS / release (`drivers/iommu/intel/iommu.c`)
- ARM SMMUv3 `arm_smmu_ats_supported()` and probe
  (`drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c`)
- AMD IOMMU `pdev_get_caps()` (`drivers/iommu/amd/iommu.c`)
- IOMMU reset prepare/done (`drivers/iommu/iommu.c`)

**Step 5.3: Callees**
Record: `pci_physfn()` (returns `dev->physfn` for VFs).

**Step 5.4: Reachability**
Record: Yes. IOMMU `probe_device` during PCI add / SR-IOV VF create.
Userspace can create VFs (sysfs `sriov_numvfs`). Not a rare config-only
path if IOMMU + SR-IOV + ATS are enabled.

**Step 5.5: Similar patterns**
Record: `pci_ats_required()`, `pci_pri_supported()`, PASID helpers
already use `pci_physfn()`. This helper was the outlier.

Verified probe vs quirk order:
- `pci_device_add()`: HEADER fixups → `pci_ats_init()` → `device_add()`
  (IOMMU probe)
- `pci_bus_add_device()`: FINAL fixups (`quirk_no_ats`) after that
So IOMMU can observe VF `ats_cap` before VF FINAL quirks. PF FINAL
quirks have usually already run when VFs are created later.

---

## Phase 6: This checkout

**Step 6.1: Buggy code in this tree?**
Record: Yes. Tree is **v7.3-rc4** (`7.3.0-rc4`). `pci_ats_supported()`
exists since v5.8. Pre-change body is the `!ats_cap` / `untrusted == 0`
check. `git merge-base --is-ancestor 4f2cd6091ac41 HEAD` is true (native
7.3-rc1 merge, not a reason to skip technical review).

**Step 6.2: Backport difficulty**
Record: Clean apply onto the parent helper. No API/struct change.

**Step 6.3: Related fixes already here?**
Record: No earlier substitute for PF-aware `pci_ats_supported()`.
`quirk_no_ats` is still FINAL, not HEADER, so the VF/PF gap remains
without this change.

---

## Phase 7: Subsystem context

**Step 7.1**
Record: PCI ATS / IOMMU. Criticality: **IMPORTANT** (IOMMU DMA
translation; ATS can emit Translated AT and partially bypass IOMMU).

**Step 7.2**
Record: Active (VF ATS, CXL always-on ATS, Intel/AMD/SMMUv3). Helper
itself is mature (2020).

---

## Phase 8: Impact and risk

**Step 8.1: Who is affected**
Record: SR-IOV + IOMMU + ATS. Datacenter NICs/IPUs/GPUs. Intel IPU E2000
quirk: broken ATS invalidation → “outdated translations” and “system
instability.” Those FINAL quirks match listed PF IDs; VF IDs often
differ.

**Step 8.2: Trigger**
Record: Creating/probing a VF of a PF with `ats_cap` cleared or
`untrusted` set. Common on SR-IOV enable, not every boot. Unprivileged
users cannot usually create VFs.

**Step 8.3: Failure mode**
Record:
- ATS enabled on hardware the PF quirk meant to disable → stale IOTLB /
  instability / possible bad DMA (**HIGH**)
- IOMMU thinks ATS is supported, `pci_enable_ats()` fails, detach
  warnings / inconsistent state (**MEDIUM–HIGH**)
- Untrusted PF VFs getting ATS would be a DMA/ATS bypass gap; VF
  `untrusted` is often already set from the upstream bridge, so this
  part is extra defense

Severity: **HIGH** (quirk bypass on broken ATS), not a universal panic.

**Step 8.4: Risk-benefit**
Record: Benefit high for SR-IOV ATS users on quirked devices; risk very
low (5 lines, stricter deny only). Ratio: favorable.

---

## Phase 9: Synthesis

**Step 9.1: Evidence**

For:
- Real bug: VF ATS allow-list ignored PF quirk/`untrusted`
- Concrete trigger: SR-IOV VF probe; `iova_stress` saw enable-fail /
  detach warnings
- E2000-class quirks document instability if ATS stays on
- 5-line, obviously correct, PF walk matches the rest of PCI ATS
- Reviewed by PCI and Intel/AMD/ARM IOMMU maintainers
- Self-contained; applies to this tree’s helper

Against:
- Framed as robustness in a 4-patch series, not a panic/CVE
- No Fixes:/Cc: stable (not a negative by itself)
- Affects SR-IOV+ATS, not all machines
- Untrusted gap is weaker than the quirk/`ats_cap` gap

Unresolved:
- Exact `iova_stress` trace not in the v9 mbox
- Whether every E2000 VF ID is already in the quirk table (PF walk still
  needed for timing and other `quirk_no_ats` IDs)

**Step 9.2: Stable rules**
1. Obviously correct and tested? **PASS** — one-level PF recurse; v9
   reviews; `iova_stress` mentioned
2. Real user-visible bug? **PASS** — false ATS support on VFs; IOMMU
   mismatch; quirk bypass
3. Important (crash/security/corruption/deadlock)? **PASS** — ATS on
   quirked broken invalidation is instability / stale translations; ATS
   policy is security-adjacent
4. Small and contained? **PASS** — +5/−2, one function
5. No new features/APIs? **PASS**
6. Applies to this tree? **PASS** — helper and fields exist; parent hunk
   matches

**Step 9.3: Exceptions**
Record: Not a device-ID/DT/build/doc exception. Hardware-quirk
*inheritance* for existing `quirk_no_ats` entries.

**Step 9.4: Decision**
This tree is Linux **7.3-rc4**. The helper has been wrong for VFs since
v5.8. The change is a small, reviewed correctness fix so VFs cannot use
ATS when the PF is quirk-disabled or untrusted, which is the kernel’s
PF-centric ATS model. That is appropriate here.

### What the commit solves for users of this tree
Without it, `pci_ats_supported(VF)` can be true while the PF has
`ats_cap == 0` (FINAL `quirk_no_ats`) or is untrusted. IOMMU drivers
then set up ATS on the VF. That can enable ATS on hardware the PF quirk
turned off (Intel E2000: bad invalidate endianness → stale translations
/ instability), or fail later in `pci_enable_ats()` and leave IOMMU/PCI
ATS state inconsistent.

### Verification
- [Phase 1] Tags: five Reviewed-by + Bjorn Acked-by; no Fixes/Reported-
  by/Cc: stable
- [Phase 1] Cover letter from `/tmp/ats-thread.mbox`: `iova_stress`, PF
  quirk gap
- [Phase 2] Diff: +5/−2 in `pci_ats_supported()` only
- [Phase 3] `git blame`: helper from `521376741b2c2` (v5.8); VF walk
  from `4f2cd6091ac41`
- [Phase 3] `git show 4f2cd6091ac41^:drivers/pci/ats.c`: old `return
  (dev->untrusted == 0)`
- [Phase 3] Series 2/4 is `6fd7c5c81af23`; not required for this helper
  change
- [Phase 4] `b4 dig -c 4f2cd6091ac41`: v9 1/4 at
  patch.msgid.link/20260615235037.259909-2-praan@google.com
- [Phase 4] `b4 dig -a`: v3–v9; applied = v9
- [Phase 4] `b4 dig -w`: PCI + IOMMU maintainers on Cc
- [Phase 4] mbox msg 9: Joerg “Applied, thanks.” No NAK
- [Phase 4] WebFetch lore: 403; used b4 mbox instead
- [Phase 5] Callers: VT-d, SMMUv3, AMD IOMMU,
  `pci_enable_ats`/`pci_prepare_ats`
- [Phase 5] `pci_device_add` vs `pci_bus_add_device`: IOMMU probe before
  FINAL `quirk_no_ats`
- [Phase 6] `git describe HEAD` = v7.3-rc4-27-gf0100363d8c37; `make
  kernelversion` = 7.3.0-rc4
- [Phase 6] `git merge-base --is-ancestor 4f2cd6091ac41 HEAD` = yes
- [Phase 8] E2000 quirk commit `a18615b1cfc04`: ATS invalidate endian
  bug → system instability
- UNVERIFIED: full `iova_stress` log; whether every E2000 VF ID is
  already quirked

The fix is small, surgical, and meets the stable criteria for this tree.

**YES**

 drivers/pci/ats.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
index ec6c8dbdc5e9c..a5fa7745bce8e 100644
--- a/drivers/pci/ats.c
+++ b/drivers/pci/ats.c
@@ -40,10 +40,13 @@ void pci_ats_init(struct pci_dev *dev)
  */
 bool pci_ats_supported(struct pci_dev *dev)
 {
-	if (!dev->ats_cap)
+	if (!dev->ats_cap || dev->untrusted)
 		return false;
 
-	return (dev->untrusted == 0);
+	if (dev->is_virtfn)
+		return pci_ats_supported(pci_physfn(dev));
+
+	return true;
 }
 EXPORT_SYMBOL_GPL(pci_ats_supported);
 
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-5.10] PCI/ATS: Ensure pci_ats_supported() is PF-aware for VFs

[sashiko-bot]

> From: Pranjal Shrivastava <praan@google.com>
> 
> [ Upstream commit 4f2cd6091ac41566a7300f5a4590d20a99aaa8bc ]
> 
> Update pci_ats_supported() to additionally check the associated PF's
> status when called on a VF. This ensures that PF-level quirks and
> untrusted status are correctly propagated to VFs, providing a robust
> support check that aligns with the kernel's PF-centric ATS configuration
> model and is immune to the timing of VF-specific fixups.
> 
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> Signed-off-by: Pranjal Shrivastava <praan@google.com>
> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
> Signed-off-by: Sasha Levin <sashal@kernel.org>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261019135441.1420968-456-sashal@kernel.org?part=1