[PATCH AUTOSEL 6.18-5.10] media: cec: tegra_cec: don't break off msg on NACK

[PATCH AUTOSEL 6.18-5.10] media: cec: tegra_cec: don't break off msg on NACK

[Sasha Levin]

From: Hans Verkuil <hverkuil+cisco@kernel.org>

[ Upstream commit be627f257ce283c95fd2988080dc0db3a20d0d2a ]

The Tegra CEC hardware has a bug where, if the first attempt
to transmit a message is NACKed so the transmit is aborted,
then the second attempt can contain corrupt data.

Ensure that the full message is always transmitted to avoid hitting
this bug.

I suspect some internal state is not reset in the case of aborting
a message due to a NACK.

Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

This is a hardware-quirk workaround in the Tegra HDMI CEC driver: after
a NACK abort, the next transmit can be corrupt. The local tree is
**v7.3-rc4** (`7.3.0-rc4`). The driver and
`TEGRA_CEC_HWCTRL_TX_NAK_MODE` bit have been here since the original
2017 driver, so the fix belongs in this tree.

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

Step 1.1: PARSE THE SUBJECT LINE
Record: [media: cec: tegra_cec] [don't break off] [keep transmitting a
CEC message after NACK so Tegra HW does not corrupt the retry]

Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
Record:
- Signed-off-by: Hans Verkuil \<hverkuil+cisco@kernel.org\> (author; CEC
  and Tegra CEC maintainer)
- Reviewed-by: Mikko Perttunen \<mperttunen@nvidia.com\> (NVIDIA)
- Signed-off-by: Mauro Carvalho Chehab \<mchehab+huawei@kernel.org\>
  (media maintainer)
- No Fixes:, Reported-by:, Tested-by:, Link:, or Cc: stable (absence
  expected)
- Ignored: any Sasha Levin SOB / Upstream-commit markers (none present
  on the real commit)

Step 1.3: ANALYZE THE COMMIT BODY TEXT
Record:
- Bug: Tegra CEC silicon bug. If the first transmit is NACKed and
  aborted, the second attempt can contain corrupt data. Author suspects
  internal HW state is not reset on NACK abort.
- Symptom: corrupt HDMI-CEC frames on retry after NACK (wrong bytes on
  the CEC bus).
- Version info: none in the message. Driver dates to v4.15-rc1.
- Root cause (author): abort-on-NACK leaves HW in a bad state;
  workaround is to always send the full message (`TX_NAK_MODE`).

Step 1.4: DETECT HIDDEN BUG FIXES
Record: Not disguised. Cover letter calls it “a fix” / HW-bug
workaround. Not cleanup.

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

Step 2.1: INVENTORY THE CHANGES
Record:
- File: `drivers/media/cec/platform/tegra/tegra_cec.c` (+12 / -1)
- Function: `tegra_cec_adap_enable()`
- Scope: single-file surgical change; one functional OR of an existing
  HW bit plus a comment

Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
Record:
- Before: enable path wrote `TEGRA_CEC_HW_CONTROL =
  TEGRA_CEC_HWCTRL_TX_RX_MODE` only. Hardware aborted TX on NACK.
- After: same write also sets `TEGRA_CEC_HWCTRL_TX_NAK_MODE` so the full
  frame is sent even if bytes are NACKed.
- Path: adapter enable (normal init), not an error path.
- `tegra_cec_adap_log_addr()` and `tegra_cec_adap_monitor_all_enable()`
  RMW `HW_CONTROL`, so they keep the bit. `tegra_cec_error_recovery()`
  saves/restores `hw_ctrl`, so it keeps the bit too.

Step 2.3: IDENTIFY THE BUG MECHANISM
Record: [Hardware workaround] Default abort-on-NACK leaves Tegra CEC TX
state unrestored; retry can emit corrupt data. Setting `TX_NAK_MODE`
avoids the abort path. IRQ still reports NACK via
`TX_FRAME_OR_BLOCK_NAKD` when `TX_FRAME_TRANSMITTED` fires.

Step 2.4: ASSESS THE FIX QUALITY
Record:
- Obviously correct: one existing register bit, documented in-tree since
  2017, unused until now.
- Minimal: one OR plus comment.
- Regression risk: low. Bus is occupied a bit longer after NACK (author
  notes this). NVIDIA reviewed. Software still reports
  `CEC_TX_STATUS_NACK`. POLL (the usual NACK) is one byte, so extra bus
  time is negligible.

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

Step 3.1: BLAME THE CHANGED LINES
Record: Buggy write is from `9d2d60687c9a` (“media: tegra-cec: add Tegra
HDMI CEC driver”, 2017-07-15, contained in v4.15-rc1).
`TEGRA_CEC_HWCTRL_TX_NAK_MODE` was defined in that same commit (`(1 <<
24)`), later rewritten as `BIT(24)` in `cce8ccca80d838` (2019). Bug has
been in this driver for the entire mainline life of the driver.

Step 3.2: FOLLOW THE FIXES: TAG
Record: No Fixes: tag. N/A. Introduced by original driver, not a later
regression.

Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
Record: Same-day series 1/2. 2/2 is `bce7236c16c2c` (“keep track of
number of Rx Low Drives”) — debug counter, not a prerequisite. Later
`a45a81a790b96` is an unrelated `dev_err` cleanup. Standalone.

Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Record: Hans Verkuil is listed in MAINTAINERS for both CEC FRAMEWORK and
ARM/TEGRA HDMI CEC. NVIDIA’s Mikko Perttunen reviewed. High confidence.

Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
Record: None. Uses `TEGRA_CEC_HWCTRL_TX_NAK_MODE` already in
`tegra_cec.h` in this tree. Applies standalone.

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

Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
Record:
- Lore: https://patch.msgid.link/7e50d6027e1676650d52905cd20eb212c01cd3e
  5.1783677198.git.hverkuil+cisco@kernel.org
- Cover: `[PATCH 0/2] media: tegra_cec: a fix and an enhancement` — “the
  first works around a HW bug where, if a transmit was NACKed, the
  retransmit would contain corrupt data.”
- Only v1; committed as submitted.
- No NAK, no stable nomination, no reviewer risk flags.
- Included in “[GIT PULL FOR v7.3] media: CEC fixes/improvements”.

Step 4.2: CHECK WHO REVIEWED THE PATCH
Record: To linux-media; Cc Thierry Reding and linux-tegra. Reviewed-by
Mikko Perttunen (NVIDIA). Right maintainers.

Step 4.3: SEARCH FOR THE BUG REPORT
Record: No syzbot/bugzilla. Author-discovered HW bug, confirmed by
NVIDIA review. No user-count in the thread.

Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
Record: 1/2 of 2. 2/2 is an enhancement (Rx low-drive debugfs), not
required. Do not pull 2/2 as a dependency.

Step 4.5: CHECK STABLE MAILING LIST HISTORY
Record: No stable-list discussion found for this NACK workaround. linux-
media search for “tegra_cec stable” did not hit this patch.

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

Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF
Record: `tegra_cec_adap_enable()`

Step 5.2: TRACE CALLERS
Record: Wired as `cec_adap_ops.adap_enable`. Called from
`cec_adap_enable()` in `drivers/media/cec/core/cec-adap.c`
(open/configure `/dev/cecX`, logical-address setup, enable/disable).
Userspace-reachable on Tegra HDMI.

Step 5.3: TRACE CALLEES
Record: `cec_write()` → `writel()` of `TEGRA_CEC_HW_CONTROL`. No alloc,
no new locks.

Step 5.4: FOLLOW THE CALL CHAIN
Record: userspace CEC ioctl/open → CEC core `cec_adap_enable()` →
`tegra_cec_adap_enable()`. Transmit path `tegra_cec_adap_transmit()`
fills TX FIFO; NACK is handled in `tegra_cec_irq_handler()`.
Unprivileged users with `/dev/cecX` can trigger TX, including
NACK+retry.

Step 5.5: SEARCH FOR SIMILAR PATTERNS
Record: `TX_NAK_MODE` is only used in this driver. No sibling-driver
copy of this workaround.

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

Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?
Record: Yes. Tree is v7.3-rc4. File
`drivers/media/cec/platform/tegra/tegra_cec.c` and header bit
`TEGRA_CEC_HWCTRL_TX_NAK_MODE` are present. Pre-fix enable path wrote
only `TX_RX_MODE` (blame to 2017). Bug introduced in v4.15-era driver,
long before this branch.

Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
Record: Clean apply. Context in the candidate is the INT_MASK block
without later `RX_BUS_ERROR_DETECTED` (that line is from 2/2). Against
this tree the hunk is already the intended enable write. No data-
structure or API change.

Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE
Record: No earlier alternate fix for NACK-abort corruption. This is the
first use of `TX_NAK_MODE` in C code.

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

Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
Record: [drivers/media/cec/platform/tegra] [PERIPHERAL / platform
driver, but real Tegra HDMI product path]. CONFIG_CEC_TEGRA, depends on
ARCH_TEGRA.

Step 7.2: ASSESS SUBSYSTEM ACTIVITY
Record: Mature. Driver since 2017; low churn. This is an old HW bug, not
new-code churn.

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

Step 8.1: DETERMINE WHO IS AFFECTED
Record: Tegra HDMI-CEC users (Jetson and other Tegra boards with CEC).
Config- and platform-specific, not universal.

Step 8.2: DETERMINE THE TRIGGER CONDITIONS
Record: Transmit a message that is NACKed, then retry. Common for POLL
during logical-address allocation (1 byte; author says that case is
cheap). Multi-byte NACK+retry is less common but real (absent follower,
follower busy). Userspace with CEC device access can trigger it.

Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
Record: [Corrupt CEC frame on retry] [MEDIUM functionally, HIGH for that
hardware’s CEC reliability]. Not a kernel oops. Puts garbage on the CEC
bus, which can break TV/AVR control after a NACK. That is user-visible
protocol corruption.

Step 8.4: CALCULATE RISK-BENEFIT RATIO
Record:
- Benefit: high for Tegra CEC — stops corrupt retries on a long-standing
  silicon bug.
- Risk: very low — one register bit, NVIDIA Reviewed-by, CEC maintainer
  authored it.
- Ratio: strongly favors applying the workaround.

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

Step 9.1: COMPILE THE EVIDENCE

FOR:
- Real Tegra CEC hardware bug: NACK abort → corrupt retransmit
- Hardware quirk/workaround (stable exception)
- Tiny: +12/-1, one bit OR
- Bit defined since original 2017 driver; no new API
- Authored by CEC/Tegra-CEC maintainer; Reviewed-by NVIDIA
- Standalone; 2/2 of the series is unrelated debug
- Applies to this tree: driver and define exist
- IRQ path still reports NACK correctly

AGAINST:
- Not a kernel crash, UAF, or security bug
- Tegra-only
- Slightly longer bus occupancy after NACK (documented, accepted)
- No Fixes:/Cc: stable (not a negative here)
- No public multi-user bugzilla/syzbot report

UNRESOLVED:
- lore.kernel.org WebFetch returned 403; thread recovered via `b4 dig
  -m` and gnuweeb/ratatoskr mirrors
- No stable@ discussion found
- HW “internal state not reset” is the author’s suspicion; NVIDIA did
  not contradict it

Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. Obviously correct and tested? PASS — one documented HW bit; NVIDIA
   Reviewed-by
2. Fixes a real bug that affects users? PASS — corrupt CEC retries after
   NACK
3. Important issue? PASS as hardware workaround / protocol corruption on
   HDMI-CEC, not as a kernel panic
4. Small and contained? PASS — 13-line hunk, one function
5. No new features or APIs? PASS — enables an existing unused control
   bit
6. Can apply to the local tree? PASS — file, function, and
   `TEGRA_CEC_HWCTRL_TX_NAK_MODE` are here

Step 9.3: CHECK FOR EXCEPTION CATEGORIES
Record: Hardware quirk/workaround. Qualifies even without a panic.

Step 9.4: MAKE YOUR DECISION
This is a small, reviewed workaround for a real Tegra CEC silicon bug
that corrupts the next transmit after a NACK abort. The driver and
register bit exist in this v7.3-rc4 tree and have since v4.15. Risk is a
single enable-time bit. That meets stable rules via the hardware-quirk
exception.

What it solves for users of this tree: Tegra HDMI-CEC retries after NACK
can put corrupt bytes on the bus; setting `TX_NAK_MODE` avoids the abort
path that triggers that bug.

Risk vs benefit: one-bit enable flag, NVIDIA-reviewed, vs broken CEC
after NACK. Benefit wins.

===============================================================
Verification:
- [Phase 1] Parsed be627f257ce283c95fd2988080dc0db3a20d0d2a: no
  Fixes/Reported-by/Cc:stable; SOB Hans Verkuil + Mauro; Reviewed-by
  Mikko Perttunen
- [Phase 1] Cover letter (mbox): “works around a HW bug” / corrupt
  retransmit after NACK
- [Phase 2] Diff: `tegra_cec_adap_enable()` OR
  `TEGRA_CEC_HWCTRL_TX_NAK_MODE` into HW_CONTROL (+12/-1)
- [Phase 2] Confirmed RMW of HW_CONTROL in `tegra_cec_adap_log_addr`,
  `tegra_cec_adap_monitor_all_enable`, `tegra_cec_error_recovery`
  preserves the bit
- [Phase 2] IRQ still sets `CEC_TX_STATUS_NACK` on
  `TX_FRAME_TRANSMITTED` + `TX_FRAME_OR_BLOCK_NAKD`
- [Phase 3] git blame parent: HW_CONTROL write from 9d2d60687c9a
  (v4.15-rc1); TX_NAK_MODE in original header
- [Phase 3] git merge-base --is-ancestor 9d2d60687c9a HEAD: yes
- [Phase 3] No Fixes: tag; follow-up bce7236c16c2c is debug-only, not a
  prereq
- [Phase 4] b4 dig -c: https://patch.msgid.link/7e50d6027e1676650d52905c
  d20eb212c01cd3e5.1783677198.git.hverkuil+cisco@kernel.org
- [Phase 4] b4 dig -a: v1 only
- [Phase 4] b4 dig -w: linux-media, linux-tegra, Thierry Reding
- [Phase 4] b4 dig -m: NVIDIA Reviewed-by; no NAK; no Cc:stable in
  thread
- [Phase 4] lore.kernel.org WebFetch: 403; used mbox + gnuweeb/ratatoskr
  instead
- [Phase 5] Callers: cec-adap.c `cec_adap_enable()` → ops->adap_enable;
  userspace `/dev/cecX`
- [Phase 5] grep TX_NAK_MODE: only tegra_cec.c/.h
- [Phase 6] git describe HEAD: v7.3-rc4-27-gf0100363d8c37; make
  kernelversion 7.3.0-rc4
- [Phase 6] Header bit present; enable function present; clean single-
  hunk change
- [Phase 7] MAINTAINERS: Hans Verkuil maintains ARM/TEGRA HDMI CEC and
  CEC FRAMEWORK
- [Phase 8] Failure mode: corrupt CEC retry after NACK, not oops;
  severity MEDIUM/HIGH for that hardware
- UNVERIFIED: no TRM quote confirming “internal state not reset”; author
  suspicion only, not used as the sole reason

**YES**

 drivers/media/cec/platform/tegra/tegra_cec.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/media/cec/platform/tegra/tegra_cec.c b/drivers/media/cec/platform/tegra/tegra_cec.c
index fe66336e734f8..f8ffaeb78118d 100644
--- a/drivers/media/cec/platform/tegra/tegra_cec.c
+++ b/drivers/media/cec/platform/tegra/tegra_cec.c
@@ -243,7 +243,18 @@ static int tegra_cec_adap_enable(struct cec_adapter *adap, bool enable)
 		  TEGRA_CEC_INT_MASK_RX_REGISTER_FULL |
 		  TEGRA_CEC_INT_MASK_RX_START_BIT_DETECTED);
 
-	cec_write(cec, TEGRA_CEC_HW_CONTROL, TEGRA_CEC_HWCTRL_TX_RX_MODE);
+	/*
+	 * TX_NAK_MODE ensures that the whole message is transmitted even
+	 * if each byte is NACKed. Without this flag the retransmit of the
+	 * messages after a NACK can be corrupt. This is a bug in the hardware.
+	 *
+	 * While less efficient, in practice you rarely transmit messages
+	 * that can be NACKed, with the exception of POLL messages which
+	 * are just one byte anyway.
+	 */
+	cec_write(cec, TEGRA_CEC_HW_CONTROL,
+		  TEGRA_CEC_HWCTRL_TX_RX_MODE |
+		  TEGRA_CEC_HWCTRL_TX_NAK_MODE);
 	return 0;
 }
 
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] gpu: host1x: Wait for timeout worker completion on channel free

[Sasha Levin]

From: Mikko Perttunen <mperttunen@nvidia.com>

[ Upstream commit 7a39b9856acccc8e9b05845ca2bf62494fcd3dfa ]

cdma_timeout_destroy() used cancel_delayed_work() to cancel pending
timeout work when destroying the CDMA. Usually this is fine, but
there is a narrow race condition where the timeout handler has started
execution but has not taken cdma->lock; the channel is freed causing
cdma_stop to take cdma->lock and flush the channel; host1x_cdma_deinit
then proceeds with deinitializing cdma while the handler is waiting to
take cdma->lock.

Therefore change cdma_timeout_destroy to use cancel_delayed_work_sync
instead to ensure any pending timeout work completes before proceeding.

Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260609-b4-host1x-small-fixes-a-v1-1-7c1131c0b3ad@nvidia.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The local tree is **v7.3-rc4** (`7.3.0-rc4`). The host1x CDMA timeout
path is present, and this is a one-line `cancel_delayed_work` →
`cancel_delayed_work_sync` race/UAF fix that is standalone and meets
stable criteria.

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

**Step 1.1: PARSE THE SUBJECT LINE**
Record: **[gpu/host1x] [Wait / ensure completion] [Wait for timeout
worker completion on channel free]**
Subsystem prefix `gpu: host1x:`. The verb is “Wait … on channel free”,
i.e. synchronize teardown with a running work item. That is a teardown-
race fix, not a feature.

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
Record:
- **Fixes:** none (expected for this review path)
- **Reported-by:** none
- **Tested-by:** none
- **Reviewed-by:** none on the commit itself
- **Acked-by:** none
- **Link:** `https://patch.msgid.link/20260609-b4-host1x-small-fixes-
  a-v1-1-7c1131c0b3ad@nvidia.com`
- **Cc: stable:** none (expected)
- **Signed-off-by:** Mikko Perttunen `<mperttunen@nvidia.com>` (author);
  Thierry Reding `<treding@nvidia.com>` (Tegra/host1x maintainer).
  Ignored any Sasha Levin SOB (none on this commit).
- Series marker in the msgid: **patch 1/6** of `host1x-small-fixes-a`.

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
Record:
- **Bug:** `cdma_timeout_destroy()` used `cancel_delayed_work()`, which
  does not wait if the timeout work is already running.
- **Mechanism:** timeout handler has started but has not yet taken
  `cdma->lock`; channel free runs `cdma_stop` (takes the lock, flushes),
  then `host1x_cdma_deinit()` tears CDMA down while the handler is still
  waiting for that lock.
- **Symptom/failure mode:** use-after-free / use of a destroyed mutex
  and CDMA state from the timeout worker. That is a kernel crash /
  memory-safety bug, not a cosmetic issue.
- **Version info:** none in the message. The call has existed since
  host1x channel support.
- **Author’s root cause:** async cancel vs running work vs lock/deinit
  order.

**Step 1.4: DETECT HIDDEN BUG FIXES**
Record: Not hidden. It is an explicit race/UAF fix. Cover letter (see
Phase 4) calls patches 1–4 “logic issues that are unlikely to happen but
technically possible.” Unlikely trigger does not make a UAF inapplicable
to stable.

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

**Step 2.1: INVENTORY THE CHANGES**
Record:
- File: `drivers/gpu/host1x/hw/cdma_hw.c` — **1 insertion, 1 deletion**
- Function: `cdma_timeout_destroy()`
- Scope: **single-file surgical fix** (one call-site change)

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
Record:
- **Before:** if `cdma->timeout.initialized`,
  `cancel_delayed_work(&cdma->timeout.wq)` then `initialized = false`.
  Pending work is cancelled; **running** work is not waited for.
- **After:** `cancel_delayed_work_sync()` — cancel pending work **and
  wait** if the handler is executing.
- **Path:** channel teardown / CDMA destroy, not the submit hot path.

Verified teardown order in this tree:

```102:113:drivers/gpu/host1x/channel.c
static void release_channel(struct kref *kref)
{
        ...
        host1x_hw_cdma_stop(host, &channel->cdma);
        host1x_cdma_deinit(&channel->cdma);
        clear_bit(channel->id, chlist->allocated_channels);
}
```

```528:541:drivers/gpu/host1x/cdma.c
int host1x_cdma_deinit(struct host1x_cdma *cdma)
{
        ...
        host1x_pushbuffer_destroy(pb);
        host1x_hw_cdma_timeout_destroy(host1x, cdma);
        return 0;
}
```

`cdma_stop()` takes `cdma->lock`, may wait for an empty sync queue, then
unlocks. `host1x_cdma_deinit()` then runs **without** `cdma->lock`. That
matches the commit’s race: stop can finish and deinit can proceed while
`cdma_timeout_handler()` is between start and `mutex_lock(&cdma->lock)`.

The window is larger than “a few instructions.” The handler dumps debug
state **before** taking the lock:

```291:305:drivers/gpu/host1x/hw/cdma_hw.c
static void cdma_timeout_handler(struct work_struct *work)
{
        ...
        host1x_debug_dump(cdma_to_host1x(cdma));
        mutex_lock(&cdma->lock);
```

`host1x_debug_dump()` walks every channel and dumps FIFOs
(`show_all(..., true)`). A GPU timeout is also when userspace/driver
often closes the channel. That is a realistic overlap, not only a one-
instruction race.

**Step 2.3: IDENTIFY THE BUG MECHANISM**
Record:
- **Category:** race + use-after-free / use of destroyed CDMA (mutex,
  push buffer, channel).
- **Mechanism:** non-synchronous delayed-work cancel on destroy. Fix is
  the standard `cancel_*_sync` teardown pattern.
- **Not** a leak, NULL check, or new API.

Related code that correctly stays **non-sync** (would deadlock if
changed, because it runs under `cdma->lock`, which the handler also
takes):

```293:297:drivers/gpu/host1x/cdma.c
static void stop_cdma_timer_locked(struct host1x_cdma *cdma)
{
        cancel_delayed_work(&cdma->timeout.wq);
        cdma->timeout.client = NULL;
}
```

**Step 2.4: ASSESS THE FIX QUALITY**
Record:
- **Quality:** obviously correct for the stated race.
  `cancel_delayed_work_sync()` is the documented way to wait for delayed
  work before freeing the object that work touches.
- **Minimal:** one identifier change.
- **Regression risk:**
  - `_sync` can sleep. Callers of `host1x_channel_put()` →
    `release_channel()` are process-context (DRM ioctls/file close,
    client `exit`/unbind, debugfs). Sleeping is valid there.
  - `_sync` is **not** called while holding `cdma->lock` (`cdma_stop`
    drops it first). No lock-vs-work deadlock on the free path described
    in the commit.
  - Residual risk: if the timeout handler’s `host1x_debug_dump()` →
    `host1x_channel_put()` dropped the **last** channel ref,
    `release_channel()` would run on the same work and `_sync` could
    wait on itself. That path was already unsafe with async cancel (UAF
    after dump returns). No mailing-list NAK of this patch; maintainer
    applied it.

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

**Step 3.1: BLAME THE CHANGED LINES**
Record:
- Buggy `cancel_delayed_work()` in `cdma_timeout_destroy()` comes from
  **`6579324a41cc41`** (“gpu: host1x: Add channel support”, Terje
  Bergstrom, 2013-03-22).
- First contained in **`v3.10-rc1`**. This is old, long-lived driver
  code, not a last-month addition.

**Step 3.2: FOLLOW THE FIXES: TAG**
Record: No `Fixes:` tag. The introducing commit is identified by blame,
not by the message. `git merge-base --is-ancestor 6579324a41cc41 HEAD`
succeeds — the introducing commit is in this checkout.

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**
Record (recent `drivers/gpu/host1x/hw/cdma_hw.c`):
- `7a39b9856accc` — this fix
- `60bca008dd789` — Tegra264 support (does not revert the `_sync`
  change; current file still has `cancel_delayed_work_sync`)
No prerequisite refactor. Standalone.

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**
Record: Mikko Perttunen is a regular NVIDIA host1x contributor (UAF,
refcount, iommu, MLOCK, etc.). Same-series follow-ups are independent
(double `device_add`, trace offset, debug stack over-read, `pin_job`
return type, syncpoint wrap annotation). This patch does not depend on
them.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**
Record: None. It only needs `cdma_timeout_destroy()` +
`cancel_delayed_work()` / `_sync`, present since 2013. **Can apply
standalone.**

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

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**
Record:
- `b4 dig -c 7a39b9856accc` matched **v1 only** (no v2/v3).
- Lore: https://patch.msgid.link/20260609-b4-host1x-small-fixes-
  a-v1-1-7c1131c0b3ad@nvidia.com
- Cover letter: https://patch.msgid.link/20260609-b4-host1x-small-fixes-
  a-v1-0-7c1131c0b3ad@nvidia.com — “Miscellaneous fixes”; patches 1–4
  “unlikely to happen but technically possible.”
- Thierry Reding, 2026-07-16: **“Applied to drm-misc-next, thanks.”** No
  NAK, no stable discussion, no request for a different approach.
- `sashiko-bot` replied with **pre-existing** issues (`update_work` not
  cancelled in deinit; non-sync cancel in `stop_cdma_timer_locked()`).
  It did **not** reject this change. Those are separate bugs, not
  regressions of this one-liner.

**Step 4.2: CHECK WHO REVIEWED THE PATCH**
Record (`b4 dig -w`): To/Cc included Thierry Reding, David Airlie,
Simona Vetter, `dri-devel`, `linux-tegra`, `linux-kernel`. Subsystem
maintainer applied the series. No extra Reviewed-by on the commit.

**Step 4.3: SEARCH FOR THE BUG REPORT**
Record: No syzbot, bugzilla, or user crash report. Author-found race
from code inspection. Severity still UAF if it hits.

**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**
Record: Series is 6 independent small fixes. This is patch 1/6 and does
not need 2–6.

**Step 4.5: CHECK STABLE MAILING LIST HISTORY**
Record: WebFetch to `lore.kernel.org/stable/` returned 403.
**UNVERIFIED** whether stable@ already discussed this specific commit.
No `Cc: stable` on the patch.

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

**Step 5.1: KEY FUNCTIONS**
Record: `cdma_timeout_destroy` (changed). Related:
`cdma_timeout_handler`, `cdma_timeout_init`, `host1x_cdma_deinit`,
`release_channel`, `cdma_stop`.

**Step 5.2: TRACE CALLERS**
Record:
- `cdma_timeout_destroy` via `host1x_cdma_ops.timeout_destroy` →
  `host1x_hw_cdma_timeout_destroy()` → **`host1x_cdma_deinit()`** only.
- `host1x_cdma_deinit()` from **`release_channel()`** (last
  `host1x_channel_put()`).
- `host1x_channel_put()` call sites (all process context):
  - `drivers/gpu/drm/tegra/uapi.c` — channel close / ioctl error
  - `drm/tegra` gr2d/gr3d/vic/nvdec — client exit / context close
  - `drivers/crypto/tegra/tegra-se-main.c` — SE driver
  - `drivers/gpu/host1x/debug.c` — debugfs dump

**Step 5.3: TRACE CALLEES**
Record: `cancel_delayed_work_sync()` only. Can sleep; flushes the
delayed work.

**Step 5.4: FOLLOW THE CALL CHAIN**
Record: Userspace on Tegra DRM can trigger it: submit a job with a
timeout → timeout work queued → close channel (`DRM_TEGRA` channel close
/ process exit) while the handler runs. Unprivileged on devices that
expose tegra DRM. **Reachable from userspace.**

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**
Record: `stop_cdma_timer_locked()` still uses unsynchronized cancel
**under the lock** (correct). `cdma->update_work` is still not cancelled
in deinit (pre-existing, called out by sashiko-bot; **not** this patch).

===============================================================
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**.
- Commit **`7a39b9856acccc8e9b05845ca2bf62494fcd3dfa` is already an
  ancestor of HEAD** (`git merge-base --is-ancestor` succeeded). Current
  `cdma_timeout_destroy()` already calls `cancel_delayed_work_sync()`.
- The **bug** existed here until that commit: same function, same
  `cancel_delayed_work()`, since **v3.10**. This is mainline, so the fix
  is already applied; the question is whether the same change belongs on
  this tree’s stable-style policy given the code is the host1x driver
  this tree ships.
- Introducing commit **is** in this tree. This is not “bug added after
  this tree branched.”

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**
Record: **Clean apply.** Surrounding function is still the 2013
structure plus later whitespace. One-line identifier swap; no data-
structure or API change.

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**
Record: This exact fix is already in HEAD (mainline). No alternate fix,
no revert. No other commit on this file addresses the same cancel-vs-
running-work race.

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

**Step 7.1: SUBSYSTEM AND CRITICALITY**
Record: **drivers/gpu/host1x** (NVIDIA Tegra host1x DMA/sync engine).
**IMPORTANT** for Tegra (Android, Jetson, embedded), **PERIPHERAL** for
generic x86. `CONFIG_TEGRA_HOST1X` depends on `ARCH_TEGRA ||
COMPILE_TEST`.

**Step 7.2: SUBSYSTEM ACTIVITY**
Record: Actively maintained (Tegra264, context devices, multiple 2026
fixes). Author is a core contributor; Thierry Reding applied the series.

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

**Step 8.1: WHO IS AFFECTED**
Record: **Driver-specific / platform-specific** — Tegra SoCs using
host1x (DRM 2D/3D/VIC/NVDEC, Tegra SE crypto). Not universal mm/net.

**Step 8.2: TRIGGER CONDITIONS**
Record:
- Job timeout work is running (or sitting in `host1x_debug_dump` before
  the lock).
- Concurrent last `host1x_channel_put()` (channel close, client unbind,
  process exit).
- Timing-dependent. Author: “narrow” / cover letter “unlikely” — but
  timeout + channel teardown is a real recovery path.
- Unprivileged userspace on Tegra DRM can close a channel; timeout is a
  driver-internal delayed work.

**Step 8.3: FAILURE MODE SEVERITY**
Record: Timeout handler runs against CDMA/channel that
`host1x_cdma_deinit()` already tore down: destroyed mutex, freed push
buffer, stale channel. **UAF / kernel oops.** Severity: **HIGH** (crash;
possible memory-safety issue). Not a log-only bug.

**Step 8.4: RISK-BENEFIT RATIO**
Record:
- **Benefit:** High for Tegra users — prevents UAF on channel free vs
  timeout. Low for everyone else (config-gated).
- **Risk:** Very low — 1 line, standard API, no lock held, process
  context.
- **Ratio:** Benefit outweighs risk for any tree that still has the
  unsynchronized cancel.

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

**Step 9.1: COMPILE THE EVIDENCE**

**FOR backporting:**
- Real race: running timeout work vs CDMA/channel destroy.
- Failure mode is UAF / oops, not style.
- One-line, obviously correct `cancel_delayed_work_sync`.
- Bug in code since **v3.10**; no missing helpers.
- Standalone; series mates not required.
- Maintainer (Thierry Reding) applied v1 with no objections.
- Teardown is reachable from userspace channel close on Tegra.
- `debug_dump` before the lock makes the window practical during GPU
  timeout recovery.

**AGAINST:**
- No `Reported-by` / syzbot / production stack trace.
- Author called it unlikely.
- Tegra-only.
- Cover letter grouped it with “miscellaneous” logic issues.
- sashiko-bot noted other incomplete teardown (`update_work`); this
  patch does not fix that (and does not need to).
- This checkout already contains the commit (it is mainline 7.3-rc4).
  That is not a reason the **fix** is wrong for trees that still have
  async cancel.

**UNRESOLVED:**
- Stable@ archive search via WebFetch: 403.
- No empirical reproduction here.
- Self-flush if last kref is dropped from inside `debug_dump`: analyzed
  from code, not discussed on list.

**Step 9.2: STABLE RULES CHECKLIST**
1. Obviously correct and tested? **PASS** — standard workqueue teardown;
   maintainer applied; in mainline since 2026-07.
2. Fixes a real bug that affects users? **PASS** — UAF on channel free
   vs timeout handler.
3. Important issue (crash, security, corruption, deadlock)? **PASS** —
   UAF/oops; **HIGH**.
4. Small and contained? **PASS** — 1 line, one function.
5. No new features or APIs? **PASS**.
6. Can apply to the local tree? **PASS** — host1x CDMA timeout code is
   here; the change is trivial. (HEAD already has the post-image because
   this is the originating mainline tree.)

**Step 9.3: EXCEPTION CATEGORIES**
Record: None (not a device ID, quirk, DT, build, or docs exception). It
qualifies as a normal small crash-class fix.

**Step 9.4: DECISION**
This tree has host1x and the historical bug. The fix is a textbook
cancel-vs-running-work UAF close, one line, no prerequisites, no new
API. Stable rules are satisfied. Unlikely trigger does not outweigh an
oops/UAF on a path userspace can hit after a GPU timeout.

### What the commit solves
`cdma_timeout_destroy()` cancelled timeout work asynchronously. If
`cdma_timeout_handler()` was already running (especially in
`host1x_debug_dump()` before `cdma->lock`), `release_channel()` could
`cdma_stop` + `host1x_cdma_deinit()` and free CDMA while the handler
still used it. `cancel_delayed_work_sync()` waits for that worker first.

### Stable rules / risk
Meets all six stable criteria. Risk is a possible extra wait on channel
free (correct). Benefit is avoiding a kernel UAF on Tegra host1x.

### Concerns
No user report; Tegra-only; leftover `update_work` teardown is a
separate bug. None of those block this one-liner.

### Verification
- **[Phase 1]** Parsed subject/tags/body from `git log -1` + `git show
  7a39b9856accc`; no Fixes/Reported-by/Cc-stable; Link msgid present.
- **[Phase 2]** Diff is one token in `cdma_timeout_destroy`; read
  handler, `cdma_stop`, `host1x_cdma_deinit`, `release_channel`.
- **[Phase 2]** Confirmed handler calls `host1x_debug_dump()` before
  `mutex_lock`; dump uses `show_all(..., true)`.
- **[Phase 3]** `git blame` on parent: `6579324a41cc41` (2013); `git
  describe --contains` → `v3.10-rc1`.
- **[Phase 3]** `git merge-base --is-ancestor 6579324a41cc41 HEAD` and
  `7a39b9856accc HEAD` both true.
- **[Phase 3]** `git log --oneline` on `drivers/gpu/host1x/` for author
  and series; patch is standalone.
- **[Phase 4]** `b4 dig -c/-a/-w/-m`: v1 only; recipients include
  Thierry; mbox cover letter + “Applied to drm-misc-next”.
- **[Phase 4]** WebFetch lore/stable: 403 — listed UNVERIFIED.
- **[Phase 5]** `git grep host1x_channel_put` — DRM/crypto/debugfs,
  process context.
- **[Phase 6]** `git describe HEAD` / `make kernelversion` → v7.3-rc4;
  current file already has `_sync`.
- **[Phase 7]** `drivers/gpu/host1x/Kconfig` → `CONFIG_TEGRA_HOST1X`.
- **[Phase 8]** Failure mode from code: handler vs deinit = UAF; trigger
  = timeout work + last channel put.

**YES**

 drivers/gpu/host1x/hw/cdma_hw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/host1x/hw/cdma_hw.c b/drivers/gpu/host1x/hw/cdma_hw.c
index 3f3f0018eee0d..ab714d221120c 100644
--- a/drivers/gpu/host1x/hw/cdma_hw.c
+++ b/drivers/gpu/host1x/hw/cdma_hw.c
@@ -355,7 +355,7 @@ static int cdma_timeout_init(struct host1x_cdma *cdma)
 static void cdma_timeout_destroy(struct host1x_cdma *cdma)
 {
 	if (cdma->timeout.initialized)
-		cancel_delayed_work(&cdma->timeout.wq);
+		cancel_delayed_work_sync(&cdma->timeout.wq);
 
 	cdma->timeout.initialized = false;
 }
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.12] iommu/tegra241-cmdqv: Rate-limit the error ISR's log message

[Sasha Levin]

From: Nicolin Chen <nicolinc@nvidia.com>

[ Upstream commit a86c36163c9722545d27e92bdad8418fdcaa8b1d ]

tegra241_cmdqv_isr() logs the error-map registers on every error interrupt.
A malfunctioning device, or a guest deliberately faulting its own VCMDQs,
can raise these interrupts rapidly, and the unconditional dev_warn() then
floods the kernel log.

Rate-limit the message with dev_warn_ratelimited(), and pass the error-map
registers straight to it so their four MMIO reads run only when the limiter
prints, instead of building the string on every interrupt.

Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The local checkout is **v7.3-rc4**. The driver and the unconditional ISR
`dev_warn()` are present here; the change is a small, self-contained
log-flood / guest-DoS mitigation, so it belongs in this tree.

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

**Step 1.1: PARSE THE SUBJECT LINE**
Record: **[iommu/tegra241-cmdqv] [Rate-limit] [stop the error ISR from
printing on every interrupt]**

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
Record:
- **Fixes:** none (expected)
- **Reported-by:** none
- **Tested-by:** none
- **Reviewed-by / Acked-by:** none on the commit itself
- **Link:** none
- **Cc: stable:** none on this patch
- **Assisted-by:** Claude:claude-opus-4-8
- **Signed-off-by:** Nicolin Chen (NVIDIA; author), Will Deacon (arm-
  smmu maintainer; applied it)
- Pipeline markers such as Sasha Levin SOB / “[Upstream commit]” were
  not on the real commit (`a86c36163c972`)

Notable: no user/syzbot report. The cover letter says the series came
from **Sashiko** (LLM) review, not a production crash.

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
Record:
- **Bug:** `tegra241_cmdqv_isr()` logs error-map registers with
  unconditional `dev_warn()` on every error interrupt.
- **Symptom:** kernel log flood.
- **Trigger (stated):** malfunctioning device, or a **guest deliberately
  faulting its own VCMDQs**, raising interrupts rapidly.
- **Root cause:** every interrupt builds a 256-byte string (including
  four extra MMIO reads) and prints it.
- **Fix:** `dev_warn_ratelimited()`, and pass the MMIO reads as printk
  args so they run only when the limiter actually prints.
- **Version info:** none in the message.

**Step 1.4: DETECT HIDDEN BUG FIXES**
Record: Not a disguised cleanup. It is an explicit flood/DoS mitigation.
It does not fix a UAF, leak, or crash by itself.

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

**Step 2.1: INVENTORY THE CHANGES**
Record:
- File: `drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c` (+7 / −9)
- Function: `tegra241_cmdqv_isr()`
- Scope: **single-file surgical** (one logging site)

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
Record:
- **Before:** ISR always `snprintf()`s into `char err_str[256]`, always
  does four `CMDQ_ERR_MAP` MMIO reads, always `dev_warn()`.
- **After:** no stack buffer; `dev_warn_ratelimited(...)` with the four
  `readl_relaxed()` calls as arguments.
- Path: **error interrupt path** (threaded IRQ). Error *handling* after
  the log is unchanged.

Verified `dev_level_ratelimited()` in `include/linux/dev_printk.h`: the
`__VA_ARGS__` are only substituted inside `if (__ratelimit(&_rs))`, so
those MMIO reads run only when a line is printed.

**Step 2.3: IDENTIFY THE BUG MECHANISM**
Record:
- **Category:** ISR log flood / availability (guest-triggered printk
  storm), plus extra MMIO on every interrupt.
- **Not:** UAF, leak, deadlock, OOB, or NULL deref.
- **Hardware workaround?** No.

**Step 2.4: ASSESS THE FIX QUALITY**
Record:
- Obviously correct: standard `*_ratelimited` pattern already used in
  other IOMMU fault paths (`arm-smmu-v3.c`, `virtio-iommu.c`, AMD/Intel,
  etc.).
- Minimal; no unrelated edits.
- Regression risk: **very low**. Worst case is fewer error-map dumps in
  dmesg (intended). Error recovery is untouched.
- Red flags: LLM-assisted; no `Fixes:`/`Reported-by`. Not a new API.

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

**Step 3.1: BLAME THE CHANGED LINES**
Record:
- Unconditional `dev_warn()` + `snprintf` were in the original driver:
  `918eb5c856f6` (“Add in-kernel support for NVIDIA Tegra241 (Grace)
  CMDQV”), **2024-08-30**, first in **v6.12-rc1**.
- This tree is **v7.3-rc4**, so that code is in this lineage.

**Step 3.2: FOLLOW THE FIXES: TAG**
Record: No `Fixes:` tag. N/A. The logging has been there since the
driver was added.

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**
Record: This is **v2 11/11** of “Fix error-interrupt races and VINTF
lifecycle bugs” (Nicolin Chen, 2026-07-14). Cover letter: ordered
**most-critical-first**; this is the last, smallest issue (“ISR flooding
the kernel log under repeated guest errors”).
Standalone: it only changes the log line and does **not** need the
earlier UAF/lifecycle patches to be correct.

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**
Record: Nicolin Chen is the NVIDIA CMDQV contributor for this file; Will
Deacon applied the series. Same-day siblings are real
lifecycle/UAF/bounds fixes. This one is the leftover logging hardening.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**
Record: None required. `dev_warn_ratelimited` is old. The hunk applies
to the original ISR as well as the post-series ISR.

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

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**
Record:
- `b4 dig -c a86c36163c972` → https://patch.msgid.link/2e9d088c059037d5f
  c23532820444720b870d2c7.1784059577.git.nicolinc@nvidia.com
- **v1** (2026-07-02) and **v2** (2026-07-14); committed version is **v2
  11/11**.
- No NAK on this patch. Review noise in the thread was about **patch
  10/11** (dropped); Will applied 01–09 and 11.
- No reviewer asked for `Cc: stable` on *this* patch. Patch 07/11 in the
  same series did have `Cc: stable` (unrelated vSID check).
- WebFetch to lore returned **403**; thread was read from the b4 mbox
  instead.

**Step 4.2: CHECK WHO REVIEWED THE PATCH**
Record (`b4 dig -w`): Nicolin Chen, Will Deacon, Robin Murphy, Joerg
Roedel, Jason Gunthorpe; lists `iommu@`, `linux-arm-kernel`, `linux-
tegra`. Maintainer **Will Deacon applied it** (“Applied (apart from
patch 10)”).

**Step 4.3: SEARCH FOR THE BUG REPORT**
Record: No syzbot/bugzilla link. Origin is **Sashiko** static review,
described in the cover letter. Nicolin also noted Sashiko false
positives (including a wrong “level-triggered / kdump storm” claim);
CMDQV is **edge-triggered**, so an *unacked* pending error does not re-
assert. **Each new error still fires the ISR**, which is the remaining
flood path this patch addresses.

**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**
Record: 11-patch series; this patch is independent logging. Not blocked
on the dropped 10/11.

**Step 4.5: CHECK STABLE MAILING LIST HISTORY**
Record: **UNVERIFIED** via lore.kernel.org/stable (HTTP 403). The
submitted 11/11 message itself has no `Cc: stable`.

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

semcode MCP: **not available**. Used `git grep` / file reads.

**Step 5.1: IDENTIFY KEY FUNCTIONS**
Record: `tegra241_cmdqv_isr()` only.

**Step 5.2: TRACE CALLERS**
Record: Registered in `__tegra241_cmdqv_probe()` via
`request_threaded_irq(..., tegra241_cmdqv_isr, IRQF_ONESHOT, ...)`. Not
a hardirq; still a hot error path. Hardware: NVIDIA Tegra241 (Grace)
CMDQ-V (`CONFIG_TEGRA241_CMDQV`).

**Step 5.3: TRACE CALLEES**
Record: `readl_relaxed` of VINTF/CMDQ error maps;
`dev_warn_ratelimited`; then `tegra241_vintf0_handle_error` /
`tegra241_vintf_user_handle_error`. Those handlers are unchanged.

**Step 5.4: FOLLOW THE CALL CHAIN**
Record: Reachable when CMDQV is enabled (Grace SMMU). A guest with a
user VINTF/VCMDQ can generate command-queue errors; each new error
latches and interrupts. That is a userspace/VM-reachable path, not a
theoretical internal-only site.

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**
Record: Rate-limited IOMMU fault logs are the normal pattern elsewhere.
This driver was the outlier with a raw `dev_warn()` in the ISR.

===============================================================
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**
- Driver file exists; original ISR logging from `918eb5c856f6` (v6.12).
- `git merge-base --is-ancestor a86c36163c972 HEAD` → **yes** (already
  merged here). That is not used as “already selected for stable”; it
  only confirms this lineage has the driver and the fix.

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**
Record: **Clean apply** on this tree (already applied). The hunk does
not depend on later ISR locking. On a tree that still has the original
`snprintf`/`dev_warn` ISR, it would apply with at most trivial context.

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**
Record: No earlier equivalent rate-limit. `a2ee315db4261` only uses
`WARN_ON_ONCE` for out-of-bounds map bits; it does not throttle the
“unexpected error reported” line.

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

**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**
Record: **drivers/iommu/arm/arm-smmu-v3** (NVIDIA Grace CMDQ-V).
**PERIPHERAL/IMPORTANT for that platform**: only `CONFIG_TEGRA241_CMDQV`
/ Tegra241 (Grace) systems, including virtualization hosts using user
VINTFs.

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**
Record: Actively developed in 2026 (large Sashiko fix series + iommufd
work). Logging bug itself is old (v6.12).

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

**Step 8.1: DETERMINE WHO IS AFFECTED**
Record: **platform-specific / config-specific** — NVIDIA Grace +
`CONFIG_TEGRA241_CMDQV`. Hosts that expose guest VCMDQs are the
interesting population.

**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**
Record: CMDQV error IRQ. Commonness: rare on healthy HW; can be
**frequent** if a device malfunctions or a **guest injects VCMDQ
errors**. Unprivileged guest with VCMDQ access can trigger it. Not every
boot.

**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**
Record:
- Direct effect: dmesg/console flood; extra MMIO + `snprintf` on every
  interrupt.
- Indirect: printk/console contention, lost messages, possible stalls on
  a slow console.
- Not an oops, UAF, or data corruption.
- **Severity: MEDIUM** (availability / “oh, that’s not good”), with a
  stated guest DoS path.

**Step 8.4: CALCULATE RISK-BENEFIT RATIO**
Record:
- **Benefit:** medium for Grace virtualization hosts; low for everyone
  else.
- **Risk:** very low (7 lines, logging only).
- **Ratio:** favorable. Official stable rules allow “oh, that’s not
  good” and require an exploit explanation for “could be a problem”
  issues; the message gives that explanation.

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

**Step 9.1: COMPILE THE EVIDENCE**

FOR:
- Real, described flood: guest or bad device can fire the error IRQ
  repeatedly; each new error still interrupts (edge-triggered, latched
  per event).
- Tiny, obviously correct, matches other IOMMU drivers.
- Error handling unchanged; MMIO for the log runs only when printing.
- Driver and buggy logging exist in **this** 7.3-rc4 tree (since v6.12).
- Applied by the arm-smmu maintainer; no NAK on this patch.
- Official rules: not a trivia cleanup; exploit path is written down.

AGAINST:
- No production `Reported-by`; LLM-found.
- Least-critical patch in its series (11/11).
- Threaded IRQ (`IRQF_ONESHOT`), so not a hardirq printk.
- Unacked-guest *storm* was already ruled out as a false positive; this
  only limits *new*-error spam.
- Not a crash/corruption/UAF.

UNRESOLVED:
- Could not query lore.kernel.org/stable (403).
- No Tested-by.

**Step 9.2: APPLY THE STABLE RULES CHECKLIST**
1. Obviously correct and tested? **PASS** — standard ratelimit;
   maintainer applied. No extra tester tag.
2. Fixes a real bug that affects users? **PASS** — log flood / guest-
   driven interrupt spam on Grace CMDQV; users of that hardware exist.
3. Important issue? **PASS** (low end) — not oops/corruption; it is an
   explained availability issue (“oh, that’s not good” / guest printk
   DoS), which the documented rules allow.
4. Small and contained? **PASS** — ~16 lines, one function.
5. No new features or APIs? **PASS**.
6. Can apply to the local tree? **PASS** — pre-image exists here; apply
   is clean.

**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**
Record: None (not a device ID, quirk table, DT, build, or docs fix).
Qualifies as a normal small bugfix, not via an exception.

**Step 9.4: MAKE YOUR DECISION**
This tree contains the Tegra241 CMDQV driver and the original
unconditional ISR `dev_warn()`. The patch is a 7-line, obviously correct
rate-limit that closes a guest-reachable log flood without touching
recovery logic. Benefit is limited to Grace CMDQV, but risk is
negligible, so it meets the bar for this tree.

What it solves for users here: a VM or failing CMDQ can spam the host
log and extra MMIO on every error IRQ. That is not a panic, but it is a
real host-side availability nuisance on this platform.

Verification:
- [Phase 1] Tags: Assisted-by Claude; SOB Nicolin Chen + Will Deacon; no
  Fixes/Reported-by/Cc: stable on this commit
- [Phase 2] Diff: `tegra241_cmdqv_isr()` snprintf+dev_warn →
  dev_warn_ratelimited; +7/−9
- [Phase 2] Confirmed `dev_level_ratelimited` only evaluates args when
  `__ratelimit()` allows print
- [Phase 3] `git blame` / original file: logging from `918eb5c856f6`
  (v6.12-rc1)
- [Phase 3] `git describe --contains 918eb5c856f6` →
  v6.12-rc1~149^2^2~19
- [Phase 3] Series: v2 11/11; parent is VINTF0 leak fix, not a
  functional prereq
- [Phase 4] `b4 dig -c a86c36163c972`: lore/patch.msgid.link match; v1
  then v2
- [Phase 4] `b4 dig -a`: v1 2026-07-02, v2 2026-07-14 (applied)
- [Phase 4] `b4 dig -w`: iommu maintainers on To/Cc; Will applied 11/11,
  dropped 10/11
- [Phase 4] mbox: cover letter lists log flood; no comments/NAK on
  11/11; Cc: stable only on 07/11
- [Phase 4] WebFetch lore/stable: 403; stable-list search UNVERIFIED
- [Phase 5] Caller: `request_threaded_irq` in `__tegra241_cmdqv_probe`;
  CONFIG_TEGRA241_CMDQV
- [Phase 6] `git describe HEAD` → v7.3-rc4-27-gf0100363d8c37; `make
  kernelversion` → 7.3.0-rc4
- [Phase 6] `git merge-base --is-ancestor a86c36163c972 HEAD` → ancestor
  (code exists here)
- [Phase 8] Failure mode: printk flood / guest DoS, severity MEDIUM
- UNVERIFIED: lore.kernel.org/stable discussion (HTTP 403)

**YES**

 drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c | 16 +++++++---------
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c b/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c
index fdbd487848e64..8c9530873ed98 100644
--- a/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c
+++ b/drivers/iommu/arm/arm-smmu-v3/tegra241-cmdqv.c
@@ -350,21 +350,19 @@ static irqreturn_t tegra241_cmdqv_isr(int irq, void *devid)
 {
 	struct tegra241_cmdqv *cmdqv = (struct tegra241_cmdqv *)devid;
 	void __iomem *reg_vintf_map = REG_CMDQV(cmdqv, VINTF_ERR_MAP);
-	char err_str[256];
 	u64 vintf_map;
 
 	/* Use readl_relaxed() as register addresses are not 64-bit aligned */
 	vintf_map = (u64)readl_relaxed(reg_vintf_map + 0x4) << 32 |
 		    (u64)readl_relaxed(reg_vintf_map);
 
-	snprintf(err_str, sizeof(err_str),
-		 "vintf_map: %016llx, vcmdq_map %08x:%08x:%08x:%08x", vintf_map,
-		 readl_relaxed(REG_CMDQV(cmdqv, CMDQ_ERR_MAP(3))),
-		 readl_relaxed(REG_CMDQV(cmdqv, CMDQ_ERR_MAP(2))),
-		 readl_relaxed(REG_CMDQV(cmdqv, CMDQ_ERR_MAP(1))),
-		 readl_relaxed(REG_CMDQV(cmdqv, CMDQ_ERR_MAP(0))));
-
-	dev_warn(cmdqv->dev, "unexpected error reported. %s\n", err_str);
+	dev_warn_ratelimited(
+		cmdqv->dev,
+		"unexpected error reported. vintf_map: %016llx, vcmdq_map %08x:%08x:%08x:%08x\n",
+		vintf_map, readl_relaxed(REG_CMDQV(cmdqv, CMDQ_ERR_MAP(3))),
+		readl_relaxed(REG_CMDQV(cmdqv, CMDQ_ERR_MAP(2))),
+		readl_relaxed(REG_CMDQV(cmdqv, CMDQ_ERR_MAP(1))),
+		readl_relaxed(REG_CMDQV(cmdqv, CMDQ_ERR_MAP(0))));
 
 	/* Handle VINTF0 and its LVCMDQs */
 	if (vintf_map & BIT_ULL(0)) {
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] media: cec: tegra: add missing MODULE_DEVICE_TABLE()

[Sasha Levin]

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

[ Upstream commit 8dcf23edaf4bdf22259f6a47cfddc8bb1467425c ]

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.

This is a source-level fix.  It does not claim dynamic hardware
reproduction; the evidence is the driver-owned match table, its use by
the platform driver, and the missing module alias publication.

Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

This is a one-line OF module-alias fix on a driver that has been in the
tree since v4.15. Local checkout is **v7.3-rc4** (`7.3.0-rc4`,
`f0100363d8c37`), not a numbered stable branch. The candidate is
`8dcf23edaf4bd`.

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

Step 1.1: PARSE THE SUBJECT LINE
Record: `[media/cec/tegra] [add] missing MODULE_DEVICE_TABLE() so OF
module aliases are generated`

Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
Record:
- Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> (author)
- Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> (CEC/Tegra CEC
  maintainer; applied the patch)
- No Fixes:, Reported-by:, Tested-by:, Reviewed-by:, Acked-by:, Link:,
  or Cc: stable
- Absence of Fixes:/Cc: stable is expected for this review pipeline and
  is not a negative signal

Step 1.3: ANALYZE THE COMMIT BODY TEXT
Record:
- Bug: OF match table is wired to `.of_match_table` but not exported via
  `MODULE_DEVICE_TABLE(of, ...)`.
- Symptom: when `CONFIG_CEC_TEGRA=m`, depmod/modinfo get no `of:`
  aliases, so udev will not autoload `tegra_cec.ko` for
  `nvidia,tegra114-cec` / `tegra124-cec` / `tegra210-cec`.
- Version info: none in the message. Git shows the match table dates to
  the original driver (v4.15-rc1).
- Root cause: missing module-alias publication, not a probe/runtime
  logic error.
- Author states this is a source-level finding, not a live hardware
  repro.

Step 1.4: DETECT HIDDEN BUG FIXES
Record: Not a disguised cleanup. It is an explicit autoload/hardware-
enablement fix. The “source-level” wording is candor, not a claim that
nothing is wrong.

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

Step 2.1: INVENTORY THE CHANGES
Record:
- File: `drivers/media/cec/platform/tegra/tegra_cec.c` (+1 / -0)
- Functions: none. Adds `MODULE_DEVICE_TABLE(of, tegra_cec_of_match)`
  after the existing `tegra_cec_of_match[]` table.
- Scope: single-file, one-line surgical change.

Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
Record:
- Before: table exists and is assigned to
  `platform_driver.driver.of_match_table`, so a **already loaded** or
  **built-in** driver still matches DT nodes.
- After: `scripts/mod/file2alias.c` also emits `of:` modaliases into the
  `.ko`, so userspace can autoload the module from sysfs modalias.
- Path affected: module build / autoload, not probe/remove/IRQ/CEC
  transfer.

Step 2.3: IDENTIFY THE BUG MECHANISM
Record:
- Category: hardware enablement / missing device-table export (same
  family as adding IDs).
- Mechanism: `MODULE_DEVICE_TABLE()` creates the
  `__mod_device_table__kmod_*` alias that `file2alias.c` consumes.
  Without it, the kernel can bind the driver once loaded, but the module
  will not be loaded automatically.

Step 2.4: ASSESS THE FIX QUALITY
Record:
- Obviously correct: sibling CEC platform drivers (`stm32-cec`,
  `meson/ao-cec`, `s5p_cec`, `stih-cec`, `cec-gpio`) already use the
  same pattern.
- Minimal: one line, no API/struct/locking change.
- Regression risk: very low. Builtin builds are unaffected at runtime;
  modular builds only gain aliases.

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

Step 3.1: BLAME THE CHANGED LINES
Record:
- Match table introduced in `9d2d60687c9a06` ("media: tegra-cec: add
  Tegra HDMI CEC driver", Hans Verkuil, 2017-07-15; first contained in
  **v4.15-rc1**).
- Original file had the OF table and `.of_match_table =
  of_match_ptr(...)` and **no** `MODULE_DEVICE_TABLE`.
- Bug has been present for the entire life of the driver.

Step 3.2: FOLLOW THE FIXES: TAG
Record: No Fixes: tag. Not applicable. Introduction commit is
`9d2d60687c9a06`, present in this tree (`git merge-base --is-ancestor`
of the candidate vs HEAD succeeds).

Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
Record (recent on this file):
- `7bc1f3c8bd673` (2023): drop `of_match_ptr` so the table is always
  used (build fix for !OF).
- `8dcf23edaf4bd` (this commit)
- Later functional CEC fixes (`be627f257ce28`, `bce7236c16c2c`) do not
  depend on this line.
- Standalone; not patch X/Y.

Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Record:
- Pengpeng Hou submitted a large set of “add missing
  MODULE_DEVICE_TABLE()” patches (rtc, vdpa, watchdog, fbdev, soc, can,
  clk, power, this CEC driver). Same recipe, LLM-style commit text.
- Hans Verkuil is listed maintainer of `ARM/TEGRA HDMI CEC` and applied
  this patch. That is a strong quality signal for the **change**, even
  if the author is doing a sweep.

Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
Record: None. The macro has existed for decades
(`include/linux/module.h`). The table and `.of_match_table` assignment
are original. Applies standalone.

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

Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
Record:
- `b4 dig -c 8dcf23edaf4bd` →
  https://patch.msgid.link/20260704122631.99057-1-pengpeng@iscas.ac.cn
- Single revision (v1 only). `b4 dig -a` also matched an unrelated 2024
  Liao Chen v4l2-subdev series by patch-id search noise; this commit is
  a standalone v1.
- Direct lore HTTP fetch returned 403; full thread was saved via `b4 dig
  -m` to `/tmp/tegra_cec_moddev.mbox`.
- NVIDIA Tegra developer Mikko Perttunen replied 2026-07-15: objected to
  the “source-level fix / no dynamic hardware reproduction” paragraph as
  AI boilerplate, and said **“Otherwise looks fine to me.”** No NAK. No
  request for v2. Hans applied v1 as-is (that paragraph remained).
- No reviewer asked for Cc: stable.

Step 4.2: CHECK WHO REVIEWED THE PATCH
Record (`b4 dig -w`): To/Cc included Hans Verkuil, Mauro Chehab, Thierry
Reding, Jonathan Hunter, linux-tegra, linux-media, linux-kernel. Right
lists and maintainers. Informal ack from Mikko Perttunen (NVIDIA);
applied by Hans Verkuil.

Step 4.3: SEARCH FOR THE BUG REPORT
Record: No Reported-by, bugzilla, or syzbot. Evidence is the missing
export next to a live OF table. No user report of failed autoload was
found.

Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
Record: Same-day author sweep of missing `MODULE_DEVICE_TABLE` across
subsystems. Not a dependent series; each driver patch is self-contained.
Sibling CEC OF drivers already had the macro.

Step 4.5: CHECK STABLE MAILING LIST HISTORY
Record: No lore.kernel.org/stable thread for this exact Tegra CEC patch
(search did not return a relevant hit). Same-class patches **have** gone
into stable before, including:
- `PCI: tegra: Add missing MODULE_DEVICE_TABLE` on 4.19-stable
- `can: ctucanfd: add missing MODULE_DEVICE_TABLE()` from the same
  author, committed to linux-stable by Greg Kroah-Hartman
  (`d937bdb244a75` upstream)

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

Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF
Record: No functions modified. Macro addition adjacent to
`tegra_cec_of_match[]`. Related structures: `tegra_cec_driver`
(`module_platform_driver`).

Step 5.2: TRACE CALLERS
Record: `tegra_cec_probe` is the platform probe (DT device
instantiation). `MODULE_DEVICE_TABLE` is not called at runtime;
`scripts/mod/file2alias.c` `do_table()` consumes the alias at module
build. Impact surface is autoload of `tegra_cec.ko` only.

Step 5.3: TRACE CALLEES
Record: N/A for the added line. The driver already includes
`<linux/module.h>` and `<linux/of.h>`.

Step 5.4: FOLLOW THE CALL CHAIN
Record: Reachable for users with `CONFIG_CEC_TEGRA=m` on Tegra
114/124/210 HDMI CEC DT nodes (e.g. Jetson TK1 / older Tegra boards).
Unprivileged userspace cannot trigger a crash; the user-visible failure
is “CEC adapter never appears until `modprobe tegra_cec`”. Builtin
(`=y`) is already fine.

Step 5.5: SEARCH FOR SIMILAR PATTERNS
Record: Other CEC platform drivers already export OF tables. This file
was the outlier. Same missing-macro pattern exists across many drivers
and is treated as a real autoload bug.

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

Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?
Record: Yes. File `drivers/media/cec/platform/tegra/tegra_cec.c` exists.
Pre-commit parent still has the OF table and `.of_match_table` without
the macro. Candidate **is already an ancestor of HEAD** (`git merge-base
--is-ancestor 8dcf23edaf4bd HEAD`). Bug introduced v4.15-rc1; present in
every long-lived stable series that has this driver.

Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
Record: Expected apply: **clean**. Context around the table (compatibles
tegra114/124/210) is original. Later commits only add the macro and then
unrelated CEC protocol fixes. Line numbers differ slightly on current
HEAD because of later edits, but the hunk is trivial.

Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE
Record: This is the fix; it is already in this 7.3-rc4 tree. No earlier
substitute autoload fix on this file. `7bc1f3c8bd673` only dropped
`of_match_ptr`; it did not add aliases.

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

Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
Record: `drivers/media/cec/platform/tegra/` — HDMI CEC on NVIDIA Tegra.
Criticality: **PERIPHERAL** (SoC-specific media driver), but real
product hardware (Jetson TK1 and Tegra X1 designs were the original test
targets).

Step 7.2: ASSESS SUBSYSTEM ACTIVITY
Record: Low churn. Driver added 2017; occasional correctness fixes.
Mature. The missing macro is long-standing, not a regression from recent
refactoring.

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

Step 8.1: DETERMINE WHO IS AFFECTED
Record: Driver-specific / config-specific: `CONFIG_CEC_TEGRA=m` on DT
platforms with `nvidia,tegra114-cec`, `nvidia,tegra124-cec`, or
`nvidia,tegra210-cec`. Not universal.

Step 8.2: DETERMINE THE TRIGGER CONDITIONS
Record: Every boot/hotplug of that DT node when the driver is a module
and nothing else loads it. Common on distros that package CEC as a
module; irrelevant if the vendor kernel builds it in. Not a race. Not
triggerable as a crash by unprivileged users.

Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
Record: HDMI CEC device never binds until manual `modprobe`. No oops,
leak, or corruption. Severity: **MEDIUM** for those boards
(feature/hardware dead), **LOW** globally. This is the same user-visible
class as “device ID missing so the module never loads.”

Step 8.4: CALCULATE RISK-BENEFIT RATIO
Record:
- Benefit: restores intended autoload for modular Tegra CEC; matches
  every other CEC OF driver.
- Risk: one compile-time alias line; no runtime path change.
- Ratio: high benefit for affected users, negligible risk.

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

Step 9.1: COMPILE THE EVIDENCE

FOR backporting:
- Real bug: OF match table used by the platform driver is not published
  to module aliases.
- `CEC_TEGRA` is **tristate**; modular builds are first-class.
- One line, obviously correct, no new API.
- Same pattern as the documented **device-ID / hardware enablement**
  exception.
- Maintainer-applied (Hans Verkuil); NVIDIA engineer said the change
  looks fine.
- Sibling CEC drivers already have `MODULE_DEVICE_TABLE(of, ...)`.
- Bug present since v4.15; no prerequisites.
- Same class of patches has historically been accepted into stable
  (including this author’s `can: ctucanfd` MODULE_DEVICE_TABLE fix).

AGAINST:
- Not a crash, UAF, deadlock, or security hole.
- No end-user report; author did not claim hardware reproduction.
- Peripheral SoC driver; small user population.
- Author is doing a mass static-analysis sweep; commit text was called
  out as AI boilerplate.
- Builtin kernels are unaffected.

UNRESOLVED:
- Could not HTTP-fetch lore (403); discussion recovered from `b4 dig -m`
  instead.
- Could not find a stable-list thread for **this** SHA.

Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. Obviously correct and tested? **PASS** — one well-known macro;
   applied by the subsystem maintainer; NVIDIA developer agreed. Build-
   tested at least (author/reviewer).
2. Fixes a real bug that affects users? **PASS** — modular autoload for
   real Tegra CEC DT compatibles.
3. Important issue? **PASS** under the hardware-enablement exception
   (device does not come up). Not CRITICAL crash/corruption.
4. Small and contained? **PASS** — +1 line, one file.
5. No new features or APIs? **PASS** — publishes an existing table.
6. Can apply to the local tree? **PASS** — file and table exist; hunk is
   trivial. (This 7.3-rc4 tree already contains the commit.)

Step 9.3: CHECK FOR EXCEPTION CATEGORIES
Record: **Device ID / module alias publication for an existing driver.**
Closest listed exception is new device IDs; this is the matching half
(exporting the IDs the driver already matches). Also analogous to
quirks/DT enablement: it makes already-supported hardware actually
attach when built as a module.

Step 9.4: MAKE YOUR DECISION
The local tree is mainline **7.3.0-rc4**. The driver and buggy omission
exist here and in any stable series that still has `tegra_cec`. The
patch is a one-line, maintainer-acked autoload fix with no runtime risk.
That is stable material.

What problem it solves for stable users: with `CONFIG_CEC_TEGRA=m`, udev
never loads the module from the DT compatible, so HDMI CEC stays dead
until a manual modprobe. Distros that ship this as a module on
Jetson/Tegra boards hit that.

Risk vs benefit: benefit is hardware actually probing; risk is
essentially zero.

Verification:
- [Phase 1] Parsed tags: author + Hans Verkuil SOB only; no
  Fixes/Reported-by/Cc: stable
- [Phase 1] Body describes missing OF alias publication, not a crash
- [Phase 2] Diff: +1 line `MODULE_DEVICE_TABLE(of, tegra_cec_of_match)`
  in `tegra_cec.c`
- [Phase 2] Confirmed `.of_match_table = tegra_cec_of_match` already
  present
- [Phase 3] `git blame`: table from `9d2d60687c9a06` (v4.15-rc1); macro
  from `8dcf23edaf4bd`
- [Phase 3] Original driver dump: no MODULE_DEVICE_TABLE
- [Phase 3] Author sweep of similar one-liners; Hans is MAINTAINERS
  owner of ARM/TEGRA HDMI CEC
- [Phase 4] `b4 dig -c 8dcf23edaf4bd`:
  https://patch.msgid.link/20260704122631.99057-1-pengpeng@iscas.ac.cn
- [Phase 4] `b4 dig -a`: single v1; no later revision
- [Phase 4] `b4 dig -w`: linux-media, linux-tegra, Hans, Mauro, Thierry
  Reding, Jonathan Hunter
- [Phase 4] mbox: Mikko Perttunen “Otherwise looks fine to me”;
  complaint was about AI commit-message padding only
- [Phase 4] lore WebFetch 403; content taken from mbox
- [Phase 4] No stable@ thread for this SHA; same-class
  MODULE_DEVICE_TABLE patches have landed in stable
- [Phase 5] Kconfig `CEC_TEGRA` is tristate; Makefile
  `obj-$(CONFIG_CEC_TEGRA) += tegra_cec.o`
- [Phase 5] `MODULE_DEVICE_TABLE` in `include/linux/module.h` creates
  file2alias symbol; `scripts/mod/file2alias.c` `do_table()` consumes it
- [Phase 5] Other CEC OF drivers already have the macro
- [Phase 6] `git describe HEAD`: v7.3-rc4-27-gf0100363d8c37; `make
  kernelversion`: 7.3.0-rc4
- [Phase 6] `git merge-base --is-ancestor 8dcf23edaf4bd HEAD`: yes
  (already in this tree)
- [Phase 6] Backport difficulty: clean one-liner
- [Phase 7] Peripheral media driver, maintainer-applied
- [Phase 8] Failure mode: module not autoloaded → CEC unused; severity
  MEDIUM for Tegra modular users, not a panic
- UNVERIFIED: live udev autoload on real Tegra hardware (author did not
  claim it)

**YES**

 drivers/media/cec/platform/tegra/tegra_cec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/cec/platform/tegra/tegra_cec.c b/drivers/media/cec/platform/tegra/tegra_cec.c
index 3ed50097262f6..fe66336e734f8 100644
--- a/drivers/media/cec/platform/tegra/tegra_cec.c
+++ b/drivers/media/cec/platform/tegra/tegra_cec.c
@@ -458,6 +458,7 @@ static const struct of_device_id tegra_cec_of_match[] = {
 	{ .compatible = "nvidia,tegra210-cec", },
 	{},
 };
+MODULE_DEVICE_TABLE(of, tegra_cec_of_match);
 
 static struct platform_driver tegra_cec_driver = {
 	.driver = {
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] clk: tegra: support 48MHz clock for pll_p_out1

[Sasha Levin]

From: Dmitry Osipenko <digetx@gmail.com>

[ Upstream commit 46e31d69a547530fbef499bde888b6bb45a1deac ]

UEFI on Surface2 sets pll_p_out1 to 48MHz which is not supported by kernel
and causes BUG() early on. Add 48MHz clock support for pll_p_out1.

Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Jonas Schwöbel <jonasschwoebel@yahoo.de>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Brian Masney <bmasney@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The local tree is **v7.3-rc4** (mainline). The change is a one-line
parent-rate case that stops a deterministic early-boot `BUG()` when UEFI
leaves `pll_p_out1` at 48 MHz. Surrounding `_calc_rate` logic has been
in-tree since 2013, so this is a self-contained crash fix, not a new
API.

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

Step 1.1: PARSE THE SUBJECT LINE
Record: **[clk: tegra:] [support] [allow pll_p_out1 parent rate 48 MHz
in `_calc_rate` so firmware-programmed 48 MHz does not hit `BUG()`]**

Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
Record:
- **Acked-by:** Thierry Reding `<treding@nvidia.com>` (Tegra maintainer)
- **Signed-off-by:** Dmitry Osipenko (author; long-time Tegra clk
  contributor)
- **Signed-off-by:** Jonas Schwöbel
- **Signed-off-by:** Svyatoslav Ryhel (submitter)
- **Signed-off-by:** Brian Masney (clk maintainer who applied it)
- **No Fixes:** tag (expected)
- **No Cc: stable** (expected)
- **No Reported-by / Tested-by / Link:**
- Ignore any Sasha Levin SOB if present in a candidate wrapper; none on
  the real commit `46e31d69a5475`

Step 1.3: ANALYZE THE COMMIT BODY TEXT
Record:
- **Bug:** UEFI on Microsoft Surface 2 programs `pll_p_out1` to 48 MHz.
  `_calc_rate()` only accepted 9.6 MHz and 28.8 MHz in that switch arm;
  48 MHz fell into `default:` which prints an error and calls `BUG()`.
- **Symptom:** kernel `BUG()` during early clock init (boot crash).
- **Root cause:** missing parent-rate case in the out-of-table PLL
  calculator used when PLLA’s freq table has no matching input rate.
- **Version info:** none in the message. Cover letter (v2 0/1) says the
  case is aligned with NVIDIA downstream 3.4 tegra114 logic.

Step 1.4: DETECT HIDDEN BUG FIXES
Record: **Not a hidden fix.** Subject says “support” but the body is
explicit: this prevents `BUG()`. It is a firmware/hardware compatibility
quirk, not a new clock API.

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

Step 2.1: INVENTORY THE CHANGES
Record:
- **File:** `drivers/clk/tegra/clk-pll.c` (+1 / −0)
- **Function:** `_calc_rate()`
- **Scope:** single-file, one `case 48000000:` added next to existing
  9.6/28.8 MHz cases

Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
Record:
- **Before:** `parent_rate == 48000000` → `default` → `pr_err` +
  `BUG()`.
- **After:** same arm as 9.6/28.8 MHz: `cfreq = parent_rate /
  (parent_rate / 1000000)` (1 MHz for 48 MHz), then existing M/N/P
  calculation and range checks.
- **Path:** clock-init `clk_set_rate()` on PLLA (and any other PLL using
  default `_calc_rate`). Error path only in the sense that the old path
  was a fatal default; this is the out-of-table rate calculator, not a
  new userspace API.

Verified boot path in this tree:
- Tegra114 `init_table` sets `TEGRA114_CLK_PLL_A` to 564480000 (`clk-
  tegra114.c`).
- `tegra_init_from_table()` calls `clk_set_rate()`.
- PLLA parent is `"pll_p_out1"` (`tegra114_audio_plls[]`).
- `pll_a_freq_table[]` only lists 9600000 and 28800000 input rates, so
  `_get_table_rate()` fails and `_calc_rate()` runs.
- That is the `BUG()` the commit describes.

Step 2.3: IDENTIFY THE BUG MECHANISM
Record:
- **Category:** (h) hardware/firmware workaround + (g) logic: missing
  switch case that caused (kernel `BUG()`).
- **Mechanism:** firmware leaves a valid PLLP divider output of 48 MHz;
  the calculator treated it as an impossible reference and crashed.

Step 2.4: ASSESS THE FIX QUALITY
Record:
- **Quality:** obviously correct. Same formula already used for the
  other PLLP_OUT1 rates. Tegra maintainer acked it.
- **Minimal:** one line, no API/data-structure change.
- **Regression risk:** very low. Extra parent rate only changes the 48
  MHz path; other rates unchanged.
- **Nuance (verified):** tegra114 PLLA uses `pllp_nmp.divm_width = 5`,
  so `divm_max` is 31. For 48 MHz, `cfg->m = 48`, which can fail the
  existing `cfg->m > divm_max` check and return `-EINVAL` instead of
  programming PLLA. That is still far better than `BUG()`:
  `clk_pll_set_rate()` then `WARN_ON`s and returns. Completeness of PLLA
  programming is a separate issue; the crash is fixed.

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

Step 3.1: BLAME THE CHANGED LINES
Record:
- Switch and `BUG()` introduced in **`8f8f484bf355e5`** (“clk: tegra:
  add Tegra specific clocks”, Prashant Gaikwad, 2013-01-11; in v3.9
  era).
- 9.6/28.8 MHz formula adjusted in **`e52d7c04bb3911`** (2015).
- 48 MHz case added by **`46e31d69a5475`** (this commit).
- Buggy missing-rate behavior has been present for ~13 years.

Step 3.2: FOLLOW THE FIXES: TAG
Record: **No Fixes: tag.** Not applicable. Introduced by the original
2013 Tegra clk driver, not a recent regression.

Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
Record: Recent `clk-pll.c` commits are unrelated (GFP helpers,
`determine_rate`, RPM). This commit is **standalone**, not patch X/Y of
a clk series. Author/submitter Tegra DT work around the same time
(TF600T, grouper, tegra114 EMC) does not need to land with this 1-line
clk case.

Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Record: Dmitry Osipenko is a regular Tegra clk contributor (`Don't allow
zero clock rate`, PLLU config, gate refcounting, etc.). Submitter Ryhel
resubmitted with maintainer Ack. Applied by Brian Masney.

Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
Record: **None.** Diff only adds a `case` label. `_calc_rate`, the
9.6/28.8 arm, and `BUG()` default all exist in this file independently
of later refactors. Can apply standalone.

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

Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
Record:
- **b4 dig:**
  https://patch.msgid.link/20260427132447.118272-2-clamor95@gmail.com
- **v1:** 2026-04-17 `20260417073452.23342-2-clamor95@gmail.com`
- **v2 / resend:** 2026-04-27 (cover + patch); Thierry Ack 2026-05-28
- Cover letter: “Fix this by adding 48MHz clock support… aligned with
  downstream 3.4 kernel for tegra114 logic”
- **No NAK.** Only reviewer reply was Thierry’s **Acked-by**.
- **No Cc: stable** in review (absence is not a negative).

Step 4.2: CHECK WHO REVIEWED THE PATCH
Record: Recipients included Stephen Boyd, Michael Turquette, Thierry
Reding, Jonathan Hunter, linux-clk, linux-tegra. **Thierry Reding
acked.** Right maintainers were on the thread.

Step 4.3: SEARCH FOR THE BUG REPORT
Record: No bugzilla/syzbot link. Description is a concrete
firmware+hardware trigger (Surface 2 UEFI), not theoretical. Surface 2
has **no in-tree DT** (tegra114 boards present: dalmore, roth, tn7,
asus-tf701t only). Users still hit this with UEFI + out-of-tree/work-in-
progress DT; the clk driver is in-tree for all Tegra114.

Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
Record: Series is **v2 0/1 + 1/1**. Self-contained. No sibling patch
required for the `BUG()` fix.

Step 4.5: CHECK STABLE MAILING LIST HISTORY
Record: **UNVERIFIED** — lore.kernel.org returned 403 (Anubis). Original
linux-tegra/linux-clk thread was retrieved via `b4 dig -m`; no stable-
list discussion in that mbox.

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

Step 5.1: IDENTIFY KEY FUNCTIONS
Record: **`_calc_rate()`** only.

Step 5.2: TRACE CALLERS
Record:
- Default `pll->params->calc_rate` in `_tegra_clk_register_pll()` for
  non-PLLM PLLs.
- Called from **`clk_pll_set_rate()`** and
  **`clk_pll_determine_rate()`** when `_get_table_rate()` misses.
- Tegra210 PLLs use `tegra210_pll_fixed_mdiv_cfg` instead; this path is
  **tegra20/30/114/124**.
- Context: boot clock init and later audio PLL rate changes. Not a
  syscall-hot path, but **every boot** on affected firmware.

Step 5.3: TRACE CALLEES
Record: Integer divider math only (`cfreq`, `m`/`n`/`p`). No allocation,
no locks inside `_calc_rate`. `clk_pll_set_rate` takes `pll->lock` after
calc.

Step 5.4: FOLLOW THE CALL CHAIN
Record:
`tegra114_clock_init` → `tegra_clk_apply_init_table` →
`tegra_init_from_table` → `clk_set_rate(pll_a, 564480000)` →
`clk_pll_set_rate` → `_calc_rate`.
**Reachable from boot on Tegra114 when parent is 48 MHz.** Unprivileged
userspace is not required; firmware state is enough.

Step 5.5: SEARCH FOR SIMILAR PATTERNS
Record: Same `_calc_rate` switch is the single shared calculator. No
duplicate 48 MHz holes in sibling functions. Freq tables still lack 48
MHz PLLA rows (out-of-table path is intentional, per comment).

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

Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?
Record:
- Tree: **`git describe HEAD` = `v7.3-rc4-27-gf0100363d8c37`**,
  `VERSION=7 PATCHLEVEL=3 SUBLEVEL=0 EXTRAVERSION=-rc4`.
- `git merge-base --is-ancestor 46e31d69a5475 HEAD` → **already in this
  checkout** (landed in v7.3-rc1).
- The **vulnerable pattern** (`_calc_rate` switch + `BUG()` on unknown
  parent rate) is here and dates to 2013. The 48 MHz hole is what this
  commit fills. This is not post-7.3 code; older stables that still lack
  the case have the bug.

Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
Record: **Clean apply** on any tree that still has the 9.6/28.8 arm
without `case 48000000:`. Context in this file is stable. No backport
rewrite needed.

Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE
Record: This **is** the fix (`46e31d69a5475`). No earlier alternate 48
MHz handling in `clk-pll.c`.

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

Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
Record: **drivers/clk/tegra** — SoC clock driver. **IMPORTANT** for
NVIDIA Tegra 20/30/114/124, not core-mm/VFS. Boot-blocking on those
SoCs.

Step 7.2: ASSESS SUBSYSTEM ACTIVITY
Record: Mature driver (2013), still receiving fixes. This is a long-
standing hole, not churn from a new subsystem.

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

Step 8.1: DETERMINE WHO IS AFFECTED
Record: **Platform/firmware-specific:** Tegra boards whose firmware sets
`pll_p_out1` to 48 MHz. Documented trigger is **Surface 2 UEFI**. Any
tegra20/30/114/124 PLL using default `_calc_rate` with that parent rate.

Step 8.2: DETERMINE THE TRIGGER CONDITIONS
Record: **Every boot** with that firmware, during CAR init table
application. Not a race. Not unprivileged-syscall; **unusable machine**
if you boot Linux on that hardware.

Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
Record: **`BUG()` on boot → CRITICAL** for affected devices (oops/panic,
system does not come up). After the fix, worst case on tegra114 is
`-EINVAL` + `WARN_ON` if M overflows, not a hard `BUG()`.

Step 8.4: CALCULATE RISK-BENEFIT RATIO
Record:
- **Benefit:** high for those devices (boot vs die); moderate overall
  (narrow hardware).
- **Risk:** very low (one `case` label, existing formula).
- **Ratio:** strongly favors taking it. Matches the **hardware quirk**
  stable exception (USB/PCI quirk analogue: one-line table addition so
  existing driver survives real firmware).

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

Step 9.1: COMPILE THE EVIDENCE
**FOR:**
- Deterministic early-boot `BUG()`, verified via init_table →
  `clk_set_rate(pll_a)` → `_calc_rate`.
- One-line, obviously correct, same math as 9.6/28.8 MHz.
- Acked by Tegra maintainer Thierry Reding; applied by clk maintainer.
- Code path present since 2013; no prerequisites.
- Hardware/firmware quirk, not a new UAPI.

**AGAINST:**
- Subject looks like a feature (“support 48MHz”).
- Surface 2 DT is not in mainline; user population is small.
- PLLA 5-bit M may still reject the computed `m=48` (WARN instead of
  BUG). Incomplete programming, but the crash is gone.
- No syzbot/CVE/Fixes tag (expected for this review queue).

**UNRESOLVED:**
- Stable-list discussion (lore 403).
- Whether every tegra114 board with 48 MHz pll_p_out1 can actually lock
  PLLA after this; downstream 3.4 used this same case.

Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. Obviously correct and tested? **PASS** — one case, maintainer Ack, in
   mainline since v7.3-rc1.
2. Fixes a real bug that affects users? **PASS** — UEFI Surface 2 (and
   same firmware pattern) `BUG()` at boot.
3. Important issue? **PASS** — boot `BUG()`, severity CRITICAL for that
   hardware.
4. Small and contained? **PASS** — +1 line, one function.
5. No new features or APIs? **PASS** — quirk: accept a parent rate the
   hardware/firmware already programs. No new sysfs/uapi/driver.
6. Can apply to the local tree? **PASS** — surrounding `_calc_rate`
   exists; patch is a single case add (already present on this 7.3-rc4
   HEAD because the candidate came from this lineage).

Step 9.3: CHECK FOR EXCEPTION CATEGORIES
Record: **Hardware quirk/workaround** (firmware-programmed clock the
driver must not `BUG()` on). Analogous to USB/PCI quirk table entries.

Step 9.4: MAKE YOUR DECISION
This is a surgical boot-crash fix for a real firmware configuration. It
meets stable rules and the quirk exception. Limited hardware does not
disqualify it: obscure-device quirks are routinely taken. Incomplete
PLLA table entries do not restore the `BUG()`, so they are not a reason
to reject.

What problem it solves: Tegra `_calc_rate()` treated 48 MHz `pll_p_out1`
as illegal and called `BUG()` while setting PLLA during clock init.
Surface 2 UEFI programs that rate.

Risk vs benefit: one `case` vs a boot panic. Benefit dominates.

Concerns: no in-tree Surface 2 DT; possible later `-EINVAL` if M
overflows. Neither makes the `BUG()` acceptable to leave in stable.

Verification:
- [Phase 1] Tags: Acked-by Thierry Reding; SOBs Osipenko, Schwöbel,
  Ryhel, Masney; no Fixes/Cc-stable/Reported-by
- [Phase 2] Diff: +1 line `case 48000000:` in `_calc_rate()` in
  `drivers/clk/tegra/clk-pll.c`
- [Phase 2] tegra114 `init_table` sets PLLA 564480000; parent
  `pll_p_out1`; freq table has no 48 MHz input → `_calc_rate` on boot
- [Phase 2] `divm_width=5` → m=48 may `-EINVAL` after the fix; `BUG()`
  still avoided
- [Phase 3] git blame: switch/`BUG()` from `8f8f484bf355e5` (2013); this
  commit `46e31d69a547530fbef499bde888b6bb45a1deac`
- [Phase 3] `git merge-base --is-ancestor 46e31d69a5475 HEAD` → already
  in this 7.3-rc4 tree
- [Phase 3] No Fixes tag; standalone; no prerequisite commits
- [Phase 4] `b4 dig -c 46e31d69a5475` → lore patch-id match; v1
  2026-04-17, v2 2026-04-27
- [Phase 4] `b4 dig -a`: v1 then v2 (“aligned with downstream 3.4”)
- [Phase 4] `b4 dig -w`: linux-clk, linux-tegra, Thierry, Boyd, Hunter
- [Phase 4] mbox: Thierry Acked-by; no NAK
- [Phase 4] lore WebFetch 403; stable list UNVERIFIED
- [Phase 5] callers: `clk_pll_set_rate`, `clk_pll_determine_rate`;
  default calc_rate for non-PLLM
- [Phase 6] `git describe HEAD` = v7.3-rc4-27-gf0100363d8c37; Makefile
  7.3.0-rc4; file and BUG() default present
- [Phase 6] No other 48 MHz pll_p_out1 fix in this file
- [Phase 7] clk/tegra, important for Tegra SoCs
- [Phase 8] Failure mode: `BUG()` at boot, CRITICAL for affected
  firmware
- UNVERIFIED: stable@ discussion; whether PLLA actually locks at 564.48
  MHz with 48 MHz parent on Surface 2 hardware

**YES**

 drivers/clk/tegra/clk-pll.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index 591b9f0c155a0..e48ca3f4b5f86 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -575,6 +575,7 @@ static int _calc_rate(struct clk_hw *hw, struct tegra_clk_pll_freq_table *cfg,
 		break;
 	case 9600000:
 	case 28800000:
+	case 48000000:
 		/*
 		 * PLL_P_OUT1 rate is not listed in PLLA table
 		 */
-- 
2.53.0