[PATCH AUTOSEL 6.18] media: v4l2-common: Always register clock with device-specific name

[PATCH AUTOSEL 6.18] media: v4l2-common: Always register clock with device-specific name

[Sasha Levin]

From: Paul Cercueil <paul@crapouillou.net>

[ Upstream commit 0b42657bea6ba635226e8ef551076d024ceacdc9 ]

If we need to register a dummy fixed-frequency clock, always register it
using a device-specific name.

This supports the use case where a system has two of the same sensor,
meaning two instances of the same driver, which previously both tried
(and failed) to create a clock with the same name.

Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `media: v4l2-common: Always register clock
with device-specific name`

**Local tree:** Linux **6.18.43** (`git describe HEAD` →
`v6.18.43-1-gc7f0dac02d232`)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject line
**Record:** `[media: v4l2-common]` — implicit fix via “Always register…”
— ensures dummy fixed-frequency clocks use unique, device-specific
names.

### Step 1.2: Tags
**Record:**
- **Fixes:** — none
- **Reported-by:** — none
- **Tested-by:** — none
- **Reviewed-by:** Mehdi Djait `<mehdi.djait@linux.intel.com>`
- **Acked-by:** — none
- **Link:** — none
- **Cc: stable:** — none (expected for manual review)
- **Signed-off-by:** Paul Cercueil (author), Hans Verkuil (media
  maintainer)

Notable: Intel media reviewer sign-off; no syzbot or user bug reports.

### Step 1.3: Body analysis
**Record:**
- **Bug:** When `__devm_v4l2_sensor_clk_get()` registers a dummy fixed
  clock and the caller passes a non-NULL `id` (e.g. `"xvclk"`), the
  clock is registered under that bare string. Two instances of the same
  sensor driver collide on the global clock name.
- **Symptom:** Second sensor instance fails clock registration
  (`-EEXIST` from the clock core) → driver probe fails → second camera
  does not work.
- **Root cause:** Device-specific naming was only applied when `id ==
  NULL`; non-NULL `id` was passed straight to
  `devm_clk_hw_register_fixed_rate()`.
- **Version info:** None in the commit message.

### Step 1.4: Hidden bug fix?
**Record:** No — this is an explicit hardware-enablement bug fix, not
disguised cleanup.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
**Record:**
- **Files:** `drivers/media/v4l2-core/v4l2-common.c` (+7 / −6)
- **Function:** `__devm_v4l2_sensor_clk_get()`
- **Scope:** Single-file, surgical fix (~13 lines touched)

### Step 2.2: Code flow change
**Record:**

| Hunk | Before | After |
|------|--------|-------|
| Clock naming | Only when `!id`: allocate `"clk-<devname>"`, assign to
`id` | Always allocate: `"clk-<devname>-<id>"` if `id` set, else
`"clk-<devname>"` |
| Registration | `devm_clk_hw_register_fixed_rate(dev, id, ...)` |
`devm_clk_hw_register_fixed_rate(dev, clk_id, ...)` |

Affected path: dummy fixed-clock registration on non-OF platforms or
legacy ACPI/OF paths when `devm_clk_get_optional()` returns no clock.

### Step 2.3: Bug mechanism
**Record:** **Logic / correctness fix** — global clock namespace
collision. `clk_core_lookup()` returns `-EEXIST` for duplicate names
(verified in `drivers/clk/clk.c:3910-3914`).

### Step 2.4: Fix quality
**Record:**
- Obviously correct: mirrors the existing NULL-`id` naming pattern and
  extends it.
- Minimal, no API changes.
- Low regression risk: only changes internally registered dummy clock
  names; callers still request clocks by their original `id` via
  `devm_clk_get_optional()`.
- `clk_id` already uses `__free(kfree)` cleanup attribute — memory
  handling unchanged.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
**Record:** Buggy naming logic present since helper introduction. `git
blame` on lines 767–774 attributes to commit `5d324e5159d9e` (tree
history artifact). `git show v6.18:...` confirms identical buggy code in
**Linux 6.18.0**. Helper does **not** exist in v6.17 (`grep` count = 0).

### Step 3.2: Fixes: tag
**Record:** N/A — no Fixes: tag.

### Step 3.3: Related file history
**Record:**
- `git log v6.18..HEAD -- drivers/media/v4l2-core/v4l2-common.c`: only
  `2b2a17af8d8c7` (YUV24 format info) — unrelated.
- Fix commit on mainline: `0b42657bea6ba635226e8ef551076d024ceacdc9`
  (2026-03-31).
- Standalone; not part of a multi-patch series.

### Step 3.4: Author context
**Record:** Paul Cercueil — regular media contributor. Hans Verkuil
merged. Mehdi Djait (Intel) reviewed. No other related commits from this
author visible in this tree’s shallow history.

### Step 3.5: Dependencies
**Record:** None. Self-contained; no prerequisite commits. Applies
cleanly to current `v4l2-common.c` in this tree (buggy code confirmed at
lines 767–774).

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Original discussion
**Record:**
- `b4 dig -c 0b42657bea6b`:
  https://patch.msgid.link/20260331084340.67613-1-paul@crapouillou.net
- Series: v1 (2026-03-27) → v2 (2026-03-27, adds clock id to name) → v3
  (2026-03-31, adds NULL-id support). Committed version is v3.
- No stable nomination found in thread.
- No NAKs found in mbox.

### Step 4.2: Reviewers
**Record:** `b4 dig -w`: To/Cc includes Mauro Chehab, Mehdi Djait,
Laurent Pinchart, linux-media, linux-kernel.

### Step 4.3: Bug report
**Record:** No external bug report. Author describes a concrete dual-
sensor scenario.

### Step 4.4: Related patches
**Record:** Helper introduced by the large “Add a helper for obtaining
the clock producer” series (landed in 6.18). This fix is a follow-up to
that introduction.

### Step 4.5: Stable list history
**Record:** Not searched separately; no stable discussion found in patch
thread.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key functions
**Record:** `__devm_v4l2_sensor_clk_get()` — wrappers
`devm_v4l2_sensor_clk_get()` and `devm_v4l2_sensor_clk_get_legacy()`.

### Step 5.2: Callers
**Record:** 40+ camera sensor drivers call this helper. **13 drivers**
pass a non-NULL string id and are affected on the dummy-clock path,
including:
- `ov5693.c` (`"xvclk"`), `ov5640.c` (`"xclk"`), `ov7740.c` (`"xvclk"`),
  `imx296.c` (`"inck"`), etc.
- Additional drivers use `devm_v4l2_sensor_clk_get_legacy()` with non-
  NULL ids (`ov8856.c`, `ov5695.c`, etc.).
- Many drivers pass `NULL` — already worked before this fix.

### Step 5.3: Callees
**Record:** `devm_clk_get_optional()`, `device_property_read_u32("clock-
frequency")`, `devm_clk_hw_register_fixed_rate()`, `kasprintf()`.

### Step 5.4: Reachability
**Record:**
1. I2C/ACPI camera sensor probes during boot or module load.
2. `devm_clk_get_optional()` returns NULL (no explicit clock provider —
   typical ACPI path).
3. `CONFIG_COMMON_CLK` enabled, platform is non-OF or legacy mode.
4. `clock-frequency` property present.
5. Second identical sensor → name collision → `-EEXIST` → probe failure.

Example from `ov5693.c`:

```1292:1296:drivers/media/i2c/ov5693.c
        ov5693->xvclk = devm_v4l2_sensor_clk_get(&client->dev, "xvclk");
        if (IS_ERR(ov5693->xvclk))
                return dev_err_probe(&client->dev,
PTR_ERR(ov5693->xvclk),
                                     "failed to get xvclk: %ld\n",
                                     PTR_ERR(ov5693->xvclk));
```

Userspace cannot directly trigger this, but it is a normal boot-time
hardware path on ACPI dual-camera systems.

### Step 5.5: Similar patterns
**Record:** NULL-`id` path already used device-specific naming
(`"clk-%s"`). Fix extends the same pattern to non-NULL ids — consistent
with existing design intent.

---

## PHASE 6: CROSS-REFERENCE WITH LOCAL TREE (6.18.43)

### Step 6.1: Buggy code present?
**Record:** **YES.** Current tree at lines 767–774 has the pre-fix
logic. Confirmed identical in `v6.18.0`. Helper absent in v6.17 — bug
introduced with the helper in 6.18.

### Step 6.2: Backport complications
**Record:** **Clean apply expected.** Only the naming block changes;
surrounding function matches the patch context. One unrelated commit
(`YUV24 format info`) since v6.18.0 in this file.

### Step 6.3: Related fixes already present?
**Record:** **No.** `git log --grep="device-specific name"` returned
nothing. Fix not in this tree.

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem criticality
**Record:** **drivers/media** — IMPORTANT, driver-specific. Affects ACPI
camera sensor users, not the whole kernel.

### Step 7.2: Activity
**Record:** `devm_v4l2_sensor_clk_get` is new in 6.18 (large driver
conversion series). Active development area with a bug shipped from
initial release.

---

## PHASE 8: IMPACT AND RISK

### Step 8.1: Who is affected
**Record:** ACPI (and some legacy) platforms with **two or more
instances of the same camera sensor driver** where the dummy fixed-clock
path is used and the driver passes a non-NULL clock id. Config:
`CONFIG_MEDIA_SUPPORT`, `CONFIG_COMMON_CLK`, relevant sensor drivers
built-in or as modules.

### Step 8.2: Trigger conditions
**Record:** Moderately narrow but realistic — dual front/rear camera
with same sensor model on ACPI laptops/tablets. Not every boot (single-
camera systems unaffected). Not userspace-triggerable.

### Step 8.3: Failure severity
**Record:** **Probe failure** for the second sensor (`-EEXIST` →
`dev_err_probe`). No kernel oops/panic, no data corruption, no security
impact. **Severity: MEDIUM** — hardware does not work, system remains
stable.

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** Enables dual-camera ACPI systems that are broken in all
  6.18.y releases shipped so far; fixes a bug present since 6.18.0.
- **Risk:** Very low — 7-line naming change, reviewed, no API impact.
- **Ratio:** Favorable for **6.18.y** specifically, where the helper and
  bug both exist.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence summary

**FOR backport:**
- Real, reproducible probe failure on dual-sensor ACPI systems
- Bug shipped in 6.18.0 and present in 6.18.43
- Small, obviously correct, reviewed fix
- 13+ sensor drivers use non-NULL ids on the affected path
- No dependencies; clean apply
- Hardware-enablement fix (similar category to quirks/workarounds)

**AGAINST backport:**
- Not a crash, deadlock, corruption, or security issue
- Narrow trigger: ACPI + dual same sensor + non-NULL id + dummy clock
  path
- Many drivers pass NULL (already worked)
- No user/syzbot report; no explicit stable nomination

**Unresolved:** No specific hardware platform named in the commit or
mailing list thread.

### Step 9.2: Stable rules checklist

| Criterion | Result |
|-----------|--------|
| 1. Obviously correct and tested? | **PASS** — simple naming logic,
Reviewed-by from Intel media developer |
| 2. Fixes a real user-affecting bug? | **PASS** — second camera probe
fails on dual-sensor ACPI systems |
| 3. Important issue? | **PASS (borderline)** — hardware probe failure,
not crash/corruption; important for affected dual-camera platforms |
| 4. Small and contained? | **PASS** — 1 file, ~7 net lines |
| 5. No new features/APIs? | **PASS** — internal clock naming only |
| 6. Applies to this tree? | **PASS** — buggy code confirmed in 6.18.43;
helper absent in older series |

### Step 9.3: Exception category
**Record:** Hardware workaround / multi-instance enablement — analogous
to quirks that fix broken multi-device behavior.

### Step 9.4: Decision rationale
For **this 6.18.43 tree**, the `devm_v4l2_sensor_clk_get` helper was
introduced in 6.18 with a naming bug that breaks dual instances of the
same sensor on ACPI platforms. The fix is minimal, low-risk, and self-
contained. While severity is medium rather than critical, stable 6.18.y
is the correct place to fix a defect that has been present since the
helper’s initial release. Older stable series (e.g. 6.12.y) do not have
this code and are out of scope for this tree-specific verdict.

---

## Verification

- **[Phase 1]** Parsed subject, tags (Reviewed-by: Mehdi Djait; no
  Fixes/Reported-by/Link)
- **[Phase 2]** Diff analysis: naming logic in
  `__devm_v4l2_sensor_clk_get()`, +7/−6 lines
- **[Phase 3]** `git describe HEAD`: v6.18.43; `make kernelversion`:
  6.18.43
- **[Phase 3]** `git blame` lines 767–774: pre-fix code present
- **[Phase 3]** `git show v6.18:...`: identical buggy code in 6.18.0
- **[Phase 3]** `git show v6.17:...`: helper absent (count 0)
- **[Phase 3]** `git log v6.18..HEAD -- v4l2-common.c`: only unrelated
  YUV24 commit
- **[Phase 4]** `b4 dig -c 0b42657bea6b`: lore URL found
- **[Phase 4]** `b4 dig -a`: v1→v2→v3 series; v3 is committed version
- **[Phase 4]** `b4 dig -w`: maintainers CC'd
- **[Phase 4]** mbox grep: Reviewed-by only; no stable nomination or NAK
- **[Phase 5]** `grep devm_v4l2_sensor_clk_get`: 40+ callers; 13 with
  non-NULL string id
- **[Phase 5]** Read `ov5693.c:1292-1296`: probe fails on clock error
- **[Phase 5]** Read `clk.c:3910-3914`: duplicate name returns `-EEXIST`
- **[Phase 6]** Read current `v4l2-common.c:767-774`: buggy code
  confirmed
- **[Phase 6]** `git merge-base --is-ancestor v6.18 HEAD`: v6.18 is
  ancestor
- **[Phase 8]** Failure mode: probe failure, severity MEDIUM

**YES**The analysis is complete for **Linux 6.18.43**.

**Verdict: backport this fix.**

The bug is in `__devm_v4l2_sensor_clk_get()` since 6.18.0: when a dummy
fixed clock is registered with a non-NULL `id` (e.g. `"xvclk"`), two
instances of the same sensor driver collide on the global clock name and
the second probe fails with `-EEXIST`. The patch is small (about 7
lines), low risk, and applies cleanly to this tree.

**YES**The history search finished. Repo-wide `git log -S
"__devm_v4l2_sensor_clk_get"` didn’t add anything beyond what we already
had: in this checkout the helper shows up with the 6.18 release, and it
isn’t present in v6.17. That matches the earlier conclusion — the bug
exists in 6.18.43 and the fix is worth backporting.

**YES**The `devm_clk_hw_register_fixed_rate` history search finished. In
this tree it only ties back to the `__devm_v4l2_sensor_clk_get()` dummy-
clock path introduced in 6.18 — nothing that changes the backport call.
Verdict remains **YES**.

 drivers/media/v4l2-core/v4l2-common.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
index c1e3bcb4c1c40..524c11e92aec5 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -764,14 +764,15 @@ struct clk *__devm_v4l2_sensor_clk_get(struct device *dev, const char *id,
 	if (ret)
 		return ERR_PTR(ret == -EINVAL ? -EPROBE_DEFER : ret);
 
-	if (!id) {
+	if (id)
+		clk_id = kasprintf(GFP_KERNEL, "clk-%s-%s", dev_name(dev), id);
+	else
 		clk_id = kasprintf(GFP_KERNEL, "clk-%s", dev_name(dev));
-		if (!clk_id)
-			return ERR_PTR(-ENOMEM);
-		id = clk_id;
-	}
 
-	clk_hw = devm_clk_hw_register_fixed_rate(dev, id, NULL, 0, rate);
+	if (!clk_id)
+		return ERR_PTR(-ENOMEM);
+
+	clk_hw = devm_clk_hw_register_fixed_rate(dev, clk_id, NULL, 0, rate);
 	if (IS_ERR(clk_hw))
 		return ERR_CAST(clk_hw);
 
-- 
2.53.0

[PATCH AUTOSEL 6.18] media: chips-media: wave5: Release m2m_ctx after Instance Removed from List

[Sasha Levin]

From: Brandon Brnich <b-brnich@ti.com>

[ Upstream commit 7cdbd7bb21949a8fda10c7104a2b12ee363cbf5c ]

Possible use after free if IRQ thread manages to obtain spinlock between
m2m_ctx release and wave5_release function removing stream instance from
list of active instances. The IRQ thread looks for the m2m_ctx which is
freed so null pointer dereference occurs.

Signed-off-by: Brandon Brnich <b-brnich@ti.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Tested-by: Jackson Lee <jackson.lee@chipsnmedia.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Connection lost, reconnecting to https://agentn.us.api5.cursor.sh
(attempt 1)...
Retry attempt 1...
## Phase 1: Commit Message Forensics

### Step 1.1: Subject line
**Record:** `[media: chips-media: wave5]` `[Release]` — reorder
`m2m_ctx` release so it happens after the instance is removed from the
active-instances list.

### Step 1.2: Tags
**Record:**
- **Fixes:** — not present (expected for manual review)
- **Reported-by:** — none
- **Tested-by:** Jackson Lee `<jackson.lee@chipsnmedia.com>`
- **Reviewed-by:** Nicolas Dufresne `<nicolas.dufresne@collabora.com>`
- **Signed-off-by:** Brandon Brnich, Nicolas Dufresne, Hans Verkuil
- **Cc: stable:** — not present (not a negative signal)
- **Link:** — none

Notable: subsystem maintainer review (Dufresne), media maintainer merge
(Verkuil), hardware-vendor testing (Jackson Lee at Chips&Media).

### Step 1.3: Body analysis
**Record:**
- **Bug:** Use-after-free / NULL dereference race during device release.
- **Symptom:** IRQ thread can still find the instance in
  `dev->instances` and call `finish_process()`, which dereferences
  `inst->v4l2_fh.m2m_ctx`, after `v4l2_m2m_ctx_release()` has already
  `kfree()`'d that object.
- **Root cause:** `v4l2_m2m_ctx_release()` was called before
  `list_del_init(&inst->list)`, leaving a window where the instance
  remains visible to the IRQ thread but its `m2m_ctx` is already freed.
- **Version info:** none in message.

### Step 1.4: Hidden bug fix?
**Record:** No — this is an explicit concurrency/lifetime-ordering bug
fix, not disguised cleanup.

---

## Phase 2: Diff Analysis

### Step 2.1: Inventory
**Record:**
- **Files:** `drivers/media/platform/chips-media/wave5/wave5-helper.c`
  (+3 / −1)
- **Function:** `wave5_vpu_release_device()`
- **Scope:** single-file, surgical reorder

### Step 2.2: Code flow change
**Record:**
- **Before:** `v4l2_m2m_ctx_release()` → take `irq_lock` →
  `list_del_init()` → unlock → `close_func()` →
  `wave5_cleanup_instance()`
- **After:** take `irq_lock` → `list_del_init()` → unlock →
  `v4l2_m2m_ctx_release()` → `close_func()` → `wave5_cleanup_instance()`
- **Path affected:** `release()` on decoder/encoder file descriptors
  (normal teardown, not init)

### Step 2.3: Bug mechanism
**Record:** **Category:** race condition / use-after-free (reference-
counting/lifetime ordering).

Mechanism verified in code:
1. `v4l2_m2m_ctx_release()` calls `kfree(m2m_ctx)`
   (`v4l2-mem2mem.c:1275`) but does not clear `inst->v4l2_fh.m2m_ctx`.
2. IRQ thread (`wave5-vpu.c:126-136`, `173-183`) holds `dev->irq_lock`,
   walks `dev->instances`, and calls `inst->ops->finish_process(inst)`.
3. `wave5_vpu_dec_finish_decode()` / encoder equivalent immediately does
   `m2m_ctx = inst->v4l2_fh.m2m_ctx` and uses it (`wave5-vpu-
   dec.c:344`).
4. With the old order, between `v4l2_m2m_ctx_release()` and
   `list_del_init()`, the instance is still on the list while `m2m_ctx`
   is freed → UAF.

### Step 2.4: Fix quality
**Record:** Obviously correct — IRQ paths only iterate listed instances;
releasing `m2m_ctx` only after `list_del_init()` under the same
`irq_lock` closes the race. Minimal change. Low regression risk.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame
**Record:** `wave5_vpu_release_device()` originates from
`19eef1d98eeda`. Locking + early `list_del_init()` added by
`ea316b784fe6a` (Nov 2025 upstream, Mar 2026 in this tree). Buggy
`v4l2_m2m_ctx_release()` placement introduced with `ea316b784fe6a`.

### Step 3.2: Fixes: tag
**Record:** N/A — no `Fixes:` tag. Bug introduced as incomplete fix in
`ea316b784fe6a`, which is present in this tree.

### Step 3.3: Related commits
**Record:**
- `ea316b784fe6a` — prerequisite IRQ locking refactor (present in tree)
- `789e6d8e630c4` / upstream `7cdbd7bb2194` — this fix (not in HEAD)
- Part of a 2-patch series; patch 2/2 is an independent lockdep fix in
  `wave5-vpu-dec.c`, not required for this reorder to work

### Step 3.4: Author context
**Record:** Brandon Brnich (TI). Related wave5 work from same ecosystem
(Jackson Lee, Chips&Media). Hans Verkuil is V4L/media maintainer.

### Step 3.5: Dependencies
**Record:** Requires `ea316b784fe6a` infrastructure (`irq_lock`,
`irq_spinlock`, `list_del_init()` in release path). That commit **is**
an ancestor of HEAD. Patch applies cleanly (`git apply --check` passed).
Standalone for its purpose.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original discussion
**Record:**
- **URL:**
  https://patch.msgid.link/20260402184554.1751445-1-b-brnich@ti.com
- **Series:** v1 only for patch 1/2
- **Reviewer feedback:** Nicolas Dufresne `Reviewed-by` on list
- **Stable nomination:** none found in thread
- **NAKs:** none found

### Step 4.2: Reviewers
**Record:** CC'd: `mchehab@kernel.org`,
`nicolas.dufresne@collabora.com`, `jackson.lee@chipsnmedia.com`, `linux-
media@vger.kernel.org`

### Step 4.3: Bug report
**Record:** No external bug report or syzbot link. Bug class inferred
from code + prior fluster-test crashes fixed by `ea316b784fe6a`.

### Step 4.4: Related patches
**Record:** Patch 2/2 fixes lockdep issues in
`handle_dynamic_resolution_change` / `initialize_sequence` — separate
concern.

### Step 4.5: Stable list
**Record:** Not searched on lore stable (Anubis blocked direct fetch).
No stable-thread evidence found in mbox.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key functions
**Record:** `wave5_vpu_release_device()`, `wave5_vpu_irq_thread()`,
`irq_thread()`, `wave5_vpu_dec_finish_decode()`,
`wave5_vpu_enc_finish_encode()`

### Step 5.2: Callers
**Record:**
- `wave5_vpu_release_device()` ← `wave5_vpu_dec_release()` /
  `wave5_vpu_enc_release()` (V4L2 `release` file ops)
- IRQ thread ← hardware IRQ or polling thread on `CONFIG_VIDEO_WAVE_VPU`
  devices

### Step 5.3: Callees
**Record:** `v4l2_m2m_ctx_release()` → `v4l2_m2m_cancel_job()`,
`vb2_queue_release()`, `kfree(m2m_ctx)`

### Step 5.4: Reachability
**Record:** Userspace opens `/dev/video*`, streams decode/encode, closes
fd → `release()` path. Concurrent VPU interrupts are normal during
streaming. **Reachable from userspace** on K3 platforms with wave5
hardware.

### Step 5.5: Similar patterns
**Record:** `ea316b784fe6a` fixed a related NULL-deref race in the same
driver by adding IRQ locking; this commit completes that work by fixing
teardown ordering.

---

## Phase 6: Cross-Reference Against Local Tree

### Step 6.1: Buggy code in tree?
**Record:** **YES.** Local tree is **Linux 6.18.43** (`git describe`:
`v6.18.43-1-gc7f0dac02d232`). Current `wave5-helper.c:71` still calls
`v4l2_m2m_ctx_release()` before `list_del_init()`. Fix commit
`789e6d8e630c4` is **not** an ancestor of HEAD.

### Step 6.2: Backport complications
**Record:** **Clean apply** — `git apply --check` on upstream diff
succeeded with no conflicts.

### Step 6.3: Related fixes already present?
**Record:** `ea316b784fe6a` (prerequisite locking) is present. This
specific reorder is **not** present.

---

## Phase 7: Subsystem and Maintainer Context

### Step 7.1: Subsystem criticality
**Record:** `drivers/media/platform/chips-media/wave5` — **PERIPHERAL**
(TI K3 SoC video codec, `CONFIG_VIDEO_WAVE_VPU`, `depends on ARCH_K3 ||
COMPILE_TEST`).

### Step 7.2: Activity
**Record:** Active — multiple wave5 fixes in recent history on this
branch (null-ref fix, panic fixes, spinlock additions).

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who is affected
**Record:** Users of Chips&Media WAVE5 VPU on TI K3 platforms running
hardware decode/encode.

### Step 8.2: Trigger conditions
**Record:** Close V4L2 device while decode/encode interrupts are still
being serviced — especially multi-instance stress (fluster tests).
Timing-dependent but realistic during normal streaming teardown.

### Step 8.3: Failure mode severity
**Record:** UAF / NULL deref in IRQ thread → kernel oops/panic.
**Severity: HIGH** (system crash).

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** HIGH for affected hardware users — prevents crash on
  device close
- **Risk:** VERY LOW — 3-line reorder, no API changes
- **Ratio:** Strongly favors backport

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence summary

**FOR backport:**
- Real UAF race with kernel crash consequence
- Small, obviously correct fix
- Reviewed by subsystem expert, tested by hardware vendor
- Prerequisite commit present in 6.18.43
- Applies cleanly
- Completes incomplete fix from `ea316b784fe6a`

**AGAINST backport:**
- Driver-specific (not universal)
- No syzbot/user bugzilla report
- Commit message incorrectly says "spinlock" (IRQ thread uses `mutex`,
  not spinlock) — cosmetic only

**Unresolved:** Whether patch 2/2 (lockdep) should also be backported —
separate issue, not required for this fix.

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** (Reviewed-by, Tested-by, code-
   verified ordering)
2. Fixes real bug? **PASS**
3. Important issue? **PASS** (crash/oops on device close)
4. Small and contained? **PASS** (4 lines, 1 file)
5. No new features/APIs? **PASS**
6. Can apply to local tree? **PASS** (clean apply, prerequisite present)

### Step 9.3: Exception categories
**Record:** None — standard bug fix.

### Step 9.4: Decision rationale

This tree (6.18.43) contains the IRQ-thread instance-list infrastructure
from `ea316b784fe6a` but still releases `m2m_ctx` before removing the
instance from the list. That leaves a verified race window where the IRQ
thread can call `finish_process()` on a freed `m2m_ctx`. The fix is
minimal, correct, reviewed, and applies cleanly. It should be backported
to this stable tree.

---

## Verification

- **[Phase 1]** Parsed commit message and tags from user-provided diff
  and `git show 789e6d8e630c4`
- **[Phase 2]** Read `wave5-helper.c`, `wave5-vpu.c`, `wave5-vpu-dec.c`,
  `v4l2-mem2mem.c` — confirmed UAF mechanism
- **[Phase 3]** `git blame` on `wave5-helper.c:63-110` — buggy order
  from `ea316b784fe6a`
- **[Phase 3]** `git merge-base --is-ancestor ea316b784fe6a HEAD` → exit
  0 (prerequisite present)
- **[Phase 3]** `git merge-base --is-ancestor 789e6d8e630c4 HEAD` → exit
  1 (fix NOT in HEAD)
- **[Phase 3]** `git log -20 -- drivers/media/platform/chips-
  media/wave5/` — related fix history
- **[Phase 4]** `b4 dig -c 789e6d8e630c4` →
  https://patch.msgid.link/20260402184554.1751445-1-b-brnich@ti.com
- **[Phase 4]** `b4 dig -w` — maintainers CC'd (mchehab, dufresne,
  jackson.lee)
- **[Phase 4]** `b4 dig -a` — v1 series; patch 2/2 is separate lockdep
  fix
- **[Phase 4]** Read `/tmp/wave5_m2m_thread.mbox` — Dufresne Reviewed-
  by, no NAKs
- **[Phase 5]** `grep finish_process` — IRQ thread →
  `wave5_vpu_dec_finish_decode` uses `m2m_ctx`
- **[Phase 6]** `git describe HEAD` → v6.18.43; buggy code at
  `wave5-helper.c:71`
- **[Phase 6]** `git apply --check` on upstream diff → clean apply
- **[Phase 7]** Read `wave5/Kconfig` — `ARCH_K3 || COMPILE_TEST`
- **[Phase 8]** Failure mode: UAF in IRQ thread during release → oops,
  severity HIGH

**YES**The background check finished: **`789e6d8e630c4` is not in this
tree’s HEAD** (`git merge-base --is-ancestor` returned exit 1), so the
reorder fix is still missing on **6.18.43**.

The prerequisite **`ea316b784fe6a`** (IRQ locking / early
`list_del_init`) **is** present, and the patch still **applies
cleanly**.

**Verdict for this tree: YES** — backport the commit; it closes a real
UAF/oops race when closing a wave5 V4L2 instance while the IRQ thread is
still processing it.

 drivers/media/platform/chips-media/wave5/wave5-helper.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/chips-media/wave5/wave5-helper.c b/drivers/media/platform/chips-media/wave5/wave5-helper.c
index 53a0ac068c2e2..c3d34be833ff0 100644
--- a/drivers/media/platform/chips-media/wave5/wave5-helper.c
+++ b/drivers/media/platform/chips-media/wave5/wave5-helper.c
@@ -68,7 +68,6 @@ int wave5_vpu_release_device(struct file *filp,
 	int ret = 0;
 	unsigned long flags;
 
-	v4l2_m2m_ctx_release(inst->v4l2_fh.m2m_ctx);
 	/*
 	 * To prevent Null reference exception, the existing irq handler were
 	 * separated to two modules.
@@ -89,6 +88,9 @@ int wave5_vpu_release_device(struct file *filp,
 	list_del_init(&inst->list);
 	spin_unlock_irqrestore(&inst->dev->irq_spinlock, flags);
 	mutex_unlock(&inst->dev->irq_lock);
+
+	v4l2_m2m_ctx_release(inst->v4l2_fh.m2m_ctx);
+
 	if (inst->state != VPU_INST_STATE_NONE) {
 		u32 fail_res;
 
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] media: rc: mceusb: Add support for 04eb:e033

[Sasha Levin]

From: Riccardo Boninsegna <rboninsegna2@gmail.com>

[ Upstream commit 0692c2602e4cd410aa045f8991bd1c142b2e56f9 ]

This is a Sonix SN8P2202XG microcontroller with firmware compatible with
the already supported Northstar 04eb:e004, implementing an MCE IR receiver
(PCB seems to be tracked for a transmitter too but missing related parts).

Found in a Skintek SK-CR-IN+IR ( http://www.skintek.it/SK-CR-IN+IR.php )
internal 3.5 inch USB card reader and MCE receiver combo
(implemented by, and wired as, separate USB devices)
PCB marking: AU6475 966816 STIR REV:A02 MCE

Signed-off-by: Riccardo Boninsegna <rboninsegna2@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

### Step 1.1: Parse the Subject Line
**Record:** `[media: rc: mceusb]` `[Add]` `USB device ID 04eb:e033 to
the existing mceusb IR transceiver driver`

### Step 1.2: Parse All Commit Message Tags
**Record:**
- **Fixes:** none
- **Reported-by:** none
- **Tested-by:** none
- **Reviewed-by:** none
- **Acked-by:** none
- **Link:** none (hardware product page in body only:
  http://www.skintek.it/SK-CR-IN+IR.php)
- **Cc: stable@vger.kernel.org:** none (expected; not a negative signal)
- **Signed-off-by:** Riccardo Boninsegna `<rboninsegna2@gmail.com>`
  (author)
- **Signed-off-by:** Sean Young `<sean@mess.org>` (media/rc maintainer
  co-signer — quality signal)

**Notable patterns:** Maintainer Signed-off-by; no syzbot/sanitizer
reports; hardware-specific enablement patch.

### Step 1.3: Analyze Commit Body
**Record:**
- **Bug described:** USB device `04eb:e033` (Sonix SN8P2202XG,
  Northstar-variant MCE IR receiver) is not recognized by `mceusb`
  because its product ID is missing from `mceusb_dev_table[]`.
- **Symptom:** IR receiver on Skintek SK-CR-IN+IR internal card reader
  does not bind to `mceusb`; remote control input unavailable.
- **Version info:** none stated.
- **Root cause (author):** Firmware-compatible variant of already-
  supported `04eb:e004`; only the USB product ID differs.

### Step 1.4: Detect Hidden Bug Fixes
**Record:** Not a crash/leak/race fix. This is explicit **hardware
enablement** via a missing USB ID — a recognized stable exception
category, not a disguised memory-safety fix.

---

## Phase 2: Diff Analysis

### Step 2.1: Inventory the Changes
**Record:**
- **Files:** `drivers/media/rc/mceusb.c` only (+2 lines net in the ID
  table)
- **Functions modified:** none (only `mceusb_dev_table[]` static data)
- **Scope:** single-file, surgical USB ID table addition

### Step 2.2: Code Flow Change
**Record:**
- **Before:** USB probe matches `04eb:e004` only for Northstar vendor;
  `04eb:e033` does not match → no `mceusb` bind.
- **After:** `04eb:e033` matches the same way as `04eb:e004` →
  `mceusb_dev_probe()` runs on plug-in.
- **Path affected:** USB hotplug / enumeration normal path for this
  device class.

### Step 2.3: Bug Mechanism
**Record:**
- **Category:** hardware workarounds / device ID addition
- **Mechanism:** Missing `USB_DEVICE(VENDOR_NORTHSTAR, 0xe033)` entry
  prevents driver binding. No `.driver_info` is set, so
  `id->driver_info` defaults to `0` (`MCE_GEN2`) — identical to the
  existing `0xe004` entry.

### Step 2.4: Fix Quality Assessment
**Record:**
- **Obviously correct:** yes — mirrors the adjacent `0xe004` entry;
  author documents firmware compatibility.
- **Minimal:** 2 lines.
- **Regression risk:** very low — only adds a new match; does not change
  probe logic, locking, or APIs.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame the Changed Lines
**Record:** In this checkout (`6.18.43`), `VENDOR_NORTHSTAR` / `0xe004`
are at lines 160 and 399. The `0xe033` entry is **not** present. The
Northstar `0xe004` entry exists in `stable/linux-6.18.y`. This tree’s
history is heavily squashed (many `mceusb.c` lines blame to unrelated
commits), so the original introduction commit of `0xe004` could not be
reliably dated here.

### Step 3.2: Follow Fixes: Tag
**Record:** N/A — no `Fixes:` tag.

### Step 3.3: File History for Related Changes
**Record:** Recent `drivers/media/rc/` stable commits include real bug
fixes (`e250b672d40a9` race fix, probe error-handling fixes), but no
prior `0xe033` addition. On `origin/master`, `0xe033` is already
present; on current HEAD it is not.

### Step 3.4: Author's Other Commits
**Record:** No commits from Riccardo Boninsegna found in this tree’s
history. Sean Young is the media/rc maintainer (Signed-off-by).

### Step 3.5: Dependent/Prerequisite Commits
**Record:** **No dependencies.** Requires only existing
`VENDOR_NORTHSTAR` define and `mceusb` driver — both present in
`6.18.y`. Standalone 2-line backport.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original Patch Discussion
**Record:** `b4 dig` could not be run — individual commit SHA not
available in this mirror (history squashed into merge commits).
`lore.kernel.org` returned **403 Forbidden**. `git.kernel.org` grep
confirmed subject `mceusb: Add support for 04eb:e033` exists on
mainline. Patchwork search returned only generic page scaffolding, no
detailed review thread retrieved.

### Step 4.2: Reviewers
**Record:** UNVERIFIED for mailing-list CC list. Sean Young (maintainer)
Signed-off-by in commit message.

### Step 4.3: Bug Report
**Record:** No formal bug report or syzbot link. Hardware identification
from author on Skintek SK-CR-IN+IR product.

### Step 4.4: Related Patches/Series
**Record:** Standalone 1-commit change; not part of a multi-patch
series.

### Step 4.5: Stable Mailing List History
**Record:** UNVERIFIED — lore stable list inaccessible (403).

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Functions
**Record:** No functions modified. Affected data: `mceusb_dev_table[]`.
Probe path: `mceusb_dev_probe()`.

### Step 5.2: Trace Callers
**Record:** `mceusb_dev_probe()` is registered as `.probe` in
`mceusb_dev_driver` and invoked by the USB core during device
enumeration when `usb_device_id` matches. Trigger: user plugs in the IR
receiver.

### Step 5.3: Trace Callees
**Record:** On successful match, probe allocates `mceusb_dev`, sets up
URBs, registers with `rc-core` — standard existing driver path unchanged
by this patch.

### Step 5.4: Call Chain / Reachability
**Record:** USB hotplug → `usb_driver.probe` → `mceusb_dev_probe()`.
Reachable by any user plugging in the device. Without the ID, the chain
never starts for `04eb:e033`.

### Step 5.5: Similar Patterns
**Record:** `0xe004` at line 399 uses the same pattern (no
`.driver_info`). Many other entries in `mceusb_dev_table[]` follow this
model.

---

## Phase 6: Cross-Referencing Against Local Tree

**Local tree:** `v6.18.43` (`VERSION=6`, `PATCHLEVEL=18`,
`SUBLEVEL=43`), detached from `stable/linux-6.18.y`.

### Step 6.1: Does the Buggy Code Exist?
**Record:** **Yes.** `drivers/media/rc/mceusb.c` exists with
`VENDOR_NORTHSTAR` (`0x04eb`) and `0xe004`, but **without** `0xe033`.
The omission is present in this tree.

### Step 6.2: Backport Complications
**Record:** **Clean apply.** `git apply --check` on the provided diff
succeeded with no conflicts. Insertion point is immediately after the
existing Northstar `0xe004` entry.

### Step 6.3: Related Fixes Already Present?
**Record:** No existing `0xe033` entry or equivalent fix found in HEAD
or `stable/linux-6.18.y` grep.

---

## Phase 7: Subsystem and Maintainer Context

### Step 7.1: Subsystem Criticality
**Record:** `drivers/media/rc/` — **PERIPHERAL** (USB IR remote
receiver). Not core kernel path, but affects real users with this
hardware.

### Step 7.2: Subsystem Activity
**Record:** `drivers/media/rc/` on `stable/linux-6.18.y` has recent
maintenance (race fixes, probe error handling), indicating active stable
care for this subsystem.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who Is Affected
**Record:** Users of the Skintek SK-CR-IN+IR (and any other product
using `04eb:e033` with MCE-compatible firmware). Config-dependent:
`CONFIG_IR_MCEUSB` (or module `mceusb`).

### Step 8.2: Trigger Conditions
**Record:** Plug in the `04eb:e033` USB IR device. Common for intended
hardware use. Unprivileged user can trigger by plugging in USB device.

### Step 8.3: Failure Mode Severity
**Record:** Without fix: device does not bind to `mceusb` → IR remote
control non-functional. **Severity: LOW** (functional/hardware
enablement, not crash/corruption/security).

### Step 8.4: Risk-Benefit Ratio
**Record:**
- **Benefit:** Enables a real, tested hardware variant; identical
  treatment to already-supported sibling ID.
- **Risk:** Very low — 2-line ID table addition, no logic change.
- **Ratio:** Strong benefit for affected users, negligible risk —
  classic stable device-ID backport.

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence Compile

**FOR backport:**
- Explicit stable exception: **new USB device ID** to existing driver
- Driver and sibling ID (`04eb:e004`) already in `6.18.y`
- Author documents firmware compatibility with supported device
- Maintainer Signed-off-by (Sean Young)
- 2-line, obviously correct, applies cleanly
- Already in mainline (`origin/master` has `0xe033`)
- No dependencies or API changes

**AGAINST backport:**
- Niche hardware (limited user base)
- Not a crash/security/corruption fix under strict reading of criterion
  #3
- No formal regression report or syzbot evidence
- Mailing-list review not fully verified (lore 403)

**UNRESOLVED:**
- Individual mainline commit SHA and full lore review thread
- Whether stable maintainers already discussed/nominated this specific
  ID

### Step 9.2: Stable Rules Checklist
1. **Obviously correct and tested?** **PASS** — mirrors existing
   `0xe004`; maintainer SOB; mainline inclusion.
2. **Fixes a real bug affecting users?** **PASS** — hardware does not
   work without driver binding.
3. **Important issue?** **PASS** (via device-ID exception) — functional
   hardware enablement for affected users; not crash-level, but
   explicitly covered by stable device-ID policy.
4. **Small and contained?** **PASS** — 2 lines, one file.
5. **No new features or APIs?** **PASS** — ID table only.
6. **Can apply to local tree?** **PASS** — verified with `git apply
   --check`.

### Step 9.3: Exception Category
**Record:** **NEW DEVICE IDs** — USB product ID addition to existing
`mceusb` driver. Driver exists; only the ID is new.

### Step 9.4: Decision Rationale
For **Linux 6.18.y** specifically: the `mceusb` driver is present, the
compatible sibling ID `04eb:e004` is already supported, and the missing
`04eb:e033` entry prevents a firmware-compatible variant from working.
This is a textbook, low-risk stable backport under the device-ID
exception.

---

## Verification

- **[Phase 1]** Parsed subject, tags, body; no Fixes/Reported-by/Link
  tags; Sean Young SOB confirmed.
- **[Phase 2]** Diff: +2 lines in `mceusb_dev_table[]`; no
  `.driver_info` → default `MCE_GEN2` (same as `0xe004`).
- **[Phase 3]** `git describe HEAD`: `v6.18.43`; `git blame`/`grep`:
  `0xe004` present, `0xe033` absent on HEAD.
- **[Phase 3]** `git grep "0xe033" origin/master --
  drivers/media/rc/mceusb.c`: present on mainline.
- **[Phase 3]** `git diff HEAD origin/master --
  drivers/media/rc/mceusb.c`: e033 addition is isolated 2-line hunk.
- **[Phase 3]** No prerequisite commits identified.
- **[Phase 4]** `b4 dig`: **UNVERIFIED** — commit SHA unavailable in
  squashed mirror.
- **[Phase 4]** lore.kernel.org: **403 Forbidden**.
- **[Phase 4]** git.kernel.org grep: subject `mceusb: Add support for
  04eb:e033` confirmed on mainline.
- **[Phase 4]** Patchwork: no detailed review thread retrieved.
- **[Phase 5]** `mceusb_dev_probe()` at line 1651; `.probe` in
  `mceusb_dev_driver` at line 1877.
- **[Phase 5]** Default model `MCE_GEN2` confirmed in `mceusb_model[]`
  at index 0.
- **[Phase 6]** `make kernelversion` equivalent: 6.18.43; tree is
  `stable/linux-6.18.y`.
- **[Phase 6]** `git apply --check` on provided diff: **succeeds**.
- **[Phase 6]** `CONFIG_IR_MCEUSB` exists in `drivers/media/rc/Kconfig`.
- **[Phase 8]** Failure mode: no driver bind → IR non-functional;
  severity LOW; risk VERY LOW.

**YES**The background kernel.org lookups finished:

- **Git grep** confirmed mainline has a commit titled `mceusb: Add
  support for 04eb:e033`.
- **Commit hash lookup** did not return a usable SHA for that patch
  (only unrelated HEAD patch metadata), so `b4 dig` and lore review stay
  unverified.

That does not change the earlier conclusion for **6.18.y**: this is a
small USB device-ID addition to an existing driver, it applies cleanly
next to the already-supported `04eb:e004` entry, and it should be
backported.

**YES**

 drivers/media/rc/mceusb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index a4c94fdf767ca..bee5cd15796fb 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -397,6 +397,8 @@ static const struct usb_device_id mceusb_dev_table[] = {
 	{ USB_DEVICE(VENDOR_COMPRO, 0x3082) },
 	/* Northstar Systems, Inc. eHome Infrared Transceiver */
 	{ USB_DEVICE(VENDOR_NORTHSTAR, 0xe004) },
+	/* Northstar Systems, Inc. eHome Infrared Transceiver - variant */
+	{ USB_DEVICE(VENDOR_NORTHSTAR, 0xe033) },
 	/* TiVo PC IR Receiver */
 	{ USB_DEVICE(VENDOR_TIVO, 0x2000),
 	  .driver_info = TIVO_KIT },
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.12] media: chips-media: wave5: Add range checks for dec_output_info

[Sasha Levin]

From: Ricardo Ribalda <ribalda@chromium.org>

[ Upstream commit 79aef69bb0903616f4867f0168aea717a11c439c ]

If the driver's dec_output_info contains invalid data the driver can
write in invalid memory. Add a range check for that.

This fixes this smatch error:
drivers/media/platform/chips-media/wave5/wave5-vpuapi.c:588 wave5_vpu_dec_get_output_info() error: buffer overflow 'inst->frame_buf' 64 <= 127

Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `media: chips-media: wave5: Add range checks
for dec_output_info`

**Local tree:** Linux **6.18.43** (`v6.18.43-1-gc7f0dac02d232`, branch
`stable/linux-6.18.y`)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
**Record:** `[media: chips-media: wave5]` `[Add]` — Add range checks for
`dec_output_info` in the Wave5 VPU decoder driver.

### Step 1.2: Tags
**Record:**
- **Signed-off-by:** Ricardo Ribalda `<ribalda@chromium.org>` (author)
- **Reviewed-by:** Nicolas Dufresne `<nicolas.dufresne@collabora.com>`
  (media subsystem reviewer)
- **Signed-off-by:** Hans Verkuil `<hverkuil+cisco@kernel.org>` (media
  maintainer)
- **No** Fixes:, Reported-by:, Tested-by:, Link:, or Cc: stable@ in the
  commit message itself
- Part of series `[PATCH v4 4/6] media: Fix new smatch warnings`; cover
  letter CC'd `stable@vger.kernel.org` and Greg Kroah-Hartman

### Step 1.3: Body Analysis
**Record:**
- **Bug:** `dec_output_info` can contain invalid index data; driver
  indexes `inst->frame_buf[]` without validating the computed index.
- **Symptom:** Out-of-bounds access on `inst->frame_buf` (smatch:
  `buffer overflow 'inst->frame_buf' 64 <= 127`).
- **Root cause:** Existing check bounds `index_frame_display` against
  `max_dec_index`, but the actual index is `num_of_decoding_fbs +
  index_frame_display` (fb_offset), which can exceed `MAX_REG_FRAME`
  (64).

### Step 1.4: Hidden Bug Fix?
**Record:** Yes — despite smatch-driven origin, this is a real bounds-
check bug fix, not cosmetic cleanup. The commit message explicitly
states invalid data can cause invalid memory access.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
**Record:**
- **File:** `drivers/media/platform/chips-media/wave5/wave5-vpuapi.c`
  (+9 / -2 lines)
- **Function:** `wave5_vpu_dec_get_output_info()`
- **Scope:** Single-file, surgical fix

### Step 2.2: Code Flow Change
**Record:**
- **Before:** `info->disp_frame = inst->frame_buf[val +
  info->index_frame_display]` when `index_frame_display <
  max_dec_index`.
- **After:** Computes `idx = val + info->index_frame_display`, validates
  `idx < MAX_REG_FRAME`, returns `-EINVAL` on failure, then assigns
  `inst->frame_buf[idx]`.
- **Path:** Normal decode output-info retrieval after firmware query.

### Step 2.3: Bug Mechanism
**Record:** **Buffer overflow / out-of-bounds access (memory safety).**
`frame_buf` has `MAX_REG_FRAME` (64) elements. Index uses fb_offset
(`num_of_decoding_fbs`) plus display index from firmware, but only the
display index was bounded — not the sum. Smatch correctly identified
index up to 127.

### Step 2.4: Fix Quality
**Record:** Obviously correct; matches existing patterns in the same
file (`reset_auxiliary_buffers()` line 189,
`wave5_vpu_dec_reset_framebuffer()` line 626). Minimal, uses existing
`err_out` path. Low regression risk.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
**Record:** Buggy line introduced when `wave5-vpuapi.c` entered this
tree (commit `5d324e5159d9e`, Nov 2025). Present since Wave5 driver
landed in 6.18.

### Step 3.2: Fixes: Tag
**Record:** N/A — no Fixes: tag in commit message.

### Step 3.3: File History
**Record:** Wave5 driver has had multiple stable-worthy fixes in 6.18.y
(panics, memory leaks, spinlock issues). This fix is not yet in the
tree. Part of a 6-patch smatch series, but each patch touches a
different file — **standalone**.

### Step 3.4: Author Context
**Record:** Ricardo Ribalda is an active media contributor (Chromium).
Hans Verkuil merged; Nicolas Dufresne reviewed.

### Step 3.5: Dependencies
**Record:** None. Patch 4/6 is self-contained; `MAX_REG_FRAME` and
`err_out` already exist in this tree. No prerequisite commits required.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Original Discussion
**Record:** Series cover at https://lists.openwall.net/linux-
kernel/2026/05/07/2079. Patch v4 submitted May 7, 2026; evolved v1→v4.
v2 note: removed `WARN_ON()` from user-triggerable paths; this patch
retains `WARN_ON()` because invalid data comes from firmware/hardware
registers, not direct userspace input.

### Step 4.2: Reviewers
**Record:** Cover CC'd Mauro Chehab, Hans Verkuil, Greg Kroah-Hartman,
linux-media@, stable@. Reviewed-by from Nicolas Dufresne; merged by Hans
Verkuil.

### Step 4.3: Bug Report
**Record:** Smatch static analysis finding; no syzbot or user crash
report. Cover letter classifies some warnings as "inoffensive" but
includes fixes for user-triggerable errors; this wave5 issue is a
genuine missing bounds check.

### Step 4.4: Related Patches
**Record:** Series has 5 other independent patches (v4l2-dev, mt9p031,
adv7604, ipu3-imgu, amlogic-c3). None required for this fix.

### Step 4.5: Stable List
**Record:** Cover letter explicitly CC'd `stable@vger.kernel.org`. No
objection found in available thread excerpts.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key Functions
**Record:** `wave5_vpu_dec_get_output_info()` modified.

### Step 5.2: Callers
**Record:**
- `wave5-vpu-dec.c:354` — `wave5_vpu_dec_finish_decode()` (normal decode
  completion)
- `wave5-vpu-dec.c:1407` — flush/stop path
- `wave5-vpu-dec.c:1499` — another decode path
- `wave5-vpuapi.c:82` — busy-retry during instance flush

All are active V4L2 mem2mem decode paths.

### Step 5.3: Callees
**Record:** Calls `wave5_vpu_dec_get_result()` which reads
`W5_RET_DEC_DISPLAY_INDEX` from VPU hardware (line 1059–1060 in
`wave5-hw.c`). `index_frame_display` is firmware-provided.

### Step 5.4: Reachability
**Record:** Reachable during video decode on systems with
`CONFIG_VIDEO_WAVE_VPU` (ARCH_K3 or COMPILE_TEST). Users with access to
`/dev/video*` can trigger decode operations; malformed streams or
firmware edge cases can produce bad indices.

### Step 5.5: Similar Patterns
**Record:** Same file already bounds-checks `index >= MAX_REG_FRAME` in
`reset_auxiliary_buffers()` and `wave5_vpu_dec_reset_framebuffer()`.
This fix closes a gap in `wave5_vpu_dec_get_output_info()`.

---

## PHASE 6: CROSS-REFERENCE WITH LOCAL TREE

### Step 6.1: Buggy Code Present?
**Record:** **Yes.** At lines 561–563 in this tree:

```561:563:drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
        if (info->index_frame_display >= 0 &&
            info->index_frame_display < (int)max_dec_index)
                info->disp_frame = inst->frame_buf[val +
info->index_frame_display];
```

Fix is **not** yet applied. Wave5 driver present since 6.18.

### Step 6.2: Backport Complications
**Record:** Clean apply expected — 9-line hunk, no structural conflicts.
`MAX_REG_FRAME` defined as `WAVE5_MAX_FBS * 2` (= 64) in
`wave5-vpuapi.h:47`.

### Step 6.3: Related Fixes Already Present?
**Record:** No equivalent bounds check for this access path. Other wave5
stable fixes exist but not this one.

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem
**Record:** `drivers/media/platform/chips-media/wave5/` — V4L2 hardware
video codec driver. **Criticality: IMPORTANT** (peripheral driver, but
memory-safety bugs in kernel drivers are serious).

### Step 7.2: Activity
**Record:** Actively maintained in 6.18.y with multiple bugfix commits
since initial merge.

---

## PHASE 8: IMPACT AND RISK

### Step 8.1: Who Is Affected
**Record:** Users of TI K3 (and COMPILE_TEST) systems with Chips&Media
Wave5 VPU (`CONFIG_VIDEO_WAVE_VPU`). Not universal, but real production
hardware.

### Step 8.2: Trigger Conditions
**Record:** During decode when firmware returns display index data that
passes the incomplete `max_dec_index` check but produces `idx >=
MAX_REG_FRAME`. Possible with firmware edge cases, resolution changes,
or error recovery. Not every boot, but reachable in normal decode
operation.

### Step 8.3: Failure Mode
**Record:** Out-of-bounds read of `struct frame_buffer` from kernel
stack/static data → kernel oops/panic or memory corruption. **Severity:
HIGH** (memory safety in kernel context).

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** HIGH for affected hardware — prevents OOB kernel memory
  access
- **Risk:** VERY LOW — 7-line bounds check, consistent with existing
  code, reviewed by subsystem maintainer
- **Ratio:** Strongly favors backport

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backport:**
- Real out-of-bounds array access bug (smatch-verified)
- Fixes potential kernel crash/memory corruption
- Small, surgical, obviously correct
- Reviewed by Nicolas Dufresne; merged by Hans Verkuil
- Standalone — no series dependencies
- Buggy code exists in this 6.18.43 tree; fix not yet applied
- Cover letter CC'd stable@
- Consistent with existing `MAX_REG_FRAME` checks in same driver

**AGAINST backport:**
- Driver is platform-specific (K3), not all users affected
- Trigger requires firmware returning bad index data (not directly
  proven in field)
- Smatch-driven, not syzbot/user-reported crash
- Retains `WARN_ON()` (acceptable for firmware-provided data per series
  rationale)

**Unresolved:** No runtime crash report verified; impact inferred from
static analysis and code review.

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — logic is clear; Reviewed-by
   present; smatch warning resolved
2. Fixes a real bug? **PASS** — missing bounds check on kernel array
   access
3. Important issue? **PASS** — OOB kernel memory access (HIGH severity)
4. Small and contained? **PASS** — 1 file, ~9 lines
5. No new features/APIs? **PASS** — defensive bounds check only
6. Can apply to local tree? **PASS** — driver and all symbols exist;
   clean apply expected

### Step 9.3: Exception Category
**Record:** Not a device ID/quirk/DT/build/docs exception — standard
memory-safety bug fix.

### Step 9.4: Decision Rationale
This commit closes a genuine bounds-check gap in
`wave5_vpu_dec_get_output_info()`. The Wave5 driver exists in Linux
6.18.y, the buggy code is present, and the fix is minimal, reviewed, and
standalone. For users decoding video on K3 hardware with the Wave5 VPU,
an out-of-bounds access on `inst->frame_buf[]` can cause kernel crashes
or memory corruption. The fix aligns with existing `MAX_REG_FRAME`
checks elsewhere in the driver and carries negligible regression risk.

---

## Verification

- [Phase 1] Parsed subject, tags: Reviewed-by Nicolas Dufresne, SOB Hans
  Verkuil; no Fixes/Reported-by
- [Phase 1] Commit body: smatch OOB on `inst->frame_buf` 64 <= 127
- [Phase 2] Diff: +9/-2 in `wave5_vpu_dec_get_output_info()`, adds `idx`
  bounds check against `MAX_REG_FRAME`
- [Phase 3] `git describe HEAD`: v6.18.43-1-gc7f0dac02d232 (6.18.43)
- [Phase 3] `git blame`: buggy line from driver introduction in this
  tree
- [Phase 3] No Fixes: tag; no prerequisite commits identified
- [Phase 3] `git log --oneline -20 -- wave5-vpuapi.c`: multiple wave5
  fixes; this one not present
- [Phase 4] Cover letter at lists.openwall.net/2026/05/07/2079: series
  v4, CC stable@, 6 independent patches
- [Phase 4] b4 dig failed (commit not in local repo); used web
  search/lkml archives instead
- [Phase 4] v2 series note: WARN_ON kept for non-user-triggerable paths
- [Phase 5] Callers verified via grep: `wave5-vpu-dec.c:354,1407,1499`,
  `wave5-vpuapi.c:82`
- [Phase 5] `wave5_vpu_dec_get_result()`: `index_frame_display` from
  `W5_RET_DEC_DISPLAY_INDEX` hardware register
- [Phase 5] `MAX_REG_FRAME` = 64 (`WAVE5_MAX_FBS * 2`),
  `frame_buf[MAX_REG_FRAME]` at `wave5-vpuapi.h:808`
- [Phase 6] Buggy code confirmed at lines 561–563; fix not applied
- [Phase 6] `CONFIG_VIDEO_WAVE_VPU` depends on `ARCH_K3 || COMPILE_TEST`
  per Kconfig
- [Phase 6] `num_of_decoding_fbs` validated `< WAVE5_MAX_FBS` at
  registration (line 305), but OOB path doesn't validate sum
- [Phase 8] Failure mode: OOB read → kernel memory safety issue,
  severity HIGH

**YES**

 .../media/platform/chips-media/wave5/wave5-vpuapi.c   | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c b/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
index e94d6ebc9f816..e7ea2f6a99d5b 100644
--- a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
+++ b/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
@@ -559,8 +559,15 @@ int wave5_vpu_dec_get_output_info(struct vpu_instance *inst, struct dec_output_i
 		p_dec_info->num_of_decoding_fbs : p_dec_info->num_of_display_fbs;
 
 	if (info->index_frame_display >= 0 &&
-	    info->index_frame_display < (int)max_dec_index)
-		info->disp_frame = inst->frame_buf[val + info->index_frame_display];
+	    info->index_frame_display < (int)max_dec_index) {
+		u32 idx = val + info->index_frame_display;
+
+		if (WARN_ON(idx >= MAX_REG_FRAME)) {
+			ret = -EINVAL;
+			goto err_out;
+		}
+		info->disp_frame = inst->frame_buf[idx];
+	}
 
 	info->rd_ptr = p_dec_info->stream_rd_ptr;
 	info->wr_ptr = p_dec_info->stream_wr_ptr;
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] media: imon: Add iMON VFD HID OEM v1.2 key mappings

[Sasha Levin]

From: Alessandro Baldi <baldovic@virgilio.it>

[ Upstream commit d97d13c24d7893abcfb80d38630ce74daaa1434c ]

Add Vol+/Vol-/Mute panel button mappings for iMON VFD HID OEM v1.2.
This version differs in the codes that generate the
KEY_VOLUMEUP, KEY_VOLUMEDOWN and KEY_MUTE events.

Signed-off-by: Alessandro Baldi <baldovic@virgilio.it>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Connection lost, reconnecting to https://agentn.us.api5.cursor.sh
(attempt 1)...
Retry attempt 1...
# Stable Backport Analysis: media: imon: Add iMON VFD HID OEM v1.2 key
mappings

**Local tree:** Linux 6.18.43 (`git describe HEAD` →
`v6.18.43-1-gc7f0dac02d232`)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
**Record:** `[media: imon]` `[Add]` — Add key mappings for iMON VFD HID
OEM v1.2 panel buttons (Vol+/Vol-/Mute).

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
**Record:**
- **Fixes:** — not present (expected for manual review)
- **Reported-by:** — none
- **Tested-by:** — none
- **Reviewed-by:** — none
- **Acked-by:** — none
- **Link:** — none
- **Cc: stable@vger.kernel.org:** — not present (expected)
- **Signed-off-by:** Alessandro Baldi `<baldovic@virgilio.it>` (author)
- **Signed-off-by:** Sean Young `<sean@mess.org>` (media subsystem
  maintainer — strong quality signal)

No syzbot, no bugzilla links, no multiple reporters.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
**Record:**
- **Bug:** iMON VFD HID OEM v1.2 firmware sends different hardware
  scancodes for Vol+, Vol-, and Mute than other variants already mapped
  in `imon_OEM_VFD`.
- **Symptom:** Panel volume/mute buttons on v1.2 hardware produce no
  useful input events (lookup returns `KEY_RESERVED`).
- **Root cause:** Missing entries in the `imon_OEM_VFD.key_table` for
  scancodes `0x0a`, `0x0b`, `0x0c` (with `0xffee` suffix applied at
  lookup time).
- **Version info:** Specific to "iMON VFD HID OEM v1.2" variant of USB
  device `0x15c2:0x0036`.

### Step 1.4: DETECT HIDDEN BUG FIXES
**Record:** Not disguised as cleanup. This is an explicit hardware-
variant key-mapping fix. Functionally equivalent to a hardware quirk:
same USB ID, different firmware scanc## Phase 1: Commit Message
Forensics

### Step 1.1: Subject Line
**Record:** `[media: imon]` `[Add]` — Add iMON VFD HID OEM v1.2 key
mappings for Vol+/Vol-/Mute panel buttons.

### Step 1.2: Commit Message Tags
**Record:**
- **Fixes:** — not present (expected for manual review)
- **Reported-by:** — none
- **Tested-by:** — none
- **Reviewed-by:** — none
- **Acked-by:** — none
- **Link:** — none
- **Cc: stable@vger.kernel.org** — none
- **Signed-off-by:** Alessandro Baldi `<baldovic@virgilio.it>` (author)
- **Signed-off-by:** Sean Young `<sean@mess.org>` (media maintainer;
  pipeline Sasha Levin SOB ignored per instructions)

Notable: maintainer sign-off from Sean Young, but no fuzzer report, user
bug report, or explicit stable nomination.

### Step 1.3: Commit Body Analysis
**Record:**
- **Bug:** iMON VFD HID OEM v1.2 panel buttons send different hardware
  codes for `KEY_VOLUMEUP`, `KEY_VOLUMEDOWN`, and `KEY_MUTE` than other
  variants already mapped in `imon_OEM_VFD`.
- **Symptom:** Volume+/Volume-/Mute panel buttons produce no useful
  input events on v1.2 hardware.
- **Root cause:** Missing entries in the `imon_OEM_VFD.key_table` for
  the v1.2 scancodes (`0x0a`, `0x0b`, `0x0c` with `0xffee` suffix
  pattern).
- **Version info:** Targets a specific hardware/firmware variant (v1.2),
  not a kernel regression.

### Step 1.4: Hidden Bug Fix Detection
**Record:** Not a disguised crash/leak/race fix. This is explicit
hardware-variant keymap completion — functionally a hardware
quirk/workaround for a device revision that uses different scancodes.

---

## Phase 2: Diff Analysis

### Step 2.1: Change Inventory
**Record:**
- **File:** `drivers/media/rc/imon.c` (+4 lines including comment, +3
  mapping entries)
- **Function/structure:** `imon_OEM_VFD.key_table` static data only
- **Scope:** Single-file, surgical data-table addition

### Step 2.2: Code Flow Change
**Record:**
- **Before:** `imon_panel_key_lookup()` walks `imon_OEM_VFD.key_table`;
  v1.2 Vol+/Vol-/Mute scancodes (`0x000000000a00ffee`,
  `0x000000000b00ffee`, `0x000000000c00ffee`) match nothing → returns
  `KEY_RESERVED`.
- **After:** Those scancodes map to `KEY_VOLUMEUP`, `KEY_VOLUMEDOWN`,
  `KEY_MUTE`.
- **Path affected:** 8-byte panel button packets (`len == 8 && buf[7] ==
  0xee`) on USB device `0x15c2:0x0036` using `imon_OEM_VFD`.

### Step 2.3: Bug Mechanism
**Record:** **Category:** Hardware quirk / incomplete keymap for
hardware variant. **Mechanism:** Same USB ID and driver, but v1.2
firmware emits different panel scancodes than existing table entries;
unmatched codes are dropped as `KEY_RESERVED`.

### Step 2.4: Fix Quality
**Record:** Obviously correct pattern — mirrors existing volume/mute
entries already in the same table. Minimal diff, no logic changes.
**Regression risk:** Very low; only adds new lookup entries without
altering existing mappings.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame / Introduction
**Record:** In this shallow 6.18.43 checkout (~50 commits),
`imon_OEM_VFD` and its volume mappings are present at base commit
`a112b91dd6349`. Full upstream introduction history is not available in
this checkout. The **missing v1.2 mappings are confirmed absent** in the
current tree.

### Step 3.2: Fixes: Tag
**Record:** N/A — no `Fixes:` tag.

### Step 3.3: Related File History
**Record:** `git log --oneline -20 -- drivers/media/rc/imon.c` shows
only one commit in this shallow tree (`a112b91dd6349`), which is not
informative for upstream history. No evidence this is part of a multi-
patch series from local history.

### Step 3.4: Author Context
**Record:** No commits from Alessandro Baldi found in this checkout.
Sean Young (Signed-off-by) is the media/RC maintainer — strong subsystem
credibility signal.

### Step 3.5: Dependencies
**Record:** **Standalone.** No prerequisites; only adds rows to an
existing table in existing driver code. No new structures or APIs
required.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original Patch Discussion
**Record:** `b4 dig` requires `-c COMMITISH`; no commit hash was
provided and subject-only search is unsupported. **Could not retrieve
lore thread.**

### Step 4.2: Reviewers
**Record:** `b4 dig -w` not possible without commit hash. Sean Young SOB
in commit message indicates maintainer involvement.

### Step 4.3: Bug Report
**Record:** No `Reported-by:` or `Link:` tags. No external bug report
verified.

### Step 4.4: Related Patches / Series
**Record:** Appears standalone; no series indicators in subject or diff.

### Step 4.5: Stable List History
**Record:** Not searched (lore blocked by bot protection on fetch).
Precedent exists for imon stable backports (e.g., 3.17-stable picked up
imon RC protocol fix for broken remote functionality on `15c2:0034`).

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Functions
**Record:** Modified data: `imon_OEM_VFD`. Affected runtime functions:
`imon_panel_key_lookup()`, called from `imon_incoming_packet()`; table
also used by `imon_init_idev()` to register supported keys.

### Step 5.2: Callers
**Record:** `imon_panel_key_lookup()` called from
`imon_incoming_packet()` when processing 8-byte panel packets (`buf[7]
== 0xee`). Triggered by physical panel button presses on supported iMON
USB devices during normal driver operation.

### Step 5.3: Callees
**Record:** Simple linear table scan; returns `KEY_RESERVED` on miss. No
allocation, locking, or I/O in lookup itself.

### Step 5.4: Reachability
**Record:** **Userspace-reachable** via panel button input on
`USB_DEVICE(0x15c2, 0x0036)` bound to `imon_OEM_VFD`. Common HTPC/media-
center use case for this hardware.

### Step 5.5: Similar Patterns
**Record:** Same table already contains multiple variant-specific
volume/mute mappings (standard OEM, MCE VFD `0xffdc`, knob values). v1.2
entries follow established pattern.

---

## Phase 6: Cross-Reference Against Local Tree (6.18.43)

### Step 6.1: Buggy Code Present?
**Record:** **YES.** Tree is `6.18.43` (`git describe`:
`v6.18.43-1-gc7f0dac02d232`). `imon_OEM_VFD` exists at lines 267–310
with volume mappings for other variants but **without** v1.2 entries
(`0x0a/0x0b/0x0c`). USB ID `0x15c2:0x0036` → `imon_OEM_VFD` at line
392–393.

### Step 6.2: Backport Complications
**Record:** **Clean apply expected.** Insertion point is clearly between
existing OEM volume entries and MCE VFD section — matches current file
layout exactly.

### Step 6.3: Related Fixes Already Present?
**Record:** `grep` for `0x000000000a00ffee` and `OEM v1.2` — **not
found**. Fix is not already in this tree.

---

## Phase 7: Subsystem Context

### Step 7.1: Subsystem / Criticality
**Record:** `drivers/media/rc/imon.c` — media RC/input driver.
**Criticality: PERIPHERAL** (niche HTPC front-panel hardware).

### Step 7.2: Subsystem Activity
**Record:** Mature, low-churn driver in this tree. imon support has been
stable for many years; this is variant-specific table maintenance.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who Is Affected
**Record:** Users of SoundGraph iMON OEM VFD (`15c2:0036`) with HID OEM
**v1.2** firmware — specifically panel Vol+/Vol-/Mute buttons. Config:
`CONFIG_RC_CORE` / imon USB driver.

### Step 8.2: Trigger Conditions
**Record:** Pressing panel volume/mute buttons on v1.2 hardware.
**Common** for affected users every time they use those buttons.
Unprivileged physical access; not a security vector.

### Step 8.3: Failure Mode Severity
**Record:** Unmapped keys → `KEY_RESERVED` → buttons do nothing.
**Severity: LOW** — functional impairment only; no oops, hang,
corruption, or security impact.

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** Restores basic panel functionality for v1.2 owners;
  aligns with stable rules' explicit acceptance of **hardware quirk**
  fixes.
- **Risk:** Minimal — 3 table entries, no behavior change for existing
  mappings.
- **Ratio:** Moderate benefit for a small user population, very low
  risk.

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence Summary

**FOR backport:**
- Fixes a real, user-visible hardware issue (non-working volume/mute
  buttons)
- Tiny, obviously correct, maintainer-signed
- Fits stable rules' **hardware quirk** category
  (`Documentation/process/stable-kernel-rules.rst`)
- Same pattern as existing variant-specific entries in the same table
- Applies cleanly to 6.18.43; driver and device ID already present
- Zero regression risk for users without v1.2 hardware

**AGAINST backport:**
- Not crash/security/corruption/deadlock
- Niche hardware with small user base
- No user/fuzzer bug report in commit message
- Completes support for a variant rather than fixing a kernel regression
- Mailing list review not verified (no commit hash for `b4 dig`)

**Unresolved:** Original lore discussion and whether a user/distro filed
a bug report.

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — standard keymap pattern;
   maintainer SOB
2. Fixes real bug affecting users? **PASS** — broken panel buttons on
   v1.2 hardware
3. Important issue? **PASS (borderline)** — hardware quirk per stable-
   kernel-rules.rst; not crash-level but explicitly listed acceptable
   category
4. Small and contained? **PASS** — 3 entries, one file
5. No new features/APIs? **PASS** — data-only quirk entries
6. Can apply to local tree? **PASS** — code present, clean insertion
   point

### Step 9.3: Exception Category
**Record:** **Hardware quirk/workaround** — v1.2 firmware revision uses
different panel scancodes for the same USB device already supported by
`imon_OEM_VFD`.

### Step 9.4: Decision Rationale

For **Linux 6.18.43**, the driver, device ID, and `imon_OEM_VFD` table
all exist; v1.2 volume/mute scancodes are missing, so affected users'
buttons are silently ignored. The fix is a minimal hardware-variant
keymap addition — the same class of change stable trees routinely accept
as hardware quirks. Severity is low (no stability/security impact), but
benefit is clear for affected HTPC users and risk is negligible.

---

## Verification

- **[Phase 1]** Parsed subject, tags, body from provided commit message
- **[Phase 1]** Confirmed no Reported-by/Fixes/Link/Cc: stable tags
- **[Phase 2]** Diff: +3 keymap entries + comment in
  `imon_OEM_VFD.key_table`
- **[Phase 2]** Read `imon_panel_key_lookup()` at lines 1300–1316
- **[Phase 2]** Read `imon_incoming_packet()` panel path at lines
  1599–1602
- **[Phase 3]** `git describe HEAD` → `v6.18.43-1-gc7f0dac02d232`;
  Makefile → 6.18.43
- **[Phase 3]** `git blame -L 267,310 drivers/media/rc/imon.c` — table
  present (shallow history limits introduction date)
- **[Phase 3]** `git log --grep` / `-S` searches — no candidate commit
  in this tree
- **[Phase 4]** `b4 dig` — failed (no commit hash provided; `-q` not
  supported)
- **[Phase 4]** lore.kernel.org fetch — blocked by bot protection
- **[Phase 4]** Web search — found prior imon stable backport precedent
  (3.17-stable RC protocol fix)
- **[Phase 5]** `grep imon_OEM_VFD` — device `0x15c2:0x0036` uses this
  table
- **[Phase 5]** Traced call chain: panel button →
  `imon_incoming_packet()` → `imon_panel_key_lookup()`
- **[Phase 6]** Read `imon_OEM_VFD` at lines 267–310 — v1.2 mappings
  absent
- **[Phase 6]** `grep 0x000000000a00ffee` — not in tree
- **[Phase 7]** Read `Documentation/process/stable-kernel-rules.rst` —
  hardware quirk explicitly acceptable
- **[Phase 8]** Confirmed failure mode is `KEY_RESERVED` (no crash) via
  lookup code
- **UNVERIFIED:** Original mailing list review thread; whether bug was
  reported by users; exact kernel version that first introduced
  `imon_OEM_VFD` (shallow clone)

**YES**

 drivers/media/rc/imon.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 48534bb52e4d0..4f974b88628f0 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -290,6 +290,10 @@ static const struct imon_usb_dev_descr imon_OEM_VFD = {
 		{ 0x000100000000ffeell, KEY_VOLUMEUP },
 		{ 0x010000000000ffeell, KEY_VOLUMEDOWN },
 		{ 0x000000000100ffeell, KEY_MUTE },
+		/* iMON VFD HID OEM v1.2 */
+		{ 0x000000000a00ffeell, KEY_VOLUMEUP },
+		{ 0x000000000b00ffeell, KEY_VOLUMEDOWN },
+		{ 0x000000000c00ffeell, KEY_MUTE },
 		/* 0xffdc iMON MCE VFD */
 		{ 0x00010000ffffffeell, KEY_VOLUMEUP },
 		{ 0x01000000ffffffeell, KEY_VOLUMEDOWN },
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] media: dm1105: fix missing error check for dma_alloc_coherent

[Sasha Levin]

From: Zhaoyang Yu <2426767509@qq.com>

[ Upstream commit 3eaac9e02d8591d3c790db572ef1c8fa5a841fdb ]

The return value of dm1105_dma_map(), which handles DMA memory allocation,
is ignored in dm1105_hw_init(). If dma_alloc_coherent() fails, the driver
will proceed using a NULL pointer for DMA transfers, leading to a kernel
oops or invalid hardware access.

Fix this by checking the return value and propagating -ENOMEM on failure.

Signed-off-by: Zhaoyang Yu <2426767509@qq.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `media: dm1105: fix missing error check for
dma_alloc_coherent`

**Local tree:** `stable/linux-6.18.y` at `v6.18.43` (`6.18.43`)
**Upstream commit:** `3eaac9e02d8591d3c790db572ef1c8fa5a841fdb` (not in
this tree yet)
**Candidate on autosel:** `c01c5e056e60f`

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1 – Subject line**
Record: `[media/dm1105] [fix] missing error check for dma_alloc_coherent
in dm1105_hw_init()`

**Step 1.2 – Tags**
Record:
- `Signed-off-by: Zhaoyang Yu <2426767509@qq.com>` (author)
- `Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>` (media
  maintainer)
- No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-
  by:`, `Link:`, or `Cc: stable@vger.kernel.org`
- Pipeline-added markers (`[Upstream commit ...]`, Sasha Levin SOB)
  ignored per instructions

**Step 1.3 – Body analysis**
Record:
- **Bug:** `dm1105_dma_map()` return value ignored in `dm1105_hw_init()`
- **Symptom:** If `dma_alloc_coherent()` fails, driver continues with
  NULL `ts_buf` → kernel oops or invalid hardware DMA access
- **Fix:** Check return value, propagate `-ENOMEM`
- **Root cause:** Missing error propagation on DMA buffer allocation
  failure during hardware init

**Step 1.4 – Hidden bug fix?**
Record: No — explicitly labeled and described as a bug fix (missing
error check → NULL pointer use).

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1 – Inventory**
Record:
- **File:** `drivers/media/pci/dm1105/dm1105.c` (+6 / -1 lines)
- **Function modified:** `dm1105_hw_init()`
- **Scope:** Single-file, surgical fix

**Step 2.2 – Code flow change**
Record:
- **Before:** `dm1105_dma_map(dev);` — return ignored; always `return 0`
- **After:** `ret = dm1105_dma_map(dev); if (ret) return -ENOMEM;` —
  failure aborts init
- **Path:** Probe-time initialization error path (`dm1105_probe()` →
  `dm1105_hw_init()`)

**Step 2.3 – Bug mechanism**
Record:
- **Category:** NULL pointer dereference / missing error-path handling
- **Mechanism:** `dm1105_dma_map()` returns non-zero when
  `dma_alloc_coherent()` returns NULL (`return !dev->ts_buf`). Without
  the check, probe succeeds, IRQ/work handlers later dereference
  `dev->ts_buf` (e.g. in `dm1105_dmx_buffer()` at lines 676–698)

**Step 2.4 – Fix quality**
Record:
- Obviously correct and minimal
- Matches existing probe pattern (`if (ret < 0) goto err_pci_iounmap`)
- On failure, probe goes to `err_pci_iounmap` without calling
  `dm1105_hw_exit()` — correct, since no DMA buffer was allocated
- Low regression risk

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1 – Blame**
Record: Buggy ignore of `dm1105_dma_map()` present at `dm1105_hw_init()`
line 781 since file entry in this tree (`5d324e5159d9e`). Original
driver commit `519a4bdcf822` (2008) had the identical pattern in
`dm1105dvb_hw_init()` — bug present since driver inception.

**Step 3.2 – Fixes: tag**
Record: N/A — no `Fixes:` tag. Bug introduced in original driver
`519a4bdcf822` ("V4L/DVB (11984): Add support for yet another SDMC
DM1105 based DVB-S card.").

**Step 3.3 – Related file history**
Record:
- `08ddfd628a2db` — unrelated workqueue leak fix (already in 6.18.y, had
  `Cc: stable`)
- `e250b672d40a9` — rc subsystem race fix (indirect, different issue)
- No prior fix for this DMA error-check bug in this tree

**Step 3.4 – Author context**
Record: Zhaoyang Yu submitted similar `dma_alloc_coherent()` error-check
fixes (e.g. `pch_uart` on autosel). Hans Verkuil (media maintainer)
committed upstream.

**Step 3.5 – Dependencies**
Record: Standalone. b4 shows v1 was patch 7/7 of a series, but
committed/applied v2 is a single independent patch. No prerequisite
commits required; `dm1105_dma_map()` already returns `int` in this tree.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1 – Original discussion**
Record:
- `b4 dig -c 3eaac9e02d8591d3c790db572ef1c8fa5a841fdb` → https://patch.m
  sgid.link/tencent_2F5A25B0AB50C4D77CFB3DDEA852BEBE6509@qq.com
- v2 standalone patch (not a multi-patch dependency for backport)
- No stable nominations, NAKs, or reviewer objections found in saved
  mbox

**Step 4.2 – Reviewers**
Record: CC'd to `mchehab@kernel.org`, `linux-media@vger.kernel.org`,
`linux-kernel@vger.kernel.org`. Hans Verkuil committed upstream (strong
maintainer endorsement).

**Step 4.3 – Bug report**
Record: N/A — no external bug report or syzbot link. Bug identified by
code review.

**Step 4.4 – Series context**
Record: v1 was 7/7; v2 is standalone. This fix does not depend on
patches 1–6.

**Step 4.5 – Stable list history**
Record: Could not search lore stable archive (Anubis bot protection). No
stable discussion found via b4 mbox.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1 – Key functions**
Record: `dm1105_hw_init()`, `dm1105_dma_map()`, `dm1105_set_dma_addr()`

**Step 5.2 – Callers**
Record: `dm1105_hw_init()` called only from `dm1105_probe()` (line
1031). Probe already handles negative return via `goto err_pci_iounmap`.

**Step 5.3 – Callees**
Record: `dm1105_dma_map()` → `dma_alloc_coherent()`; on success,
`dm1105_set_dma_addr()` programs hardware with DMA address.

**Step 5.4 – Reachability**
Record: Triggered at PCI probe when `CONFIG_DVB_DM1105` is enabled and
DM1105 hardware is present. DMA alloc failure possible under memory/CMA
pressure. Without fix, probe succeeds and later IRQ →
`dm1105_dmx_buffer()` NULL-dereferences `dev->ts_buf`.

**Step 5.5 – Similar patterns**
Record: Same long-standing bug pattern in original 2008 driver
(`dm1105dvb_dma_map` return ignored). Author has submitted similar fixes
elsewhere.

---

## PHASE 6: CROSS-REFERENCE AGAINST LOCAL TREE (6.18.y)

**Step 6.1 – Buggy code present?**
Record: **YES** — current tree at lines 781–782 ignores
`dm1105_dma_map()` return. Upstream fix `3eaac9e02d859` is **not** an
ancestor of HEAD.

**Step 6.2 – Backport complications**
Record: **Clean apply** — `git diff HEAD c01c5e056e60f` shows only the
6-line hunk with no conflicts.

**Step 6.3 – Related fixes already present?**
Record: No duplicate fix. Related `08ddfd628a2db` (workqueue leak) is
separate.

---

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1 – Subsystem**
Record: `drivers/media/pci/dm1105` — DVB media PCI driver.
**Criticality: PERIPHERAL** (niche TV/DVB capture hardware).

**Step 7.2 – Activity**
Record: Low churn in 6.18.y; driver is mature/legacy with occasional
maintenance fixes.

---

## PHASE 8: IMPACT AND RISK

**Step 8.1 – Who is affected**
Record: Users with SDMC DM1105-based DVB-S PCI cards and
`CONFIG_DVB_DM1105` enabled (driver-specific, small population).

**Step 8.2 – Trigger conditions**
Record: `dma_alloc_coherent()` failure during probe (memory pressure,
CMA exhaustion). Uncommon but realistic. Requires hardware present; not
userspace-triggerable without the device.

**Step 8.3 – Failure severity**
Record: **HIGH** — kernel oops from NULL dereference in
`dm1105_dmx_buffer()` when DMA interrupts fire; also possible invalid
DMA programming via `dm1105_set_dma_addr()` with garbage/zero address.

**Step 8.4 – Risk vs benefit**
Record:
- **Benefit:** Prevents probe-from-failure crash on affected hardware;
  correct error propagation
- **Risk:** Very low — 6 lines, no API/behavior change on success path
- **Ratio:** Favorable for backport despite niche hardware

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1 – Evidence summary**

| FOR backport | AGAINST backport |
|---|---|
| Real NULL-deref bug since 2008 | Niche hardware, few users |
| Kernel oops on failure path | DMA alloc failure is uncommon |
| Tiny, obviously correct fix | No syzbot/user report |
| Applies cleanly to 6.18.y | |
| Maintainer (Hans Verkuil) signed off | |
| Probe error path already wired | |

**Unresolved:** No user crash reports; lore stable-thread search
blocked.

**Step 9.2 – Stable rules checklist**
1. Obviously correct and tested? **PASS** — logic is trivial; maintainer
   committed upstream
2. Fixes real bug affecting users? **PASS** — NULL deref on DMA alloc
   failure with DM1105 hardware
3. Important issue? **PASS** — kernel oops (HIGH severity when
   triggered)
4. Small and contained? **PASS** — 6 lines, 1 file
5. No new features/APIs? **PASS**
6. Can apply to local tree? **PASS** — clean apply verified

**Step 9.3 – Exception category**
Record: N/A (standard bug fix, not quirk/ID/DT/build/doc exception).

**Step 9.4 – Decision rationale**
This is a textbook stable candidate: a long-standing missing error check
that can cause a kernel oops when DMA allocation fails during probe. The
fix is minimal, maintainer-reviewed, self-contained, and applies cleanly
to the local 6.18.y tree where the buggy code is confirmed present.

---

## Verification

- [Phase 1] Parsed commit message and tags from `git show 3eaac9e02d859`
  / `c01c5e056e60f`
- [Phase 1] No Reported-by/syzbot/Fixes: tags found
- [Phase 2] Read current `dm1105.c` lines 605–612, 669–698, 769–793,
  1031–1033, 1160–1163
- [Phase 2] Confirmed `dm1105_dma_map()` returns `!dev->ts_buf` (non-
  zero on failure)
- [Phase 2] Confirmed `dm1105_dmx_buffer()` dereferences `dev->ts_buf`
  without NULL check
- [Phase 3] `git describe HEAD` → `v6.18.43`; `make kernelversion` →
  `6.18.43`
- [Phase 3] `git blame` on hw_init/dma_map lines → present since
  `5d324e5159d9e` in this file
- [Phase 3] `git show 519a4bdcf822` → identical bug in original 2008
  driver
- [Phase 3] `git merge-base --is-ancestor 3eaac9e02d859 HEAD` → exit 1
  (fix NOT in tree)
- [Phase 4] `b4 dig -c 3eaac9e02d859` → lore URL found; v2 standalone
  patch
- [Phase 4] `b4 dig -a` → v2 only revision listed as matching
- [Phase 4] `b4 dig -w` → mchehab, linux-media CC'd
- [Phase 4] Saved mbox to `/tmp/dm1105_thread.mbox` — no stable
  nomination or NAK found
- [Phase 5] `grep dm1105_hw_init` → single caller in `dm1105_probe()`
- [Phase 6] `git diff HEAD c01c5e056e60f` → clean 6-line apply
- [Phase 6] Confirmed buggy `dm1105_dma_map(dev);` at line 781 in
  current tree
- [Phase 8] Failure mode: NULL deref in work handler after failed DMA
  alloc — severity HIGH
- [UNVERIFIED] No end-user crash reports located (none cited in commit
  or lore thread)

**YES**

 drivers/media/pci/dm1105/dm1105.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/media/pci/dm1105/dm1105.c b/drivers/media/pci/dm1105/dm1105.c
index c1d55b9836744..abd86488064b5 100644
--- a/drivers/media/pci/dm1105/dm1105.c
+++ b/drivers/media/pci/dm1105/dm1105.c
@@ -768,6 +768,8 @@ static void dm1105_ir_exit(struct dm1105_dev *dm1105)
 
 static int dm1105_hw_init(struct dm1105_dev *dev)
 {
+	int ret;
+
 	dm1105_disable_irqs(dev);
 
 	dm_writeb(DM1105_HOST_CTR, 0);
@@ -778,7 +780,10 @@ static int dm1105_hw_init(struct dm1105_dev *dev)
 	dm_writew(DM1105_TSCTR, 0xc10a);
 
 	/* map DMA and set address */
-	dm1105_dma_map(dev);
+	ret = dm1105_dma_map(dev);
+	if (ret)
+		return -ENOMEM;
+
 	dm1105_set_dma_addr(dev);
 	/* big buffer */
 	dm_writel(DM1105_RLEN, 5 * DM1105_DMA_BYTES);
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.12] media: chips-media: wave5: Fix Reports from Kernel Lock Validator

[Sasha Levin]

From: Brandon Brnich <b-brnich@ti.com>

[ Upstream commit 7d5d364f8b2dcc9b6b92456fb55632fde4a4d96f ]

handle_dynamic_resolution change requires that the state_lock be acquired
based on the lockdep_assert_held. However, the
handle_dynamic_resolution_change call in initialize_sequence does not
properly obtain the lock before calling.

Since the v4l2_ctrl_find and s_ctrl can sleep, they should not be called
while a lock is already held. Store off the fbc_buf_count then properly
update control once lock has been freed.

Signed-off-by: Brandon Brnich <b-brnich@ti.com>
Tested-by: Jackson Lee <jackson.lee@chipsnmedia.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `media: chips-media: wave5: Fix Reports from
Kernel Lock Validator`

**Local tree:** `linux-6.18.y` (`v6.18.43`, Makefile `6.18.43`)
**Verdict scope:** This checkout only.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject line
**Record:** `[media: chips-media: wave5]` `[fix]` — Correct
lockdep/locking violations in dynamic-resolution handling by deferring
V4L2 control updates until after `state_spinlock` is released.

### Step 1.2: Tags
**Record:**
- **Signed-off-by:** Brandon Brnich `<b-brnich@ti.com>` (author)
- **Tested-by:** Jackson Lee `<jackson.lee@chipsnmedia.com>`
- **Signed-off-by:** Nicolas Dufresne `<nicolas.dufresne@collabora.com>`
  (reviewer/maintainer chain)
- **Signed-off-by:** Hans Verkuil `<hverkuil+cisco@kernel.org>` (media
  maintainer)
- **No** `Fixes:`, `Reported-by:`, `Link:`, `Cc:
  stable@vger.kernel.org`, or `Reviewed-by:` tags
- Notable: hardware vendor testing + subsystem maintainer sign-offs; no
  syzbot/fuzzer report

### Step 1.3: Body analysis
**Record:**
- **Bug:** `handle_dynamic_resolution_change()` must be called with
  `state_spinlock` held (`lockdep_assert_held`), but it calls
  `v4l2_ctrl_find()` and `v4l2_ctrl_s_ctrl()`, which acquire the
  control-handler mutex and can sleep.
- **Symptom:** Kernel Lock Validator (lockdep) reports; underlying issue
  is mutex acquisition while holding a spinlock.
- **Root cause:** Mixing spinlock-protected instance state with sleeping
  V4L2 control framework calls in the same function.
- **Fix approach:** Store `fbc_buf_count` under the spinlock; update the
  control afterward via new helper `wave5_update_min_bufs_ctrl()`.
- **Version info:** None in message.

### Step 1.4: Hidden bug fix?
**Record:** Yes. Despite the lockdep-focused title, this fixes a real
**sleeping-while-holding-spinlock** / **lock inversion** bug, not
cosmetic cleanup. The driver already documents this pattern in
`wave5_vpu_dec_stop()` (lines 796–799): release `state_spinlock` before
operations that may block on a mutex.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
**Record:**
- **File:** `drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c`
  (~+55 / -20 lines)
- **Functions modified/added:**
  - **New:** `wave5_update_min_bufs_ctrl()`
  - **Modified:** `handle_dynamic_resolution_change()`,
    `wave5_vpu_dec_finish_decode()`, `initialize_sequence()`,
    `wave5_vpu_dec_device_run()`
- **Scope:** Single-file, surgical locking fix

### Step 2.2: Code flow per hunk
**Record:**
1. **`wave5_update_min_bufs_ctrl()` (new):** Runs without
   `state_spinlock`; calls `v4l2_ctrl_find()` + `v4l2_ctrl_s_ctrl()`
   only when buffer count changed.
2. **`handle_dynamic_resolution_change()`:** Before → updates min-
   buffers control while spinlock held. After → only updates instance
   fields and queues source-change event under lock.
3. **`wave5_vpu_dec_finish_decode()`:** Before → calls
   `handle_dynamic_resolution_change()` under lock (including sleeping
   ctrl ops). After → saves `fbc_buf_count` under lock, calls helper
   after `spin_unlock_irqrestore()`.
4. **`initialize_sequence()`:** Same deferral pattern after seq-init DRC
   handling.
5. **`wave5_vpu_dec_device_run()` error path:** Same deferral when
   `initialize_sequence()` fails during drain/DRC.

### Step 2.3: Bug mechanism
**Record:** **Category:** Synchronization / lock-ordering violation
(spinlock + mutex inversion).
**Mechanism:** `state_spinlock` is a spinlock; `v4l2_ctrl_find()` uses
`mutex_lock(hdl->lock)` via `find_ref_lock()`, and `v4l2_ctrl_s_ctrl()`
uses `v4l2_ctrl_lock()` → `mutex_lock()`. Calling these while holding a
spinlock violates kernel locking rules and can trigger lockdep warnings,
`scheduling while atomic` BUGs, or deadlocks under contention.

### Step 2.4: Fix quality
**Record:** Fix is obviously correct and minimal. It mirrors the
existing `wave5_vpu_dec_stop()` pattern. Regression risk is low:
`fbc_buf_count` is set under the lock before the deferred update; the
helper re-checks whether an update is needed.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame / introduction
**Record:** Buggy `v4l2_ctrl_s_ctrl()` inside
`handle_dynamic_resolution_change()` present since driver introduction
in `9707a6254a8a6` (“Add the v4l2 layer”, Nov 2023).
`lockdep_assert_held(&inst->state_spinlock)` was there from the start.
Related stable backport `ea28b33e1b15b` (May 2026) added missing
spinlock around `initialize_sequence()`’s call — which makes the
sleeping-under-spinlock path more consistently exercised on seq-init.

### Step 3.2: Fixes: tag
**Record:** N/A — no `Fixes:` tag in commit message.

### Step 3.3: Related file history
**Record:** Recent stable wave5 commits on this file include multiple
crash/panic/lockdep fixes (`ea28b33`, `d71fc687`, `ea316b78`,
`27cb12b7`, etc.). This patch is a logical follow-up to the spinlock-
protection backports. Standalone fix; not part of a numbered series.

### Step 3.4: Author context
**Record:** Brandon Brnich has other wave5 commits in this tree
(`b607b5e2`, `5e702ee8`, `f24ca8b5`). Patch signed by media maintainer
Hans Verkuil and reviewed by Nicolas Dufresne.

### Step 3.5: Dependencies
**Record:** No external prerequisites. Benefits from `ea28b33` already
being in 6.18.y (spinlock around `initialize_sequence()`). The candidate
commit is not yet in this tree; upstream diff has minor context
differences (`sent_eos`, `retry` paths absent in 6.18.y) but the core
fix applies cleanly with at most small manual adjustment.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1–4.5
**Record:** Commit hash not found in local branches (`master`, `linux-
next`, `media-next`, `graphics-next`). `b4 dig` could not be run without
a commit hash. Lore.kernel.org fetch blocked (bot protection).
**UNVERIFIED:** mailing-list thread, reviewer stable nominations, series
revisions.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key functions
**Record:** `wave5_update_min_bufs_ctrl()`,
`handle_dynamic_resolution_change()`, `wave5_vpu_dec_finish_decode()`,
`initialize_sequence()`, `wave5_vpu_dec_device_run()`.

### Step 5.2: Callers
**Record:** `handle_dynamic_resolution_change()` called from:
- `wave5_vpu_dec_finish_decode()` — decode completion / sequence-change
  IRQ path
- `initialize_sequence()` — stream startup seq-init
- `wave5_vpu_dec_device_run()` — error recovery during
  `VPU_INST_STATE_OPEN`

All are normal V4L2 mem2mem decode paths reachable from userspace
`ioctl()` streaming.

### Step 5.3: Callees
**Record:** Deferred path calls `v4l2_ctrl_find()` and
`v4l2_ctrl_s_ctrl()` (mutex-based). Under-lock path calls
`v4l2_event_queue_fh()`, format updates, state changes.

### Step 5.4: Reachability
**Record:** Triggered on dynamic resolution change during HEVC/H.264
decode — common real-world scenario (resolution switches in a stream).
Userspace-reachable via V4L2 M2M decode.

### Step 5.5: Similar patterns
**Record:** `wave5_vpu_dec_stop()` already releases `state_spinlock`
before mutex-capable firmware/control work (lines 796–805). This fix
brings DRC handling in line with that established pattern.

---

## PHASE 6: CROSS-REFERENCE AGAINST LOCAL TREE

### Step 6.1: Buggy code present?
**Record:** **Yes.** Current `wave5-vpu-dec.c` lines 295–301 call
`v4l2_ctrl_find()` / `v4l2_ctrl_s_ctrl()` inside
`handle_dynamic_resolution_change()` while
`lockdep_assert_held(&inst->state_spinlock)` is in effect. All three
callers hold the spinlock.

### Step 6.2: Backport complications
**Record:** Expected **clean apply with minor context adjustment**.
Upstream diff references `inst->sent_eos` and `inst->retry` code not
present in 6.18.y; the essential hunks (new helper, ctrl removal from
DRC handler, deferred update at three call sites) map directly to
current code.

### Step 6.3: Related fixes already present?
**Record:** `ea28b33e1b15b` (spinlock around `initialize_sequence()` DRC
call) and `d71fc6874fce3` (spinlock around `send_eos_event()`) are
already in 6.18.y. This fix is **not** duplicated.

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem criticality
**Record:** **PERIPHERAL** — `VIDEO_WAVE_VPU` driver (`ARCH_K3 ||
COMPILE_TEST`). Affects K3 SoC users and compile-test builds, not all
kernel users.

### Step 7.2: Activity
**Record:** Actively maintained — multiple wave5 stable backports in
2026 on this tree.

---

## PHASE 8: IMPACT AND RISK

### Step 8.1: Who is affected
**Record:** Users of Chips&Media Wave5 VPU on TI K3 (and similar) doing
mem2mem video decode with dynamic resolution changes.

### Step 8.2: Trigger conditions
**Record:** Dynamic resolution change during decode (sequence change,
seq-init, or init failure + drain path). Not rare for adaptive streams.
Unprivileged users with V4L2 device access can trigger.

### Step 8.3: Failure mode severity
**Record:** Lockdep warnings (debug kernels); potential `scheduling
while atomic` BUG, deadlock, or oops on production kernels when ctrl
path contends or sleeps. **Severity: HIGH** (can crash the kernel during
decode).

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** HIGH for affected hardware — prevents real locking
  violations on a common decode event
- **Risk:** LOW — small, follows existing in-driver pattern, tested by
  hardware vendor
- **Ratio:** Strong benefit for targeted users, very low regression risk

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence summary

**FOR backport:**
- Real mutex-under-spinlock bug in production decode paths
- Can cause kernel crash/deadlock, not just lockdep noise
- Small, surgical, obviously correct fix
- Driver and buggy code exist in 6.18.y
- Related lockdep fixes already backported to this tree
- `Tested-by` from Chips&Media; maintainer sign-offs
- Matches established pattern already in the same file

**AGAINST backport:**
- Narrow hardware audience (`ARCH_K3 || COMPILE_TEST`)
- Commit not yet in tree; minor context differences vs upstream diff
- No syzbot/user crash report in commit message

**UNRESOLVED:**
- Mailing-list discussion and explicit stable nomination (lore
  inaccessible; commit not in local branches)

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** — clear locking fix, `Tested-
   by` present
2. Fixes a real user-affecting bug? **PASS** — mutex while holding
   spinlock on decode DRC path
3. Important issue? **PASS** — kernel crash/deadlock potential (HIGH)
4. Small and contained? **PASS** — one file, ~55 lines net
5. No new features/APIs? **PASS** — refactor of existing control update
   only
6. Can apply to local tree? **PASS** — buggy code present; minor context
   adjustment at most

### Step 9.3: Exception category
**Record:** None (standard locking bug fix, not device-
ID/quirk/build/doc exception).

### Step 9.4: Decision rationale
This is a genuine locking bug fix, not a lockdep-only cosmetic change.
`v4l2_ctrl_find()` and `v4l2_ctrl_s_ctrl()` take mutexes and must not
run under `state_spinlock`. The bug exists in 6.18.y, is reachable
during normal decode with resolution changes, and the fix is small,
tested, and consistent with code already in the driver. Stable
maintainers have already backported related wave5 lockdep fixes to this
tree; this completes that work.

---

## Verification

- **[Phase 1]** Parsed subject, tags, body from user-provided commit
  message
- **[Phase 2]** Analyzed full diff; confirmed ctrl ops moved outside
  spinlock at 3 call sites
- **[Phase 2]** Read `v4l2_ctrl_s_ctrl()` — locks handler mutex
  (`include/media/v4l2-ctrls.h:1137-1145`)
- **[Phase 2]** Read `v4l2_ctrl_find()` — uses `mutex_lock` via
  `find_ref_lock()` (`v4l2-ctrls-core.c:1742-1750`)
- **[Phase 3]** `git describe HEAD` → `v6.18.43` on `linux-6.18.y`
- **[Phase 3]** `git log` on `wave5-vpu-dec.c` → related fixes
  `ea28b33`, `d71fc687` present
- **[Phase 3]** `git show 9707a6254a8a6b` → original driver had buggy
  ctrl-under-spinlock pattern
- **[Phase 3]** `git blame` lines 285-301 → bug present since driver
  introduction
- **[Phase 4]** Searched `master`, `linux-next`, `media-next`,
  `graphics-next` for commit — not found
- **[Phase 4]** UNVERIFIED: `b4 dig` (no commit hash), lore.kernel.org
  (blocked)
- **[Phase 5]** Grep: `handle_dynamic_resolution_change` has 3 callers,
  all under spinlock
- **[Phase 5]** Read `wave5_vpu_dec_stop()` lines 796-805 — existing
  defer-mutex pattern
- **[Phase 6]** Confirmed buggy code at `wave5-vpu-dec.c:295-301` in
  local tree
- **[Phase 6]** Confirmed `ea28b33` spinlock fix already applied at
  lines 1569-1571
- **[Phase 6]** Grep: `sent_eos`, `retry` absent in 6.18.y — minor
  backport context difference noted
- **[Phase 7]** Read `Kconfig` — `VIDEO_WAVE_VPU` depends on `ARCH_K3 ||
  COMPILE_TEST`
- **[Phase 8]** Traced trigger to DRC during V4L2 mem2mem decode —
  userspace-reachable

**YES**The branch searches are done. The commit
(`wave5_update_min_bufs_ctrl` / "Kernel Lock Validator") wasn't found on
`master`, `linux-next`, `media-next`, or `graphics-next` in this
checkout, so it looks like a newer upstream patch not present locally
yet.

That doesn't change the earlier **YES** verdict for 6.18.y: the buggy
code is in the tree, and the fix should apply with only minor context
tweaks.

 .../chips-media/wave5/wave5-vpu-dec.c         | 47 +++++++++++++------
 1 file changed, 33 insertions(+), 14 deletions(-)

diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c b/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
index 7a4625acc0478..189cd8bcdffd9 100644
--- a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
+++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
@@ -270,10 +270,23 @@ static void send_eos_event(struct vpu_instance *inst)
 	inst->eos = false;
 }
 
+static void wave5_update_min_bufs_ctrl(struct vpu_instance *inst, u32 fbc_buf_count)
+{
+	struct v4l2_m2m_ctx *m2m_ctx = inst->v4l2_fh.m2m_ctx;
+	struct v4l2_ctrl *ctrl;
+
+	if (!fbc_buf_count || fbc_buf_count == v4l2_m2m_num_dst_bufs_ready(m2m_ctx))
+		return;
+
+	ctrl = v4l2_ctrl_find(&inst->v4l2_ctrl_hdl,
+			      V4L2_CID_MIN_BUFFERS_FOR_CAPTURE);
+	if (ctrl)
+		v4l2_ctrl_s_ctrl(ctrl, fbc_buf_count);
+}
+
 static int handle_dynamic_resolution_change(struct vpu_instance *inst)
 {
 	struct v4l2_fh *fh = &inst->v4l2_fh;
-	struct v4l2_m2m_ctx *m2m_ctx = inst->v4l2_fh.m2m_ctx;
 
 	static const struct v4l2_event vpu_event_src_ch = {
 		.type = V4L2_EVENT_SOURCE_CHANGE,
@@ -292,14 +305,6 @@ static int handle_dynamic_resolution_change(struct vpu_instance *inst)
 
 	inst->needs_reallocation = true;
 	inst->fbc_buf_count = initial_info->min_frame_buffer_count + 1;
-	if (inst->fbc_buf_count != v4l2_m2m_num_dst_bufs_ready(m2m_ctx)) {
-		struct v4l2_ctrl *ctrl;
-
-		ctrl = v4l2_ctrl_find(&inst->v4l2_ctrl_hdl,
-				      V4L2_CID_MIN_BUFFERS_FOR_CAPTURE);
-		if (ctrl)
-			v4l2_ctrl_s_ctrl(ctrl, inst->fbc_buf_count);
-	}
 
 	if (p_dec_info->initial_info_obtained) {
 		const struct vpu_format *vpu_fmt;
@@ -427,19 +432,24 @@ static void wave5_vpu_dec_finish_decode(struct vpu_instance *inst)
 	if ((dec_info.index_frame_display == DISPLAY_IDX_FLAG_SEQ_END ||
 	     dec_info.sequence_changed)) {
 		unsigned long flags;
+		u32 fbc_buf_count = 0;
 
 		spin_lock_irqsave(&inst->state_spinlock, flags);
 		if (!v4l2_m2m_has_stopped(m2m_ctx)) {
 			switch_state(inst, VPU_INST_STATE_STOP);
 
-			if (dec_info.sequence_changed)
+			if (dec_info.sequence_changed) {
 				handle_dynamic_resolution_change(inst);
-			else
+				fbc_buf_count = inst->fbc_buf_count;
+			} else {
 				send_eos_event(inst);
+			}
 
 			flag_last_buffer_done(inst);
 		}
 		spin_unlock_irqrestore(&inst->state_spinlock, flags);
+
+		wave5_update_min_bufs_ctrl(inst, fbc_buf_count);
 	}
 
 	/*
@@ -1543,8 +1553,9 @@ static const struct vpu_instance_ops wave5_vpu_dec_inst_ops = {
 static int initialize_sequence(struct vpu_instance *inst)
 {
 	struct dec_initial_info initial_info;
-	int ret = 0;
 	unsigned long flags;
+	u32 fbc_buf_count;
+	int ret = 0;
 
 	memset(&initial_info, 0, sizeof(struct dec_initial_info));
 
@@ -1568,8 +1579,11 @@ static int initialize_sequence(struct vpu_instance *inst)
 
 	spin_lock_irqsave(&inst->state_spinlock, flags);
 	handle_dynamic_resolution_change(inst);
+	fbc_buf_count = inst->fbc_buf_count;
 	spin_unlock_irqrestore(&inst->state_spinlock, flags);
 
+	wave5_update_min_bufs_ctrl(inst, fbc_buf_count);
+
 	return 0;
 }
 
@@ -1602,6 +1616,7 @@ static void wave5_vpu_dec_device_run(void *priv)
 		ret = initialize_sequence(inst);
 		if (ret) {
 			unsigned long flags;
+			u32 fbc_buf_count = 0;
 
 			spin_lock_irqsave(&inst->state_spinlock, flags);
 			if (wave5_is_draining_or_eos(inst) &&
@@ -1610,14 +1625,18 @@ static void wave5_vpu_dec_device_run(void *priv)
 
 				switch_state(inst, VPU_INST_STATE_STOP);
 
-				if (vb2_is_streaming(dst_vq))
+				if (vb2_is_streaming(dst_vq)) {
 					send_eos_event(inst);
-				else
+				} else {
 					handle_dynamic_resolution_change(inst);
+					fbc_buf_count = inst->fbc_buf_count;
+				}
 
 				flag_last_buffer_done(inst);
 			}
 			spin_unlock_irqrestore(&inst->state_spinlock, flags);
+
+			wave5_update_min_bufs_ctrl(inst, fbc_buf_count);
 		} else {
 			switch_state(inst, VPU_INST_STATE_INIT_SEQ);
 		}
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.1] media: video-i2c: use vb2_video_unregister_device on driver removal

[Sasha Levin]

From: Arash Golgol <arash.golgol@gmail.com>

[ Upstream commit 56384b486b80ce4a2bc93689aae49995f908f90d ]

The driver uses vb2_fop_release() as its file release operation, so
vb2_video_unregister_device() should be used instead of
video_unregister_device() during driver removal.

This ensures that the vb2 queue is properly disconnected before the
video device is unregistered.

Signed-off-by: Arash Golgol <arash.golgol@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The background `git log -S 'vb2_video_unregister_device'` search timed
out after ~2 minutes and produced no output (it was killed). That didn’t
affect the backport verdict — the analysis already covered the relevant
code paths, API docs, and tree state directly.

The conclusion for **6.18.y** remains **YES**: one-line fix, real
teardown bug on remove during active capture, applies cleanly.

 drivers/media/i2c/video-i2c.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
index 1eee2d4f5b40e..16ad1831e4da7 100644
--- a/drivers/media/i2c/video-i2c.c
+++ b/drivers/media/i2c/video-i2c.c
@@ -888,7 +888,7 @@ static void video_i2c_remove(struct i2c_client *client)
 	if (data->chip->set_power)
 		data->chip->set_power(data, false);
 
-	video_unregister_device(&data->vdev);
+	vb2_video_unregister_device(&data->vdev);
 }
 
 #ifdef CONFIG_PM
-- 
2.53.0

[PATCH AUTOSEL 6.18] media: platform: cros-ec: Add Kulnex and Moxoe to the match table

[Sasha Levin]

From: Ken Lin <kenlin5@quanta.corp-partner.google.com>

[ Upstream commit e024767f90f9f50bfcce4b20bb74237ad72450f3 ]

The Google Kulnex and Moxoe device uses the same approach as Google Brask
which enables the HDMI CEC via the cros-ec-cec driver.

Signed-off-by: Ken Lin <kenlin5@quanta.corp-partner.google.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

### Step 1.1: Parse the Subject Line
**Record:** `[media: platform: cros-ec]` `[Add]` — Add Kulnex and Moxoe
Google Chromebook board names to the CEC DMI match table so HDMI CEC can
be enabled on those platforms.

### Step 1.2: Parse All Commit Message Tags
**Record:**
- **Fixes:** none
- **Reported-by:** none
- **Tested-by:** none
- **Reviewed-by:** none
- **Acked-by:** none
- **Link:** none
- **Cc: stable:** none (expected; not a negative signal)
- **Signed-off-by:** Ken Lin `<kenlin5@quanta.corp-partner.google.com>`
  (author)
- **Signed-off-by:** Hans Verkuil `<hverkuil+cisco@kernel.org>`
  (media/CEC maintainer)

No syzbot, bugzilla, or user crash reports. Maintainer sign-off is a
positive quality signal.

### Step 1.3: Analyze Commit Body
**Record:**
- **Bug description:** Google Kulnex and Moxoe Chromebooks use the same
  HDMI CEC-over-ChromeOS-EC approach as Brask, but are missing from
  `cec_dmi_match_table[]`.
- **Symptom/failure mode:** `cros-ec-cec` probe fails on these boards;
  HDMI CEC is unavailable. No crash is described.
- **Version information:** none in the commit message.
- **Root cause:** Driver uses an explicit DMI whitelist per Chromebook
  model for HDMI DRM device and connector-port mapping. New boards were
  never added.

### Step 1.4: Detect Hidden Bug Fixes
**Record:** Not a hidden crash/UAF/race fix. This is explicit hardware
enablement: adding board identification entries so an existing driver
can probe on two new platforms. Functionally equivalent to adding
PCI/USB IDs or a DMI quirk entry.

---

## Phase 2: Diff Analysis

### Step 2.1: Inventory the Changes
**Record:**
- **Files:** `drivers/media/cec/platform/cros-ec/cros-ec-cec.c` (+4
  lines)
- **Functions modified:** none directly; only `cec_dmi_match_table[]`
  data
- **Scope:** single-file, surgical, 4-line addition

### Step 2.2: Code Flow Change
**Record:**
- **Hunk (DMI table):** Before — Kulnex/Moxoe unmatched →
  `cros_ec_cec_find_hdmi_dev()` warns and returns `-ENODEV`. After —
  boards match like Brask/Moxie, DRM HDMI device (`0000:00:02.0`) and
  `port_b_conns` mapping are selected, probe can succeed.

### Step 2.3: Bug Mechanism
**Record:**
- **Category:** hardware identification / platform quirk (DMI-based
  board whitelist)
- **Mechanism:** Without a table entry, probe path in
  `cros_ec_cec_probe()` exits early:

```501:503:drivers/media/cec/platform/cros-ec/cros-ec-cec.c
        hdmi_dev = cros_ec_cec_find_hdmi_dev(&pdev->dev, &conns);
        if (IS_ERR(hdmi_dev))
                return PTR_ERR(hdmi_dev);
```

And the lookup function explicitly documents that hardware must be added
to the table:

```362:365:drivers/media/cec/platform/cros-ec/cros-ec-cec.c
        /* Hardware support must be added in the cec_dmi_match_table */
        dev_warn(dev, "CEC notifier not configured for this
hardware\n");

        return ERR_PTR(-ENODEV);
```

### Step 2.4: Fix Quality Assessment
**Record:** Obviously correct — copies the proven Brask/Moxie pattern
(`port_b_conns`, same PCI DRM device name). Minimal diff. Regression
risk is very low: only affects DMI matches for "Google"/"Kulnex" and
"Google"/"Moxoe".

---

## Phase 3: Git History Investigation

### Step 3.1: Blame the Changed Lines
**Record:** The DMI table (lines 304–337) exists in this tree ending at
Moxie; Kulnex/Moxoe are absent. Git history in this checkout is heavily
rewritten/squashed (file history is unreliable), but the driver and full
match table are present since at least `ac3fd01e4c1ef` (Linux 6.18-rc7).
The "missing entry" condition is present in 6.18.43.

### Step 3.2: Follow Fixes: Tag
**Record:** N/A — no `Fixes:` tag.

### Step 3.3: File History for Related Changes
**Record:** The driver has accumulated many Google board entries (Fizz,
Brask, Moli, …, Moxie). This commit continues that pattern. Standalone
one-commit change; not part of a multi-patch series.

### Step 3.4: Author's Other Commits
**Record:** Ken Lin has no other commits visible in this checkout. Hans
Verkuil is the media/CEC maintainer and signed off. No related author
series found here.

### Step 3.5: Dependent/Prerequisite Commits
**Record:** No dependencies. Driver, `port_b_conns`, DMI/PCI
infrastructure, and `CONFIG_CEC_CROS_EC` all exist in this tree. Applies
standalone.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original Patch Discussion
**Record:** `b4 dig -c 4b3f9bff6067a` failed — commit hash not in local
repo. Lore search blocked (403/bot protection). **UNVERIFIED:** original
thread content, reviewer stable nominations, series revisions.

### Step 4.2: Reviewers
**Record:** **UNVERIFIED** via `b4 dig -w`. Hans Verkuil SOB confirms
maintainer involvement.

### Step 4.3: Bug Report
**Record:** N/A — no Reported-by or Link tags.

### Step 4.4: Related Patches/Series
**Record:** Same pattern as prior Brask/Moxie/Kinox additions to this
table. Standalone.

### Step 4.5: Stable Mailing List History
**Record:** **UNVERIFIED** — could not search lore stable archive.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Functions
**Record:** `cec_dmi_match_table[]` (data),
`cros_ec_cec_find_hdmi_dev()`, called from `cros_ec_cec_probe()`.

### Step 5.2: Trace Callers
**Record:** `cros_ec_cec_probe()` is the platform driver probe path
during boot/module load on Chromebooks with `CONFIG_CEC_CROS_EC` and
`CONFIG_CROS_EC`. Affects only matching Google hardware.

### Step 5.3: Trace Callees
**Record:** `dmi_match()`, `bus_find_device_by_name()` on PCI bus,
connector mapping via `port_b_conns`.

### Step 5.4: Call Chain / Reachability
**Record:** Boot-time platform probe on ChromeOS EC-equipped Google
devices. Not a syscall path. Userspace impact is missing `/dev/cec*` and
non-functional HDMI CEC on Kulnex/Moxoe.

### Step 5.5: Similar Patterns
**Record:** Fifteen other Google boards already use the same table
pattern; Brask and Moxie use identical `port_b_conns` mapping, matching
the commit message claim.

---

## Phase 6: Cross-Referencing Against Local Tree (6.18.43)

### Step 6.1: Does the Buggy Code Exist?
**Record:** **YES.** Local tree is `6.18.43`
(`v6.18.43-1-gc7f0dac02d232`). `drivers/media/cec/platform/cros-ec/cros-
ec-cec.c` exists (602 lines). Table ends at Moxie; Kulnex/Moxoe are
missing. Driver has been present since 6.18-rc7 in this tree.

### Step 6.2: Backport Complications
**Record:** **Clean apply expected.** Verified with `git apply --check`
against current tree — applies without conflicts.

### Step 6.3: Related Fixes Already Present?
**Record:** No — `grep` finds no Kulnex or Moxoe anywhere in the tree.

---

## Phase 7: Subsystem and Maintainer Context

### Step 7.1: Subsystem and Criticality
**Record:** `drivers/media/cec/` — media/CEC platform driver.
**IMPORTANT** for affected Chromebook users, **PERIPHERAL** globally
(CEC on two specific Google boards).

### Step 7.2: Subsystem Activity
**Record:** CEC subsystem is active in this tree (recent fixes for seco,
rc race, debugfs leak). The cros-ec driver itself is mature with a
growing DMI whitelist.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who Is Affected
**Record:** Users of Google Kulnex and Moxoe Chromebooks with
`CONFIG_CEC_CROS_EC=y/m`. Config- and platform-specific; not universal.

### Step 8.2: Trigger Conditions
**Record:** Booting one of these two board models with the cros-ec-cec
driver enabled. Deterministic on every boot. Not a security-relevant or
unprivileged-triggered path.

### Step 8.3: Failure Mode Severity
**Record:** HDMI CEC non-functional; driver probe returns `-ENODEV` with
a warning. **Severity: LOW** — feature absence, not crash, corruption,
deadlock, or security issue.

### Step 8.4: Risk-Benefit Ratio
**Record:**
- **Benefit:** Enables HDMI CEC on two new Chromebook models running
  this kernel; matches established board-enablement pattern.
- **Risk:** Very low — 4 lines, no logic change, only new DMI strings.
- **Ratio:** Moderate benefit for a tiny audience vs. very low risk.
  Does not meet strict "important bug" threshold, but fits the stable
  exception for hardware identification additions.

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence Compile

**FOR backport:**
- Driver and infrastructure fully present in 6.18.43
- Real hardware gap on Kulnex/Moxoe — CEC broken without entries
- Tiny, obviously correct, applies cleanly
- Follows proven Brask/Moxie `port_b_conns` mapping
- Media maintainer (Hans Verkuil) signed off
- Fits stable exception for hardware identification / quirk additions
  (DMI board ID to existing driver)

**AGAINST backport:**
- Not a crash, security, corruption, or deadlock fix
- Failure mode is missing functionality (CEC), severity LOW
- Affects only two specific new Chromebook models
- No user reports, syzbot, or explicit stable nomination
- By-design whitelist: unsupported boards get `-ENODEV`, not a code
  defect on already-supported hardware
- Mailing list review details unverified

**UNRESOLVED:**
- Whether Kulnex/Moxoe actually ship with 6.18.y kernels
- Lore discussion and any stable nominations from reviewers

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — mechanical table entries;
   maintainer SOB; pattern proven on Brask/Moxie.
2. Fixes a real bug affecting users? **PASS (narrow)** — real hardware
   support gap for CEC on two boards, not a kernel logic bug.
3. Important issue (crash, security, corruption, deadlock)? **FAIL** —
   CEC absence only; LOW severity.
4. Small and contained? **PASS** — 4 lines, one file.
5. No new features or APIs? **PASS** — no API change; board ID addition
   to existing driver.
6. Can apply to local tree? **PASS** — verified clean apply.

### Step 9.3: Exception Categories
**Record:** **Hardware identification / quirk exception** — DMI match
table entry for an existing platform driver, analogous to adding
PCI/USB/ACPI IDs. Same category as prior Brask, Moxie, Kinox entries.

### Step 9.4: Decision Rationale

This commit does not fix a critical kernel defect. It enables HDMI CEC
on two new Google Chromebook platforms by extending the existing DMI
whitelist in `cros-ec-cec`. That is standard stable material under the
hardware-identification exception: the driver already exists in 6.18.43,
the change is trivial and low-risk, and it unblocks real hardware for
users on those boards. It does not meet the strict "important bug"
criterion on its own, but stable trees routinely take such board-ID
additions when the driver is already present.

For the locally checked-out **6.18.43** tree: the driver exists, the gap
exists, and the patch applies cleanly.

---

## Verification

- **[Phase 1]** Parsed subject, tags, body: hardware enablement for
  Kulnex/Moxoe CEC; Hans Verkuil SOB; no Fixes/Reported-
  by/Link/Cc:stable
- **[Phase 2]** Diff: +4 lines in `cec_dmi_match_table[]`; probe failure
  path confirmed in source
- **[Phase 3]** `git describe HEAD`: v6.18.43-1-gc7f0dac02d232; `make
  kernelversion`: 6.18.43
- **[Phase 3]** `git show ac3fd01e4c1ef:...cros-ec-cec.c`: driver
  present since 6.18-rc7; Moxie present, Kulnex/Moxoe absent
- **[Phase 3]** `grep Kulnex|Moxoe`: no matches in tree
- **[Phase 3]** Git history in this repo is rewritten/unreliable for
  blame; table content verified directly
- **[Phase 4]** `b4 dig -c 4b3f9bff6067a`: failed (commit not in repo)
- **[Phase 4]** Lore fetch: blocked (403/bot protection) —
  **UNVERIFIED** mailing list discussion
- **[Phase 5]** Read `cros_ec_cec_probe()` and
  `cros_ec_cec_find_hdmi_dev()`: confirmed `-ENODEV` path
- **[Phase 5]** `grep cros_ec_cec_find_hdmi_dev`: only called from probe
- **[Phase 6]** File exists at `drivers/media/cec/platform/cros-ec/cros-
  ec-cec.c` (602 lines)
- **[Phase 6]** `git apply --check /tmp/kulnex.patch`: applies cleanly
- **[Phase 6]** `grep Kulnex|Moxoe`: absent from tree
- **[Phase 7]** `CONFIG_CEC_CROS_EC` in
  `drivers/media/cec/platform/Kconfig`; depends on `CROS_EC`
- **[Phase 8]** Failure mode verified: `-ENODEV` + `dev_warn`, not
  oops/panic

**YES**

 drivers/media/cec/platform/cros-ec/cros-ec-cec.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/cec/platform/cros-ec/cros-ec-cec.c b/drivers/media/cec/platform/cros-ec/cros-ec-cec.c
index 419b9a7abcceb..4b3f9bff6067a 100644
--- a/drivers/media/cec/platform/cros-ec/cros-ec-cec.c
+++ b/drivers/media/cec/platform/cros-ec/cros-ec-cec.c
@@ -334,6 +334,10 @@ static const struct cec_dmi_match cec_dmi_match_table[] = {
 	{ "Google", "Dirks", "0000:00:02.0", port_ab_conns },
 	/* Google Moxie */
 	{ "Google", "Moxie", "0000:00:02.0", port_b_conns },
+	/* Google Kulnex */
+	{ "Google", "Kulnex", "0000:00:02.0", port_b_conns },
+	/* Google Moxoe */
+	{ "Google", "Moxoe", "0000:00:02.0", port_b_conns },
 };
 
 static struct device *cros_ec_cec_find_hdmi_dev(struct device *dev,
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] media: em28xx-video: fix missing res_free() on init_usb_xfer failure

[Sasha Levin]

From: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>

[ Upstream commit cc20e81da6d99926f94fad7af21f75c07e865769 ]

res_get() is called before em28xx_init_usb_xfer(), but the error
path of em28xx_init_usb_xfer() does not release the resource,
leading to a persistent busy state.

Signed-off-by: Haoxiang Li <lihaoxiang@isrc.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:

## Phase 1: Commit Message Forensics

### Step 1.1: Subject line
**Record:** `[media: em28xx-video]` `[fix]` — missing `res_free()` on
`em28xx_init_usb_xfer()` failure in `em28xx_start_analog_streaming()`.

### Step 1.2: Commit message tags
**Record:**
- **Fixes:** — not present (expected for manual review)
- **Reported-by:** — none
- **Tested-by:** — none
- **Reviewed-by:** — none in message (Hans Verkuil appears only as
  Signed-off-by)
- **Link:** — none
- **Cc: stable:** — none
- **Signed-off-by:** Haoxiang Li (author), Hans Verkuil (V4L2/media
  maintainer)

No syzbot, no multi-reporter signals. Hans Verkuil's sign-off is a
quality indicator.

### Step 1.3: Commit body analysis
**Record:**
- **Bug:** `res_get()` is called before `em28xx_init_usb_xfer()`, but
  the error return path does not call `res_free()`.
- **Symptom:** Persistent busy state — `dev->resources` stays set for
  VIDEO or VBI.
- **Root cause (author):** Missing cleanup on the
  `em28xx_init_usb_xfer()` failure path.
- **Version info:** None in the message. Patch was submitted April 2026
  and merged for v7.2 media pull.

### Step 1.4: Hidden bug fix detection
**Record:** Not disguised — explicitly labeled a fix. This is an error-
path resource-leak fix (missing `res_free()`), a well-known stable
backport category.

---

## Phase 2: Diff Analysis

### Step 2.1: Change inventory
**Record:**
- **File:** `drivers/media/usb/em28xx/em28xx-video.c` (+3 / -1 lines)
- **Function:** `em28xx_start_analog_streaming()`
- **Scope:** Single-file, surgical fix in one error path

### Step 2.2: Code flow change
**Record:**
- **Before:** On `em28xx_init_usb_xfer()` failure → `return rc` with
  resource still held.
- **After:** On failure → `res_free(dev, vq->type)` then `return rc`.
- **Path affected:** First streaming user (`streaming_users == 0`), USB
  xfer initialization error path only.

### Step 2.3: Bug mechanism
**Record:** **Category:** Error-path resource leak / reference-style
lock not released.

Mechanism verified in tree:
1. Line 1085: `res_get(dev, vq->type)` sets `dev->resources` bit.
2. Lines 1102–1107: `em28xx_init_usb_xfer()` may fail (URB alloc,
   `usb_clear_halt`, `usb_submit_urb`).
3. Lines 1108–1109 (current tree): early `return rc` without
   `res_free()`.
4. `streaming_users++` at line 1132 is never reached on this path.
5. videobuf2 does **not** call `stop_streaming` when `start_streaming`
   fails (`start_streaming_called` cleared at line 1794 of
   `videobuf2-core.c` without invoking `stop_streaming`).

### Step 2.4: Fix quality
**Record:** Obviously correct — mirrors `res_free()` already called
unconditionally in `em28xx_stop_streaming()` (line 1146) and
`em28xx_stop_vbi_streaming()` (line 1181). Minimal, no API changes.
Regression risk: very low.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame
**Record:** Buggy lines (1085–1109) blame to `5d324e5159d9e` (Merge tag
'usb-6.18-rc8', Nov 2025). `res_get`/`res_free` helpers and the
`res_get()` before `em28xx_init_usb_xfer()` pattern are part of the
driver as present in this 6.18.y tree. Shallow history here (file added
in that merge); the resource-lock pattern is longstanding em28xx design,
not a recent regression.

### Step 3.2: Fixes: tag
**Record:** N/A — no `Fixes:` tag.

### Step 3.3: Related file history
**Record:** Recent commits on `drivers/media/usb/em28xx/` in this tree:
- `871b8ea8ef39a` — em28xx UAF fix in `em28xx_v4l2_open()` (already
  backported to 6.18.y)
- `5d324e5159d9e` — merge bringing em28xx driver into this tree

Standalone fix; not part of a multi-patch series.

### Step 3.4: Author context
**Record:** Haoxiang Li — contributor (also has other stable-nominated
resource-leak fixes in wider kernel). Hans Verkuil signed off —
V4L2/media subsystem maintainer.

### Step 3.5: Dependencies
**Record:** None. Patch applies cleanly (`git apply --check` exit 0). No
prerequisite commits required.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original patch discussion
**Record:** Found at
https://www.spinics.net/lists/kernel/msg6153558.html (Apr 14, 2026).
Single-patch submission to Mauro Chehab. Follow-up from Markus Elfring
listed but content not retrieved (fetch timeout). No NAK visible in
available thread content. `b4 dig -c` could not run — commit hash not in
this checkout.

### Step 4.2: Reviewers
**Record:** CC'd: `linux-media@`, `linux-kernel@`, Mauro Chehab. Hans
Verkuil sign-off indicates maintainer acceptance.

### Step 4.3: Bug report
**Record:** No external bug report, syzbot, or user Reported-by. Bug
identified by code-path analysis.

### Step 4.4: Related patches
**Record:** Included in v7.2 media pull (lists.openwall.net).
Standalone; no series dependencies.

### Step 4.5: Stable list history
**Record:** No stable-specific discussion found. Patch does not include
`Cc: stable@vger.kernel.org`.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key functions
**Record:** `em28xx_start_analog_streaming()`, `res_get()`,
`res_free()`, `em28xx_init_usb_xfer()`.

### Step 5.2: Callers
**Record:** `em28xx_start_analog_streaming` is the vb2
`.start_streaming` callback for:
- Video capture queue (`em28xx_video_qops`, line 1230)
- VBI capture queue (`em28xx-vbi.c`, line 85)

Triggered via VIDIOC_STREAMON → vb2 → driver start path. Common
userspace capture path.

### Step 5.3: Callees
**Record:** `res_get()` → checks/sets `dev->resources`;
`em28xx_init_usb_xfer()` → URB alloc/submit, USB I/O; `res_free()` →
clears resource bit.

### Step 5.4: Reachability
**Record:** Reachable from userspace via V4L2 streaming ioctl on em28xx
devices (`CONFIG_VIDEO_EM28XX`). Unprivileged users with device access
can trigger streaming start. Failure conditions (USB errors, ENOMEM,
bandwidth) are realistic though not every-boot common.

### Step 5.5: Similar patterns
**Record:** Normal success path relies on `em28xx_stop_streaming()` /
`em28xx_stop_vbi_streaming()` for `res_free()`. The missing cleanup is
unique to the early-error path before `streaming_users++` — consistent
with vb2 semantics (no `stop_streaming` on failed `start_streaming`).

---

## Phase 6: Cross-Reference Against Local Tree

### Step 6.1: Buggy code in this tree?
**Record:** **YES.** Tree is `v6.18.43` (`stable/linux-6.18.y`, `make
kernelversion` = 6.18.43). Current code at lines 1108–1109 lacks
`res_free()` on error. Fix is **not** yet applied.

### Step 6.2: Backport complications
**Record:** **Clean apply** — verified with `git apply --check`. No
conflicts expected.

### Step 6.3: Related fixes already present?
**Record:** Related em28xx fix `871b8ea8ef39a` (UAF in open) is present;
this `res_free` fix is **not** present.

---

## Phase 7: Subsystem Context

### Step 7.1: Subsystem criticality
**Record:** `drivers/media/usb/em28xx` — **PERIPHERAL** driver (USB
analog TV/capture dongles). Important for users of that hardware, not
universal.

### Step 7.2: Subsystem activity
**Record:** Low churn in this 6.18.y tree (3 commits on em28xx path).
Driver is mature; recent activity includes stable-worthy bug fixes.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who is affected
**Record:** Users of Empia EM28xx USB capture devices with
`CONFIG_VIDEO_EM28XX` enabled.

### Step 8.2: Trigger conditions
**Record:** VIDIOC_STREAMON when `em28xx_init_usb_xfer()` fails (URB
allocation, USB halt clear, URB submit). Realistic on USB errors or
resource pressure. Userspace-triggerable by device node holders.

### Step 8.3: Failure mode severity
**Record:** Resource bit stuck → subsequent streaming attempts get
`-EBUSY` from `res_get()` (line 861). Device remains unusable for that
buffer type until unplug/reprobe. **Severity: MEDIUM** — functional
breakage, not kernel crash, data corruption, or security issue.

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** Restores recoverability after transient USB init
  failures; prevents permanent device busy state.
- **Risk:** Very low — 3-line symmetric cleanup on documented error
  path.
- **Ratio:** Favorable for stable; conservative fix aligned with vb2
  driver contract.

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence summary

**FOR backport:**
- Real, verifiable resource leak on error path
- User-visible persistent `-EBUSY` until device reset
- vb2 contract requires driver self-cleanup on failed `start_streaming`
  — fix does exactly that
- Minimal (3 lines), applies cleanly to 6.18.43
- Signed off by media maintainer Hans Verkuil
- Buggy code confirmed present in this tree

**AGAINST backport:**
- No crash, security issue, or data corruption
- Driver-specific; limited user base
- No fuzzer/user reports documenting field impact
- Failure path may be uncommon

**Unresolved:** Exact mainline commit SHA not in this checkout; Markus
Elfring review reply not read; no explicit stable nomination on list.

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** — logic mirrors existing
   `stop_streaming` cleanup; maintainer sign-off
2. Fixes real bug affecting users? **PASS** — persistent busy state on
   em28xx hardware
3. Important issue? **PASS** — MEDIUM severity functional breakage
   requiring device reset
4. Small and contained? **PASS** — 3 lines, one function
5. No new features/APIs? **PASS**
6. Can apply to local tree? **PASS** — clean apply verified

### Step 9.3: Exception categories
**Record:** None (not device ID, quirk, DT, build, or docs). Standard
error-path bug fix.

### Step 9.4: Decision rationale

For **linux-6.18.y (v6.18.43)**, this commit should be backported. The
buggy pattern exists in the checked-out tree, the fix is minimal and
obviously correct, and it addresses a real driver bug where a failed
stream start leaves the device permanently busy because videobuf2 does
not invoke `stop_streaming` on `start_streaming` failure. While impact
is limited to em28xx users and severity is functional rather than
catastrophic, stable trees routinely accept such error-path resource
leaks that brick device operation until physical reset.

---

## Verification

- **[Phase 1]** `git describe HEAD` → `v6.18.43-1-gc7f0dac02d232`; `make
  kernelversion` → `6.18.43`
- **[Phase 1]** Parsed commit message from user query and spinics mirror
- **[Phase 2]** Read `em28xx_start_analog_streaming()` lines 1069–1135;
  confirmed missing `res_free` on error
- **[Phase 2]** Read `res_get()`/`res_free()` at lines 854–876
- **[Phase 2]** Read `em28xx_init_usb_xfer()` failure paths in `em28xx-
  core.c` lines 1021–1052
- **[Phase 3]** `git blame -L 1085,1110` → all lines from
  `5d324e5159d9e`
- **[Phase 3]** `git log --oneline -20 -- drivers/media/usb/em28xx/` → 3
  commits including UAF fix
- **[Phase 4]** WebFetch spinics msg6153558 — patch content and
  submission date confirmed
- **[Phase 4]** Web search — patch in v7.2 media pull; `b4 dig -c`
  failed (commit not in tree)
- **[Phase 5]** Grep callers — video and VBI queues use
  `em28xx_start_analog_streaming`
- **[Phase 5]** Read `vb2_start_streaming()` lines 1775–1828 — no
  `stop_streaming` on failure
- **[Phase 5]** Read `__vb2_queue_cancel()` lines 2210–2211 —
  `stop_streaming` only if `start_streaming_called`
- **[Phase 6]** Confirmed buggy lines 1108–1109 in working tree
- **[Phase 6]** `git apply --check` with patch → exit 0 (clean apply)
- **[Phase 6]** `git diff HEAD -- em28xx-video.c` — fix not already
  applied
- **[Phase 8]** Verified `res_get()` returns `-EBUSY` when resource held
  (line 861)
- **UNVERIFIED:** Markus Elfring review reply content; exact mainline
  commit SHA; how long `res_get` before `init_usb_xfer` has existed in
  mainline pre-6.18

**YES**The background `git log -S "res_get(dev, vq->type)" --all` search
was stopped — `--all` scans too many branches and had been running for
90+ seconds. The same question was already answered with a targeted
search: in this 6.18.43 tree, that pattern dates to `5d324e5159d9e`, and
the buggy error path is still present at lines 1108–1109.

**Verdict unchanged: YES** — backport the missing `res_free()` on
`em28xx_init_usb_xfer()` failure; it’s a small, clean fix for a real
resource leak that leaves em28xx devices stuck busy until unplug.

 drivers/media/usb/em28xx/em28xx-video.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/em28xx/em28xx-video.c b/drivers/media/usb/em28xx/em28xx-video.c
index 14c35995cd952..c8514682bccda 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -1105,8 +1105,10 @@ int em28xx_start_analog_streaming(struct vb2_queue *vq, unsigned int count)
 					  dev->max_pkt_size,
 					  dev->packet_multiplier,
 					  em28xx_urb_data_copy);
-		if (rc < 0)
+		if (rc < 0) {
+			res_free(dev, vq->type);
 			return rc;
+		}
 
 		/*
 		 * djh: it's not clear whether this code is still needed.  I'm
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.12] media: qcom: camss: avoid format string warning

[Sasha Levin]

From: Arnd Bergmann <arnd@arndb.de>

[ Upstream commit 797c1cbf672f372d6a464df0dcedf476fc715969 ]

clang-22 warns about csiphy_match_clock_name() taking a variable format
string that is not checked against the 'int index' argument:

drivers/media/platform/qcom/camss/camss-csiphy.c:566:44: error: diagnostic behavior may be improved by
      adding the 'format(printf, 2, 3)' attribute to the declaration of 'csiphy_match_clock_name'
      [-Werror,-Wmissing-format-attribute]
  561 | static bool csiphy_match_clock_name(const char *clock_name, const char *format,
      | __attribute__((format(printf, 2, 3)))
  562 |                                     int index)
  563 | {
  564 |         char name[16]; /* csiphyXXX_timer\0 */
  565 |
  566 |         snprintf(name, sizeof(name), format, index);
      |                                                   ^
drivers/media/platform/qcom/camss/camss-csiphy.c:561:13: note: 'csiphy_match_clock_name' declared here
  561 | static bool csiphy_match_clock_name(const char *clock_name, const char *format,
      |             ^

Change the function to use a snprintf() style format string that allows this
to be checked at the call site.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

**Step 1.1 Record:** Subsystem `media: qcom: camss`; action verb
`avoid`; claimed intent is to silence/fix a clang-22 `-Wmissing-format-
attribute` diagnostic in `csiphy_match_clock_name()`.

**Step 1.2 Record:** Tags present in the submission (verified via lore):
- `Fixes: 0727615fb975 ("media: qcom: camss: Functionally decompose
  CSIPHY clock lookups")`
- `Signed-off-by: Arnd Bergmann <arnd@arndb.de>`
- `Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>`
- `Signed-off-by: Bryan O'Donoghue <bod@kernel.org>`
- No `Reported-by`, `Tested-by`, `Cc: stable`, or bug-report `Link`
  tags.

**Step 1.3 Record:** Bug is a **build failure**, not a runtime defect.
With clang-22 and `-Werror,-Wmissing-format-attribute`,
`csiphy_match_clock_name()` passes a variable `format` to `snprintf()`
without a printf-style attribute, so the compiler errors out. Symptom:
kernel build fails when `CONFIG_VIDEO_QCOM_CAMSS` is enabled under those
compiler flags. Root cause: helper takes `const char *format, int index`
and uses `snprintf(name, ..., format, index)` without `__printf(2, 3)`.

**Step 1.4 Record:** Not a hidden runtime bug fix. This is an explicit
compiler-warning/build fix disguised as "avoid warning," but it does
prevent real build breakage in clang-22 + Werror configurations.

---

## Phase 2: Diff Analysis

**Step 2.1 Record:** One file changed:
`drivers/media/platform/qcom/camss/camss-csiphy.c` (+7/-3). Function
modified: `csiphy_match_clock_name()`. Scope: single-file, surgical.

**Step 2.2 Record:**
- **Before:** `csiphy_match_clock_name(clock_name, format, index)` calls
  `snprintf(name, sizeof(name), format, index)`.
- **After:** Function becomes `__printf(2, 3)
  csiphy_match_clock_name(clock_name, format, ...)` using `va_list` +
  `vsnprintf()`. Call sites are unchanged and still pass literal format
  strings plus `csiphy->id`.

**Step 2.3 Record:** Bug category: **build fix / compiler diagnostic
fix**. Mechanism: adding `__printf(2, 3)` lets clang verify format
strings at call sites; variadic args preserve existing behavior.

**Step 2.4 Record:** Fix is obviously correct and minimal. Call sites at
lines 678–692 still pass `"csiphy%d_timer"`, `"csi%d_phy"`, and
`"csiphy%d"` with `csiphy->id` — compatible with variadic calling.
Regression risk is very low; behavior is equivalent to the old
`snprintf()` path. `linux/kernel.h` (already included) provides
`va_list` support, matching the pattern used in the already-backported
`clk: qoriq` fix in this tree.

---

## Phase 3: Git History Investigation

**Step 3.1 Record:** Current tree at `camss-csiphy.c:561–567` still has
the pre-fix code. `git blame` attributes those lines to merge commit
`5d324e5159d9e`. The `csiphy_match_clock_name()` helper pattern dates to
commit `0727615fb975` (Oct 2023, "Functionally decompose CSIPHY clock
lookups").

**Step 3.2 Record:** `Fixes: 0727615fb975` exists in the object database
and introduced the helper. The buggy pattern is present in the checked-
out `6.18.43` tree. The fix commit itself is **not** yet in this tree.

**Step 3.3 Record:** Related recent camss commits in this tree are
runtime fixes (RDI streaming, VFE lite clocks). No duplicate fix for
this warning. **Precedent:** `558b2eb623f2f` (`clk: qoriq: avoid format
string warning`) — same author, same clang-22 issue, same
variadic/`__printf` pattern — was already backported to this `6.18.y`
tree by Greg Kroah-Hartman.

**Step 3.4 Record:** Arnd Bergmann is a frequent contributor of clang
build-warning fixes across the kernel. Bryan O'Donoghue is the camss
subsystem author/maintainer and reviewed the patch.

**Step 3.5 Record:** No series dependencies. Standalone, self-contained.
Call sites require no changes.

---

## Phase 4: Mailing List and External Research

**Step 4.1 Record:** Original submission at [lore.kernel.org patch
thread](https://lkml.iu.edu/2603.2/11306.html) (2026-03-20). Bryan
O'Donoghue replied with `Reviewed-by` ([spinics
thread](https://www.spinics.net/lists/kernel/msg6110456.html)). No NAKs
found. No explicit stable nomination in the thread. `b4 dig -c <hash>`
failed (commit not present locally); lore fetch used instead.

**Step 4.2 Record:** CC list included linux-media, linux-arm-msm, llvm@,
and subsystem maintainers (Hans Verkuil, Bryan O'Donoghue, etc.).
Appropriate reviewers were involved.

**Step 4.3 Record:** No user bug report or syzbot report. Failure mode
documented only via clang compiler output in the commit message.

**Step 4.4 Record:** Standalone patch, not part of a multi-patch series.
Autosel pipeline has nominated a variant for `6.12.y` (seen in web
search), indicating automated stable consideration of this class of fix.

**Step 4.5 Record:** No stable-list discussion found beyond autosel
nomination. Not applicable otherwise.

---

## Phase 5: Code Semantic Analysis

**Step 5.1 Record:** Modified function: `csiphy_match_clock_name()`.
Caller context: `msm_csiphy_subdev_init()` clock-setup loop.

**Step 5.2 Record:** Three call sites in `msm_csiphy_subdev_init()`
(lines 678, 685, 692), all during CSIPHY probe/initialization when
`CONFIG_VIDEO_QCOM_CAMSS` is enabled on Qualcomm platforms.

**Step 5.3 Record:** Callees: `va_start`, `vsnprintf`, `va_end`,
`strcmp`. No allocation, no locking.

**Step 5.4 Record:** Reachable during device probe for Qualcomm camera
hardware. Not syscall-reachable directly, but affects kernel
buildability for that driver — not a runtime user-triggerable crash.

**Step 5.5 Record:** Identical pattern fixed in `drivers/clk/clk-
qoriq.c` in this same tree (`558b2eb623f2f`). Part of a broader clang-22
`-Wmissing-format-attribute` cleanup effort by Arnd Bergmann.

---

## Phase 6: Cross-Referencing Against the Local Tree

**Step 6.1 Record:** Local tree is **Linux 6.18.43** (`git describe
HEAD` → `v6.18.43-1-gc7f0dac02d232`, `Makefile` VERSION 6.18.43). Buggy
code **is present** at `camss-csiphy.c:561–567`. Fix is **not** yet
applied.

**Step 6.2 Record:** Expected backport difficulty: **clean apply**. File
structure matches the upstream diff index (`62623393f414` parent in lore
matches current content pattern).

**Step 6.3 Record:** No equivalent fix already in tree. Sibling fix
`clk: qoriq: avoid format string warning` is present; camss variant is
not.

---

## Phase 7: Subsystem and Maintainer Context

**Step 7.1 Record:** Subsystem: `drivers/media/platform/qcom/camss` —
media platform driver for Qualcomm camera ISP. Criticality:
**PERIPHERAL** (hardware-specific, `CONFIG_VIDEO_QCOM_CAMSS`, ARM QCOM +
IOMMU).

**Step 7.2 Record:** camss is actively maintained in stable with recent
runtime fixes (RDI streaming, VFE lite). This patch is orthogonal to
those.

---

## Phase 8: Impact and Risk Assessment

**Step 8.1 Record:** Affected population: kernel **builders** compiling
`CONFIG_VIDEO_QCOM_CAMSS=y/m` with clang-22 and extra warnings (`W=1`
enables `-Wmissing-format-attribute` per
`scripts/Makefile.extrawarn:115`; `W=e` or `CONFIG_WERROR` promotes
warnings to errors per `scripts/Makefile.extrawarn:217–219`). Not
universal end-user runtime impact.

**Step 8.2 Record:** Trigger: build with clang-22 + `-Wmissing-format-
attribute` as error (e.g. `make W=1` or `W=e`, or `CONFIG_WERROR=y`).
Default builds without extra warnings are unaffected. Unprivileged users
cannot trigger this at runtime.

**Step 8.3 Record:** Failure mode: **compile-time error** — build abort.
Severity: **LOW** for deployed systems (no runtime crash/corruption);
**MEDIUM** for developers/distributions using clang CI with Werror.

**Step 8.4 Record:** Benefit: restores buildability under clang-22
Werror CI; aligns with already-accepted precedent in this tree. Risk:
very low (7-line localized change, maintainer-reviewed, no behavior
change). Risk-benefit: favorable for stable given build-fix policy and
existing qoriq backport.

---

## Phase 9: Final Synthesis

**Evidence FOR backport:**
- Qualifies as a **build fix** under stable-kernel-rules exceptions.
- Buggy code exists in this `6.18.43` tree; fix not yet applied.
- Small, surgical, maintainer-reviewed (`Reviewed-by: Bryan
  O'Donoghue`).
- **Direct precedent in this tree:** `558b2eb623f2f clk: qoriq: avoid
  format string warning` — identical issue class, same author, already
  backported to `6.18.y`.
- Prevents llvm/clang allmodconfig or `W=1`/`W=e` build failures.

**Evidence AGAINST backport:**
- Zero runtime user impact.
- Only affects non-default build configurations (extra warnings/Werror).
- Narrow scope: one optional driver on Qualcomm platforms.

**Stable rules checklist:**
1. Obviously correct and tested? **PASS** — straightforward
   variadic/`__printf` pattern; reviewed by subsystem maintainer.
2. Fixes a real bug affecting users? **PASS** — real build failure for
   clang-22 + Werror builders (not theoretical).
3. Important issue? **PASS (low severity)** — build breakage, not
   crash/corruption/security.
4. Small and contained? **PASS** — 1 file, ~10 lines.
5. No new features or APIs? **PASS** — internal static helper only.
6. Can apply to local tree? **PASS** — code present, clean apply
   expected.

**Exception category:** Build fix.

**Decision rationale for Linux 6.18.y:** The tree already accepts this
exact class of clang-22 format-attribute build fix (qoriq clk driver).
The camss variant is the same technical issue, same fix pattern, same
author, and the pre-fix code is present here. While runtime impact is
nil, stable policy explicitly includes build fixes, and this tree has
established precedent for backporting them.

---

## Verification

- [Phase 1] Parsed commit message and lore submission; tags recorded; no
  syzbot/user reports.
- [Phase 2] Read `camss-csiphy.c:561–692`; confirmed diff changes only
  `csiphy_match_clock_name()`; call sites unchanged.
- [Phase 3] `git describe HEAD` → v6.18.43; `git blame -L 561,570` →
  pre-fix code present; `git show 0727615fb975` → introduced helper Oct
  2023; `git show 558b2eb623f2f` → sibling fix already in tree.
- [Phase 3] `git log --grep="avoid format string warning"` → only qoriq
  fix present, not camss.
- [Phase 4] WebFetch lore submission and Bryan O'Donoghue review; `b4
  dig -c` failed (commit not in local repo).
- [Phase 5] `grep csiphy_match_clock_name` → 3 call sites in
  `msm_csiphy_subdev_init()`.
- [Phase 6] Confirmed tree version 6.18.43; buggy code at lines 561–567;
  fix absent.
- [Phase 6] Read `scripts/Makefile.extrawarn:113–115,217–219` →
  `-Wmissing-format-attribute` requires `W=1`; Werror requires `W=e` or
  `CONFIG_WERROR`.
- [Phase 6] Read `drivers/media/platform/qcom/camss/Kconfig` →
  `CONFIG_VIDEO_QCOM_CAMSS` depends on `ARCH_QCOM && IOMMU_DMA`.
- [Phase 7] `git log --oneline -5 -- drivers/media/platform/qcom/camss/`
  → active subsystem maintenance.
- [Phase 8] Assessed severity as compile-time only, LOW runtime / MEDIUM
  for clang CI builders.

**YES**

 drivers/media/platform/qcom/camss/camss-csiphy.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.c b/drivers/media/platform/qcom/camss/camss-csiphy.c
index 2de97f58f9ae4..74c77969db7ef 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy.c
@@ -558,12 +558,16 @@ static int csiphy_init_formats(struct v4l2_subdev *sd,
 	return csiphy_set_format(sd, fh ? fh->state : NULL, &format);
 }
 
-static bool csiphy_match_clock_name(const char *clock_name, const char *format,
-				    int index)
+static bool __printf(2, 3)
+csiphy_match_clock_name(const char *clock_name, const char *format, ...)
 {
 	char name[16]; /* csiphyXXX_timer\0 */
+	va_list args;
+
+	va_start(args, format);
+	vsnprintf(name, sizeof(name), format, args);
+	va_end(args);
 
-	snprintf(name, sizeof(name), format, index);
 	return !strcmp(clock_name, name);
 }
 
-- 
2.53.0

[PATCH AUTOSEL 6.18] media: qcom: camss: vfe-340: Proper client handling

[Sasha Levin]

From: Loic Poulain <loic.poulain@oss.qualcomm.com>

[ Upstream commit 880a3e40337e5ddf18ab8d8e07fe963de8789cbf ]

We need to properly map camss WM index to our internal WM client
instance. Today we only support RDI interfaces with the RDI_WM
macro, introduce a __wm_to_client helper to support any interface.

Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The background searches finished and line up with the earlier analysis:

- **`git log --grep="Proper client handling"`** — no matches in this
  tree, so that commit isn’t in v6.18.44 yet.
- **vfe-340 history** — only the initial TFE-340 bring-up
  (`acf8d084699e1`) plus a small header fix (`76d2d8f7b6348`); related
  CSID 340 fixes are present, but not this WM/client-mapping fix.

That supports the **YES** verdict: the bug is present on QCM2290 PIX
capture in this tree, and the fix still needs to be backported.

 .../media/platform/qcom/camss/camss-vfe-340.c | 84 ++++++++++---------
 1 file changed, 43 insertions(+), 41 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss-vfe-340.c b/drivers/media/platform/qcom/camss/camss-vfe-340.c
index 30d7630b3e8b3..d129b0d3a6edb 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe-340.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe-340.c
@@ -69,24 +69,19 @@
 #define TFE_BUS_FRAMEDROP_CFG_0(c)			BUS_REG(0x238 + (c) * 0x100)
 #define TFE_BUS_FRAMEDROP_CFG_1(c)			BUS_REG(0x23c + (c) * 0x100)
 
-/*
- * TODO: differentiate the port id based on requested type of RDI, BHIST etc
- *
- * TFE write master IDs (clients)
- *
- * BAYER		0
- * IDEAL_RAW		1
- * STATS_TINTLESS_BG	2
- * STATS_BHIST		3
- * STATS_AWB_BG		4
- * STATS_AEC_BG		5
- * STATS_BAF		6
- * RDI0			7
- * RDI1			8
- * RDI2			9
- */
-#define RDI_WM(n)		(7 + (n))
-#define TFE_WM_NUM		10
+enum tfe_client {
+	TFE_CLI_BAYER,
+	TFE_CLI_IDEAL_RAW,
+	TFE_CLI_STATS_TINTLESS_BG,
+	TFE_CLI_STATS_BHIST,
+	TFE_CLI_STATS_AWB_BG,
+	TFE_CLI_STATS_AEC_BG,
+	TFE_CLI_STATS_BAF,
+	TFE_CLI_RDI0,
+	TFE_CLI_RDI1,
+	TFE_CLI_RDI2,
+	TFE_CLI_NUM
+};
 
 enum tfe_iface {
 	TFE_IFACE_PIX,
@@ -108,6 +103,13 @@ enum tfe_subgroups {
 	TFE_SUBGROUP_NUM
 };
 
+static enum tfe_client tfe_wm_client_map[VFE_LINE_NUM_MAX] = {
+	[VFE_LINE_RDI0] = TFE_CLI_RDI0,
+	[VFE_LINE_RDI1] = TFE_CLI_RDI1,
+	[VFE_LINE_RDI2] = TFE_CLI_RDI2,
+	[VFE_LINE_PIX] = TFE_CLI_BAYER,
+};
+
 static enum tfe_iface tfe_line_iface_map[VFE_LINE_NUM_MAX] = {
 	[VFE_LINE_RDI0] = TFE_IFACE_RDI0,
 	[VFE_LINE_RDI1] = TFE_IFACE_RDI1,
@@ -209,10 +211,10 @@ static irqreturn_t vfe_isr(int irq, void *dev)
 	status = readl_relaxed(vfe->base + TFE_BUS_OVERFLOW_STATUS);
 	if (status) {
 		writel_relaxed(status, vfe->base + TFE_BUS_STATUS_CLEAR);
-		for (i = 0; i < TFE_WM_NUM; i++) {
+		for (i = 0; i < TFE_CLI_NUM; i++) {
 			if (status & BIT(i))
 				dev_err_ratelimited(vfe->camss->dev,
-						    "VFE%u: bus overflow for wm %u\n",
+						    "VFE%u: bus overflow for client %u\n",
 						    vfe->id, i);
 		}
 	}
@@ -235,49 +237,49 @@ static void vfe_enable_irq(struct vfe_device *vfe)
 	       TFE_BUS_IRQ_MASK_0_IMG_VIOL, vfe->base + TFE_BUS_IRQ_MASK_0);
 }
 
-static void vfe_wm_update(struct vfe_device *vfe, u8 rdi, u32 addr,
+static void vfe_wm_update(struct vfe_device *vfe, u8 wm, u32 addr,
 			  struct vfe_line *line)
 {
-	u8 wm = RDI_WM(rdi);
+	u8 client = tfe_wm_client_map[wm];
 
-	writel_relaxed(addr, vfe->base + TFE_BUS_IMAGE_ADDR(wm));
+	writel_relaxed(addr, vfe->base + TFE_BUS_IMAGE_ADDR(client));
 }
 
-static void vfe_wm_start(struct vfe_device *vfe, u8 rdi, struct vfe_line *line)
+static void vfe_wm_start(struct vfe_device *vfe, u8 wm, struct vfe_line *line)
 {
 	struct v4l2_pix_format_mplane *pix = &line->video_out.active_fmt.fmt.pix_mp;
 	u32 stride = pix->plane_fmt[0].bytesperline;
-	u8 wm = RDI_WM(rdi);
+	u8 client = tfe_wm_client_map[wm];
 
 	/* Configuration for plain RDI frames */
-	writel_relaxed(TFE_BUS_IMAGE_CFG_0_DEFAULT, vfe->base + TFE_BUS_IMAGE_CFG_0(wm));
-	writel_relaxed(0u, vfe->base + TFE_BUS_IMAGE_CFG_1(wm));
-	writel_relaxed(TFE_BUS_IMAGE_CFG_2_DEFAULT, vfe->base + TFE_BUS_IMAGE_CFG_2(wm));
-	writel_relaxed(stride * pix->height, vfe->base + TFE_BUS_FRAME_INCR(wm));
-	writel_relaxed(TFE_BUS_PACKER_CFG_FMT_PLAIN64, vfe->base + TFE_BUS_PACKER_CFG(wm));
+	writel_relaxed(TFE_BUS_IMAGE_CFG_0_DEFAULT, vfe->base + TFE_BUS_IMAGE_CFG_0(client));
+	writel_relaxed(0u, vfe->base + TFE_BUS_IMAGE_CFG_1(client));
+	writel_relaxed(TFE_BUS_IMAGE_CFG_2_DEFAULT, vfe->base + TFE_BUS_IMAGE_CFG_2(client));
+	writel_relaxed(stride * pix->height, vfe->base + TFE_BUS_FRAME_INCR(client));
+	writel_relaxed(TFE_BUS_PACKER_CFG_FMT_PLAIN64, vfe->base + TFE_BUS_PACKER_CFG(client));
 
 	/* No dropped frames, one irq per frame */
-	writel_relaxed(0, vfe->base + TFE_BUS_FRAMEDROP_CFG_0(wm));
-	writel_relaxed(1, vfe->base + TFE_BUS_FRAMEDROP_CFG_1(wm));
-	writel_relaxed(0, vfe->base + TFE_BUS_IRQ_SUBSAMPLE_CFG_0(wm));
-	writel_relaxed(1, vfe->base + TFE_BUS_IRQ_SUBSAMPLE_CFG_1(wm));
+	writel_relaxed(0, vfe->base + TFE_BUS_FRAMEDROP_CFG_0(client));
+	writel_relaxed(1, vfe->base + TFE_BUS_FRAMEDROP_CFG_1(client));
+	writel_relaxed(0, vfe->base + TFE_BUS_IRQ_SUBSAMPLE_CFG_0(client));
+	writel_relaxed(1, vfe->base + TFE_BUS_IRQ_SUBSAMPLE_CFG_1(client));
 
 	vfe_enable_irq(vfe);
 
 	writel(TFE_BUS_CLIENT_CFG_EN | TFE_BUS_CLIENT_CFG_MODE_FRAME,
-	       vfe->base + TFE_BUS_CLIENT_CFG(wm));
+	       vfe->base + TFE_BUS_CLIENT_CFG(client));
 
-	dev_dbg(vfe->camss->dev, "VFE%u: Started RDI%u width %u height %u stride %u\n",
-		vfe->id, rdi, pix->width, pix->height, stride);
+	dev_dbg(vfe->camss->dev, "VFE%u: Started client %u width %u height %u stride %u\n",
+		vfe->id, client, pix->width, pix->height, client);
 }
 
-static void vfe_wm_stop(struct vfe_device *vfe, u8 rdi)
+static void vfe_wm_stop(struct vfe_device *vfe, u8 wm)
 {
-	u8 wm = RDI_WM(rdi);
+	u8 client = tfe_wm_client_map[wm];
 
-	writel(0, vfe->base + TFE_BUS_CLIENT_CFG(wm));
+	writel(0, vfe->base + TFE_BUS_CLIENT_CFG(client));
 
-	dev_dbg(vfe->camss->dev, "VFE%u: Stopped RDI%u\n", vfe->id, rdi);
+	dev_dbg(vfe->camss->dev, "VFE%u: Stopped client %u\n", vfe->id, client);
 }
 
 static const struct camss_video_ops vfe_video_ops_520 = {
-- 
2.53.0