[PATCH AUTOSEL 7.0-5.10] serial: qcom-geni: Fix RTS behavior with flow control

[PATCH AUTOSEL 7.0-5.10] serial: qcom-geni: Fix RTS behavior with flow control

[Sasha Levin]

From: Anup Kulkarni <anup.kulkarni@oss.qualcomm.com>

[ Upstream commit 0b1837c04d2335ec50b9a55b0282dcde7bc12439 ]

When userspace enables flow control (CRTSCTS), the driver
deasserts RTS even when the receive buffer has space. This prevents the
peer device from transmitting, causing communication to stall.

The root cause is that the driver unconditionally uses manual RTS control
regardless of flow control mode. When CRTSCTS is set, the hardware should
automatically manage RTS based on buffer status, but the driver overrides
this by setting manual control.

Fix this by introducing port->manual_flow flag. In set_termios(), disable
manual flow when CRTSCTS is set. In set_mctrl(), only assert
SE_UART_MANUAL_RFR when manual_flow is active. Verified by enabling and
disabling hardware flow control with stty.

Signed-off-by: Anup Kulkarni <anup.kulkarni@oss.qualcomm.com>
Link: https://patch.msgid.link/20260310104155.339010-1-anup.kulkarni@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have enough information to complete the full analysis.

## Analysis

### PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject line parse**
- Record: [serial: qcom-geni:] [fix] [RTS behavior with hardware flow
  control (CRTSCTS)]

**Step 1.2: Tag inventory**
- Record: Signed-off-by: Anup Kulkarni (author, @oss.qualcomm.com),
  Signed-off-by: Greg KH (applied to tty tree). Link: patch.msgid.link
  URL. NO Fixes: tag, NO Cc: stable, NO Reported-by, NO Tested-by, NO
  Reviewed-by, NO Acked-by. Only v1 of patch, no reviewer replies on
  thread.

**Step 1.3: Commit body analysis**
- Record: Bug: "driver deasserts RTS even when the receive buffer has
  space" when CRTSCTS is enabled, causing "communication to stall". Root
  cause: driver unconditionally uses manual RTS control via
  `UART_MANUAL_RFR_EN`, which overrides hardware's auto-flow control. No
  stack trace or reproducer. Author verified fix "by enabling and
  disabling hardware flow control with stty".

**Step 1.4: Hidden bug fix detection**
- Record: Not hidden - commit message explicitly says "Fix RTS behavior"
  and describes the bug clearly.

### PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Record: Single file `drivers/tty/serial/qcom_geni_serial.c`. +15/-4
  lines. Modifies `qcom_geni_serial_set_mctrl()` (1 line guard added)
  and `qcom_geni_serial_set_termios()` (restructured CRTSCTS branch).
  Adds `bool manual_flow` to `struct qcom_geni_serial_port`. Scope:
  surgical single-driver fix.

**Step 2.2: Code flow change**
- Record:
  - set_mctrl BEFORE: `if (!(mctrl & TIOCM_RTS) && !uport->suspended)` →
    enable manual RFR (`UART_MANUAL_RFR_EN | UART_RFR_NOT_READY`) then
    unconditionally write.
  - set_mctrl AFTER: Only enables manual RFR when `port->manual_flow` is
    true AND RTS not set AND not suspended.
  - set_termios BEFORE: Only toggles `UART_CTS_MASK` bit in TX config.
  - set_termios AFTER: Also sets `port->manual_flow = false` when
    CRTSCTS set (HW manages), `true` otherwise.

**Step 2.3: Bug mechanism**
- Record: Category (g) Logic/correctness fix. The mechanism: when
  CRTSCTS is enabled, hardware should automatically drive RTS based on
  RX FIFO fullness. But any call to `set_mctrl` with `!TIOCM_RTS` (which
  happens during resume: `ops->set_mctrl(uport, 0)` at
  serial_core.c:2421, at B0 baud transitions serial_core.c:1685, or on
  ioctl TIOCMBIC) would cause the driver to write `UART_MANUAL_RFR_EN |
  UART_RFR_NOT_READY`, forcing manual RTS deassertion and preventing the
  peer from transmitting.

**Step 2.4: Fix quality**
- Record: Simple, easy to verify by reading. Logic is correct: when
  hardware flow control is enabled, never override with manual mode. The
  `manual_flow` flag is BSS-initialized to `false`, which matches
  "hardware controls RTS" default. Small regression risk: before the
  first `set_termios` call, any `set_mctrl(!TIOCM_RTS)` path now writes
  0 instead of enabling manual mode; this is arguably more correct but
  changes initial state. No public API changes, no lock changes.

### PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame the changed lines**
- Record: The manual RFR logic in `set_mctrl` was added in
  `8a8a66a1a18a1` (v4.19, July 2018) "tty: serial: qcom_geni_serial: Add
  support for flow control". The early-return guard
  `!uart_cts_enabled(uport)` was removed in `e8a6ca808c5ed` (v5.0) "tty:
  serial: qcom_geni_serial: Allow mctrl when flow control is disabled" —
  which actually made the bug more exposed (before that change, the
  manual-mode code path was unreachable when CRTSCTS was off, but still
  buggy when on).

**Step 3.2: Follow the Fixes: tag**
- Record: No Fixes: tag in this commit. Most likely should reference
  `8a8a66a1a18a1` (v4.19) as the origin — the bug has existed since flow
  control support was added to this driver.

**Step 3.3: File history for related changes**
- Record: Recent related fix `947cc4ecc06cb` "serial: qcom-geni: fix
  soft lockup on sw flow control and suspend" (July 2024) was tagged
  `Cc: stable # 4.17` — shows that flow-control-related bugs in this
  driver have been deemed stable-worthy. Also `23f5f5debcaac` "serial:
  qcom-geni: fix shutdown race" exists. No overlap/conflict with this
  fix.

**Step 3.4: Author commits**
- Record: `git log --author="Anup Kulkarni"` shows only 1 other commit
  (`4fcc287f3c692` "serial: qcom-geni: Enable support for half-duplex
  mode"). Newer contributor but from @oss.qualcomm.com - this is the
  vendor (Qualcomm) whose hardware this driver supports. Patch went
  through Greg KH's tty tree.

**Step 3.5: Dependencies**
- Record: No dependencies found. The fix is self-contained and
  references only symbols that exist since the original flow control
  support commit (v4.19).

### PHASE 4: MAILING LIST RESEARCH

**Step 4.1: b4 dig**
- Record: Single revision (v1) at https://patch.msgid.link/2026031010415
  5.339010-1-anup.kulkarni@oss.qualcomm.com. Thread mbox retrieved. Only
  one message in thread - just the patch itself, no replies, no NAK, no
  explicit stable nomination.

**Step 4.2: Who reviewed**
- Record: `b4 dig -w` shows to/cc: gregkh, jirislaby (tty maintainers),
  praveen.talari/viken.dadhaniya/zongjian/jseerapu (Qualcomm),
  bryan.odonoghue (linaro), krzk (Krzysztof Kozlowski), linux-serial,
  linux-arm-msm, linux-kernel. Appropriate maintainers were CC'd but no
  one publicly replied on lore before Greg applied it.

**Step 4.3: Bug report search**
- Record: No Reported-by or bug link in commit. Web search did not
  surface a specific user report for this stall.

**Step 4.4: Related patches/series**
- Record: `b4 dig -a` shows v1 only; standalone single-patch submission.

**Step 4.5: Stable list history**
- Record: Nothing found discussing this specific fix on stable@.

### PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions modified**
- Record: `qcom_geni_serial_set_mctrl`, `qcom_geni_serial_set_termios`.

**Step 5.2: Callers**
- Record: Both are `uart_ops` callbacks registered in
  `qcom_geni_console_pops`/`qcom_geni_uart_pops`. Called indirectly
  through `port->ops->set_mctrl(...)` and `uport->ops->set_termios(...)`
  from `drivers/tty/serial/serial_core.c`. Key caller sites for
  `set_mctrl`: startup/shutdown, suspend/resume (lines 2333/2421), RS485
  disable path (1483), B0 transitions (1685/1692), throttle/unthrottle
  (with AUTORTS — not used here). This makes the bug reachable on every
  resume and on any baud change to/from B0 when CRTSCTS is active — very
  common paths.

**Step 5.3: Callees**
- Record: set_mctrl only calls `writel(...)` to SE_UART_MANUAL_RFR. No
  locking, no allocation. Minimal side effects.

**Step 5.4: Call chain reachability**
- Record: Reachable from any userspace UART open with CRTSCTS, stty
  changes, system suspend/resume, and B0 transitions. Definitely user-
  reachable, exercised on every device with hardware flow control
  enabled.

**Step 5.5: Similar patterns**
- Record: Verified driver does NOT advertise `UPSTAT_AUTORTS` (no hits
  for that flag) - so auto-RTS tty layer logic doesn't apply; the driver
  relies entirely on hardware register-level RFR management when CRTSCTS
  is on. This confirms the issue: the driver's set_mctrl was silently
  overriding hardware-managed RTS.

### PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Does buggy code exist in stable?**
- Record: Verified the identical buggy `set_mctrl` body exists in stable
  6.17.y, 6.12.y, 6.6.y, 6.1.y, and 5.15.y. The same CRTSCTS branch `if
  (termios->c_cflag & CRTSCTS) tx_trans_cfg &= ~UART_CTS_MASK; else
  tx_trans_cfg |= UART_CTS_MASK;` is present in all of them. Bug has
  existed since v4.19 → affects ALL currently supported stable trees.

**Step 6.2: Backport complications**
- Record: Low complexity backport. The struct has `bool cts_rts_swap` in
  every stable branch (verified). Both hunks context-match. Minor
  difference: 5.15 uses legacy `to_dev_port(uport, uport)` macro
  (irrelevant to the hunk). Expected: clean apply or minor context
  rewrap.

**Step 6.3: Related fixes already in stable**
- Record: `947cc4ecc06cb` (flow control soft lockup fix) is already in
  stable and addresses a different flow-control issue. No conflict with
  this fix.

### PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1: Subsystem criticality**
- Record: Subsystem: `drivers/tty/serial/` — Qualcomm GENI serial
  driver. Criticality: PERIPHERAL (driver-specific) but IMPORTANT for
  the affected platforms (Qualcomm SoCs used in Chromebooks, embedded
  devices, Android phones, etc., where hardware flow control to
  Bluetooth/GPS/modem peripherals is critical).

**Step 7.2: Subsystem activity**
- Record: Driver is actively maintained, with regular fixes going in.
  This suggests real users.

### PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Who is affected**
- Record: Users of Qualcomm SoCs running Linux that use UART with
  `CRTSCTS` enabled — commonly Bluetooth HCI over UART, GPS modules,
  baseband modems. Affects Android devices, Chromebooks, embedded
  Qualcomm platforms.

**Step 8.2: Trigger conditions**
- Record: Trigger is any invocation of set_mctrl with RTS cleared while
  CRTSCTS is active. Concrete triggers:
  1. System suspend/resume cycle (very common on mobile/laptop)
  2. B0 baud transitions (modem hangup)
  3. Any direct ioctl(TIOCMBIC, &TIOCM_RTS)
  Unprivileged? Root access to the tty device is typical for the
trigger.

**Step 8.3: Failure mode severity**
- Record: Functional failure — communication stalls because RTS is stuck
  deasserted and peer stops transmitting. No kernel crash, no data
  corruption, no security hole. Severity: MEDIUM-HIGH — "communication
  stall" is a real stability issue for devices depending on this UART
  (e.g., Bluetooth dropouts, serial session lockups). Not a crash, but
  noticeable and disruptive.

**Step 8.4: Risk-benefit**
- Record:
  - Benefit: MEDIUM — fixes a real functional bug on actively-used
    hardware (Qualcomm platforms) with a clear reproduction path,
    especially after resume.
  - Risk: LOW — 15 lines, single file, trivial to audit, no
    locking/memory changes, no API changes. The `manual_flow` field
    defaults to `false` which aligns with hardware-managed mode (safe
    default).
  - Ratio: Favorable for backport. Very low risk of regression for
    benefit of fixing real-world stalls.

### PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence**
- FOR: Real user-visible bug clearly described; present since v4.19 in
  all stable trees; small surgical fix; touches only a driver callback;
  correct logical direction (CRTSCTS means HW controls, manual mode
  should be off); fix verified by author with stty; applies cleanly; no
  API/feature additions; author is Qualcomm, i.e., the hardware vendor.
- AGAINST: No Fixes: tag; no Cc: stable; no reviewer Ack/Reviewed-by; no
  user bug report linked; single-revision patch with no lore discussion;
  reachable in common paths but severity is functional (not
  crash/security/corruption).
- UNRESOLVED: Could not directly observe the reproduction trace (no
  stack trace in commit).

**Step 9.2: Stable rules checklist**
1. Obviously correct? YES — straightforward logic; author tested.
2. Fixes a real bug? YES — stated reproducer via stty.
3. Important? MEDIUM — functional stall on Qualcomm platforms using flow
   control (BT/GPS/modem), not a crash/security/corruption.
4. Small and contained? YES — 15 lines, 1 file, 1 driver.
5. No new features/APIs? YES — internal bool field only.
6. Applies to stable? YES — verified code exists unchanged in 5.15.y
   through 6.17.y.

**Step 9.3: Exception categories**
- Not strictly an exception, but closely aligned with a hardware
  workaround in a mature driver.

**Step 9.4: Decision**
This is a real, reproducible bug fix in a driver used on widely-deployed
Qualcomm hardware (Chromebooks, Android, embedded). The fix is tiny,
purely internal, doesn't introduce APIs or affect other subsystems, and
the logic is clearly correct (hardware flow control should not be
overridden by manual RTS assertion). The bug is reachable in common
operational paths (resume, B0 transitions). Backport risk is minimal.

## Verification

- [Phase 1] Parsed tags from commit: only Signed-off-by (author + Greg
  KH) and Link. No Fixes:, no Cc: stable, no Reported-by, no Reviewed-
  by/Acked-by.
- [Phase 2] Diff analysis confirmed on the actual patch text: 1-line
  guard in set_mctrl, 2 branches expanded to set `manual_flow`, 1 new
  struct field.
- [Phase 3] `git log` on file showed history; `git show 8a8a66a1a18a1`
  and `git show e8a6ca808c5ed` confirmed the code origin (v4.19 via git
  describe) and the removal of the CTS-enabled guard (v5.0).
- [Phase 3] `git describe --contains 8a8a66a1a18a1` →
  v4.19-rc1~102^2~33; `e8a6ca808c5ed` → v5.0-rc4~20^2~1. Bug has been
  present since v4.19.
- [Phase 3] `git log --author="Anup Kulkarni"` → 2 commits total (this
  one plus half-duplex mode). Relatively new contributor, Qualcomm
  vendor author.
- [Phase 3] `git log --grep="serial.*qcom.*flow"` → confirmed
  `947cc4ecc06cb` (previous flow control fix, tagged `Cc: stable #
  4.17`) is a precedent.
- [Phase 4] `b4 dig -c 0b1837c04d233` → found single lore thread, v1
  only, single message, no replies.
- [Phase 4] `b4 dig -c 0b1837c04d233 -w` → recipients confirmed: gregkh,
  jirislaby, Qualcomm team, bryan.odonoghue, krzk, linux-serial, linux-
  arm-msm, linux-kernel.
- [Phase 4] `b4 dig -c 0b1837c04d233 -a` → only v1 exists; went direct
  to Greg's tree.
- [Phase 4] Saved thread to /tmp/qcom_geni_thread.mbox; read contents -
  confirmed no replies, no reviewer feedback.
- [Phase 5] Grepped `UPSTAT_AUTORTS|UPSTAT_AUTOCTS` in
  qcom_geni_serial.c → no matches. Driver does NOT use UPSTAT_AUTORTS,
  so throttle/unthrottle don't clear RTS through set_mctrl path.
- [Phase 5] Grepped `SE_UART_MANUAL_RFR|UART_MANUAL_RFR_EN` → only 2
  writers: `qcom_geni_set_rs485_mode()` (only when RS485 enabled) and
  `qcom_geni_serial_set_mctrl()` (the fixed function). No other paths
  touch this register.
- [Phase 5] Read `serial_core.c:2320-2451` → confirmed
  `ops->set_mctrl(uport, 0)` is called at resume (2421) with
  `uport->suspended` already 0, directly triggering the bug path when
  CRTSCTS is active.
- [Phase 5] Read `serial_core.c:1680-1694` → confirmed B0 transition
  logic can cause set_mctrl with !TIOCM_RTS while CRTSCTS is active.
- [Phase 6] `git show stable/linux-
  {6.17,6.12,6.6,6.1,5.15}.y:drivers/tty/serial/qcom_geni_serial.c` →
  verified identical buggy `set_mctrl` body and identical CRTSCTS
  handling in set_termios in all five stable trees. Struct has
  `cts_rts_swap` in all of them, so the `manual_flow` addition will fit
  cleanly.
- [Phase 8] Failure mode: communication stall (peer cannot transmit). No
  crash. Severity: MEDIUM-HIGH functional. Trigger: common (resume, B0).
- UNVERIFIED: Could not obtain a literal crash/stall reproducer from
  commit message; the author's claim of verification via stty is the
  only direct test evidence. Did not independently reproduce the bug.

The fix is small, narrowly scoped, logically sound, and addresses a real
functional bug that is triggered on common paths (resume, B0) in a
driver used on widely-deployed hardware. It meets the stable kernel
rules.

**YES**

 drivers/tty/serial/qcom_geni_serial.c | 19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
index e6b0a55f0cfb2..9854bb2406e3f 100644
--- a/drivers/tty/serial/qcom_geni_serial.c
+++ b/drivers/tty/serial/qcom_geni_serial.c
@@ -146,6 +146,7 @@ struct qcom_geni_serial_port {
 	int wakeup_irq;
 	bool rx_tx_swap;
 	bool cts_rts_swap;
+	bool manual_flow;
 
 	struct qcom_geni_private_data private_data;
 	const struct qcom_geni_device_data *dev_data;
@@ -250,7 +251,7 @@ static void qcom_geni_serial_set_mctrl(struct uart_port *uport,
 	if (mctrl & TIOCM_LOOP)
 		port->loopback = RX_TX_CTS_RTS_SORTED;
 
-	if (!(mctrl & TIOCM_RTS) && !uport->suspended)
+	if (port->manual_flow && !(mctrl & TIOCM_RTS) && !uport->suspended)
 		uart_manual_rfr = UART_MANUAL_RFR_EN | UART_RFR_NOT_READY;
 	writel(uart_manual_rfr, uport->membase + SE_UART_MANUAL_RFR);
 }
@@ -1401,11 +1402,21 @@ static void qcom_geni_serial_set_termios(struct uart_port *uport,
 	else
 		stop_bit_len = TX_STOP_BIT_LEN_1;
 
-	/* flow control, clear the CTS_MASK bit if using flow control. */
-	if (termios->c_cflag & CRTSCTS)
+	/* Configure flow control based on CRTSCTS flag.
+	 * When CRTSCTS is set, use HW/auto flow control mode, where HW
+	 * controls the RTS/CTS pin based FIFO state.
+	 * When CRTSCTS is clear, the CTS pin value is ignored for TX
+	 * path and RTS pin can be set/cleared using registers, for RX
+	 * path.
+	 */
+
+	if (termios->c_cflag & CRTSCTS) {
 		tx_trans_cfg &= ~UART_CTS_MASK;
-	else
+		port->manual_flow = false;
+	} else {
 		tx_trans_cfg |= UART_CTS_MASK;
+		port->manual_flow = true;
+	}
 
 	if (baud) {
 		uart_update_timeout(uport, termios->c_cflag, baud);
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] bus: mhi: host: pci_generic: Add Telit FE912C04 modem support

[Sasha Levin]

From: Daniele Palmas <dnlplm@gmail.com>

[ Upstream commit ac12b852b4ead4a586299c8f68cdcbcaf1bf6cbc ]

Add SDX35 based modem Telit FE912C04, reusing FN920C04 configuration.

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

Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260323122837.3406521-1-dnlplm@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Based on my analysis, this is a clear device-ID addition to an existing
driver. Let me provide the comprehensive analysis.

## Phase 1: Commit Message Forensics

**Step 1.1 - Subject line parse:**
Record: subsystem=`bus: mhi: host: pci_generic`, action verb=`Add`,
summary=`Add Telit FE912C04 modem support`

**Step 1.2 - Tag analysis:**
- Signed-off-by: Daniele Palmas (author, repeat contributor for Telit
  modems)
- Signed-off-by: Manivannan Sadhasivam (MHI maintainer)
- Link: lore.kernel.org thread
  (`20260323122837.3406521-1-dnlplm@gmail.com`)
- No Fixes:, no Cc: stable, no Reported-by:, no Tested-by:, no Reviewed-
  by:, no syzbot

Record: Standard maintainer-applied patch with no fix-related tags.

**Step 1.3 - Commit body:**
Single-paragraph body: states the device is SDX35-based, will reuse the
existing FN920C04 configuration, and includes an `lspci` snippet
confirming the PCI subsystem ID `1c5d:2045`. No bug description, no
symptom, no crash trace.

Record: This is a hardware enablement commit, not a bug fix.

**Step 1.4 - Hidden bug fix detection:**
The verb is "Add" with "modem support". No "handle", "ensure",
"prevent", "fix", "clean up". The diff is a textbook device-ID addition
reusing existing config. Not a hidden bug fix.

Record: Pure hardware enablement - new PCI device ID + descriptor for an
existing driver.

## Phase 2: Diff Analysis

**Step 2.1 - Inventory:**
- Files: `drivers/bus/mhi/host/pci_generic.c` only
- Total: +13 lines, -0 lines
- Functions modified: none (only adds a static struct and a table entry)
- Scope: single-file, surgical, additive

**Step 2.2 - Code flow change:**
- Before: `mhi_pci_id_table[]` did not match PCI VID 0x17cb / SVID
  `1c5d:2045`
- After: PCI core probes → matches new entry → loads MHI driver with
  `mhi_telit_fe912c04_info` (which uses already-existing
  `modem_telit_fn920c04_config`)

Record: Adds one new PCI table row + one descriptor struct. No
behavioral change for any existing device.

**Step 2.3 - Bug mechanism:**
Not a bug fix. This is category (h) "Hardware workarounds → Device ID
additions" from the stable rules exceptions.

**Step 2.4 - Fix quality:**
- Obviously correct: a new struct with same fields as
  `mhi_telit_fe990b40_info`, reusing `modem_telit_fn920c04_config`
  already proven for SDX35 hardware
- Minimal/surgical: 13 lines, contained in tables only
- Regression risk: nil for any user without that exact 1c5d:2045 device;
  for users with it, there is no other code path (driver simply wouldn't
  bind today)

## Phase 3: Git History Investigation

**Step 3.1 - git blame:** Not applicable - no existing buggy code is
being fixed; only additions.

**Step 3.2 - Fixes: tag:** Not present (and not expected for a device-ID
addition).

**Step 3.3 - File history (recent same-file commits):**
```
ac12b852b4ead Add Telit FE912C04 modem support       <- this commit
6eaee77923ddf Add Telit FE990B40 modem support
00559ba3ae740 Add Telit FN990B40 modem support
6348f62ef7ecc Add Telit FN920C04 modem support
```
Record: This is the latest in a steady cadence of Telit modem device-ID
additions. All prior siblings in this series were backported to stable
(verified below).

**Step 3.4 - Author history:**
Daniele Palmas is a long-time Telit modem submitter; Manivannan
Sadhasivam is the MHI subsystem maintainer who applied it.

**Step 3.5 - Dependencies:**
- Requires `modem_telit_fn920c04_config` (introduced by 6348f62ef7ecc,
  backported to 6.12+).
- Diff context anchored on `mhi_telit_fe990b40_info` (introduced by
  6eaee77923ddf, backported to 6.12+).
Both dependencies exist in stable 6.12.y, 6.18.y, 6.19.y, 7.0.y.

## Phase 4: Mailing List Investigation

**Step 4.1 - b4 dig:**
- `b4 dig -c ac12b852b4ead4a586299c8f68cdcbcaf1bf6cbc` matched by patch-
  id and resolved to
  https://lore.kernel.org/all/20260323122837.3406521-1-dnlplm@gmail.com/
- Single revision (PATCH 1/1), no v2/v3.
- Maintainer reply: "Applied, thanks!" - no review concerns, no NAKs, no
  stable nomination requested.

**Step 4.2 - Reviewers:** Patch sent to maintainer Manivannan
Sadhasivam, mhi@lists.linux.dev, linux-arm-msm@vger.kernel.org. Right
people CC'd. Maintainer applied.

**Step 4.3 - Bug reports:** Not applicable; no Reported-by/Link to bug
tracker.

**Step 4.4 - Series context:** Standalone single-patch.

**Step 4.5 - Stable list:** No prior stable discussion (typical for a
new device ID).

## Phase 5: Code Semantic Analysis

**Step 5.1 - Functions:** None modified; only data-structure additions.

**Step 5.2-5.4 - Reachability:** The new entry is reachable only when
the PCI core enumerates a device with VID=QCOM(0x17cb), DID=0x011a,
SVID=0x1c5d, SSID=0x2045. No other code path is affected.

**Step 5.5 - Similar patterns:** The same pattern (adding
`mhi_pci_dev_info` + `pci_device_id`) is used for FN920C04, FN990B40,
FE990B40 - all backported.

## Phase 6: Cross-Referencing & Stable Tree Analysis

**Step 6.1 - Buggy code in stable:** N/A (no bug being fixed).

**Step 6.2 - Backport feasibility:**
- 7.0.y, 6.19.y, 6.18.y, 6.12.y: dependencies present → patch should
  apply cleanly with at most trivial offset.
- 6.6.y: `modem_telit_fn920c04_config` and `mhi_telit_fe990b40_info` are
  NOT in `pci_generic.c` → patch will not apply cleanly. Backport for
  6.6.y would require backporting prerequisites first (which were not
  selected for 6.6.y).

**Step 6.3 - Related fixes already in stable:**
- 6348f62ef7ecc (FN920C04) → backported as 4e3297ec0c469
- 00559ba3ae740 (FN990B40) → backported as 1ee92e44c3316 / 7bce22989c7b7
- 6eaee77923ddf (FE990B40) → backported as 9bef8beef1557 / 3a15c519d2b0f

The pattern clearly establishes that every prior Telit/MHI device-ID
addition in this file has been backported.

## Phase 7: Subsystem Context

Subsystem: `drivers/bus/mhi/host/` - host-side MHI bus controllers,
primarily for Qualcomm SoC modems used as PCIe-attached cellular cards.
Criticality: PERIPHERAL (hardware-specific) but with real-world users
(laptops, IoT, M2M deployments).
Activity: Active and well-maintained.

## Phase 8: Impact and Risk

**Step 8.1 - Affected users:** Owners of Telit FE912C04 modems (a real
product). Without this patch the device will not bind to any kernel
driver.

**Step 8.2 - Trigger:** Plugging in the specific hardware. No security
relevance, no unprivileged trigger.

**Step 8.3 - Failure mode without patch:** Device simply doesn't work
(no driver binds). With patch: device works using existing, tested
FN920C04 channel/event configuration.

**Step 8.4 - Risk-benefit:**
- Benefit: enables hardware on stable users' systems - high for affected
  users, none for others
- Risk: ~0 - additive only, scoped to one specific PCI subsystem ID,
  reuses already-validated config

## Phase 9: Final Synthesis

**Stable rules checklist:**
1. Obviously correct? YES - reuses already-validated
   `modem_telit_fn920c04_config`
2. Fixes a real bug? Strictly no, but enables real hardware (explicit
   stable exception)
3. Important issue? Hardware enablement, qualifies under exception
4. Small and contained? YES - 13 lines, single file
5. No new features/APIs? YES - no userspace API change, no new module
   behavior
6. Applies to stable? YES for 6.12.y, 6.18.y, 6.19.y, 7.0.y; NO for
   6.6.y (needs prerequisites)

**Exception category:** "NEW DEVICE IDs" - explicitly listed as an
allowed addition for stable.

**Precedent:** All three sibling Telit MHI device-ID additions
(FN920C04, FN990B40, FE990B40) have been backported to stable,
establishing clear policy for this exact scenario.

## Verification

- [Phase 1] Read commit message: confirmed only Signed-off-by (author +
  maintainer) and Link tags; no Fixes/Reported-by/Cc:stable/Tested-
  by/Reviewed-by.
- [Phase 2] `git show ac12b852b4ead`: confirmed +13/-0 lines, all in
  `drivers/bus/mhi/host/pci_generic.c`; verified one new
  `mhi_pci_dev_info` struct and one `pci_device_id` table entry.
- [Phase 3.3] `git log --oneline -- drivers/bus/mhi/host/pci_generic.c`:
  confirmed prior commits FN920C04, FN990B40, FE990B40.
- [Phase 3.5] `grep modem_telit_fn920c04_config pci_generic.c`:
  confirmed config struct exists at line 846 in current tree (introduced
  by FN920C04 commit).
- [Phase 4.1] `b4 dig -c ac12b852b4ead`: matched single-revision thread
  at lore.kernel.org/all/20260323122837.3406521-1-dnlplm@gmail.com/;
  saved mbox; read maintainer's "Applied, thanks!" reply with no
  concerns.
- [Phase 6.2] `git cat-file -p stable/linux-
  {6.12,6.18,6.19,7.0}.y:drivers/bus/mhi/host/pci_generic.c`: confirmed
  `modem_telit_fn920c04_config` and `mhi_telit_fe990b40_info` (anchor
  lines for the diff) are present in 6.12.y, 6.18.y, 6.19.y, 7.0.y
  stable trees.
- [Phase 6.2] `git cat-file -p
  stable/linux-6.6.y:drivers/bus/mhi/host/pci_generic.c`: confirmed
  `modem_telit_fn920c04_config` is NOT in 6.6.y (only earlier modem
  configs present); 6.6.y would need prerequisites.
- [Phase 6.3] `git show 4e3297ec0c469 / 1ee92e44c3316 / 9bef8beef1557`:
  confirmed these are stable backports of upstream commits
  6348f62ef7ecc, 00559ba3ae740, 6eaee77923ddf with "[upstream] commit
  ... upstream." in the body, signed by Greg KH.
- [Phase 8] Diff inspection: no new module parameter, no sysfs, no
  userspace ABI; only additions to two static tables.
- UNVERIFIED: Could not verify without trying that the patch will apply
  with zero context conflict on stable 6.12.y - but anchor-line
  `mhi_telit_fe990b40_info` is present, so a clean apply is highly
  likely.

The change is a textbook PCI device-ID addition for an existing driver,
reusing already-validated configuration, with strong precedent that all
three sibling device-ID additions in the same file have been accepted to
stable. Risk is essentially nil; the benefit is enabling real hardware
for stable users. It falls squarely under the explicitly documented "NEW
DEVICE IDs" exception.

**YES**

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

diff --git a/drivers/bus/mhi/host/pci_generic.c b/drivers/bus/mhi/host/pci_generic.c
index 425362037830e..5db3df20088fd 100644
--- a/drivers/bus/mhi/host/pci_generic.c
+++ b/drivers/bus/mhi/host/pci_generic.c
@@ -892,6 +892,16 @@ static const struct mhi_pci_dev_info mhi_telit_fe990b40_info = {
 	.edl_trigger = true,
 };
 
+static const struct mhi_pci_dev_info mhi_telit_fe912c04_info = {
+	.name = "telit-fe912c04",
+	.config = &modem_telit_fn920c04_config,
+	.bar_num = MHI_PCI_DEFAULT_BAR_NUM,
+	.dma_data_width = 32,
+	.sideband_wake = false,
+	.mru_default = 32768,
+	.edl_trigger = true,
+};
+
 static const struct mhi_pci_dev_info mhi_netprisma_lcur57_info = {
 	.name = "netprisma-lcur57",
 	.edl = "qcom/prog_firehose_sdx24.mbn",
@@ -919,6 +929,9 @@ 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 },
+	/* Telit FE912C04 (sdx35) */
+	{ PCI_DEVICE_SUB(PCI_VENDOR_ID_QCOM, 0x011a, 0x1c5d, 0x2045),
+		.driver_data = (kernel_ulong_t) &mhi_telit_fe912c04_info },
 	{ PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x011a),
 		.driver_data = (kernel_ulong_t) &mhi_qcom_sdx35_info },
 	{ PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x0304),
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] clk: qcom: rcg2: expand frac table for mdss_pixel_clk_src

[Sasha Levin]

From: Pengyu Luo <mitltlatltl@gmail.com>

[ Upstream commit 0f5c8f03d990f9be9908a08a701c324e113554d2 ]

Recently, when testing 10-bit dsi C-PHY panel, clks are different
from the usual. (dsi0_phy_pll_out_dsiclk's parent is dsi0_pll_bit_clk
now (dsiclk_sel = 0)) And we failed to set dsiclk's children.

dsi_link_clk_set_rate_6g: Set clk rates: pclk=172992000, byteclk=108120000

byteclk was set first to 108120000, so the vco rate was set to
108120000 * 7 * 1 * 1 = 756840000. When we was trying to set
172992000 on mdss_pixel_clk_src later.

Since there was no matched ratio, we failed to set it. And dsiclk
divider ratio was set to 15:1 (wrong cached register value 0xf and
didn't update), we finally got 50455997, apparently wrong.

  dsi0vco_clk                1       1        0        756839941
     dsi0_pll_out_div_clk    1       1        0        756839941
        dsi0_pll_post_out_div_clk 0       0        0        216239983
        dsi0_pll_bit_clk     2       2        0        756839941
           dsi0_phy_pll_out_dsiclk 2       2        0        50455997
              disp_cc_mdss_pclk1_clk_src 1       1        0        50455997
           dsi0_pll_by_2_bit_clk 0       0        0        378419970
           dsi0_phy_pll_out_byteclk 2       2        0        108119991
              disp_cc_mdss_byte1_clk_src 2       2        0        108119991

Downstream clk_summary shows the mdss_pixel_clk_src support the
ratio(35:16)

 dsi0_phy_pll_out_dsiclk             2       2        0        378420000
     disp_cc_mdss_pclk1_clk_src       1       1        0        172992000
 dsi0_phy_pll_out_byteclk            2       2        0        108120000
     disp_cc_mdss_byte1_clk_src       2       2        0        108120000

After checking downstream source, 15:4 also seems to be supported,
add them two.

Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260321095029.2259489-1-mitltlatltl@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information I need to complete this analysis.

## Phase 1: COMMIT MESSAGE FORENSICS

**Step 1.1 - Parse subject line:**
- Subsystem: `clk: qcom: rcg2:`
- Action verb: "expand" (non-standard fix verb, but describes adding
  entries)
- Record: Qualcomm Root Clock Generator 2 driver - expand fractional
  ratio table for MDSS pixel clock source

**Step 1.2 - Parse tags:**
- Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com> (Qualcomm clock
  expert, original author of prior frac-table update b527358cb4cd5)
- Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> (msm
  subsystem maintainer)
- Link: lore.kernel.org reference to discussion
- Signed-off-by: Bjorn Andersson <andersson@kernel.org> (Qualcomm SoC
  maintainer, applied it)
- **NO** Fixes: tag (expected absence - this is why it's being reviewed)
- **NO** Cc: stable (expected absence)
- **NO** Reported-by: (author found it while testing)

**Step 1.3 - Analyze commit body:**
- Bug: When using a 10-bit DSI C-PHY panel with `pclk=172992000,
  byteclk=108120000`, `mdss_pixel_clk_src` fails to find a matching
  ratio in `frac_table_pixel[]`.
- Failure mode: `clk_pixel_determine_rate()` returns `-EINVAL`, the
  divider register keeps a stale cached value (0xf = 15:1), so actual
  pclk becomes ~50.4 MHz instead of required ~173 MHz — a ~3.4x wrong
  clock rate. Display output is corrupted/broken.
- Root cause: Table lacks the 16/35 and 4/15 ratios that downstream
  Qualcomm driver supports.
- Record: concrete runtime bug on real hardware; downstream driver
  carries the needed ratios.

**Step 1.4 - Hidden fix detection:** Subject says "expand" but the body
clearly documents a failure mode. This is a bug fix disguised as an
enhancement. The "expand" verb hides that `clk_set_rate()` completely
fails without it.

## Phase 2: DIFF ANALYSIS

**Step 2.1 - Inventory:** 1 file (`drivers/clk/qcom/clk-rcg2.c`), +2 /
-0 lines. Single-file surgical change.

**Step 2.2 - Code flow:**
- Before: `frac_table_pixel[] = { {3,8}, {2,9}, {4,9}, {1,1}, {2,3}, {}
  }`
- After: adds `{16,35}` and `{4,15}` before the sentinel
- Only affects `clk_pixel_determine_rate()` and `clk_pixel_set_rate()`
  iteration logic

**Step 2.3 - Bug mechanism:** Hardware workaround/enablement category.
The table defines numerator/denominator pairs used to compute parent
rate requests. Without the new entries, the iteration loop falls off the
end and returns `-EINVAL` for specific legitimate hardware
configurations.

**Step 2.4 - Fix quality:**
- Obviously correct: pure data table addition, cannot affect previously
  working cases.
- Cannot cause regression: iteration checks each entry in order, new
  entries only kick in when existing ones don't match.
- No risk of deadlock, UAF, etc.

## Phase 3: GIT HISTORY INVESTIGATION

**Step 3.1 - Blame:**
- `frac_table_pixel[]` was introduced by `99cbd064b059f` ("clk: qcom:
  Support display RCG clocks", May 2014)
- Entry `{2, 3}` was added by `b527358cb4cd5` (Feb 2022, Taniya Das)
  with a `Fixes:` tag

**Step 3.2 - No Fixes: tag to follow.** The missing ratios have
effectively been absent since original commit `99cbd064b059f` (2014,
v3.17-era). Code exists in every active stable tree.

**Step 3.3 - Related file history:** Prior similar fix (`b527358cb4cd5`,
"Update the frac table for pixel clock") added a single entry and was
backported broadly. Same author context (Taniya Das reviewed both).

**Step 3.4 - Author:** Pengyu Luo is a regular contributor to qcom
subsystem with multiple DSI-related fixes (`e4eb11b34d6c8`,
`ac47870fd7955`, `fd941c787cbb4`). Patch reviewed by actual subsystem
experts.

**Step 3.5 - Dependencies:** Standalone, self-contained. No
prerequisites.

## Phase 4: MAILING LIST RESEARCH

**Step 4.1 - `b4 dig -c 0f5c8f03d990f`:** Found thread at `https://lore.
kernel.org/all/20260321095029.2259489-1-mitltlatltl@gmail.com/`. Single-
patch, v1 only, applied as-is by Bjorn Andersson with "Applied,
thanks!".

**Step 4.2 - Reviewers:** Taniya Das (Qualcomm clock expert), Dmitry
Baryshkov (msm maintainer), Konrad Dybcio (Qualcomm engineer). Proper
maintainer review.

**Step 4.3 - Discussion:** Konrad asked a clarifying question about
whether these divider pairs are needed at all; Dmitry pointed to the
Qualcomm downstream commit `f7aec4359448d25c8a8d21ad8e8733d61f6b69ab`
confirming the ratios come from the vendor reference code. No NAK, no
concerns about stability.

**Step 4.4 - Series context:** Not part of a series.

**Step 4.5 - Stable discussion:** None found in the thread.

## Phase 5: CODE SEMANTIC ANALYSIS

**Step 5.1 - Key data:** `frac_table_pixel[]` array only.

**Step 5.2 - Callers:** `clk_pixel_ops` (set via `.set_rate =
clk_pixel_set_rate` and `.determine_rate = clk_pixel_determine_rate`) is
used by 17+ Qualcomm dispcc drivers: SDM845, SM6350, SM7150, SM8250,
SM8450, SM8550, SM8750, X1E80100, SC7180, SC7280, SC8280XP, QCM2290,
SM4450, SM6375, SA8775P (dispcc0/1), etc. This is a HIGH IMPACT SURFACE
— affects display on almost every modern Qualcomm SoC.

**Step 5.3 - Callees:** Pure table lookup.

**Step 5.4 - Reachability:** Reached from `clk_set_rate()` on any MDSS
pixel clock → userspace-triggerable via normal display driver operations
(DRM probe, panel enable, mode set).

**Step 5.5 - Similar patterns:** The `b527358cb4cd5` commit is the exact
same pattern (add ratio to `frac_table_pixel`) and was backported to 8
stable trees.

## Phase 6: STABLE TREE ANALYSIS

**Step 6.1 - Code exists in stable:** Verified `frac_table_pixel[]` is
identical (`{3,8}, {2,9}, {4,9}, {1,1}, {2,3}`) on 5.10, 5.15, 6.1, 6.6,
6.12, 6.18, 6.19. Every active stable tree has the same buggy state.

**Step 6.2 - Backport complexity:** The `frac_table_pixel[]` array is in
the same place across all trees. Will apply cleanly or with trivial
context adjustment.

**Step 6.3 - Related fixes in stable:** `b527358cb4cd5` (adding `{2,3}`)
is in all stable trees. This new commit is the continuation.

## Phase 7: SUBSYSTEM CONTEXT

**Step 7.1 - Subsystem:** `drivers/clk/qcom/` - Qualcomm clock driver.
Level: IMPORTANT (affects many SoC families, any user with a Qualcomm
device using `clk_pixel_ops`).

**Step 7.2 - Activity:** Actively maintained subsystem; regular flow of
fixes.

## Phase 8: IMPACT & RISK

**Step 8.1 - Affected users:** Users of Qualcomm SoCs with DSI panels
requiring the specific pixel clock ratios — explicitly 10-bit DSI C-PHY
panels and other configurations where pclk/byteclk combinations force a
16:35 or 4:15 ratio.

**Step 8.2 - Trigger conditions:** Normal display operation with
affected panels. No special privileges needed (display usage is common).

**Step 8.3 - Failure mode severity:** HIGH — pixel clock is set to
completely wrong rate (e.g., 50 MHz instead of 173 MHz, a 3.4x error).
This causes visible display corruption / non-functional display on
affected hardware. Not a crash, but user-visible broken functionality
with no workaround.

**Step 8.4 - Risk/benefit:**
- Benefit: HIGH (fixes display for a class of panels across many SoCs)
- Risk: VERY LOW (2 lines of data, table iteration is in-order; existing
  ratios still match first)
- Ratio: Strongly favors backport.

## Phase 9: SYNTHESIS

**Evidence FOR backporting:**
- Fixes real observed runtime failure with detailed clk_summary evidence
- Same pattern (adding ratio to `frac_table_pixel`) was previously
  backported to 8 stable trees (`b527358cb4cd5` went to 4.9.y, 4.14.y,
  4.19.y, 5.4.y, 5.10.y, 5.15.y, 5.16.y, 5.17.y)
- Minimal 2-line change in a const data table
- Zero functional risk (iteration is ordered; additions cannot break
  existing cases)
- Reviewed by two subsystem experts + applied by Qualcomm SoC maintainer
- Falls into "hardware quirk/workaround" exception category (analogous
  to device ID addition)
- Code exists identically in all active stable trees
- Used by 17+ SoC drivers → broad user impact

**Evidence AGAINST backporting:**
- No explicit Fixes: tag (though prior identical-pattern fix had one,
  and absence of tag is explicitly not a signal per the guidelines)
- Commit message uses "expand" instead of "fix" (but body describes
  concrete failure)
- No Cc: stable from the author

**Stable rules check:**
1. Obviously correct? YES — pure data addition
2. Fixes real bug? YES — pixel clock misprogrammed to ~3.4x wrong rate
3. Important? YES — broken display on affected hardware
4. Small and contained? YES — 2 lines in one file
5. No new features/APIs? YES — extends internal lookup table, not
   exposed
6. Applies to stable? YES — verified identical state across stable trees

**Exception category:** Fits "hardware quirks/workarounds" — enables
specific hardware configurations (10-bit DSI C-PHY panels) that were
previously non-functional due to missing table entries, directly
analogous to adding PCI/USB device IDs or codec quirks.

## Verification

- [Phase 1] Parsed tags: two Reviewed-by from Qualcomm experts, Link to
  lore, no Fixes:/Cc:stable (expected)
- [Phase 2] Diff analysis: 2-line const data addition to
  `frac_table_pixel[]` before sentinel; no control-flow change
- [Phase 3] `git log -- drivers/clk/qcom/clk-rcg2.c` + `git show
  b527358cb4cd5`: confirmed precedent commit adding `{2,3}` was accepted
  with Fixes: tag
- [Phase 3] `git log --author="Pengyu Luo"`: confirmed author has
  multiple legitimate DSI/Qualcomm fixes
- [Phase 4] `b4 dig -c 0f5c8f03d990f`: returned
  `lore.kernel.org/all/20260321095029.2259489-1-mitltlatltl@gmail.com/`
- [Phase 4] `b4 dig -c 0f5c8f03d990f -a`: single v1, no revisions
- [Phase 4] Thread contents via mbox: Taniya Das, Dmitry Baryshkov
  Reviewed-by; Konrad asked a non-blocking question; Bjorn applied with
  "Applied, thanks!"; no NAKs; no stable discussion
- [Phase 5] `grep -rln "clk_pixel_ops" drivers/clk/qcom/`: 17+
  dispcc/gcc drivers use the affected ops (SDM845, SM8250, SM8450,
  SM8550, SM8750, X1E80100, SC7180, SC7280, SC8280XP, QCM2290, SM4450,
  SM6350, SM6375, SM7150, SA8775P, etc.)
- [Phase 6] Examined `drivers/clk/qcom/clk-rcg2.c` at for-greg/5.10-200,
  5.15-200, 6.1-200, 6.6-200, 6.12-200, 6.18-200, 6.19-200:
  `frac_table_pixel[]` identical across all trees — will apply cleanly
- [Phase 6] `grep -rl "b527358cb4cd" /home/sasha/stable-
  queue/releases/`: confirmed prior similar commit was backported to
  4.9.311, 4.14.276, 4.19.238, 5.4.189, 5.10.110, 5.15.33, 5.16.19,
  5.17.2
- [Phase 8] Failure mode from commit body: pclk set to 50455997 Hz
  instead of 172992000 Hz (3.4x off) on 10-bit DSI C-PHY panels — user-
  visible display failure

---

This is a well-reviewed, minimal hardware-enablement fix (analogous to a
hardware quirk) that addresses a documented, reproducible runtime
failure on real hardware. The fix is a 2-line data-table extension with
zero regression risk. There is strong precedent: a commit with the exact
same pattern (`b527358cb4cd5`) was backported broadly to stable. The
affected code is used by 17+ Qualcomm SoC drivers, giving wide user
impact.

**YES**

 drivers/clk/qcom/clk-rcg2.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
index fc696b66ccda9..6064a0e17d519 100644
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -1117,6 +1117,8 @@ static const struct frac_entry frac_table_pixel[] = {
 	{ 4, 9 },
 	{ 1, 1 },
 	{ 2, 3 },
+	{ 16, 35},
+	{ 4, 15},
 	{ }
 };
 
-- 
2.53.0

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

[Sasha Levin]

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

[PATCH AUTOSEL 7.0-5.15] dt-bindings: clock: qcom,gcc-sc8180x: Add missing GDSCs

[Sasha Levin]

From: Val Packett <val@packett.cool>

[ Upstream commit 76404ffbf07f28a5ec04748e18fce3dac2e78ef6 ]

There are 5 more GDSCs that we were ignoring and not putting to sleep,
which are listed in downstream DTS. Add them.

Signed-off-by: Val Packett <val@packett.cool>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260312112321.370983-2-val@packett.cool
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

I have all the evidence I need. Now let me write my analysis.

## Phase 1: Commit Message Forensics

**Step 1.1: Parse subject line**
Record: Subsystem: `dt-bindings: clock: qcom,gcc-sc8180x`. Action verb:
"Add". Summary: Adds 5 missing GDSC (Global Distributed Switch
Controller) #defines to the binding header.

**Step 1.2: Parse all tags**
Record: Tags found: `Signed-off-by: Val Packett`, `Acked-by: Krzysztof
Kozlowski` (DT bindings maintainer), `Link:` to lore.kernel.org thread,
`Signed-off-by: Bjorn Andersson` (Qualcomm maintainer who applied). No
`Fixes:` tag on this bindings patch (but its companion driver patch
`3565741eb985a` has `Fixes: 4433594bbe5d`). No `Cc: stable` tag.

**Step 1.3: Analyze commit body**
Record: "There are 5 more GDSCs that we were ignoring and not putting to
sleep" — explicitly describes missing PM/power management support. The
commit adds 5 new #define identifiers (values 11-15) for MMNOC MMU TBU
(HF0/HF1/SF) and Turing MMU TBU0/TBU1 GDSCs. No version info mentioned.
Author's explanation: these were missing from mainline driver but
present in downstream DTS.

**Step 1.4: Detect hidden fix**
Record: Language uses "Add missing" — typical hidden-fix pattern. The
driver companion has `Fixes: 4433594bbe5d` tag pointing to the original
SC8180x driver (v5.12). This is a bug fix by nature (missing power
management), but THIS patch is only the header definitions.

## Phase 2: Diff Analysis

**Step 2.1: Inventory**
Record: Single file modified: `include/dt-bindings/clock/qcom,gcc-
sc8180x.h`. 5 lines added, 0 removed. Zero functions modified — purely
adding preprocessor macros.

**Step 2.2: Code flow change**
Record: Before: header defined GDSC IDs 0-10. After: header defines GDSC
IDs 0-15 (adds 11-15). No execution-path change; these are constants
used by other code (driver `drivers/clk/qcom/gcc-sc8180x.c` in the
companion patch) and potentially DTS files.

**Step 2.3: Bug mechanism category**
Record: Category (h) Hardware enablement — adds IDs needed to expose
hardware GDSCs. This is a prerequisite for the follow-on driver patch
that actually registers the 5 GDSCs so they can be power-managed.

**Step 2.4: Fix quality**
Record: Trivially correct — just #define additions. Zero regression risk
on its own (unused constants). Obvious correctness verifiable by reading
the names and numbering. No red flags.

## Phase 3: Git History Investigation

**Step 3.1: Blame**
Record: The file was introduced in commit 4433594bbe5d (SC8180x GCC
driver, v5.12-rc1, January 2021). The existing GDSC section (IDs 0-10)
has been stable since then. This patch only appends new IDs.

**Step 3.2: Fixes target**
Record: This bindings patch has no Fixes: tag. The driver companion
`3565741eb985a` has `Fixes: 4433594bbe5d` ("clk: qcom: gcc: Add global
clock controller driver for SC8180x"). That target commit is in v5.12
and every stable tree since (5.15, 6.1, 6.6, 6.12).

**Step 3.3: File history**
Record: Recent changes to the file have been small additions (GPLL9
support, USB MP resets, UFS QREF clocks) — standard "add missing"
completions. This fits the same pattern. Part of an 11-patch series
"clk: qcom: sc8180x: PM-related fixes (and refactoring)" but this
specific commit + the driver commit (patches 01/11 and 02/11) are the
only "fix missing GDSCs" pair.

**Step 3.4: Author context**
Record: Author Val Packett has submitted Qualcomm platform work
previously; the patch is Acked-by the DT binding maintainer (Krzysztof
Kozlowski) and applied by the Qualcomm SoC maintainer (Bjorn Andersson).
The driver commit got Reviewed-by from two additional Qualcomm
maintainers (Dmitry Baryshkov, Konrad Dybcio).

**Step 3.5: Dependencies**
Record: This bindings patch is a prerequisite for the driver patch
`3565741eb985a`, which references `HLOS1_VOTE_MMNOC_MMU_TBU_HF0_GDSC`
etc. Without this header change, the driver patch won't compile
(verified: `drivers/clk/qcom/gcc-sc8180x.c:17` includes this header).

## Phase 4: Mailing List Research

**Step 4.1: Original discussion**
Record: `b4 dig -c 76404ffbf07f2` found
https://patch.msgid.link/20260312112321.370983-2-val@packett.cool. Part
of v2 series (v1 had 7 patches, v2 expanded to 11 patches). Applied
version is v2. Thread saved; no stable nominations, no NAKs, no concerns
raised on this specific patch.

**Step 4.2: Reviewers**
Record: Acked-by Krzysztof Kozlowski (DT bindings maintainer). The
broader series was reviewed by subsystem maintainers Dmitry Baryshkov
and Konrad Dybcio.

**Step 4.3: Bug report search**
Record: No Reported-by tag, no bug link. The issue was identified by
comparing against downstream DTS.

**Step 4.4: Series context**
Record: 11-patch series. Patches 01-02 are the "add missing GDSCs" pair
(bindings + driver). Patches 03-06 are PM retention/runtime-PM
enablement (larger functional changes). Patches 07-08 are dispcc
changes, 09-11 are camcc refactoring. Only 01+02 are tight bug-fix
material.

**Step 4.5: Stable list**
Record: No stable-list discussion found about this specific patch.

## Phase 5: Code Semantic Analysis

**Step 5.1: Key symbols**
Record: 5 preprocessor constants:
HLOS1_VOTE_MMNOC_MMU_TBU_HF0/HF1/SF_GDSC and
HLOS1_VOTE_TURING_MMU_TBU0/1_GDSC. No functions modified.

**Step 5.2-5.4: Callers/callees**
Record: Used by `drivers/clk/qcom/gcc-sc8180x.c` to index into the
`gcc_sc8180x_gdscs[]` array (verified via grep). Not directly reachable
from user code; these IDs reference power domains managed by the clock
framework and consumed by SMMU/Turing subsystems on SC8180x hardware
(e.g. Microsoft Surface Pro X).

**Step 5.5: Similar patterns**
Record: **Strong precedent found**. An essentially identical SC8280XP
pair exists:
- `9eba4db02a88` (SC8280XP bindings: "Add missing GDSCs") +
  `4712eb7ff85b` (SC8280XP driver fix)
- Both were backported to stable as `66120ba55999a` (explicitly labeled
  `Stable-dep-of: 4712eb7ff85b`) and `a92a9604e8a43` respectively. The
  SC8280XP commit message is almost verbatim identical, and the Qualcomm
  stable process treated the bindings half as a required dependency.

## Phase 6: Cross-referencing / Stable Tree

**Step 6.1: Code in stable**
Record: The header file and driver exist in all stable trees ≥5.12. The
incomplete GDSC list is present in all active stable trees.

**Step 6.2: Backport cleanliness**
Record: Bindings file context from line 320-325 is unchanged since 2023
(last modification 19ac3579af14e "Add missing bindings on gcc-sc8180x").
The addition appends at end of GDSC section — should apply cleanly to
all stable trees without conflicts.

**Step 6.3: Related fixes in stable**
Record: SC8280XP equivalent already in stable (same fix pattern for
sibling SoC).

## Phase 7: Subsystem

**Step 7.1**: Record: `drivers/clk/qcom/` (via header it defines) and
`include/dt-bindings/` — Qualcomm clock/PM subsystem. Criticality:
PERIPHERAL (specific to SC8180x, used in Microsoft Surface Pro X-class
laptops and similar devices).

**Step 7.2**: Record: Qualcomm clock driver area is actively maintained;
this patch went through normal review cycle (v1→v2).

## Phase 8: Impact / Risk

**Step 8.1: Affected users**
Record: SC8180x platform users (notably Surface Pro X; ARM64 laptops).
When combined with driver patch, affects power consumption on these
devices.

**Step 8.2: Trigger**
Record: Always active — SMMU TBU / Turing TBU GDSCs remain powered-on
because kernel doesn't vote them off.

**Step 8.3: Severity of this patch alone**
Record: This bindings-only patch has ZERO runtime effect by itself.
Severity of the **combined fix** (with companion driver patch): MEDIUM —
power waste, excess heat, degraded battery. Not a crash, not a
corruption, but real user-facing PM issue.

**Step 8.4: Risk-benefit**
Record: Benefit: enables the companion driver fix to apply and build.
Risk: essentially zero (5 unused preprocessor macros if driver patch not
applied). As Stable-dep-of — safe and necessary.

## Phase 9: Synthesis

**Evidence FOR:**
- Companion driver fix has `Fixes: 4433594bbe5d` pointing to v5.12;
  valid bug fix
- Strong, nearly identical precedent: SC8280XP pair was backported to
  stable exactly this way (Stable-dep-of marker)
- Five trivial macro additions; zero regression risk
- Applies cleanly to all stable trees (no conflicts in the appended
  section)
- Acked by DT bindings maintainer, reviewed by Qualcomm maintainers
- Required prerequisite — without it the driver fix will not compile in
  stable

**Evidence AGAINST:**
- This patch alone has no runtime effect; it's a dependency, not a
  standalone fix
- The underlying issue is "missing PM" not "crash/corruption"
- Part of a larger 11-patch series, most of which is NOT stable material

**Stable rules check:**
1. Obviously correct — yes (5 #define lines)
2. Fixes real bug — yes, when paired with driver patch (power waste)
3. Important issue — borderline: PM/power waste, not crash
4. Small & contained — yes (5 lines, 1 file)
5. No new features/APIs — yes (enables existing hardware features
   already in DT bindings header)
6. Applies to stable — yes (verified file structure unchanged)

**Exception category**: This is effectively a DT binding additions for
existing hardware (exception category 3) AND a required Stable-dep-of
for a Fixes:-tagged driver commit — which was the exact rationale used
for the SC8280XP precedent.

## Verification

- [Phase 1] Parsed tags via `git show 76404ffbf07f2`: Acked-by Krzysztof
  Kozlowski, Signed-off-by Bjorn Andersson, Link to lore. No
  Fixes:/stable tags on bindings commit.
- [Phase 1] Companion `git show 3565741eb985a` confirmed `Fixes:
  4433594bbe5d` and two Reviewed-by tags.
- [Phase 2] Diff analysis: 5 line additions in one file, pure #define
  macros.
- [Phase 3] `git show 4433594bbe5d` and `git describe --contains
  4433594bbe5d` → v5.12-rc1~110^2^4~33. Bug present since v5.12.
- [Phase 3] `git log --oneline -- include/dt-bindings/clock/qcom,gcc-
  sc8180x.h`: confirms file has been amended via "Add missing X" commits
  repeatedly.
- [Phase 4] `b4 dig -c 76404ffbf07f2`: found
  https://patch.msgid.link/20260312112321.370983-2-val@packett.cool
- [Phase 4] `b4 dig -c 76404ffbf07f2 -a`: found v1 (7-patch) and v2
  (11-patch). Applied = v2 (latest).
- [Phase 4] Thread saved and searched for "stable": no stable
  nominations or objections.
- [Phase 5] `grep qcom,gcc-sc8180x.h drivers/clk/qcom/gcc-sc8180x.c`:
  confirms line 17 includes this header — driver build depends on these
  defines.
- [Phase 5] `git show 3565741eb985a | grep HLOS1_VOTE_`: driver patch
  uses all 5 new defines.
- [Phase 5] Precedent: `git show 66120ba55999a`: confirmed "[ Upstream
  commit 9eba4db02a88e7a810aabd70f7a6960f184f391f ]" and "Stable-dep-of:
  4712eb7ff85b" — identical pattern backported to stable for SC8280XP.
- [Phase 5] `git show a92a9604e8a43`: confirmed companion SC8280XP
  driver fix was also backported.
- [Phase 6] `git describe --contains 9eba4db02a88` → v6.6-rc1. Stable
  backports landed in older branches with Stable-dep-of marker.
- [Phase 6] Read current file (lines 300-327): confirmed GDSC section
  ends at USB30_SEC_GDSC=10; appending 5 new IDs won't conflict with any
  downstream state in stable.
- UNVERIFIED: Could not fetch the actual lore thread content (anti-bot
  wall); relied on saved mbox and local commit metadata. Could not
  verify stable maintainer's intention for this specific pair, but
  SC8280XP precedent is unambiguous.

## Conclusion

This is a pure DT-bindings header addition that is safe on its own (zero
runtime impact) and is a **required prerequisite** for the companion
driver patch `3565741eb985a` which has a `Fixes:` tag pointing to v5.12.
The almost identical SC8280XP bindings commit (`9eba4db02a88`) was
backported to stable as `Stable-dep-of: 4712eb7ff85b`, establishing a
clear precedent. Without this patch, the driver fix cannot compile in
stable trees. It is small, obviously correct, applies cleanly, and
follows an exception category (DT bindings for existing hardware +
required dependency for a Fixes:-tagged fix).

**YES**

 include/dt-bindings/clock/qcom,gcc-sc8180x.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/dt-bindings/clock/qcom,gcc-sc8180x.h b/include/dt-bindings/clock/qcom,gcc-sc8180x.h
index b9d8438a15ffb..9ed7b794aacc4 100644
--- a/include/dt-bindings/clock/qcom,gcc-sc8180x.h
+++ b/include/dt-bindings/clock/qcom,gcc-sc8180x.h
@@ -322,5 +322,10 @@
 #define USB30_MP_GDSC						8
 #define USB30_PRIM_GDSC						9
 #define USB30_SEC_GDSC						10
+#define HLOS1_VOTE_MMNOC_MMU_TBU_HF0_GDSC		11
+#define HLOS1_VOTE_MMNOC_MMU_TBU_HF1_GDSC		12
+#define HLOS1_VOTE_MMNOC_MMU_TBU_SF_GDSC		13
+#define HLOS1_VOTE_TURING_MMU_TBU0_GDSC			14
+#define HLOS1_VOTE_TURING_MMU_TBU1_GDSC			15
 
 #endif
-- 
2.53.0