[PATCH AUTOSEL 7.0-6.12] bus: mhi: host: pci_generic: Add Qualcomm SDX35 modem

[Sasha Levin <sashal@kernel.org>]

From: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>

[ Upstream commit 6a7084102bb9659f699005c420eb59eade6d3b4f ]

Add support for sdx35 modem. Similar to SDX75, SDX35 can take longer to
transition to ready during power up, so use modem_qcom_v2_mhiv_config
configurations.

01:00.0 Unassigned class [ff00]: Qualcomm Device 011a
            Subsystem: Qualcomm Device 011a

Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260123-mhi_sdx35-v1-1-79440abf0c92@oss.qualcomm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

I have all the information needed. Let me now write the full analysis.

---

## Complete Analysis

### PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject line parsing**
- Record: subsystem=`bus: mhi: host: pci_generic`, action=`Add`,
  summary=`Qualcomm SDX35 modem support`

**Step 1.2: Tag parsing**
- Record: Signed-off-by: Krishna Chaitanya Chundru (author); Signed-off-
  by: Manivannan Sadhasivam (MHI maintainer, who applied the patch);
  Link: to patch.msgid.link. No Fixes:, no Cc: stable, no Reported-by:,
  no syzbot references. Single-version patch (v1), applied directly by
  the maintainer.

**Step 1.3: Commit body analysis**
- Record: Body states SDX35 (like SDX75) can take longer to transition
  to ready during power up, hence using the existing
  `modem_qcom_v2_mhiv_config` which has `ready_timeout_ms = 50000`.
  Provides `lspci` output showing the device signature (vendor 0x17cb /
  PID 0x011a). No stack traces, no bug symptoms — this is hardware
  enablement, not a bug fix.

**Step 1.4: Hidden bug fix detection**
- Record: Not a hidden bug fix. Pure hardware enablement — new device
  support for an existing driver. No "handle", "ensure", "initialize",
  or "balance" language.

### PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Record: Single file `drivers/bus/mhi/host/pci_generic.c`, +12/-0
  lines. Adds one static `struct mhi_pci_dev_info mhi_qcom_sdx35_info`
  (10 lines) and one entry in `mhi_pci_id_table[]` (2 lines). No
  existing code modified. Single-file, purely additive.

**Step 2.2: Code flow change**
- Record: Before: PID 0x011a only matched specifically via
  `PCI_DEVICE_SUB` for Telit FN920C04 (subvendor 0x1c5d, subdevice
  0x2020); other SDX35 boards did not bind. After: the specific Telit
  match stays (first in table → takes precedence), and any other
  0x17cb:0x011a modem binds to a new generic SDX35 config that uses the
  already-existing `modem_qcom_v2_mhiv_config`.

**Step 2.3: Bug mechanism**
- Record: Category (h) — hardware workaround / new device ID. No
  locking, memory, refcount, or error-path changes.

**Step 2.4: Fix quality**
- Record: Obviously correct — follows the same pattern used for every
  other MHI modem (SDX55, SDX65, SDX75, SDX72). Match ordering preserves
  existing FN920C04 binding because `pci_match_id()` returns the first
  matching entry. Zero risk to existing devices; only affects previously
  unbound 0x011a hardware. Uses an already-upstream config
  (`modem_qcom_v2_mhiv_config`, present since commit `5571519009d09` in
  v6.8).

### PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: git blame**
- Record: The `modem_qcom_v2_mhiv_config` that this patch consumes was
  introduced in `5571519009d09` ("bus: mhi: host: pci_generic: Add SDX75
  based modem support", v6.8). The table and struct patterns being
  extended are long-standing.

**Step 3.2: Fixes: tag follow-up**
- Record: N/A — no Fixes: tag. This is hardware enablement, not a bug
  fix.

**Step 3.3: File history**
- Record: Recent `pci_generic.c` changes show a steady cadence of device
  ID additions (Foxconn T99W760 `ac35e04f8000a`, FN990B40
  `00559ba3ae740`, FE990B40 `6eaee77923ddf`, FN920C04 `6348f62ef7ecc`,
  T99W696 `0d63055e1406c`, etc.). Each follows the same pattern: new
  `mhi_pci_dev_info` struct + new PCI ID table entry. Self-contained,
  standalone — no series.

**Step 3.4: Author history**
- Record: Krishna Chaitanya Chundru (Qualcomm) is a regular contributor
  to MHI / Qcom PCIe subsystems. Co-signed and applied by Manivannan
  Sadhasivam, the MHI maintainer. Authorial credibility is high.

**Step 3.5: Dependencies**
- Record: Depends only on `modem_qcom_v2_mhiv_config` (present since
  v6.8). Applies standalone. No series prerequisites.

### PHASE 4: MAILING LIST RESEARCH

**Step 4.1: b4 dig**
- Record: `b4 dig -c 6a7084102bb96` matched by patch-id and returned `ht
  tps://lore.kernel.org/all/20260123-mhi_sdx35-v1-1-
  79440abf0c92@oss.qualcomm.com/`. Single revision (v1). Read the full
  thread via mbox.

**Step 4.2: Review history**
- Record: Only one reviewer comment — Konrad Dybcio noted the
  "Unassigned class" in the lspci output looks like a separate issue;
  Mani replied that this is a well-known Qcom-modem endpoint class issue
  and he had posted a separate PCI quirk patch for it. No NAKs, no
  concerns raised about this patch. No stable-tree nomination by any
  reviewer. Maintainer applied as-is.

**Step 4.3: Bug reports**
- Record: N/A — no Reported-by, no bug-report Link.

**Step 4.4: Series**
- Record: Standalone single patch (v1-1-1).

**Step 4.5: Stable ML**
- Record: No stable@ list discussion relevant to this patch.

### PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1-5.5:**
- Record: No functions are modified. The change is data-only (two static
  structures). `modem_qcom_v2_mhiv_config` is consumed by existing MHI
  init paths (`mhi_register_controller()` via `mhi_pci_probe()`), which
  are unchanged. No call-chain impact — the new data only activates the
  existing, stable driver code paths for a previously-unbound PID.

### PHASE 6: STABLE-TREE CROSS-REFERENCING

**Step 6.1: Does the code exist in stable?**
- Record: `pci_generic.c` and `modem_qcom_v2_mhiv_config` exist in
  6.6.y, 6.12.y, 6.16.y, 6.17.y, and 7.0.y. The SDX75 commit that
  introduced the v2 config entered mainline in v6.8, so trees at or
  beyond 6.8 can apply this. For trees older than 6.8 (e.g. 6.6.y,
  6.1.y, 5.15.y), `modem_qcom_v2_mhiv_config` does not exist and this
  patch does not apply without additional backports.

**Step 6.2: Backport complications**
- Record: Clean apply expected for 6.12.y, 6.16.y, 6.17.y (the
  `mhi_qcom_sdx55_info` anchor and the 0x011a table entry context both
  exist in recent stable trees per `4e3297ec0c469` in 6.12.y which
  backported the FN920C04 context). For trees before v6.8, would require
  backporting the v2 config first — not worth it.

**Step 6.3: Related fixes in stable**
- Record: Similar device-ID additions in this exact file have routinely
  been picked into stable via AUTOSEL: `4e3297ec0c469` (FN920C04 →
  6.12.y), `bcaec58996672` (FN990B40 → 6.16.y), `df42e29132596` (T99W696
  variants → 6.17.y), etc. Consistent precedent.

### PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1: Subsystem / criticality**
- Record: `drivers/bus/mhi/host/pci_generic.c` — MHI host stack, used by
  Qualcomm PCIe modems (WWAN). PERIPHERAL in the sense that it affects
  users of specific hardware, but popular hardware (laptops, routers, 5G
  WWAN cards).

**Step 7.2: Activity**
- Record: Actively developed. The file receives multiple device-ID
  additions per release cycle.

### PHASE 8: IMPACT AND RISK

**Step 8.1: Affected users**
- Record: Users of SDX35-based modems that are NOT the Telit FN920C04.
  Examples: Qcom reference designs, SDX35-based 5G/LTE cards from
  various OEMs. Without this patch, those boards don't bind to the
  driver at all.

**Step 8.2: Trigger conditions**
- Record: Device probe on the affected PCI card. Common, normal-path
  code.

**Step 8.3: Failure mode severity**
- Record: WITHOUT patch: SDX35 modem does not bind → no WWAN
  connectivity on affected hardware (functional loss for those users).
  Not a crash/corruption — severity MEDIUM (feature not working), but it
  is a real user-visible loss of function. WITH patch: existing devices
  unaffected (FN920C04 keeps its specific entry first), new hardware
  starts working.

**Step 8.4: Risk vs benefit**
- Record: Benefit = hardware enablement for SDX35 modems. Risk =
  essentially zero: additive-only change, reuses an existing config,
  match ordering keeps existing Telit FN920C04 behavior, no code paths
  modified. Classic device-ID-add exception to stable rules.

### PHASE 9: SYNTHESIS

**Step 9.1: Evidence**
- FOR: Exception category (new device ID to existing driver); tiny
  additive change (+12 lines); reuses existing upstream infrastructure;
  applied by the subsystem maintainer; no concerns raised in review;
  consistent with precedent of similar MHI modem additions being picked
  into stable (FN920C04, FN990B40, FE990B40, T99W696 variants).
- AGAINST: No Fixes:/Cc: stable (expected per task instructions —
  absence is not a negative signal); not a bug fix in the traditional
  sense; won't apply to trees older than v6.8.
- Unresolved: None of material weight.

**Step 9.2: Stable-rules checklist**
1. Obviously correct? YES — trivial additive data.
2. Fixes a real issue? YES — enables hardware that currently does not
   work.
3. Important? MEDIUM — feature enablement (functional, not
   catastrophic).
4. Small and contained? YES — 12 lines, one file.
5. No new features/APIs? YES — no new exported symbols, no new userspace
   ABI.
6. Applies to stable? YES for recent trees (v6.8+); NO for older trees.

**Step 9.3: Exception category**
- Record: DEVICE ID ADDITION to an existing driver — explicit stable-
  rules exception.

**Step 9.4: Decision**
- The change meets the device-ID-addition exception. It uses
  infrastructure already present in 6.8+, is minimal, is applied by the
  maintainer, has no regression risk, and has strong precedent among
  sibling MHI modem additions that have routinely been picked up by
  stable.

---

### Verification

- [Phase 1] Parsed tags from commit body: found Signed-off-by author +
  MHI maintainer, Link: to lore, no Fixes:/Reported-by:/Cc: stable.
- [Phase 2] Read the diff in the file context at
  `drivers/bus/mhi/host/pci_generic.c` lines 900–948: confirmed the new
  `PCI_DEVICE(0x17cb, 0x011a)` entry is placed AFTER the specific
  `PCI_DEVICE_SUB(..., 0x1c5d, 0x2020)` for FN920C04, preserving
  existing match.
- [Phase 3] `git log -S "modem_qcom_v2_mhiv_config"`: confirmed config
  introduced in `5571519009d09` (SDX75, v6.8).
- [Phase 3] `git log -- drivers/bus/mhi/host/pci_generic.c`: confirmed
  steady cadence of similar device-ID additions.
- [Phase 4] `b4 dig -c 6a7084102bb96`: matched single-revision thread at
  lore.kernel.org/all/20260123-mhi_sdx35-v1-1-
  79440abf0c92@oss.qualcomm.com.
- [Phase 4] Read full mbox thread: one review comment (Konrad re:
  unrelated class quirk), Mani applied as-is. No NAKs, no stable
  nomination.
- [Phase 6] `git log stable/linux-6.12.y --grep=FN920C04`: confirmed
  `4e3297ec0c469` backport present (precedent).
- [Phase 6] `git log stable/linux-6.16.y --grep="Add Telit FN990B40"`:
  confirmed `bcaec58996672` backport present (precedent).
- [Phase 6] `git log stable/linux-6.17.y --grep="mhi.*pci_generic"`:
  confirmed `df42e29132596` (T99W696 variants) backport present.
- [Phase 6] Confirmed file exists in all active stable trees;
  `modem_qcom_v2_mhiv_config` specifically requires v6.8+.
- [Phase 7] File path `drivers/bus/mhi/host/pci_generic.c` → MHI host /
  PCIe modem bus — peripheral hardware driver.
- UNVERIFIED: Exact match behavior on every stable tree — presumed clean
  apply for 6.12+ based on file structure; unverified for pre-6.8 trees
  (but not applicable since v2 config doesn't exist there).

This is a textbook device-ID addition to an existing driver — explicit
stable-kernel-rules exception, minimal scope, zero regression risk,
maintainer-applied, with clear precedent for sibling commits being
backported.

**YES**

 drivers/bus/mhi/host/pci_generic.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/bus/mhi/host/pci_generic.c b/drivers/bus/mhi/host/pci_generic.c
index 0884a384b77fc..425362037830e 100644
--- a/drivers/bus/mhi/host/pci_generic.c
+++ b/drivers/bus/mhi/host/pci_generic.c
@@ -407,6 +407,16 @@ static const struct mhi_pci_dev_info mhi_qcom_sdx55_info = {
 	.sideband_wake = false,
 };
 
+static const struct mhi_pci_dev_info mhi_qcom_sdx35_info = {
+	.name = "qcom-sdx35m",
+	.config = &modem_qcom_v2_mhiv_config,
+	.bar_num = MHI_PCI_DEFAULT_BAR_NUM,
+	.dma_data_width = 32,
+	.mru_default = 32768,
+	.sideband_wake = false,
+	.edl_trigger = true,
+};
+
 static const struct mhi_pci_dev_info mhi_qcom_sdx24_info = {
 	.name = "qcom-sdx24",
 	.edl = "qcom/prog_firehose_sdx24.mbn",
@@ -909,6 +919,8 @@ static const struct pci_device_id mhi_pci_id_table[] = {
 	/* Telit FN920C04 (sdx35) */
 	{PCI_DEVICE_SUB(PCI_VENDOR_ID_QCOM, 0x011a, 0x1c5d, 0x2020),
 		.driver_data = (kernel_ulong_t) &mhi_telit_fn920c04_info },
+	{ PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x011a),
+		.driver_data = (kernel_ulong_t) &mhi_qcom_sdx35_info },
 	{ PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x0304),
 		.driver_data = (kernel_ulong_t) &mhi_qcom_sdx24_info },
 	{ PCI_DEVICE_SUB(PCI_VENDOR_ID_QCOM, 0x0306, PCI_VENDOR_ID_QCOM, 0x010c),
-- 
2.53.0