[PATCH AUTOSEL 7.0-5.10] ALSA: sparc/dbri: add missing fallthrough

[PATCH AUTOSEL 7.0-5.10] ALSA: sparc/dbri: add missing fallthrough

[Sasha Levin]

From: Rosen Penev <rosenp@gmail.com>

[ Upstream commit 2bcbb163162789d3488562073dbb99d9bd71a762 ]

Fixes compiler error with probably newer compilers:

sound/sparc/dbri.c:595:2: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
  595 |         case 1:
      |         ^
sound/sparc/dbri.c:595:2: note: insert 'break;' to avoid fall-through
  595 |         case 1:
      |         ^
      |         break;

Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260506031854.780411-1-rosenp@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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 `ALSA: sparc/dbri`; action verb `add`; intent
is to add a missing `fallthrough` annotation in `reverse_bytes()`.

Step 1.2 Record: Tags present: `Signed-off-by: Rosen Penev
<rosenp@gmail.com>`, `Link:
https://patch.msgid.link/20260506031854.780411-1-rosenp@gmail.com`,
`Signed-off-by: Takashi Iwai <tiwai@suse.de>`. No `Fixes:`, `Reported-
by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, or `Cc: stable`.

Step 1.3 Record: The commit body reports a concrete compiler error:
`-Werror,-Wimplicit-fallthrough` in `sound/sparc/dbri.c` at the
fallthrough from `case 2` to `case 1`. Symptom is a build failure for
this driver/config with a compiler that diagnoses this unannotated
fallthrough as an error. No kernel version is named. Root cause is an
intentional fallthrough lacking the kernel `fallthrough;` marker.

Step 1.4 Record: This is not a hidden runtime bug fix; it is an explicit
build fix. Build fixes are stable-acceptable when they repair
compilation of existing code.

## Phase 2: Diff Analysis

Step 2.1 Record: One file changed: `sound/sparc/dbri.c`, `+1/-0`. One
function modified: `reverse_bytes()`. Scope is a single-file, one-line
surgical build fix.

Step 2.2 Record: Before, `case 2` performed the final bit swap and
implicitly fell into `case 1`/`case 0`, which then `break`s. After, the
same fallthrough is explicitly annotated with `fallthrough;`. Runtime
control flow is unchanged.

Step 2.3 Record: Bug category is build fix / compiler diagnostic fix.
Specific mechanism: the kernel already annotates earlier intentional
fallthroughs in the same switch, but the `case 2` to `case 1`
fallthrough lacked the annotation, triggering `-Wimplicit-fallthrough`
as an error.

Step 2.4 Record: Fix quality is high: it is one line, uses the existing
kernel `fallthrough` pseudo-keyword, matches nearby code style in
current branches, and does not change APIs or runtime behavior.
Regression risk is very low.

## Phase 3: Git History Investigation

Step 3.1 Record: `git blame` on `2bcbb16316278^` attributes this code to
`c3c9a75ede23f`, but the repository is shallow/grafted there, so that is
not a reliable true introduction point. I verified the same missing
annotation exists in local stable-related branches `pending-5.4`,
`pending-5.10`, `pending-5.15`, `pending-6.1`, `pending-6.6`,
`pending-6.12`, `pending-6.19`, and `pending-7.0`.

Step 3.2 Record: No `Fixes:` tag is present, so there is no introducing
commit to follow from the message.

Step 3.3 Record: Recent `sound/sparc/dbri.c` history on `linux-
next/master` shows this commit, then `ALSA: sparc/dbri: Use guard() for
spin locks`, then the shallow boundary. The guard refactor is not a
semantic prerequisite for adding this annotation, although older stable
branches may have slightly different context.

Step 3.4 Record: Author Rosen Penev has this recent `sound/sparc` commit
in the checked history. The commit was applied by Takashi Iwai, and
`MAINTAINERS` lists Takashi Iwai and Jaroslav Kysela as SOUND
maintainers.

Step 3.5 Record: No dependent `reverse_bytes` commits were found by
subject search. The change can be applied standalone as an annotation.
For `pending-5.4`, context differs because earlier fallthroughs are
comments rather than `fallthrough;`, so that tree may need a trivial
backport adjustment.

## Phase 4: Mailing List And External Research

Step 4.1 Record: `b4 dig -c 2bcbb16316278` found the original submission
at the provided lore/patch URL. `b4 dig -a` found only v1; no later
revision. The saved mbox contains Takashi Iwai’s reply: “Applied now.
Thanks.” No NAKs or concerns were present in the fetched thread.

Step 4.2 Record: `b4 dig -w` shows recipients: Rosen Penev, `linux-
sound@vger.kernel.org`, Jaroslav Kysela, Takashi Iwai, and `linux-
kernel@vger.kernel.org`.

Step 4.3 Record: No separate bug report or `Reported-by` tag. The
reported failure is the compiler diagnostic included in the patch email
and commit message.

Step 4.4 Record: `b4 dig -a` shows this is a single-patch series, not
part of a multi-patch dependency chain.

Step 4.5 Record: WebFetch to lore/stable search was blocked by Anubis.
Local stable branch log searches did not find this exact fix or a
related `unannotated fall-through` fix already present in the checked
stable branches.

## Phase 5: Code Semantic Analysis

Step 5.1 Record: Modified function: `reverse_bytes()`.

Step 5.2 Record: Callers found in `sound/sparc/dbri.c`: `xmit_fixed()`
calls `reverse_bytes()` for MSB fixed-pipe transmit data;
`dbri_process_one_interrupt()` calls it for fixed-data receive
interrupts.

Step 5.3 Record: `reverse_bytes()` only performs bit manipulation and
may print an error for unsupported lengths; it does not allocate memory,
take locks, or call into external subsystems.

Step 5.4 Record: Runtime paths are reachable through DBRI/CS4215
initialization/control and interrupt handling on supported SPARC SBus
DBRI hardware. For this patch, runtime reachability is not the main
issue because the fix targets compilation and preserves runtime flow.

Step 5.5 Record: Nearby switch cases already had intentional fallthrough
annotations; this patch fills the only missing annotation in that chain.

## Phase 6: Stable Tree Analysis

Step 6.1 Record: The missing annotation exists in checked stable-related
branches from `pending-5.4` through `pending-7.0`. Therefore the
affected source is present in active stable-era trees available locally.

Step 6.2 Record: Expected backport difficulty is clean or trivial for
most branches. `pending-5.4` has older comment-style fallthrough context
before `case 2`, so it may require a small context adjustment, but the
same one-line semantic change applies.

Step 6.3 Record: No related fix with this subject or `unannotated fall-
through` in `sound/sparc/dbri.c` was found in the checked stable-related
branches.

## Phase 7: Subsystem And Maintainer Context

Step 7.1 Record: Subsystem is ALSA SPARC sound driver, specifically Sun
DBRI. Criticality is peripheral/platform-specific, not core kernel-wide.

Step 7.2 Record: Recent `sound/sparc` history is sparse and mostly
maintenance/refactoring/build-style changes, indicating a mature low-
churn driver area.

## Phase 8: Impact And Risk Assessment

Step 8.1 Record: Affected users are config/platform-specific: SPARC/SBus
builds with `SND_SUN_DBRI`.

Step 8.2 Record: Trigger is building this driver with a
compiler/configuration that treats the unannotated fallthrough warning
as an error. I did not independently reproduce the compiler failure
locally.

Step 8.3 Record: Failure mode is build failure, not runtime crash or
data corruption. Severity is high for affected builders because the
kernel/module cannot be built successfully under that toolchain/config.

Step 8.4 Record: Benefit is meaningful for affected stable users because
it restores buildability of an existing driver. Risk is very low: one
annotation line, no feature, no API change, no runtime logic change.
Risk-benefit ratio favors backporting.

## Phase 9: Final Synthesis

Step 9.1 Record: Evidence for backporting: concrete compiler error,
existing driver code in stable branches, one-line obviously-correct fix,
maintainer-applied patch, no runtime behavior change, and build fixes
are valid stable material. Evidence against: platform-specific impact
and no independent local build reproduction. Unresolved: exact true
historical introduction predates the shallow boundary; lore stable
search via WebFetch was blocked.

Step 9.2 Record: Stable rules checklist:
1. Obviously correct and tested: yes for correctness by inspection;
   maintainer applied it. No local build test performed.
2. Fixes a real bug: yes, reported compiler error in existing code.
3. Important issue: yes for affected stable builds, because it can stop
   compilation.
4. Small and contained: yes, one line in one function.
5. No new features/APIs: yes.
6. Can apply to stable trees: yes with at most trivial context
   adjustment, especially for older comment-style fallthrough branches.

Step 9.3 Record: Exception category applies: build fix.

Step 9.4 Record: Decision is to backport. This is exactly the kind of
low-risk build fix stable trees should carry.

## Verification

- [Phase 1] Parsed `git show --format=fuller --stat --patch
  2bcbb16316278`: confirmed subject, tags, compiler-error body, and one-
  line patch.
- [Phase 2] Read `sound/sparc/dbri.c`: confirmed `reverse_bytes()` has
  annotated fallthroughs except the candidate-added `case 2` annotation.
- [Phase 3] Ran `git blame 2bcbb16316278^ -L 578,598 --
  sound/sparc/dbri.c`: confirmed changed area, with shallow/grafted
  limitation.
- [Phase 3] Ran branch snippet checks on `pending-5.4` through
  `pending-7.0`: confirmed the missing annotation exists in all checked
  stable-related branches.
- [Phase 3] Ran recent file history and author history checks: found
  only related maintenance/refactor commits, no dependency series.
- [Phase 4] Ran `b4 dig -c`, `-a`, `-w`, and saved the mbox: confirmed
  single v1 patch, proper ALSA recipients, and maintainer “Applied now”
  reply.
- [Phase 5] Searched `reverse_bytes(` call sites: confirmed callers are
  `xmit_fixed()` and `dbri_process_one_interrupt()`.
- [Phase 6] Searched stable branch logs: no existing backport or
  duplicate fix found locally.
- [Phase 7] Checked `MAINTAINERS`: confirmed SOUND maintainers include
  Jaroslav Kysela and Takashi Iwai.
- [Phase 8] Checked `include/linux/compiler_attributes.h`: confirmed
  `fallthrough` is the intended kernel pseudo-keyword and is available
  in checked stable branches.
- UNVERIFIED: I did not reproduce the compiler error with a local
  SPARC/SBus DBRI build.
- UNVERIFIED: The exact original introduction before the repository’s
  shallow/grafted boundary could not be determined.
- UNVERIFIED: WebFetch could not read lore/stable search results because
  Anubis blocked the page.

**YES**

 sound/sparc/dbri.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/sparc/dbri.c b/sound/sparc/dbri.c
index 75f82a92ff44f..2f5f62079fa4a 100644
--- a/sound/sparc/dbri.c
+++ b/sound/sparc/dbri.c
@@ -592,6 +592,7 @@ static __u32 reverse_bytes(__u32 b, int len)
 		fallthrough;
 	case 2:
 		b = ((b & 0xaaaaaaaa) >> 1) | ((b & 0x55555555) << 1);
+		fallthrough;
 	case 1:
 	case 0:
 		break;
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.6] docs: cgroup-v1: Update charge-commit section

[Sasha Levin]

From: "T.J. Mercier" <tjmercier@google.com>

[ Upstream commit d8769544bde51b0ac980d10f8fe9f9fed6c95995 ]

Commit 1d8f136a421f ("memcg/hugetlb: remove memcg hugetlb
try-commit-cancel protocol") removed mem_cgroup_commit_charge() and
mem_cgroup_cancel_charge(), but the docs still refer to those functions.
There is no longer any charge cancellation.

Update the docs to match the code.

Signed-off-by: T.J. Mercier <tjmercier@google.com>
Signed-off-by: Tejun Heo <tj@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 `docs: cgroup-v1`; action verb `Update`;
intent: update `Documentation/admin-guide/cgroup-v1/memcg_test.rst` so
the charge-commit section matches current memcg code.

Step 1.2 Record: tags present: `Signed-off-by: T.J. Mercier
<tjmercier@google.com>` and `Signed-off-by: Tejun Heo <tj@kernel.org>`.
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`,
`Link:`, or `Cc: stable@vger.kernel.org` tags in the committed message.

Step 1.3 Record: the body says commit `1d8f136a421f` removed
`mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`, while the
cgroup-v1 memcg docs still name them and describe cancellation.
Symptom/failure mode: incorrect documentation only. Version information:
the referenced removal commit is from 2025-01-13 in the local object
database; candidate commit is from 2026-04-30. Root cause: docs were not
updated when the code was changed.

Step 1.4 Record: this is not a hidden runtime bug fix. It is an explicit
documentation correctness fix.

## Phase 2: Diff Analysis
Step 2.1 Record: one file changed: `Documentation/admin-
guide/cgroup-v1/memcg_test.rst`, `2 insertions(+), 4 deletions(-)`. No
functions modified. Scope: single-file documentation-only surgical
change.

Step 2.2 Record: before, the section was titled `charge-commit-cancel`,
listed `mem_cgroup_commit_charge()` or `mem_cgroup_cancel_charge()`, and
described `cancel()`. After, it is titled `charge-commit`, lists
`commit_charge()`, and removes the cancellation text.

Step 2.3 Record: bug category is documentation/comment correctness.
Specific mechanism: removes stale references to APIs that are absent in
current `6.19.y`/`7.0.y` code and in `origin/master`.

Step 2.4 Record: fix quality is obviously correct for trees whose memcg
code no longer has `mem_cgroup_commit_charge()` /
`mem_cgroup_cancel_charge()`. Regression risk is zero runtime risk, but
there is a branch-selection concern: `stable/linux-6.12.y` still
contains those functions, so this exact doc update would be misleading
there.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` before the candidate shows the stale doc
lines came from `f3f5edc5e41e` in this repository’s history. `git blame
origin/master` shows the changed lines attributed to `d8769544bde51`.

Step 3.2 Record: no `Fixes:` tag. I still inspected referenced commit
`1d8f136a421f26747e58c01281cba5bffae8d289`; it removed prototypes and
implementations for `mem_cgroup_commit_charge()`,
`mem_cgroup_cancel_charge()`, and related hugetlb try/commit/cancel
helpers.

Step 3.3 Record: recent history for `Documentation/admin-
guide/cgroup-v1/memcg_test.rst` on `origin/master` has only the file
introduction/import commit and this candidate. Related path history
shows the candidate was merged via `cgroup-for-7.1-rc2-fixes`. No
prerequisite doc series found.

Step 3.4 Record: author `T.J. Mercier` has at least one other cgroup-
related commit in `origin/master`; Tejun Heo is listed in `MAINTAINERS`
as cgroup maintainer and committed the patch.

Step 3.5 Record: no code dependencies for the patch itself. It can apply
standalone to the current `stable/linux-7.0.y` checkout. Applicability
must be gated by whether the target tree’s code has removed the old
APIs.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c d8769544bde51...` found the original
submission at
`https://patch.msgid.link/20260430201142.240387-1-tjmercier@google.com`.
`b4 dig -a` found only v1 of a single-patch series. The mbox contains
Tejun’s reply: “Applied to cgroup/for-7.1-fixes.” No NAKs or concerns
found in the saved thread.

Step 4.2 Record: `b4 dig -w` shows recipients included cgroup
maintainers/list and docs list: `tj@kernel.org`, `hannes@cmpxchg.org`,
`mkoutny@suse.com`, `cgroups@vger.kernel.org`, `corbet@lwn.net`,
`skhan@linuxfoundation.org`, `linux-doc@vger.kernel.org`, `linux-
kernel@vger.kernel.org`.

Step 4.3 Record: no `Reported-by` or bug-report `Link:` tags. No syzbot,
bugzilla, or user-impact bug report applies.

Step 4.4 Record: b4 found a standalone single-patch series, not part of
a multi-patch dependency chain.

Step 4.5 Record: web search did not find stable-list discussion for this
exact patch. `WebFetch` to lore/patch.msgid was blocked by Anubis, but
b4 successfully fetched the mbox.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: no functions modified by the diff.

Step 5.2 Record: no callers affected by the diff. For documentation
accuracy, I verified current `stable/linux-7.0.y` code has
`commit_charge()` callers in `charge_memcg()`,
`mem_cgroup_replace_folio()`, and `mem_cgroup_migrate()`.

Step 5.3 Record: no changed callees. The relevant current code has
`commit_charge()` assigning `folio->memcg_data`, and callers also invoke
`memcg1_commit_charge()` where appropriate.

Step 5.4 Record: runtime reachability is not relevant because no
executable code changes.

Step 5.5 Record: similar stale docs pattern exists in stable branches;
however code state differs by branch. `6.19.y`/`7.0.y` have stale docs
and no old API. `6.12.y` still has `mem_cgroup_commit_charge()` and
`mem_cgroup_cancel_charge()` in code.

## Phase 6: Cross-Referencing And Stable Tree Analysis
Step 6.1 Record: buggy stale documentation exists in
`stable/linux-7.0.y`, `stable/linux-6.19.y`, `stable/linux-6.18.y`,
`stable/linux-6.6.y`, `stable/linux-6.1.y`, `stable/linux-5.15.y`, and
`stable/linux-5.10.y` by exact doc grep. I verified the old APIs are
absent in several of those trees, but `stable/linux-6.12.y` still
contains `mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`,
so this exact upstream text is not universally correct for all
maintained stable lines.

Step 6.2 Record: `git apply --check` of the candidate diff succeeds on
the current `stable/linux-7.0.y` checkout. Expected backport difficulty:
clean for trees with matching doc context; branch-specific review needed
for `6.12.y`.

Step 6.3 Record: no related stable fix for this exact doc update found
by local stable branch ancestry checks or web search.

## Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: subsystem is cgroup-v1 memcg documentation.
Criticality: peripheral/runtime-none; important only for documentation
correctness.

Step 7.2 Record: cgroup and memcg areas are active; recent
`origin/master` history includes multiple cgroup/mm fixes. The candidate
was applied by the cgroup maintainer.

## Phase 8: Impact And Risk Assessment
Step 8.1 Record: affected population is documentation readers and
developers/admins consulting old cgroup-v1 memcg internals. No kernel
runtime users are affected.

Step 8.2 Record: trigger condition is reading or relying on the stale
documentation. Unprivileged users cannot trigger a kernel failure
because there is no runtime behavior.

Step 8.3 Record: failure mode is incorrect documentation. Severity: LOW.
It can mislead developers/admins, but it does not fix crash, corruption,
leak, deadlock, or security behavior.

Step 8.4 Record: benefit is low but real for documentation correctness,
especially because the stable rules exception allows
documentation/comment fixes and runtime risk is zero. Risk is very low
for branches whose code matches the new text; risk is documentation-
regression risk if applied to a branch like `6.12.y` where cancellation
APIs still exist.

## Phase 9: Final Synthesis
Step 9.1 Record: evidence for backporting: tiny docs-only patch;
corrects verified stale references in current `7.0.y` and `6.19.y`;
applied by cgroup maintainer; no runtime regression risk; documentation
fixes are allowed. Evidence against: no runtime bug or user-visible
stability issue; not correct for every stable branch, specifically
verified `6.12.y` still has the old commit/cancel APIs. Unresolved: I
did not exhaustively validate every maintained stable branch’s memcg API
state.

Step 9.2 Stable rules checklist:
1. Obviously correct and tested? Yes for matching-code branches;
   verified by code grep, `git diff --check`, and `git apply --check` on
   `7.0.y`.
2. Fixes a real bug that affects users? It fixes incorrect
   documentation, not runtime behavior.
3. Important issue? No runtime severity; LOW documentation correctness
   issue.
4. Small and contained? Yes, 6-line docs-only diff in one file.
5. No new features or APIs? Yes.
6. Can apply to stable trees? Yes to at least current `7.0.y`; should
   not be applied blindly to `6.12.y`.

Step 9.3 Record: exception category is documentation fix.

Step 9.4 Decision: backport is acceptable for stable trees whose memcg
implementation no longer has charge cancellation APIs. It should be
excluded from trees like `6.12.y` where the old APIs still exist. With
that branch-selection caveat, this qualifies under the documentation-fix
exception.

Verification:
- [Phase 1] Parsed candidate commit
  `d8769544bde51b0ac980d10f8fe9f9fed6c95995`: only two Signed-off-by
  tags, no bug/report/stable tags.
- [Phase 2] `git show --stat --patch`: confirmed one docs file, `2
  insertions(+), 4 deletions(-)`.
- [Phase 3] `git show 1d8f136a421f...`: confirmed referenced commit
  removed `mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`
  from mainline code.
- [Phase 3] `git log origin/master --grep`: found candidate and merge
  via `cgroup-for-7.1-rc2-fixes`.
- [Phase 4] `b4 dig`: found lore thread and exact patch-id match.
- [Phase 4] `b4 dig -a`: only v1 single-patch series.
- [Phase 4] `b4 dig -w`: relevant cgroup and docs maintainers/lists were
  included.
- [Phase 4] Saved mbox: confirmed Tejun replied “Applied to
  cgroup/for-7.1-fixes”; no NAKs or stable nomination found.
- [Phase 5] `rg`/`git grep`: confirmed current code uses
  `commit_charge()` and no longer has old API names in `7.0.y`.
- [Phase 6] `git apply --check`: candidate applies cleanly to current
  `7.0.y`.
- [Phase 6] Branch checks: `6.12.y` still has
  `mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`, so this
  patch must not be applied there unchanged.
- [Phase 8] Runtime impact verified as none because only
  `Documentation/admin-guide/cgroup-v1/memcg_test.rst` changes.

**YES**

 Documentation/admin-guide/cgroup-v1/memcg_test.rst | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/Documentation/admin-guide/cgroup-v1/memcg_test.rst b/Documentation/admin-guide/cgroup-v1/memcg_test.rst
index 9f8e27355cba5..7c7cd457cf695 100644
--- a/Documentation/admin-guide/cgroup-v1/memcg_test.rst
+++ b/Documentation/admin-guide/cgroup-v1/memcg_test.rst
@@ -47,21 +47,19 @@ Please note that implementation details can be changed.
 	  Called when swp_entry's refcnt goes down to 0. A charge against swap
 	  disappears.
 
-3. charge-commit-cancel
+3. charge-commit
 =======================
 
 	Memcg pages are charged in two steps:
 
 		- mem_cgroup_try_charge()
-		- mem_cgroup_commit_charge() or mem_cgroup_cancel_charge()
+		- commit_charge()
 
 	At try_charge(), there are no flags to say "this page is charged".
 	at this point, usage += PAGE_SIZE.
 
 	At commit(), the page is associated with the memcg.
 
-	At cancel(), simply usage -= PAGE_SIZE.
-
 Under below explanation, we assume CONFIG_SWAP=y.
 
 4. Anonymous
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] drm/panel: feiyang-fy07024di26a30d: return display-on error

[Sasha Levin]

From: Christian Van <cvan20191@gmail.com>

[ Upstream commit c67e8787f6743101c90c7a9c4bb7cf6f1f739f83 ]

mipi_dsi_dcs_set_display_on() returns an error code, but feiyang_enable()
currently ignores it and always reports success.

Return the DCS command result so callers can observe enable failures.

Signed-off-by: Christian Van <cvan20191@gmail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260425053948.117714-1-cvan20191@gmail.com
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 `drm/panel`, action verb `return`, summary:
`feiyang-fy07024di26a30d` should propagate the MIPI DSI display-on
command error instead of reporting success.

Step 1.2 Record: tags verified:
- `Signed-off-by: Christian Van <cvan20191@gmail.com>`
- `Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>`
- `Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>`
- `Link:
  https://patch.msgid.link/20260425053948.117714-1-cvan20191@gmail.com`
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Cc: stable`, syzbot, or
sanitizer tags were present.

Step 1.3 Record: the body says `mipi_dsi_dcs_set_display_on()` returns
an error but `feiyang_enable()` ignores it and always returns success.
Verified in `drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c`.
Symptom: DRM panel core cannot observe a failed display-on command and
may continue the enable sequence as if the panel enabled successfully.
No user report, stack trace, or affected-version statement was found.

Step 1.4 Record: yes, this is a hidden bug fix: it fixes ignored error
handling in a panel enable path. It is not cleanup or refactoring.

## Phase 2: Diff Analysis
Step 2.1 Record: one file changed, `drivers/gpu/drm/panel/panel-feiyang-
fy07024di26a30d.c`; 1 insertion, 3 deletions. Modified function:
`feiyang_enable()`. Scope: single-file surgical driver fix.

Step 2.2 Record: before, `feiyang_enable()` called
`mipi_dsi_dcs_set_display_on(ctx->dsi)` and always returned `0`. After,
it returns the DCS command result directly. Affected path: normal panel
enable path, after the 200 ms enable delay.

Step 2.3 Record: bug category is logic/error-propagation correctness.
The broken mechanism was an ignored negative return from
`mipi_dsi_dcs_set_display_on()`. Verified that
`mipi_dsi_dcs_set_display_on()` returns `0` on success or a negative
error code on failure.

Step 2.4 Record: fix quality is high: minimal, obviously correct, no new
API, no locking, no data structure change. Regression risk is very low;
the only behavior change is that a real display-on failure prevents
`drm_panel_enable()` from marking the panel enabled and enabling
backlight/followers.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows the ignored return was introduced
with the original driver commit
`69dc678abc2b9d36ff005413ca6e9edabe4c369a` (`drm/panel: Add Feiyang
FY07024DI26A30-D MIPI-DSI LCD panel`), first contained in `v5.2-rc1`.

Step 3.2 Record: no `Fixes:` tag was present, so there was no tag to
follow. I inspected the original driver commit anyway; it added the
driver and already ignored this display-on return.

Step 3.3 Record: recent file history shows mostly unrelated panel API
conversions and cleanup. The candidate patch is standalone and only
needs the existing `feiyang_enable()` and
`mipi_dsi_dcs_set_display_on()` code.

Step 3.4 Record: no other `Christian Van` commits under
`drivers/gpu/drm/panel` were found in checked `master` or `graphics-
next`. Neil Armstrong is listed as DRM panel maintainer in `MAINTAINERS`
and reviewed/applied the patch.

Step 3.5 Record: no dependencies found. The patch applies directly to
`v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.19`, and `v7.0`; `v5.4`
contains the buggy code but needs a trivial context backport.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c c67e8787f6743101c90c7a9c4bb7cf6f1f739f83`
found the original submission at
`https://patch.msgid.link/20260425053948.117714-1-cvan20191@gmail.com`.
`b4 dig -a` found only v1, so the committed version is the only revision
found.

Step 4.2 Record: `b4 dig -w` showed the original recipients included
Christian Van, Jagan Teki, Neil Armstrong, Jessica Zhang, Maarten
Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie, Simona
Vetter, `dri-devel`, and `linux-kernel`. Neil Armstrong reviewed it and
later applied it to `drm-misc-fixes`.

Step 4.3 Record: no `Reported-by` or bug-report link exists. WebFetch
for lore URLs was blocked by Anubis, but `b4 mbox` fetched the thread
successfully. The thread contained Neil’s `Reviewed-by` reply and an
applied notice.

Step 4.4 Record: no multi-patch series found; this is a standalone
1-patch series.

Step 4.5 Record: WebFetch searches of `lore.kernel.org/stable` were
blocked by Anubis. Local pending/stable candidate branches searched did
not show this patch already present.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: modified function: `feiyang_enable()`.

Step 5.2 Record: `feiyang_enable()` is installed as `.enable` in
`feiyang_funcs`. `drm_panel_enable()` calls
`panel->funcs->enable(panel)` and checks negative returns. Multiple DRM
bridge/host drivers call `drm_panel_enable()`.

Step 5.3 Record: key callees are `msleep(200)` and
`mipi_dsi_dcs_set_display_on(ctx->dsi)`. The latter calls
`mipi_dsi_dcs_write()` and returns a negative error on write failure.

Step 5.4 Record: reachable through DRM panel enable paths during display
modeset/enable for systems using this panel. This is driver/hardware-
specific, not universal. No in-tree DTS user of
`feiyang,fy07024di26a30d` was found beyond the binding example and
driver match table.

Step 5.5 Record: many other panel drivers already check and return or
handle `mipi_dsi_dcs_set_display_on()` errors, confirming this driver
was an outlier.

## Phase 6: Cross-Referencing And Stable Tree Analysis
Step 6.1 Record: buggy code exists in `v5.4`, `v5.10`, `v5.15`, `v6.1`,
`v6.6`, `v6.12`, `v6.19`, and `v7.0`. The driver was introduced for
`v5.2-rc1`, so all active stable trees at or after that point likely
contain it.

Step 6.2 Record: expected backport difficulty is clean for `v5.10+`
based on apply checks. `v5.4` failed direct apply due to context drift
but contains the same ignored call and should need only a trivial one-
function backport.

Step 6.3 Record: no related stable-side fix for this same issue was
found in the checked stable/pending branches.

## Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: subsystem is DRM panel driver, criticality
`PERIPHERAL`/driver-specific. It affects users of Feiyang
FY07024DI26A30-D MIPI-DSI panels.

Step 7.2 Record: DRM panel is maintained and active. The file has had
several API-conversion commits since introduction, but this fix is not
dependent on those conversions for `v5.10+`.

## Phase 8: Impact And Risk Assessment
Step 8.1 Record: affected population is driver-specific/config-specific:
kernels with `CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D` and hardware
described with `feiyang,fy07024di26a30d`.

Step 8.2 Record: trigger is a failure of the DSI `SET_DISPLAY_ON`
command during panel enable. I did not verify a specific real-world
reporter, so frequency is unverified. It is not shown to be
unprivileged-user-triggerable.

Step 8.3 Record: failure mode is user-visible display enable
misreporting: before the patch, the panel core could treat the panel as
enabled despite the failed display-on command. Severity: `MEDIUM` for
affected hardware, because it can leave display/backlight state wrong,
but no crash, memory corruption, deadlock, or security issue was
verified.

Step 8.4 Record: benefit is moderate for affected hardware; risk is very
low because the patch only returns an existing error code from a
function that already has an `int` return type.

## Phase 9: Final Synthesis
Step 9.1 Record:
Evidence for backporting: real ignored-error bug; affects display enable
correctness; original buggy code dates to `v5.2-rc1`; one-line surgical
fix; maintainer reviewed/applied to `drm-misc-fixes`; clean apply to
`v5.10+`; no new API or feature.
Evidence against backporting: no user report, crash, security issue,
data corruption, syzbot report, or `Fixes:` tag; affected population is
limited to one panel driver; `v5.4` needs a trivial manual backport.
Unresolved: actual field frequency of DSI display-on failures was not
verified.

Step 9.2 Record:
1. Obviously correct and tested? Correct by inspection; reviewed by DRM
   panel maintainer. No explicit `Tested-by`.
2. Fixes a real bug? Yes, ignored negative return from a hardware
   command.
3. Important issue? Moderate: display enable state correctness for
   affected hardware, not a critical kernel-wide failure.
4. Small and contained? Yes, one function, one file, 1 insertion/3
   deletions.
5. No new features/APIs? Yes.
6. Can apply to stable? Yes for `v5.10+`; trivial backport needed for
   `v5.4`.

Step 9.3 Record: no automatic exception category applies; this is not a
device ID, quirk, DT, build, or documentation patch.

Step 9.4 Record: I recommend backporting. Although the impact is driver-
specific and not a crash-class bug, the fix is a genuine hardware enable
error propagation fix, very small, maintainer-reviewed, and low risk.
Stable users with this panel should not have the panel core mark the
panel enabled after the display-on command failed.

## Verification
- Phase 1: Parsed commit `c67e8787f6743101c90c7a9c4bb7cf6f1f739f83` with
  `git show`; confirmed subject, body, trailers, and diff.
- Phase 2: Read `panel-feiyang-fy07024di26a30d.c`; confirmed old
  `feiyang_enable()` ignored `mipi_dsi_dcs_set_display_on()` and
  returned `0`.
- Phase 2: Read `drm_mipi_dsi.c`; confirmed
  `mipi_dsi_dcs_set_display_on()` returns a negative error on failure.
- Phase 3: Ran `git blame -L 94,104`; confirmed buggy lines came from
  `69dc678abc2b9d`.
- Phase 3: Ran `git describe --contains 69dc678abc2b9d`; confirmed first
  containing version `v5.2-rc1`.
- Phase 3: Inspected original commit `69dc678abc2b9d`; confirmed the
  ignored return existed from driver introduction.
- Phase 4: Ran `b4 dig -c`, `b4 dig -a`, and `b4 dig -w`; confirmed one
  v1 patch, original lore URL, and recipient list.
- Phase 4: Ran `b4 mbox`; confirmed Neil Armstrong reviewed and applied
  it to `drm-misc-fixes`.
- Phase 4: WebFetch lore and stable searches were blocked by Anubis;
  this limitation did not drive the final decision.
- Phase 5: Read `drm_panel.c`; confirmed `drm_panel_enable()` checks
  negative `.enable` return and skips enabled/backlight/follower path on
  failure.
- Phase 5: Searched for `feiyang_enable`; confirmed it is used via
  `.enable = feiyang_enable`.
- Phase 5: Searched panel drivers for `mipi_dsi_dcs_set_display_on()`;
  confirmed many peers handle its return.
- Phase 6: Used `git grep` against stable tags; confirmed the ignored
  call exists in `v5.4`, `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.19`, and
  `v7.0`.
- Phase 6: Apply-checked the patch in detached worktrees; clean for
  `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.19`, and `v7.0`; failed
  direct apply on `v5.4` due to context only.
- Phase 7: Checked `MAINTAINERS`; confirmed Neil Armstrong maintains DRM
  panel drivers.
- Phase 8: Checked Kconfig and compatible strings; confirmed impact is
  limited to the Feiyang panel driver/config and no in-tree board DTS
  use was found.
- UNVERIFIED: no actual user report or frequency of display-on command
  failures was found.

**YES**

 drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
index 4f8d6d8c07e4d..dbdb7e3cb7b62 100644
--- a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
+++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
@@ -98,9 +98,7 @@ static int feiyang_enable(struct drm_panel *panel)
 	/* T12 (video & logic signal rise + backlight rise) T12 >= 200ms */
 	msleep(200);
 
-	mipi_dsi_dcs_set_display_on(ctx->dsi);
-
-	return 0;
+	return mipi_dsi_dcs_set_display_on(ctx->dsi);
 }
 
 static int feiyang_disable(struct drm_panel *panel)
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.1] smb: client: Zero-pad short GSS session keys per MS-SMB2

[Sasha Levin]

From: Piyush Sachdeva <s.piyush1024@gmail.com>

[ Upstream commit 8cb6fc3231500233ddaf63cb7fd5435008d9ed5f ]

Per MS-SMB2 section 3.2.5.3, Session.SessionKey is the first 16 bytes
of the GSS cryptographic key, right-padded with zero bytes if the key
is shorter than 16 bytes.

SMB2_auth_kerberos() copies the GSS session key from the cifs.upcall
response using kmemdup(msg->data, msg->sesskey_len, ...) and stores
the GSS-reported length verbatim in ses->auth_key.len. generate_key()
reads SMB2_NTLMV2_SESSKEY_SIZE bytes from this buffer when feeding the
HMAC-SHA256 KDF for signing key derivation. If a GSS mechanism returns
a session key shorter than 16 bytes (e.g. a deprecated single-DES
Kerberos enctype with an 8-byte session key), the KDF call performs an
out-of-bounds slab read and derives keys that do not match the server,
which pads per the spec.

Modern KDCs disable short-key enctypes by default, so this is latent
rather than reachable in production, but it is still a kernel heap
over-read.

Allocate auth_key.response with kzalloc() at a length of
max(msg->sesskey_len, SMB2_NTLMV2_SESSKEY_SIZE), copy the GSS key in,
and rely on kzalloc()'s zero initialization for the spec-mandated
padding. Set ses->auth_key.len to the padded length. Larger GSS keys
(e.g. the 32-byte aes256-cts-hmac-sha1-96 session key) continue to be
stored at their natural length, preserving the FullSessionKey path.

Emit a cifs_dbg(VFS, ...) message when a short key is encountered to
surface deprecated-enctype usage.

NTLMv2 and NTLMSSP code paths produce a 16-byte session key by
construction and are unaffected.

Signed-off-by: Piyush Sachdeva <psachdeva@microsoft.com>
Signed-off-by: Piyush Sachdeva <s.piyush1024@gmail.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough
### Phase 1: Commit Message Forensics
Record 1.1: subsystem `smb: client`; action verb `Zero-pad`; intent is
to make short GSS session keys comply with MS-SMB2 and avoid short-
buffer use in SMB2 key derivation.

Record 1.2: tags present are:
- `Signed-off-by: Piyush Sachdeva <psachdeva@microsoft.com>`
- `Signed-off-by: Piyush Sachdeva <s.piyush1024@gmail.com>`
- `Signed-off-by: Steve French <stfrench@microsoft.com>`

No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`,
`Link:`, or `Cc: stable@vger.kernel.org` tag was present in the supplied
commit message.

Record 1.3: the commit describes a real memory-safety bug:
`SMB2_auth_kerberos()` allocates exactly `msg->sesskey_len` bytes, but
SMB2 key derivation later consumes `SMB2_NTLMV2_SESSKEY_SIZE` bytes,
which is `16`. If `msg->sesskey_len < 16`, the kernel reads past the
allocated buffer and also derives a non-spec-compliant key. MS-SMB2 says
`Session.SessionKey` is the first 16 bytes of the cryptographic key,
right-padded with zeros if shorter.

Record 1.4: this is not just cleanup. It is a hidden memory-safety and
protocol-correctness fix: short allocation plus fixed 16-byte HMAC key
input creates an out-of-bounds read.

### Phase 2: Diff Analysis
Record 2.1: one file changed: `fs/smb/client/smb2pdu.c`, one hunk in
`SMB2_auth_kerberos()`, roughly 18 insertions and 5 deletions from the
supplied diff. Scope is a single-file surgical fix.

Record 2.2: before, `ses->auth_key.response = kmemdup(msg->data,
msg->sesskey_len, GFP_KERNEL)` and `ses->auth_key.len =
msg->sesskey_len`. After, the code sets `ses->auth_key.len =
max(msg->sesskey_len, 16)`, allocates a zeroed buffer of that size,
copies only the original GSS key, and leaves zero padding if the key was
short.

Record 2.3: bug category is memory safety / out-of-bounds read plus
protocol correctness. The verified consumer is `generate_key()` in
`fs/smb/client/smb2transport.c`, which calls
`hmac_sha256_init_usingrawkey(&hmac_ctx, ses->auth_key.response,
SMB2_NTLMV2_SESSKEY_SIZE)`. The HMAC helper copies `raw_key_len` bytes
from the pointer, so a shorter allocation is a real over-read.

Record 2.4: fix quality is good: it preserves larger keys, fixes only
Kerberos/GSS key storage, does not change the security blob pointer, and
uses zeroed allocation to implement the spec padding. Regression risk is
low; the only behavior change for short keys is from invalid over-
read/wrong key material to zero-padded spec behavior. It adds one VFS
debug message for short keys.

### Phase 3: Git History Investigation
Record 3.1: `git blame` on current `fs/smb/client/smb2pdu.c` shows the
current `kmemdup(msg->data, msg->sesskey_len)` lines came from
`d9d1e319b39e` (`smb: client: fix broken multichannel with
krb5+signing`), first contained in local tags starting at `v7.0`. The
fixed-size 16-byte HMAC use in current `generate_key()` came from
`4b4c6fdb25de`, first contained in local tags starting at `v6.18`.

Record 3.2: no `Fixes:` tag is present, so there was no tagged
introducing commit to follow.

Record 3.3: recent local history for `smb2pdu.c` includes related
Kerberos/multichannel work (`d9d1e319b39e`). Recent `smb2transport.c`
history includes crypto-library conversion commits. The candidate itself
is standalone for current `v7.0.y` context.

Record 3.4: local `git log master --author='Piyush Sachdeva' -10 --
fs/smb/client fs/cifs` found no matching prior local commits. `Steve
French` is listed in `MAINTAINERS` as maintainer for `COMMON INTERNET
FILE SYSTEM CLIENT (CIFS and SMB3)`, and he signed off this patch.

Record 3.5: no functional dependency was found for the current `v7.0.y`
file: `git apply --check` of the supplied patch against this checkout
succeeded. Older stable trees need path/context adjustments because
older releases use `fs/cifs/` and some have the allocation inside an `if
(!is_binding)` / `if (!ses->binding)` block.

### Phase 4: Mailing List and External Research
Record 4.1: no candidate commit hash was available locally. `git log
master`, `pending-7.0`, and `for-greg/7.0-200` with the exact subject
found no commit. `b4 dig -c '<subject>'`, `b4 dig -a`, and `b4 dig -w`
failed because `b4 dig` needs a commitish.

Record 4.2: reviewer/recipient data could not be obtained from `b4 dig`
for this candidate. The only maintainer signal verified is Steve
French’s signoff and MAINTAINERS entry.

Record 4.3: no `Link:` or `Reported-by:` tags exist. Lore web queries
were blocked by Anubis, so no bug-report thread was verified.

Record 4.4: no series context was verified. No local subject match was
found in searched branches.

Record 4.5: stable-list search via lore was blocked by Anubis; no
stable-specific discussion was verified.

### Phase 5: Code Semantic Analysis
Record 5.1: modified function: `SMB2_auth_kerberos()`.

Record 5.2: caller path verified locally: `connect.c` calls
`server->ops->sess_setup()`, SMB2/SMB3 ops point that to
`SMB2_sess_setup()`, `SMB2_select_sec()` selects `SMB2_auth_kerberos()`
for Kerberos, and `SMB2_sess_setup()` runs the selected auth function.

Record 5.3: key callees are `cifs_get_spnego_key()`,
`SMB2_sess_sendreceive()`, and `SMB2_sess_establish_session()`.
`SMB2_sess_establish_session()` calls
`server->ops->generate_signingkey()`, which reaches
`generate_smb3signingkey()` and then `generate_key()` for SMB3 dialects.

Record 5.4: reachability is from a user-requested CIFS/SMB mount using
Kerberos, with `CONFIG_CIFS_UPCALL` enabled. `Kconfig` says
`CIFS_UPCALL` enables Kerberos/SPNEGO advanced session setup and is used
for Kerberos tickets needed to mount secure servers.

Record 5.5: similar short allocation plus 16-byte consumer patterns
exist across stable tags. I verified the same `kmemdup(msg->data,
msg->sesskey_len)` and 16-byte key use in `v5.4`, `v5.10`, `v5.15`,
`v6.1`, `v6.6`, `v6.12`, `v6.18`, `v6.19`, and `v7.0`, with path changes
from `fs/cifs/` to `fs/smb/client/`.

### Phase 6: Cross-Referencing and Stable Tree Analysis
Record 6.1: buggy code exists in multiple stable-era tags. `v5.4`
through `v6.1` use `fs/cifs/`; `v6.6+` uses `fs/smb/client/`. The
relevant allocation and 16-byte key consumption pattern is present in
those checked tags.

Record 6.2: expected backport difficulty is clean for current `v7.0.y`
because `git apply --check` succeeded. Older stable trees need minor
backporting for path and context differences; pre-`d9d1e319b39e` trees
should preserve their existing binding conditional unless that
multichannel Kerberos fix is also backported.

Record 6.3: local searches for the exact subject, `short GSS session
key`, and related `MS-SMB2` terms did not find an existing local fix.

### Phase 7: Subsystem and Maintainer Context
Record 7.1: subsystem is CIFS/SMB3 client filesystem/network filesystem
code. Criticality is important: it affects users mounting SMB shares
with Kerberos/SPNEGO.

Record 7.2: subsystem is active; recent `master` history under
`fs/smb/client` includes multiple SMB client fixes and refactors. The
maintained subsystem is marked `Supported` in `MAINTAINERS`.

### Phase 8: Impact and Risk Assessment
Record 8.1: affected population is config- and workload-specific:
CIFS/SMB2+ Kerberos users with `CONFIG_CIFS_UPCALL`, especially where
the GSS session key returned to the kernel is shorter than 16 bytes.

Record 8.2: trigger condition is a Kerberos/SPNEGO session setup where
`msg->sesskey_len < SMB2_NTLMV2_SESSKEY_SIZE`. The mount path is user
reachable, but whether unprivileged users can trigger it depends on
mount permissions and local configuration, which I did not verify.

Record 8.3: failure mode is a kernel heap out-of-bounds read during HMAC
key setup and incorrect SMB key derivation. Severity is high for memory
safety, though likely low-frequency because it requires a short GSS
session key.

Record 8.4: benefit is high for affected users because it removes a
kernel heap over-read and implements the protocol-required padding. Risk
is low because the patch is small, local, and preserves behavior for
keys of length 16 or greater.

### Phase 9: Final Synthesis
Record 9.1: evidence for backporting:
- Verified short allocation in `SMB2_auth_kerberos()`.
- Verified fixed 16-byte read in `generate_key()`.
- Verified HMAC helper copies the specified key length.
- Verified MS-SMB2 requires right-zero-padding short session keys.
- Verified bug pattern exists across multiple stable-era tags.
- Fix is small, local, and cleanly applies to current `v7.0.y`.

Evidence against / concerns:
- No `Reported-by`, `Tested-by`, `Reviewed-by`, `Fixes`, or `Link` tag
  was supplied.
- No lore review discussion could be verified.
- Older stable trees need minor path/context backport adjustments.
- Trigger appears specific to short GSS keys; I did not independently
  verify real-world frequency.

Unresolved:
- No upstream commit hash was available locally, so `b4 dig` could not
  retrieve the original thread.
- Lore web searches were blocked.
- I did not compile-test the patch.

Record 9.2 stable rules:
1. Obviously correct and tested: obviously correct by code inspection;
   external testing not verified.
2. Fixes a real bug: yes, verified out-of-bounds read when `sesskey_len
   < 16`.
3. Important issue: yes, kernel heap over-read and broken key
   derivation.
4. Small and contained: yes, one function in one file.
5. No new feature/API: yes, no new API or userspace interface.
6. Can apply to stable: yes for current `v7.0.y`; minor backport work
   needed for older trees.

Record 9.3: no automatic exception category applies. This is not a
device ID, quirk, DT, build, or documentation-only change.

Record 9.4: decision is to backport. The memory-safety fix is small and
technically well justified; the limited trigger scope reduces urgency
but not suitability.

## Verification
- [Phase 1] Parsed the supplied subject and tags; no `Fixes`, `Reported-
  by`, `Tested-by`, `Reviewed-by`, `Link`, or stable Cc was present.
- [Phase 2] Read `SMB2_auth_kerberos()` in `fs/smb/client/smb2pdu.c`;
  verified current exact-size `kmemdup()` allocation and
  `ses->auth_key.len = msg->sesskey_len`.
- [Phase 2] Read `generate_key()` in `fs/smb/client/smb2transport.c`;
  verified it passes `SMB2_NTLMV2_SESSKEY_SIZE` bytes from
  `ses->auth_key.response`.
- [Phase 2] Read `lib/crypto/sha256.c`; verified HMAC raw-key setup
  copies `raw_key_len` bytes from the supplied pointer.
- [Phase 2] Verified `SMB2_NTLMV2_SESSKEY_SIZE` is `16` in
  `fs/smb/common/smb2pdu.h`.
- [Phase 3] `git blame` identified local current-line history for the
  allocation and HMAC key setup.
- [Phase 3] `git show` inspected `d9d1e319b39e` and `4b4c6fdb25de`.
- [Phase 3] `git tag --contains` showed `d9d1e319b39e` starts at local
  `v7.0` tags and `4b4c6fdb25de` at local `v6.18` tags.
- [Phase 4] `b4 dig` attempts by subject failed because no local
  commitish exists; lore WebFetch searches were blocked by Anubis.
- [Phase 5] `rg` and `ReadFile` traced `connect.c -> SMB2_sess_setup()
  -> SMB2_auth_kerberos() -> SMB2_sess_establish_session() ->
  generate_key()`.
- [Phase 6] Checked `v5.4`, `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`,
  `v6.18`, `v6.19`, and `v7.0` for the allocation and 16-byte consumer
  pattern.
- [Phase 6] `git apply --check` confirmed the supplied patch applies
  cleanly to current `v7.0.y`.
- [Phase 7] Verified CIFS/SMB3 client maintainership and supported
  status in `MAINTAINERS`.
- [Phase 8] Verified `CONFIG_CIFS_UPCALL` Kconfig text describes
  Kerberos/SPNEGO upcall support for secure SMB mounts.
- UNVERIFIED: original mailing-list review, patch revisions, explicit
  stable discussion, compile-test results, and real-world frequency of
  short GSS session keys.

**YES**

 fs/smb/client/smb2pdu.c | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/fs/smb/client/smb2pdu.c b/fs/smb/client/smb2pdu.c
index 5188218c25be4..0792e0c38b44f 100644
--- a/fs/smb/client/smb2pdu.c
+++ b/fs/smb/client/smb2pdu.c
@@ -1714,17 +1714,30 @@ SMB2_auth_kerberos(struct SMB2_sess_data *sess_data)
 	is_binding = (ses->ses_status == SES_GOOD);
 	spin_unlock(&ses->ses_lock);
 
+	/*
+	 * Per MS-SMB2 3.2.5.3, Session.SessionKey is the first 16 bytes of the
+	 * GSS cryptographic key, right-padded with zero bytes if shorter.
+	 * Allocate at least SMB2_NTLMV2_SESSKEY_SIZE bytes (zeroed) so the KDF
+	 * input buffer is always valid for HMAC-SHA256 even with deprecated
+	 * Kerberos enctypes that return a short session key.
+	 */
+	if (unlikely(msg->sesskey_len < SMB2_NTLMV2_SESSKEY_SIZE))
+		cifs_dbg(VFS,
+			 "short GSS session key (%u bytes); zero-padding per MS-SMB2 3.2.5.3\n",
+			 msg->sesskey_len);
+
 	kfree_sensitive(ses->auth_key.response);
-	ses->auth_key.response = kmemdup(msg->data,
-					 msg->sesskey_len,
-					 GFP_KERNEL);
+	ses->auth_key.len = max_t(unsigned int, msg->sesskey_len,
+				  SMB2_NTLMV2_SESSKEY_SIZE);
+	ses->auth_key.response = kzalloc(ses->auth_key.len, GFP_KERNEL);
 	if (!ses->auth_key.response) {
 		cifs_dbg(VFS, "%s: can't allocate (%u bytes) memory\n",
-			 __func__, msg->sesskey_len);
+			 __func__, ses->auth_key.len);
+		ses->auth_key.len = 0;
 		rc = -ENOMEM;
 		goto out_put_spnego_key;
 	}
-	ses->auth_key.len = msg->sesskey_len;
+	memcpy(ses->auth_key.response, msg->data, msg->sesskey_len);
 
 	sess_data->iov[1].iov_base = msg->data + msg->sesskey_len;
 	sess_data->iov[1].iov_len = msg->secblob_len;
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.15] wifi: nl80211: re-check wiphy netns in nl80211_prepare_wdev_dump() continuation

[Sasha Levin]

From: Maoyi Xie <maoyi.xie@ntu.edu.sg>

[ Upstream commit 79240f3f6d766b342b57c32397d643e1cfa26b81 ]

NL80211_CMD_GET_SCAN is implemented as a multi-call dumpit. The first
invocation of nl80211_prepare_wdev_dump() validates the requested wdev
against the caller's netns via __cfg80211_wdev_from_attrs(). Subsequent
invocations look up the same wiphy by its global index and do not check
that the wiphy is still in the caller's netns.

Add the same filter to the continuation path. If the wiphy's netns no
longer matches the caller's, return -ENODEV and the netlink dump
machinery terminates the walk cleanly.

Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>
Link: https://patch.msgid.link/20260506064854.2207105-3-maoyixie.tju@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

**Phase 1: Commit Message Forensics**
- Step 1.1 Record: Subsystem `wifi: nl80211`; action verb `re-check`;
  intent is to revalidate the wiphy net namespace during
  `nl80211_prepare_wdev_dump()` continuation.
- Step 1.2 Record: Tags are `Signed-off-by: Maoyi Xie`, `Link: https://p
  atch.msgid.link/20260506064854.2207105-3-maoyixie.tju@gmail.com`,
  `Signed-off-by: Johannes Berg`. No `Fixes`, `Reported-by`, `Tested-
  by`, `Reviewed-by`, `Acked-by`, or `Cc: stable`.
- Step 1.3 Record: The committed message says first dump invocation
  validates via `__cfg80211_wdev_from_attrs()`, but later invocations
  recover the wiphy by global index and lacked a netns check. The v3
  mailing-list patch further states the failure mode: BSS scan data can
  continue being copied from a wiphy after it moved to another netns.
- Step 1.4 Record: This is a hidden security/correctness fix, not a
  cleanup. It fixes a namespace isolation race in a multi-call netlink
  dump.

**Phase 2: Diff Analysis**
- Step 2.1 Record: One file changed, `net/wireless/nl80211.c`; commit
  stat is 12 insertions. One function changed:
  `nl80211_prepare_wdev_dump()`. Scope is single-file surgical.
- Step 2.2 Record: Before, continuation path did
  `wiphy_idx_to_wiphy(cb->args[0] - 1)`, accepted the wiphy, then
  searched `wdev_list`. After, it returns `-ENODEV` if
  `!net_eq(wiphy_net(wiphy), sock_net(cb->skb->sk))`.
- Step 2.3 Record: Bug category is race / namespace isolation /
  information disclosure. A wiphy can move netns between dumpit calls
  via `NL80211_CMD_SET_WIPHY_NETNS`.
- Step 2.4 Record: Fix quality is high: one predicate and clean error
  return before taking `wiphy.mtx`. Regression risk is low; it only
  rejects a continuation whose object no longer belongs to the caller’s
  netns.

**Phase 3: Git History**
- Step 3.1 Record: Current checkout is shallow; `git blame` attributed
  the region to a shallow boundary, so that blame is not reliable.
  Pickaxe history found the continuation-by-global-wiphy-index pattern
  in old history, including `c319d50bfcf67` (`nl80211: fix another
  nl80211_fam.attrbuf race`), contained by `v3.11-rc6`. Netns support
  for cfg80211/nl80211 was introduced by `463d018323851`, contained by
  `v2.6.32-rc1`.
- Step 3.2 Record: No `Fixes:` tag, so no tagged introducer to follow.
- Step 3.3 Record: Fetched wireless history shows the candidate
  immediately follows companion commit `15994bb0cbb8f` (`wifi: nl80211:
  require CAP_NET_ADMIN over the target netns in SET_WIPHY_NETNS`). No
  intermediate commit between them.
- Step 3.4 Record: Author has only these two fetched wireless commits.
  Committer is Johannes Berg, the nl80211/cfg80211 maintainer.
- Step 3.5 Record: No compile dependency on the companion commit, but
  logical/security context is stronger if `15994bb0cbb8f` is backported
  too.

**Phase 4: Mailing List / External Research**
- Step 4.1 Record: `b4 dig -c 79240f3f6d766...` found the v3 patch at
  the provided `patch.msgid.link` URL. `b4 dig -a` found v1 and v3; `b4
  am` showed v1, v2, v3. v3 cover says no code changes since v2 and that
  Johannes review caused comment/trailer cleanup.
- Step 4.2 Record: `b4 dig -w` shows Johannes Berg, `linux-wireless`,
  and `linux-kernel` were included.
- Step 4.3 Record: No syzbot/bugzilla report. The series cover and patch
  body provide the bug explanation and patch 1 includes a mac80211_hwsim
  reproducer for the related `SET_WIPHY_NETNS` privilege path.
- Step 4.4 Record: This is patch 2/2 in a series. Patch 1 hardens
  target-netns capability checks; patch 2 fixes dump continuation
  filtering.
- Step 4.5 Record: Lore WebFetch was blocked by Anubis; WebSearch did
  not find stable-specific discussion.

**Phase 5: Code Semantic Analysis**
- Step 5.1 Record: Modified function is `nl80211_prepare_wdev_dump()`.
- Step 5.2 Record: Exact callers are `nl80211_dump_station()`,
  `nl80211_dump_mpath()`, `nl80211_dump_mpp()`, `nl80211_dump_scan()`,
  and `nl80211_dump_survey()`.
- Step 5.3 Record: Key callees are `__cfg80211_wdev_from_attrs()`,
  `wiphy_idx_to_wiphy()`, `wiphy_net()`, `sock_net()`, `net_eq()`,
  `wiphy_to_rdev()`, and list walk over `wiphy.wdev_list`.
- Step 5.4 Record: `NL80211_CMD_GET_SCAN` maps to `nl80211_dump_scan()`
  and has no admin flag in the ops entry; `NL80211_CMD_SET_WIPHY_NETNS`
  maps to `nl80211_wiphy_netns()` with `GENL_UNS_ADMIN_PERM`.
- Step 5.5 Record: Similar dump paths `nl80211_dump_wiphy()` and
  `nl80211_dump_interface()` already filter by `net_eq(wiphy_net(...),
  sock_net(skb->sk))` each iteration.

**Phase 6: Stable Tree Analysis**
- Step 6.1 Record: The affected continuation code exists in checked tags
  `v6.19`, `v6.18`, `v6.12`, `v6.6`, `v6.1`, `v5.15`, `v5.10`, `v5.4`,
  `v4.19`, and `v4.14`.
- Step 6.2 Record: Modern stable trees have the same helper shape. Older
  trees such as `v5.4` and `v4.14` have different function
  signatures/locking, so they may need small backport adjustment.
- Step 6.3 Record: Searches in checked stable tags did not find this
  candidate or the companion commit already present.

**Phase 7: Subsystem Context**
- Step 7.1 Record: Subsystem is wireless cfg80211/nl80211, an important
  networking control-plane subsystem.
- Step 7.2 Record: `net/wireless/nl80211.c` is actively maintained;
  fetched wireless history shows this series was taken through Johannes
  Berg’s wireless tree.

**Phase 8: Impact / Risk**
- Step 8.1 Record: Affected users are systems using wireless devices
  with nl80211 netns movement support, including delegated/container
  wireless setups and mac80211_hwsim.
- Step 8.2 Record: Trigger requires a multi-call dump and a wiphy netns
  move between invocations. The related series verifies an unprivileged
  userns path when the caller has a delegated `WIPHY_FLAG_NETNS_OK`
  wiphy.
- Step 8.3 Record: Failure mode is namespace isolation breach / cross-
  netns scan-result exposure, not a crash. Severity: HIGH due
  security/isolation impact.
- Step 8.4 Record: Benefit is high for isolation correctness; risk is
  very low because the patch adds one local validation and returns an
  existing error code.

**Phase 9: Final Synthesis**
- Step 9.1 Record: Evidence for backporting: real namespace isolation
  bug, old code present across stable trees, small surgical fix,
  maintainer-applied, aligns with existing dump filtering. Evidence
  against: companion patch should also be considered, and older trees
  may require minor backport edits. Unresolved: no independent `Tested-
  by`; stable-specific lore discussion could not be fetched.
- Step 9.2 Record: Stable rules: obviously correct yes; fixes real bug
  yes; important issue yes due namespace isolation/security; small and
  contained yes; no new API/feature yes; applies cleanly or with minor
  adjustment depending on tree.
- Step 9.3 Record: No exception category applies.
- Step 9.4 Record: Backport is warranted, preferably together with
  `15994bb0cbb8f` for the complete netns hardening series.

## Verification
- Phase 1: Parsed `git show 79240f3f6d766...` and b4 v3 patch text;
  verified tags and commit body.
- Phase 2: Verified diff is one hunk in `nl80211_prepare_wdev_dump()`
  with 12 insertions.
- Phase 3: Ran `git blame`, pickaxe history, `git show` for
  `c319d50bfcf67`, `463d018323851`, companion `15994bb0cbb8f`, and
  fetched wireless history.
- Phase 4: Ran `b4 dig`, `b4 dig -a`, `b4 dig -w`, `b4 am` for v1/v2/v3,
  saved/read mbox; WebFetch to lore was blocked by Anubis.
- Phase 5: Verified callers and relevant ops entries in
  `net/wireless/nl80211.c`.
- Phase 6: Used `git grep` across stable tags to confirm affected code
  exists and checked stable logs for absence of the candidate.
- Phase 8: Severity is based on verified patch text plus code paths; no
  build or runtime test was run.

**YES**

 net/wireless/nl80211.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index b94231c8441c4..ce3121b1c3319 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1146,6 +1146,18 @@ static int nl80211_prepare_wdev_dump(struct netlink_callback *cb,
 			rtnl_unlock();
 			return -ENODEV;
 		}
+
+		/*
+		 * The first invocation validated the wdev's netns against
+		 * the caller via __cfg80211_wdev_from_attrs(). The wiphy
+		 * may have moved netns between dumpit invocations (via
+		 * NL80211_CMD_SET_WIPHY_NETNS), so re-check here.
+		 */
+		if (!net_eq(wiphy_net(wiphy), sock_net(cb->skb->sk))) {
+			rtnl_unlock();
+			return -ENODEV;
+		}
+
 		*rdev = wiphy_to_rdev(wiphy);
 		*wdev = NULL;
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.6] ipv6: Implement limits on extension header parsing

[Sasha Levin]

From: Daniel Borkmann <daniel@iogearbox.net>

[ Upstream commit 3744b0964d5267c0b651bcd8f8c25db6bf4ccbac ]

ipv6_{skip_exthdr,find_hdr}() and ip6_{tnl_parse_tlv_enc_lim,
protocol_deliver_rcu}() iterate over IPv6 extension headers until they
find a non-extension-header protocol or run out of packet data. The
loops have no iteration counter, relying solely on the packet length
to bound them. For a crafted packet with 8-byte extension headers
filling a 64KB jumbogram, this means a worst case of up to ~8k
iterations with a skb_header_pointer call each. ipv6_skip_exthdr(),
for example, is used where it parses the inner quoted packet inside
an incoming ICMPv6 error:

  - icmpv6_rcv
    - checksum validation
    - case ICMPV6_DEST_UNREACH
      - icmpv6_notify
        - pskb_may_pull()       <- pull inner IPv6 header
        - ipv6_skip_exthdr()    <- iterates here
        - pskb_may_pull()
        - ipprot->err_handler() <- sk lookup

The per-iteration cost of ipv6_skip_exthdr itself is generally
light, but skb_header_pointer becomes more costly on reassembled
packets: the first ~1232 bytes of the inner packet are in the skb's
linear area, but the remaining ~63KB are in the frag_list where
skb_copy_bits is needed to read data.

Initially, the idea was to add a configurable limit via a new
sysctl knob with default 8, in line with knobs from commit
47d3d7ac656a ("ipv6: Implement limits on Hop-by-Hop and Destination
options"), but two reasons eventually argued against it:

- It adds to UAPI that needs to be maintained forever, and
  upcoming work is restricting extension header ordering anyway,
  leaving little reason for another sysctl knob
- exthdrs_core.c is always built-in even when CONFIG_IPV6=n,
  where struct net has no .ipv6 member, so the read site would
  need an ifdef'd fallback to a constant anyway

Therefore, just use a constant (IP6_MAX_EXT_HDRS_CNT). All four
extension header walking functions are now bound by this limit.

Note that the check in ip6_protocol_deliver_rcu() happens right
before the goto resubmit, such that we don't have to have a test
for ipv6_ext_hdr() in the fast-path.

There's an ongoing IETF draft-iurman-6man-eh-occurrences to enforce
IPv6 extension headers ordering and occurrence. The latter also
discusses security implications. As per RFC8200 section 4.1, the
occurrence rules for extension headers provide a practical upper
bound which is 8. In order to be conservative, let's define
IP6_MAX_EXT_HDRS_CNT as 12 to leave enough room for quirky setups.
In the unlikely event that this is still not enough, then we might
need to reconsider a sysctl.

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Justin Iurman <justin.iurman@gmail.com>
Link: https://patch.msgid.link/20260429154648.809751-1-daniel@iogearbox.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Decision Summary
This should be backported. It is a small IPv6 networking hardening/fix
for a reachable CPU-exhaustion path: several IPv6 extension-header
walkers were bounded only by packet length, allowing crafted packets
with many minimal 8-byte extension headers to force thousands of
iterations. The patch caps traversal at 12 headers, avoids new UAPI, and
was reviewed by IPv6/networking reviewers. Risk is mainly dropping
extremely exotic packets with more than 12 extension headers; the review
discussion explicitly considered that and settled on 12 as a
conservative compromise.

## Phase Walkthrough
Phase 1: Commit Message Forensics

Record 1.1: Subsystem `ipv6`; action verb `Implement limits`; claimed
intent is to bound IPv6 extension-header parsing loops.

Record 1.2: Tags found: `Signed-off-by: Daniel Borkmann`, `Reviewed-by:
Ido Schimmel`, `Reviewed-by: Eric Dumazet`, `Reviewed-by: Justin
Iurman`, `Link:
https://patch.msgid.link/20260429154648.809751-1-daniel@iogearbox.net`,
`Signed-off-by: Jakub Kicinski`. No `Fixes:`, no `Reported-by:`, no `Cc:
stable`.

Record 1.3: The body describes crafted 64KB packets with 8-byte
extension headers causing up to about 8k iterations, with costly
`skb_header_pointer()`/`skb_copy_bits()` on reassembled packets. Symptom
is CPU work amplification/DoS potential, not memory corruption or crash.
It identifies `icmpv6_rcv -> icmpv6_notify -> ipv6_skip_exthdr()` as a
concrete path.

Record 1.4: This is not disguised cleanup. It is a direct
correctness/security hardening fix: add a bound to previously unbounded
loops.

Phase 2: Diff Analysis

Record 2.1: Five files changed, 25 insertions: `include/net/dropreason-
core.h` +6, `include/net/ipv6.h` +3, `net/ipv6/exthdrs_core.c` +7,
`net/ipv6/ip6_input.c` +5, `net/ipv6/ip6_tunnel.c` +4. Modified
functions: `ipv6_skip_exthdr()`, `ipv6_find_hdr()`,
`ip6_protocol_deliver_rcu()`, `ip6_tnl_parse_tlv_enc_lim()`.

Record 2.2: Before, these loops stopped only at non-extension-header,
`NEXTHDR_NONE`, malformed/truncated packet data, fragment handling, or
protocol handler completion. After, each loop also stops/drops once
`IP6_MAX_EXT_HDRS_CNT` is exceeded.

Record 2.3: Bug category is logic/performance DoS hardening: missing
iteration bound in packet parser. It does not fix UAF/leak/race, but it
prevents attacker-controlled excessive parsing work.

Record 2.4: Fix quality is good: small, local counters, no locking or
lifetime changes, no new sysctl/API. Regression risk is limited to
rejecting packets with more than 12 traversed extension headers.

Phase 3: Git History Investigation

Record 3.1: `git blame` shows the relevant loops are old:
`ipv6_skip_exthdr()` loop traces to initial/early history with later
signature changes; `ipv6_find_hdr()` to v3.8-era code;
`ip6_protocol_deliver_rcu()` resubmit logic to v4.x/v5.0-era changes;
`ip6_tnl_parse_tlv_enc_lim()` exists from initial/older tunnel code with
later cleanups.

Record 3.2: No `Fixes:` tag, so no introducing commit to follow. I did
inspect referenced commit `47d3d7ac656a`, which added limits for Hop-by-
Hop/Destination TLV parsing and described similar DoS behavior.

Record 3.3: Recent file history shows related commit `076b8cad77aa9`
capped TLV scanning in `ip6_tnl_parse_tlv_enc_lim()`. This commit is
related but not a hard dependency for the outer extension-header-count
limit.

Record 3.4: Daniel Borkmann has recent related IPv6 limit work in the
same area. Commit was applied by Jakub Kicinski, and reviewed by Eric
Dumazet, Ido Schimmel, and Justin Iurman.

Record 3.5: No functional prerequisite was found for the core idea.
Older stable trees before `dropreason-core.h` will need a small backport
adjustment for the new drop reason, or can use an existing generic
reason.

Phase 4: Mailing List And External Research

Record 4.1: `b4 dig -c 3744b0964d5267c0b651bcd8f8c25db6bf4ccbac` found
`[PATCH net v5]` at the provided lore/patch.msgid link.

Record 4.2: `b4 dig -a` found v1 through v5. v1 added a sysctl and was
NAKed by Justin Iurman; v4 switched to a hard-coded limit; v5 reduced
the limit from 32 to 12.

Record 4.3: No `Reported-by` or bug-report link exists. Web/lore stable
search did not find a stable-specific request or objection.

Record 4.4: Related series context: review discussion referenced IETF
extension-header occurrence work; v5 was the latest and accepted
version.

Record 4.5: No stable mailing-list-specific discussion found. WebFetch
to lore was blocked/timed out, but `b4` successfully retrieved the
thread.

Phase 5: Code Semantic Analysis

Record 5.1: Key functions are `ipv6_skip_exthdr()`, `ipv6_find_hdr()`,
`ip6_protocol_deliver_rcu()`, `ip6_tnl_parse_tlv_enc_lim()`.

Record 5.2: `git grep` found many callers of `ipv6_skip_exthdr()` across
netfilter, XFRM/ESP, drivers, audit/security hooks, ICMPv6, and tunnel
code. `ipv6_find_hdr()` is used by netfilter/nftables, BPF, OVS, IPVS,
SRv6, drivers, and TC. `ip6_protocol_deliver_rcu()` is called from IPv6
input and UDP encapsulation resubmission. `ip6_tnl_parse_tlv_enc_lim()`
is called from GRE/tunnel paths.

Record 5.3: Key callees are `skb_header_pointer()`, `pskb_pull()`,
`pskb_may_pull()`, `raw6_local_deliver()`, `inet6_protos[]` dispatch,
and protocol handlers.

Record 5.4: Reachability is verified from IPv6 receive paths:
`ip6_input_finish()` calls `ip6_protocol_deliver_rcu()`, and
`icmpv6_notify()` calls `ipv6_skip_exthdr()` on quoted inner packets.
These are network packet processing paths.

Record 5.5: Similar prior pattern exists in `47d3d7ac656a` for TLV
count/length limits and in `076b8cad77aa9` for tunnel TLV scanning.

Phase 6: Stable Tree Analysis

Record 6.1: The four key functions exist in checked tags `v5.10`,
`v5.15`, `v6.1`, `v6.6`, `v6.12`, and `v6.19`. Thus the affected code
shape exists across active LTS/stable ranges.

Record 6.2: Expected backport difficulty: clean or minor for newer
trees; minor rework for pre-`dropreason-core.h` trees because
`include/net/dropreason-core.h` is absent in `v5.10`, `v5.15`, and
`v6.1`.

Record 6.3: No alternate stable-specific fix for this exact extension-
header traversal count was found. Related TLV-limiting commits address
adjacent, not identical, loops.

Phase 7: Subsystem Context

Record 7.1: Subsystem is IPv6 networking, criticality IMPORTANT to CORE
for IPv6-enabled systems because packet receive, ICMPv6, netfilter,
tunnel, and driver offload paths call these helpers.

Record 7.2: Subsystem is active; recent history shows multiple
IPv6/tunnel/drop-reason changes, but the unbounded parsing loops
themselves are longstanding.

Phase 8: Impact And Risk

Record 8.1: Affected users are IPv6-enabled systems, especially systems
exposed to crafted IPv6 traffic or using IPv6 tunnels/netfilter paths.

Record 8.2: Trigger is a crafted IPv6 packet chain with many small
extension headers, especially costly when parsed from
fragmented/reassembled skb data. Network reachability depends on
filtering and IPv6 deployment.

Record 8.3: Failure mode is CPU work amplification/DoS risk, not crash
or corruption. Severity: HIGH for exposed IPv6 hosts because it is
remote packet-triggered parser amplification; not CRITICAL because no
verified panic, data loss, or privilege escalation was found.

Record 8.4: Benefit is high: caps an attacker-controlled loop in common
networking code. Risk is low-to-medium: packets with more than 12
traversed extension headers may now be rejected, but reviewers
explicitly judged 12 conservative relative to RFC/IETF occurrence
expectations.

Phase 9: Final Synthesis

Record 9.1: Evidence for backporting: small 25-line fix; real attacker-
controlled parser amplification; network receive reachability verified;
reviewed by networking experts; v1 concerns were resolved; no new UAPI.
Evidence against: behavior change for extreme extension-header chains;
older trees need minor drop-reason backport adjustment; no syzbot/user
report/CVE. Unresolved: no benchmark for this exact v5 patch was found,
and no stable-specific discussion was found.

Record 9.2: Stable rules: obviously correct and reviewed, yes; fixes a
real bug, yes; important issue, yes as network DoS/performance
amplification; small and contained, yes; no new feature/API, yes; stable
apply, likely clean for newer trees and minor adjustment for older
trees.

Record 9.3: No automatic exception category applies. This is not a
device ID, quirk, DT, build, or documentation fix.

Record 9.4: The risk-benefit balance favors backporting.

## Verification
- [Phase 1] Parsed `git show 3744b0964d5267c0b651bcd8f8c25db6bf4ccbac`:
  verified subject, tags, message, and 25-line diff.
- [Phase 2] Read local code in `net/ipv6/exthdrs_core.c`,
  `net/ipv6/ip6_input.c`, `net/ipv6/ip6_tunnel.c`, and
  `include/net/ipv6.h`: verified loops were unbounded before the patch.
- [Phase 3] Ran `git blame` on changed regions: verified long-lived code
  and relevant commit ancestry.
- [Phase 3] Inspected `47d3d7ac656a` and `076b8cad77aa9`: verified
  similar prior DoS-limit work.
- [Phase 4] Ran `b4 dig -c`, `b4 dig -a`, `b4 dig -w`, and `b4 mbox`:
  verified v1-v5 history, reviewers, NAK of sysctl approach, and v5
  acceptance.
- [Phase 5] Ran caller searches for all four functions: verified broad
  IPv6/netfilter/tunnel/driver call surface.
- [Phase 6] Checked `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.19`:
  verified the affected functions exist; verified `dropreason-core.h` is
  absent before v6.6.
- [Phase 8] Verified reachable call paths in `icmpv6_notify()`,
  `ip6_input_finish()`, `udpv6_queue_rcv_skb()`, and `ip6_gre` tunnel
  code.
- UNVERIFIED: exact exploitability impact across real networks and exact
  CPU-cost benchmark for this specific v5 patch.
- UNVERIFIED: clean application to every currently maintained stable
  branch; older trees likely need minor drop-reason context adjustment.

**YES**

 include/net/dropreason-core.h | 6 ++++++
 include/net/ipv6.h            | 3 +++
 net/ipv6/exthdrs_core.c       | 7 +++++++
 net/ipv6/ip6_input.c          | 5 +++++
 net/ipv6/ip6_tunnel.c         | 4 ++++
 5 files changed, 25 insertions(+)

diff --git a/include/net/dropreason-core.h b/include/net/dropreason-core.h
index a7b7abd66e215..0b674a02665ab 100644
--- a/include/net/dropreason-core.h
+++ b/include/net/dropreason-core.h
@@ -102,6 +102,7 @@
 	FN(FRAG_TOO_FAR)		\
 	FN(TCP_MINTTL)			\
 	FN(IPV6_BAD_EXTHDR)		\
+	FN(IPV6_TOO_MANY_EXTHDRS)	\
 	FN(IPV6_NDISC_FRAG)		\
 	FN(IPV6_NDISC_HOP_LIMIT)	\
 	FN(IPV6_NDISC_BAD_CODE)		\
@@ -513,6 +514,11 @@ enum skb_drop_reason {
 	SKB_DROP_REASON_TCP_MINTTL,
 	/** @SKB_DROP_REASON_IPV6_BAD_EXTHDR: Bad IPv6 extension header. */
 	SKB_DROP_REASON_IPV6_BAD_EXTHDR,
+	/**
+	 * @SKB_DROP_REASON_IPV6_TOO_MANY_EXTHDRS: Number of IPv6 extension
+	 * headers in the packet exceeds IP6_MAX_EXT_HDRS_CNT.
+	 */
+	SKB_DROP_REASON_IPV6_TOO_MANY_EXTHDRS,
 	/** @SKB_DROP_REASON_IPV6_NDISC_FRAG: invalid frag (suppress_frag_ndisc). */
 	SKB_DROP_REASON_IPV6_NDISC_FRAG,
 	/** @SKB_DROP_REASON_IPV6_NDISC_HOP_LIMIT: invalid hop limit. */
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 53c5056508be5..ec95c11b8e434 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -90,6 +90,9 @@ struct ip_tunnel_info;
 #define IP6_DEFAULT_MAX_DST_OPTS_LEN	 INT_MAX /* No limit */
 #define IP6_DEFAULT_MAX_HBH_OPTS_LEN	 INT_MAX /* No limit */
 
+/* Hard limit on traversed IPv6 extension headers */
+#define IP6_MAX_EXT_HDRS_CNT		 12
+
 /*
  *	Addr type
  *	
diff --git a/net/ipv6/exthdrs_core.c b/net/ipv6/exthdrs_core.c
index 49e31e4ae7b7f..9d06d487e8b10 100644
--- a/net/ipv6/exthdrs_core.c
+++ b/net/ipv6/exthdrs_core.c
@@ -73,6 +73,7 @@ int ipv6_skip_exthdr(const struct sk_buff *skb, int start, u8 *nexthdrp,
 		     __be16 *frag_offp)
 {
 	u8 nexthdr = *nexthdrp;
+	int exthdr_cnt = 0;
 
 	*frag_offp = 0;
 
@@ -82,6 +83,8 @@ int ipv6_skip_exthdr(const struct sk_buff *skb, int start, u8 *nexthdrp,
 
 		if (nexthdr == NEXTHDR_NONE)
 			return -1;
+		if (unlikely(exthdr_cnt++ >= IP6_MAX_EXT_HDRS_CNT))
+			return -1;
 		hp = skb_header_pointer(skb, start, sizeof(_hdr), &_hdr);
 		if (!hp)
 			return -1;
@@ -190,6 +193,7 @@ int ipv6_find_hdr(const struct sk_buff *skb, unsigned int *offset,
 {
 	unsigned int start = skb_network_offset(skb) + sizeof(struct ipv6hdr);
 	u8 nexthdr = ipv6_hdr(skb)->nexthdr;
+	int exthdr_cnt = 0;
 	bool found;
 
 	if (fragoff)
@@ -216,6 +220,9 @@ int ipv6_find_hdr(const struct sk_buff *skb, unsigned int *offset,
 			return -ENOENT;
 		}
 
+		if (unlikely(exthdr_cnt++ >= IP6_MAX_EXT_HDRS_CNT))
+			return -EBADMSG;
+
 		hp = skb_header_pointer(skb, start, sizeof(_hdr), &_hdr);
 		if (!hp)
 			return -EBADMSG;
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index 2bcb981c91aa8..bbad1d4e6b854 100644
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -363,6 +363,7 @@ INDIRECT_CALLABLE_DECLARE(int tcp_v6_rcv(struct sk_buff *));
 void ip6_protocol_deliver_rcu(struct net *net, struct sk_buff *skb, int nexthdr,
 			      bool have_final)
 {
+	int exthdr_cnt = IP6CB(skb)->flags & IP6SKB_HOPBYHOP ? 1 : 0;
 	const struct inet6_protocol *ipprot;
 	struct inet6_dev *idev;
 	unsigned int nhoff;
@@ -447,6 +448,10 @@ void ip6_protocol_deliver_rcu(struct net *net, struct sk_buff *skb, int nexthdr,
 				nexthdr = ret;
 				goto resubmit_final;
 			} else {
+				if (unlikely(exthdr_cnt++ >= IP6_MAX_EXT_HDRS_CNT)) {
+					SKB_DR_SET(reason, IPV6_TOO_MANY_EXTHDRS);
+					goto discard;
+				}
 				goto resubmit;
 			}
 		} else if (ret == 0) {
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 0b53488a92290..c1ca9b2806359 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -400,11 +400,15 @@ __u16 ip6_tnl_parse_tlv_enc_lim(struct sk_buff *skb, __u8 *raw)
 	unsigned int nhoff = raw - skb->data;
 	unsigned int off = nhoff + sizeof(*ipv6h);
 	u8 nexthdr = ipv6h->nexthdr;
+	int exthdr_cnt = 0;
 
 	while (ipv6_ext_hdr(nexthdr) && nexthdr != NEXTHDR_NONE) {
 		struct ipv6_opt_hdr *hdr;
 		u16 optlen;
 
+		if (unlikely(exthdr_cnt++ >= IP6_MAX_EXT_HDRS_CNT))
+			break;
+
 		if (!pskb_may_pull(skb, off + sizeof(*hdr)))
 			break;
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] net: usb: cdc_ncm: add Apple Mac USB-C direct networking quirk

[Sasha Levin]

From: Alex Cheema <alex@exolabs.net>

[ Upstream commit a5148bc2fa27092862ac4b9e7b5c8340d60cff34 ]

Apple Silicon Macs expose two CDC NCM "private" data interfaces over
USB-C with VID:PID 0x05ac:0x1905 and product string "Mac". This is the
same protocol Apple already ships on iPhone (0x05ac:0x12a8) and iPad
(0x05ac:0x12ab) for RemoteXPC since iOS 17 -- both data interfaces lack
an interrupt status endpoint, so they rely on the FLAG_LINK_INTR-
conditional bind path introduced in commit 3ec8d7572a69 ("CDC-NCM: add
support for Apple's private interface").

The id_table currently has entries for iPhone and iPad but not for the
Mac. Without a match, cdc_ncm falls through to the generic CDC NCM
class-match entry, which uses the FLAG_LINK_INTR-having cdc_ncm_info
struct, so bind_common() fails on the missing status endpoint and no
netdev appears.

Add id_table entries for both interface numbers (0 and 2) of the Mac,
bound to the existing apple_private_interface_info driver_info.

Verified empirically on a Mac Studio M3 Ultra running macOS 26.5: when
a Mac is connected via USB-C, ioreg shows VID 0x05ac, PID 0x1905,
product string "Mac", with two NCM data interfaces at numbers 0 and 2.
The same PID is presented by all current Apple Silicon Mac models
(MacBook Pro/Air, Mac mini, Mac Studio across the M-series), mirroring
Apple's single-PID-per-family pattern from iPhone/iPad.

After this patch, plugging a Mac into a Linux host running the patched
kernel produces two enx... interfaces (one per data interface),
"ip -br link" lists them as UP, and standard userspace networking
(DHCP, NetworkManager shared mode, etc.) works without any modprobe
overrides or out-of-tree modules.

Signed-off-by: Alex Cheema <alex@exolabs.net>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260429175739.34426-1-alex@exolabs.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

### Phase 1: Commit Message Forensics
Record: Subsystem is `net: usb: cdc_ncm`; action verb is `add`; intent
is to add an Apple Mac USB-C direct networking quirk/device match.

Record: Tags verified from `git show a5148bc2fa27` and `b4`:
`Signed-off-by: Alex Cheema <alex@exolabs.net>`, `Reviewed-by: Simon
Horman <horms@kernel.org>`, `Link:
https://patch.msgid.link/20260429175739.34426-1-alex@exolabs.net`,
`Signed-off-by: Jakub Kicinski <kuba@kernel.org>`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, or `Cc: stable@vger.kernel.org`.

Record: The body describes a real functional failure: Apple Silicon Macs
with VID:PID `05ac:1905` expose private CDC NCM interfaces without
interrupt status endpoints. Without specific IDs, they match the generic
CDC NCM entry, use `cdc_ncm_info` with `FLAG_LINK_INTR`, fail endpoint
collection in `cdc_ncm_bind_common()`, and no netdev appears. The author
reports empirical testing on Mac Studio M3 Ultra.

Record: This is not a hidden memory-safety bug; it is an explicit
hardware ID/quirk fix for already-supported Apple private CDC NCM
handling.

### Phase 2: Diff Analysis
Record: One file changed: `drivers/net/usb/cdc_ncm.c`, 8 insertions, 0
deletions. No functions modified; only `cdc_devs[]` gets two entries.
Scope is single-file, surgical, device-ID style.

Record: Before: Mac interfaces could fall through to the generic CDC NCM
class entry using `cdc_ncm_info`. After: interface numbers `0` and `2`
for `05ac:1905` bind to existing `apple_private_interface_info`.

Record: Bug category is hardware quirk/device ID addition. The local
code verifies `apple_private_interface_info` omits `FLAG_LINK_INTR`,
while `cdc_ncm_info` includes it, and `cdc_ncm_bind_common()` rejects
devices with no status endpoint when `FLAG_LINK_INTR` is set.

Record: Fix quality is high: two exact USB interface-number matches,
reused existing driver_info, no new code path beyond selecting an
existing quirk. Regression risk is very low and limited to Apple VID:PID
`05ac:1905` interfaces `0` and `2`.

### Phase 3: Git History
Record: `git blame` shows `apple_private_interface_info` and the
iPhone/iPad Apple table entries were introduced by `3ec8d7572a69` in
2024.

Record: No `Fixes:` tag is present, but the commit body references
`3ec8d7572a69`; `git show` confirms that commit introduced Apple private
support and the conditional missing-status-endpoint handling.

Record: Recent `cdc_ncm.c` history shows unrelated
bounds/filtering/refactor changes; no prerequisite besides the
referenced Apple private support was found.

Record: `git log --author="Alex Cheema" -10 -- drivers/net/usb` found no
prior local subsystem commits by the author. The patch was reviewed by
Simon Horman and committed by Jakub Kicinski.

Record: Dependency found: stable trees must already contain
`3ec8d7572a69` or an equivalent `apple_private_interface_info`; older
trees without that support will not take this patch standalone.

### Phase 4: Mailing List And External Research
Record: `b4 dig -c a5148bc2fa27` found the original submission at the
patch.msgid.link URL.

Record: `b4 dig -c a5148bc2fa27 -a` found only v1; no later revision.

Record: `b4 dig -c a5148bc2fa27 -w` showed the right net/USB maintainers
and lists were included, including Oliver Neukum, Bjørn Mork, Jakub
Kicinski, netdev, and linux-usb.

Record: Full thread via `b4 mbox` had three messages: the patch, Simon
Horman’s `Reviewed-by`, and patchwork-bot saying Jakub applied it to
`netdev/net.git` as `a5148bc2fa27`. No NAKs or concerns observed.

Record: WebFetch of lore/stable was blocked by Anubis, so stable-
specific web discussion could not be independently checked. No stable
nomination appeared in the fetched thread.

### Phase 5: Code Semantic Analysis
Record: Modified object is `cdc_devs[]`; no function body changed.

Record: Call/reachability path verified: `cdc_ncm_driver.id_table =
cdc_devs`, `.probe = usbnet_probe`; `usbnet_probe()` reads
`prod->driver_info`, sets `dev->driver_info`, then calls `info->bind`,
which is `cdc_ncm_bind()`, which calls `cdc_ncm_bind_common()`.

Record: Key callees are endpoint discovery and bind setup in
`cdc_ncm_bind_common()`, especially the verified endpoint check
requiring status only when `FLAG_LINK_INTR` is set.

Record: User reachability is USB device enumeration/probe when an
affected Mac is connected to a Linux host. This is not syscall-triggered
by an unprivileged local user; it is hardware-triggered.

Record: Similar pattern found: existing iPhone/iPad Apple entries
already bind private interfaces to `apple_private_interface_info`.

### Phase 6: Stable Tree Analysis
Record: `git merge-base --is-ancestor 3ec8d7572a69 <tag>` verified
`3ec8d7572a69` is absent from `v5.15`, `v6.1`, `v6.6`, `v6.9`, and
`v6.10`, but present in `v6.11`, `v6.12`, and `v7.0`.

Record: `git show <tag>:drivers/net/usb/cdc_ncm.c | rg ...` verified
`v6.11+` have `apple_private_interface_info` and iPhone/iPad Apple
entries, but not the Mac `0x1905` entries.

Record: `git apply --check` succeeded against the current `7.0.5` tree.
Backport should be clean for trees with the same Apple-private support;
older trees need the prerequisite and are not standalone targets.

Record: No alternate related stable fix was found locally.

### Phase 7: Subsystem Context
Record: Subsystem is USB networking driver code, under
`drivers/net/usb`. Criticality is important for users of this hardware,
not core/universal.

Record: `scripts/get_maintainer.pl -f drivers/net/usb/cdc_ncm.c`
confirmed the patch was sent to the relevant USB CDC Ethernet and
networking maintainers/lists. Recent `drivers/net/usb` history shows
active maintenance.

### Phase 8: Impact And Risk
Record: Affected users are Linux hosts connecting to Apple Silicon Macs
via USB-C direct CDC NCM networking.

Record: Trigger is plugging in the matching Mac USB device. The failure
is likely whenever the unsupported `05ac:1905` private interfaces are
exposed and lack the interrupt status endpoint, based on the commit body
and verified bind logic.

Record: Failure mode is functional loss: no netdev appears. Severity is
medium by generic bug severity, but it fits the stable exception for new
device IDs/hardware quirks.

Record: Benefit is high for affected hardware users: direct networking
works without overrides/out-of-tree modules. Risk is very low: two
exact-match USB ID entries selecting existing behavior.

### Phase 9: Final Synthesis
Evidence for backporting: it is a classic stable-acceptable hardware
quirk/device ID addition; it fixes a verified bind failure mechanism; it
is tiny and contained; it reuses existing Apple private CDC NCM support;
it was reviewed and applied by netdev maintainership; it applies cleanly
to the current stable-style tree.

Evidence against backporting: it is not a crash/security/data-corruption
fix, and it is not standalone for stable trees older than `v6.11` unless
`3ec8d7572a69` is also present.

Stable rules checklist:
1. Obviously correct and tested: yes; exact ID entries, author-tested,
   reviewer accepted.
2. Fixes a real bug: yes; no netdev appears for matching hardware.
3. Important issue: yes under hardware support/quirk exception, though
   not critical severity.
4. Small and contained: yes, 8 insertions in one table.
5. No new APIs/features: yes, no API or new driver; only IDs for
   existing behavior.
6. Applies to stable: yes for trees with Apple private support; older
   trees need prerequisite handling.

Exception category: new USB device ID / hardware quirk for an existing
driver path.

## Verification
- [Phase 1] Parsed `git show a5148bc2fa27`: confirmed subject, body,
  trailers, reviewed-by, link, and maintainer signoff.
- [Phase 2] Read `drivers/net/usb/cdc_ncm.c`: confirmed `cdc_ncm_info`
  has `FLAG_LINK_INTR`, `apple_private_interface_info` does not, and
  `cdc_ncm_bind_common()` fails missing status endpoints when
  `FLAG_LINK_INTR` is set.
- [Phase 3] `git blame` confirmed Apple private support and existing
  Apple IDs came from `3ec8d7572a69`.
- [Phase 3] `git show 3ec8d7572a69` confirmed it introduced Apple
  private CDC NCM support and the conditional endpoint check.
- [Phase 4] `b4 dig -c a5148bc2fa27`: found the original lore
  submission.
- [Phase 4] `b4 dig -a`: only v1 found.
- [Phase 4] `b4 dig -w`: confirmed relevant maintainers/lists were
  included.
- [Phase 4] `b4 mbox`: confirmed Simon Horman review and patchwork
  application by Jakub Kicinski.
- [Phase 5] `rg` and `ReadFile` traced `cdc_devs[]` to `usbnet_probe()`
  to `cdc_ncm_bind()` to `cdc_ncm_bind_common()`.
- [Phase 6] Tag ancestry checks confirmed prerequisite exists in
  `v6.11+` but not `v6.10` and older checked tags.
- [Phase 6] `git apply --check` confirmed clean apply to current tree.
- UNVERIFIED: Independent confirmation that all current Apple Silicon
  Macs use PID `0x1905`; this is author-stated in the patch, not
  independently verified here.
- UNVERIFIED: Stable mailing-list search via WebFetch was blocked by
  Anubis; no stable-specific discussion was visible in the fetched `b4`
  thread.

This should be backported to stable trees that already contain the Apple
private CDC NCM support, because it is a low-risk hardware ID/quirk fix
that restores networking for real hardware.

**YES**

 drivers/net/usb/cdc_ncm.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index bb9929727eb93..0223a172851ec 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -2012,6 +2012,14 @@ static const struct usb_device_id cdc_devs[] = {
 		.driver_info = (unsigned long)&apple_private_interface_info,
 	},
 
+	/* Mac */
+	{ USB_DEVICE_INTERFACE_NUMBER(0x05ac, 0x1905, 0),
+		.driver_info = (unsigned long)&apple_private_interface_info,
+	},
+	{ USB_DEVICE_INTERFACE_NUMBER(0x05ac, 0x1905, 2),
+		.driver_info = (unsigned long)&apple_private_interface_info,
+	},
+
 	/* Ericsson MBM devices like F5521gw */
 	{ .match_flags = USB_DEVICE_ID_MATCH_INT_INFO
 		| USB_DEVICE_ID_MATCH_VENDOR,
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.15] net: usb: r8152: add TRENDnet TUC-ET2G v2.0

[Sasha Levin]

From: Aleksander Jan Bajkowski <olek2@wp.pl>

[ Upstream commit f93836b236773862e9ee268a82e3614caf77ea01 ]

The TRENDnet TUC-ET2G V2.0 is an RTL8156B based 2.5G Ethernet controller.

Add the vendor and product ID values to the driver. This makes Ethernet
work with the adapter.

Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Birger Koblitz <mail@birger-koblitz.de>
Link: https://patch.msgid.link/20260430213435.21821-1-olek2@wp.pl
Signed-off-by: Jakub Kicinski <kuba@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 `net: usb: r8152`; action verb `add`; claimed
intent: add TRENDnet TUC-ET2G v2.0 USB device ID so the existing `r8152`
driver binds to the adapter.

Step 1.2 Record: Tags present:
- `Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>`
- `Reviewed-by: Andrew Lunn <andrew@lunn.ch>`
- `Reviewed-by: Birger Koblitz <mail@birger-koblitz.de>`
- `Link: https://patch.msgid.link/20260430213435.21821-1-olek2@wp.pl`
- `Signed-off-by: Jakub Kicinski <kuba@kernel.org>`

No `Fixes:`, `Reported-by:`, `Tested-by:`, or `Cc:
stable@vger.kernel.org` tag was present. Absence of those tags is not a
negative signal here.

Step 1.3 Record: The body describes a real hardware support failure:
TRENDnet TUC-ET2G V2.0 is RTL8156B-based, but without its USB
vendor/product ID in `rtl8152_table`, Ethernet does not work with that
adapter. No affected kernel versions are named.

Step 1.4 Record: This is not a hidden memory/synchronization bug. It is
an explicit new USB device ID addition to an existing driver, which is a
stable exception category.

## Phase 2: Diff Analysis
Step 2.1 Record: One file changed: `drivers/net/usb/r8152.c`, `+1/-0`.
No function body changed. The modified object is `rtl8152_table`. Scope:
single-file surgical device-ID addition.

Step 2.2 Record: Before the change, the table contained TRENDnet
`0xe02b` but not `0xe02c`, so USB matching would not select `r8152` for
`20f4:e02c`. After the change, `USB_DEVICE(VENDOR_ID_TRENDNET, 0xe02c)`
is matched by the driver table used by both `rtl8152_driver.id_table`
and `rtl8152_cfgselector_driver.id_table`.

Step 2.3 Record: Bug category is hardware enablement / USB device ID
addition. It does not touch error paths, locking, reference counts,
memory safety, or public APIs.

Step 2.4 Record: The fix is obviously correct if the ID maps to RTL8156B
hardware. I verified the device identity externally: WikiDevi lists TUC-
ET2G v2.0R as USB ID `20f4:e02c` with Realtek RTL8156B, and TRENDnet’s
own support page confirms the TUC-ET2G v2 product. Regression risk is
very low; existing devices are unaffected unless another incompatible
device uses the same exact USB ID.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` around the table showed the existing
TRENDnet `0xe02b` entry came from `15fba71533bc` and the new `0xe02c`
line comes from `f93836b23677`. The table terminator dates back to
`ac718b69301c`. The “bug” is not introduced by a code commit; it is the
absence of a product-specific ID for existing supported silicon.

Step 3.2 Record: No `Fixes:` tag, so there is no introducing commit to
follow.

Step 3.3 Record: Recent related history includes `15fba71533bc` adding
the first TRENDnet TUC-ET2G ID and `dc9c67820f81` adding a TP-Link ID.
The candidate is standalone on trees that already have
`VENDOR_ID_TRENDNET`.

Step 3.4 Record: The author has at least one prior `r8152` device-ID
commit, `848b09d53d92` for Dell Alienware AW1022z. The patch was
reviewed by Andrew Lunn and Birger Koblitz and applied by Jakub
Kicinski.

Step 3.5 Record: Dependency found: `VENDOR_ID_TRENDNET` was introduced
by `15fba71533bc`, and `git merge-base --is-ancestor` confirms that
commit is an ancestor of `f93836b23677`. Mainline release tags `v5.15`,
`v6.1`, `v6.6`, `v6.12`, and `v6.19` lack `VENDOR_ID_TRENDNET`, while
`v7.0-rc3` has it. Older stable backports therefore need either
`15fba71533bc` first or a small backport adjustment adding `#define
VENDOR_ID_TRENDNET 0x20f4`.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c f93836b23677` found the original patch
submission by patch-id. `b4 dig -a` reported the accepted one-patch
submission at `20260430213435.21821-1-olek2@wp.pl`; `b4` also found an
earlier identical submission from
`20260426214909.3426105-1-olek2@wp.pl`. The earlier thread had Andrew
Lunn asking for repost after netdev opened and giving his `Reviewed-by`.
No NAK or technical objection found.

Step 4.2 Record: `b4 dig -w` showed the patch was sent to netdev
maintainers/lists and USB networking lists, including Andrew Lunn, David
Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Realtek contacts,
`linux-usb`, `netdev`, and `linux-kernel`. `MAINTAINERS` confirms those
netdev maintainers for `NETWORKING DRIVERS`, and `drivers/net/usb/` is
under `USB NETWORKING DRIVERS`.

Step 4.3 Record: No separate bug report or `Reported-by` tag. External
hardware verification found TUC-ET2G v2.0R as `20f4:e02c` / RTL8156B.

Step 4.4 Record: This is a single-patch submission, not a multi-patch
fix series. The only practical dependency for older trees is the
TRENDnet vendor define from the prior TUC-ET2G ID commit.

Step 4.5 Record: WebFetch to lore was blocked by Anubis. WebSearch did
not find stable-specific discussion for `f93836b23677` or the patch
message ID. No stable objection found.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: No functions modified. Modified data structure:
`rtl8152_table`.

Step 5.2 Record: `rtl8152_table` is referenced by
`MODULE_DEVICE_TABLE(usb, rtl8152_table)`, `rtl8152_driver.id_table`,
and `rtl8152_cfgselector_driver.id_table`. Matching devices enter the
normal USB probe path via `rtl8152_probe`.

Step 5.3 Record: The relevant probe path checks vendor-specific
interface class, `rtl_check_vendor_ok`, `rtl8152_get_version`, then
calls `rtl8152_probe_once`. The config selector uses `__rtl_get_hw_ver`.
This patch adds no new calls.

Step 5.4 Record: Reachability is USB device enumeration: plugging in or
booting with the adapter attached. It is not a remote or syscall-
triggered security issue.

Step 5.5 Record: Similar pattern exists throughout the same table for
Realtek, Lenovo, TP-Link, D-Link, Dell, ASUS, and earlier TRENDnet IDs.
`git log -S'0xe02c'` found no prior `0xe02c` entry in the checked
history.

## Phase 6: Stable Tree Analysis
Step 6.1 Record: Checked mainline release tags `v5.15`, `v6.1`, `v6.6`,
`v6.12`, and `v6.19`: all contain `0x8156` and RTL8156B version
handling, but not the TRENDnet `0xe02c` ID. This means the supported
chipset path exists in those releases, but the product-specific match is
missing.

Step 6.2 Record: Backport difficulty is low. It applies cleanly to trees
with `VENDOR_ID_TRENDNET` / `0xe02b`; older bases need a minor
context/define adjustment or the prior TRENDnet ID patch.

Step 6.3 Record: No alternate local fix for `0xe02c` was found. No
stable-specific replacement fix was verified.

## Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: Subsystem is `drivers/net/usb`, USB Ethernet networking
driver. Criticality: driver-specific, important for users of this
hardware, not core-kernel-wide.

Step 7.2 Record: The file is active, with recent `r8152` feature and fix
commits, but this change is isolated to the USB ID table and does not
depend on recent functional refactoring except the vendor
define/backport context noted above.

## Phase 8: Impact And Risk
Step 8.1 Record: Affected users are systems with TRENDnet TUC-ET2G V2.0
and `CONFIG_USB_RTL8152`.

Step 8.2 Record: Trigger is common for affected users: adapter insertion
or boot with the adapter connected. Not remotely triggerable; physical
USB access is needed.

Step 8.3 Record: Failure mode is device non-binding / Ethernet
unavailable. Severity is not crash/security-critical, but it is a real
user-visible hardware functionality failure.

Step 8.4 Record: Benefit is high for affected stable users because it
makes the adapter work with an already-supported RTL8156B driver. Risk
is very low: one table entry, no behavior change for existing IDs.

## Phase 9: Final Synthesis
Evidence for backporting:
- New USB device ID for existing driver and already-supported RTL8156B
  silicon.
- Fixes a real user-visible failure: Ethernet does not work with this
  adapter.
- One-line, single-file, no API or behavior change for existing
  hardware.
- Reviewed by Andrew Lunn and Birger Koblitz; applied by Jakub Kicinski.
- Hardware identity verified as TRENDnet `20f4:e02c` / RTL8156B.

Evidence against backporting:
- Not a crash, data corruption, security, or deadlock fix.
- Older stable bases may need the prior `VENDOR_ID_TRENDNET` definition
  or a tiny backport adjustment.

Unresolved:
- I did not verify every active stable branch state directly; I verified
  mainline release tags and the dependency relationship. Lore WebFetch
  was blocked, but `b4` successfully fetched the thread.

Stable rules checklist:
1. Obviously correct and tested? Yes, one matching-table entry;
   reviewed; hardware ID verified.
2. Fixes a real bug affecting users? Yes, adapter does not bind/work
   without the ID.
3. Important issue? Yes under the stable “new device IDs” exception,
   though not crash/security.
4. Small and contained? Yes, one insertion in one file.
5. No new features/APIs? Yes, no API or behavioral change except
   matching this USB device.
6. Can apply to stable trees? Yes with low difficulty; older trees may
   need `VENDOR_ID_TRENDNET`.

Exception category: New USB device ID for an existing driver. This is a
standard stable-appropriate exception.

## Verification
- [Phase 1] Parsed commit `f93836b236773862e9ee268a82e3614caf77ea01`
  with `git show`; confirmed subject, body, tags, and `+1/-0` diff.
- [Phase 2] Compared `git diff f938^..f938`; confirmed only `{
  USB_DEVICE(VENDOR_ID_TRENDNET, 0xe02c) }` is added.
- [Phase 3] Ran `git blame` around `rtl8152_table`; confirmed existing
  `0xe02b` from `15fba71533bc` and new `0xe02c` from `f93836b23677`.
- [Phase 3] Ran `git merge-base --is-ancestor 15fba71533bc
  f93836b23677`; confirmed the vendor define dependency is in the
  candidate’s ancestry.
- [Phase 3] Checked release tags `v5.15`, `v6.1`, `v6.6`, `v6.12`,
  `v6.19`, `v7.0-rc3`, `v7.1-rc3`; confirmed older release tags have
  RTL8156/RTL_VER_13 support but lack TRENDnet IDs until `v7.0-rc3`.
- [Phase 4] Ran `b4 dig -c`, `b4 dig -a`, and `b4 dig -w`; confirmed
  patch-id match, one-patch submission, recipients, and
  review/application thread.
- [Phase 4] Read full `b4 mbox` threads; confirmed Andrew Lunn review on
  repost request, Birger Koblitz review, and patchwork notification that
  Jakub applied it.
- [Phase 4] WebFetch to lore was blocked by Anubis; external GitHub
  commit fetch confirmed the commit metadata and diff.
- [Phase 4] WebFetch of WikiDevi and TRENDnet pages verified TUC-ET2G v2
  hardware identity; WikiDevi specifically listed USB ID `20f4:e02c` and
  RTL8156B.
- [Phase 5] Searched `rtl8152_table` references; confirmed use by
  `MODULE_DEVICE_TABLE`, `rtl8152_driver.id_table`, and
  `rtl8152_cfgselector_driver.id_table`.
- [Phase 5] Read `rtl8152_probe` and config selector code; confirmed
  affected path is USB enumeration/probe, with no changed runtime logic.
- [Phase 7] Checked `MAINTAINERS`; confirmed netdev maintainers and
  `drivers/net/usb/` list coverage.
- [Phase 8] Checked `drivers/net/usb/Kconfig`; confirmed affected
  configuration is `CONFIG_USB_RTL8152`.

This is exactly the kind of low-risk new USB ID addition stable trees
normally take.

**YES**

 drivers/net/usb/r8152.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 0c83bbbea2e7c..0ac2b079e435c 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -10055,6 +10055,7 @@ static const struct usb_device_id rtl8152_table[] = {
 	{ USB_DEVICE(VENDOR_ID_DELL,    0xb097) },
 	{ USB_DEVICE(VENDOR_ID_ASUS,    0x1976) },
 	{ USB_DEVICE(VENDOR_ID_TRENDNET, 0xe02b) },
+	{ USB_DEVICE(VENDOR_ID_TRENDNET, 0xe02c) },
 	{}
 };
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl

[Sasha Levin]

From: Mingyu Wang <25181214217@stu.xidian.edu.cn>

[ Upstream commit 617eb7c0961a8dfcfc811844a6396e406b2923ea ]

While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong
timeout value` warning was observed, accompanied by SMBus controller
state machine corruption.

The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of
10 ms. The user argument is checked against INT_MAX, but it is
subsequently multiplied by 10 before being passed to msecs_to_jiffies().

A malicious user can pass a large value (e.g., 429496729) that passes
the `arg > INT_MAX` check but overflows when multiplied by 10. This
results in a truncated 32-bit unsigned value that bypasses the
internal `(int)m < 0` check in `msecs_to_jiffies()`.

The truncated value is then assigned to `client->adapter->timeout`
(a signed 32-bit int), which is reinterpreted as a negative number.
When passed to wait_for_completion_timeout(), this negative value
undergoes sign extension to a 64-bit unsigned long, triggering the
`schedule_timeout` warning and causing premature returns. This leaves
the SMBus state machine in an unrecoverable state, constituting a
local Denial of Service (DoS).

Fix this by bounding the user argument to `INT_MAX / 10`.

Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
[wsa: move the comment as well]
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

### Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem `i2c: dev`; action verb `prevent`; intent is
to prevent integer overflow in the userspace `I2C_TIMEOUT` ioctl.

Step 1.2 Record: Tags are `Signed-off-by: Mingyu Wang
<25181214217@stu.xidian.edu.cn>` and `Signed-off-by: Wolfram Sang
<wsa+renesas@sang-engineering.com>` with maintainer edit note `[wsa:
move the comment as well]`. No `Fixes:`, `Reported-by:`, `Tested-by:`,
`Reviewed-by:`, `Link:`, or `Cc: stable` tags were present.

Step 1.3 Record: The body describes a Syzkaller-found `schedule_timeout:
wrong timeout value` warning and SMBus state machine corruption after a
large userspace timeout causes overflow/truncation before storing into
signed `adapter->timeout`. Symptom is local DoS through bad timeout
behavior; root cause is validating `arg` before multiplying by 10.

Step 1.4 Record: This is not hidden cleanup; it is an explicit integer
overflow and local DoS fix.

### Phase 2: Diff Analysis
Step 2.1 Record: One file changed, `drivers/i2c/i2c-dev.c`; committed
diff is 5 insertions and 4 deletions due comment movement. Modified
function: `i2cdev_ioctl()`. Scope: single-file surgical fix.

Step 2.2 Record: Before, `I2C_TIMEOUT` accepted any `arg <= INT_MAX`,
then used `msecs_to_jiffies(arg * 10)`. After, it accepts only `arg <=
INT_MAX / 10`, so the 10 ms unit conversion cannot exceed signed 32-bit
range before assignment to `adapter->timeout`.

Step 2.3 Record: Bug category is integer overflow/truncation and type-
range validation. Broken mechanism: userspace-controlled timeout is
range-checked before scaling, but stored in `struct
i2c_adapter.timeout`, which is `int`.

Step 2.4 Record: Fix quality is high: one validation bound change, no
new API, no refactor. Regression risk is low; it rejects only extreme
timeout values that cannot be represented safely after the documented 10
ms scaling.

### Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows the existing `arg > INT_MAX` guard
came from `6ebec961d59b` and the `arg * 10` timeout assignment/comment
came from `cd97f39b7cdf`. `git describe` places them at
`v5.0-rc2~14^2~1` and `v2.6.29-rc7~62^2~2`, respectively.

Step 3.2 Record: No `Fixes:` tag, so no tagged introducing commit to
follow. I still inspected `6ebec961d59b`, which originally fixed
negative retry/timeout values and was itself stable-tagged.

Step 3.3 Record: Recent upstream `drivers/i2c/i2c-dev.c` history shows
this candidate plus unrelated cleanup/fix commits; no prerequisite
series was identified.

Step 3.4 Record: `Mingyu Wang` has this one upstream `drivers/i2c`
commit in the checked history. Wolfram Sang committed it and is the I2C
maintainer in the patch flow.

Step 3.5 Record: No dependent commit found. The patch assumes the long-
existing `I2C_TIMEOUT` case and applies cleanly to the current `v7.0.5`
checkout.

### Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c 617eb7c0961a8` found the original submission
at `https://patch.msgid.link/20260427025745.1100768-1-
25181214217@stu.xidian.edu.cn`. `b4 dig -a` found only v1. The submitted
patch was a one-line bound change; the committed version is the
maintainer-adjusted version with comment movement.

Step 4.2 Record: `b4 dig -w` shows recipients: Mingyu Wang, Wolfram
Sang, `linux-i2c@vger.kernel.org`, and `linux-kernel@vger.kernel.org`.

Step 4.3 Record: No `Link:` or `Reported-by:` tag exists. Public web
searches did not find a syzkaller bug page for this exact issue; the
Syzkaller finding is verified only from the commit/patch text.

Step 4.4 Record: No multi-patch series found; standalone patch.

Step 4.5 Record: Stable-list WebFetch was blocked by lore Anubis, and
web search did not find stable-specific discussion. No evidence of
objections or NAKs was found in the b4-fetched mbox.

### Phase 5: Code Semantic Analysis
Step 5.1 Record: Modified function: `i2cdev_ioctl()`.

Step 5.2 Record: Call path is userspace ioctl on `/dev/i2c-*` through
`i2cdev_fops.unlocked_ioctl = i2cdev_ioctl`; compat ioctls fall back to
`i2cdev_ioctl()` for commands not handled specially, including
`I2C_TIMEOUT`.

Step 5.3 Record: Key callee is `msecs_to_jiffies()`, whose runtime
helper treats negative `unsigned int` values as infinite timeout. The
result is assigned to `struct i2c_adapter.timeout`, verified as `int`.

Step 5.4 Record: Buggy path is reachable from userspace with access to
an i2c-dev node. The corrupted timeout is then used by core retry loops
and many bus drivers, including paths using
`wait_for_completion_timeout()`.

Step 5.5 Record: Similar timeout use is widespread in `drivers/i2c`, but
this specific unchecked userspace scaling pattern was found in
`i2c-dev`.

### Phase 6: Stable Tree Analysis
Step 6.1 Record: Checked `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.19`, and
`v7.0`; all contain the vulnerable `arg > INT_MAX` plus
`msecs_to_jiffies(arg * 10)` pattern.

Step 6.2 Record: Expected backport difficulty is clean or trivial. `git
apply --check` succeeded on current `v7.0.5`; checked stable snippets
have matching context.

Step 6.3 Record: No alternate stable fix found by subject/phrase
searches in local git history.

### Phase 7: Subsystem Context
Step 7.1 Record: Subsystem is I2C userspace character-device interface,
`drivers/i2c/i2c-dev.c`. Criticality: important, because it exposes bus
control to userspace and affects any system using `i2c-dev`.

Step 7.2 Record: Subsystem is mature but actively maintained. The
affected ioctl path is long-standing.

### Phase 8: Impact And Risk
Step 8.1 Record: Affected users are systems exposing `/dev/i2c-*` to
userspace, including embedded, hardware-management, and sensor-control
systems.

Step 8.2 Record: Trigger is setting `I2C_TIMEOUT` to a large value
through ioctl, then using affected I2C/SMBus transfer paths. It requires
access to the device node; no capability check is present in the ioctl
path itself.

Step 8.3 Record: Failure mode is at least a kernel `schedule_timeout:
wrong timeout value` warning and broken timeout behavior; commit text
reports SMBus controller state machine corruption and local DoS.
Severity: HIGH.

Step 8.4 Record: Benefit is high because it blocks a fuzzed, userspace-
reachable DoS class bug in maintained stable trees. Risk is very low
because the patch is one range check in one ioctl case.

### Phase 9: Final Synthesis
Step 9.1 Record: Evidence for backporting: real integer overflow,
Syzkaller-reported in commit text, userspace-reachable with i2c-dev
access, high-severity timeout corruption/DoS, tiny fix, maintainer-
applied, vulnerable code present in checked stable trees, clean apply to
`v7.0.5`. Evidence against: no public syzkaller link, no `Reported-
by`/`Tested-by`, and exact SMBus unrecoverable-state details were not
independently reproduced.

Step 9.2 Record: Stable rules: obviously correct yes; fixes real bug
yes; important issue yes, local DoS/bad kernel timeout path; small and
contained yes; no new features/APIs yes; stable applicability yes for
checked trees.

Step 9.3 Record: No exception category needed; this is a normal bug fix,
not device ID/quirk/DT/build/doc.

Step 9.4 Record: The technical merits strongly support stable
backporting.

## Verification
- Phase 1: Parsed `git show 617eb7c0961a8`; confirmed tags and absence
  of `Fixes:`, `Reported-by:`, `Link:`, and stable tag.
- Phase 2: Inspected committed diff; confirmed one-file change in
  `i2cdev_ioctl()`.
- Phase 3: `git blame` identified `6ebec961d59b` and `cd97f39b7cdf`;
  `git describe` placed them before all checked maintained stable trees.
- Phase 3: `git show 6ebec961d59b` confirmed prior timeout/retry
  negative-value fix and stable nomination.
- Phase 4: `b4 dig`, `b4 dig -a`, `b4 dig -w`, and mbox read found one
  v1 patch, proper I2C recipients, and no visible objections.
- Phase 4: WebFetch of lore was blocked by Anubis; stable-list
  discussion and public syzkaller report remain unverified.
- Phase 5: `rg` and file reads confirmed ioctl file operations, compat
  fallback, `msecs_to_jiffies()`, `adapter->timeout` as `int`, and
  downstream timeout uses.
- Phase 6: Checked `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.19`, and `v7.0`
  snippets; all contain the vulnerable pattern.
- Phase 6: `git apply --check` confirmed the upstream diff applies to
  current `v7.0.5`.
- Phase 8: `schedule_timeout()` source confirms negative timeout emits
  `wrong timeout value` and returns 0.

**YES**

 drivers/i2c/i2c-dev.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c
index 7bbe0263411eb..ccaac5e29f906 100644
--- a/drivers/i2c/i2c-dev.c
+++ b/drivers/i2c/i2c-dev.c
@@ -487,12 +487,13 @@ static long i2cdev_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 		client->adapter->retries = arg;
 		break;
 	case I2C_TIMEOUT:
-		if (arg > INT_MAX)
+		/*
+		 * For historical reasons, user-space sets the timeout value in
+		 * units of 10 ms.
+		 */
+		if (arg > INT_MAX / 10)
 			return -EINVAL;
 
-		/* For historical reasons, user-space sets the timeout
-		 * value in units of 10 ms.
-		 */
 		client->adapter->timeout = msecs_to_jiffies(arg * 10);
 		break;
 	default:
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] powerpc/vmx: avoid KASAN instrumentation in enter_vmx_ops() for kexec

[Sasha Levin]

From: Sourabh Jain <sourabhjain@linux.ibm.com>

[ Upstream commit 38e989d504fc52900a3786b7144fb53cd67e0389 ]

The kexec sequence invokes enter_vmx_ops() via copy_page() with the MMU
disabled. In this context, code must not rely on normal virtual address
translations or trigger page faults.

With KASAN enabled, functions get instrumented and may access shadow
memory using regular address translation. When executed with the MMU
off, this can lead to page faults (bad_page_fault) from which the
kernel cannot recover in the kexec path, resulting in a hang.

The kexec path sets preempt_count to HARDIRQ_OFFSET before entering
the MMU-off copy sequence.

current_thread_info()->preempt_count = HARDIRQ_OFFSET
  kexec_sequence(..., copy_with_mmu_off = 1)
    -> kexec_copy_flush(image)
         copy_segments()
           -> copy_page(dest, addr)
	         bl enter_vmx_ops()
                   if (in_interrupt())
                     return 0
	         beq .Lnonvmx_copy

Since kexec sets preempt_count to HARDIRQ_OFFSET, in_interrupt()
evaluates to true and enter_vmx_ops() returns early.

As in_interrupt() (and preempt_count()) are always inlined, mark
enter_vmx_ops() with __no_sanitize_address to avoid KASAN
instrumentation and shadow memory access with MMU disabled, helping
kexec boot fine with KASAN enabled.

Reported-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Reviewed-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Tested-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260407124349.1698552-2-sourabhjain@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Record: subsystem `powerpc/vmx`; action verb `avoid`; intent is to
prevent KASAN instrumentation of `enter_vmx_ops()` when it is reached
from the kexec MMU-off copy path.

Record: tags parsed from the candidate message:
- `Reported-by: Aboorva Devarajan <aboorvad@linux.ibm.com>`
- `Reviewed-by: Aboorva Devarajan <aboorvad@linux.ibm.com>`
- `Tested-by: Aboorva Devarajan <aboorvad@linux.ibm.com>`
- `Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>`
- `Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>`
- `Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>`
- `Link: https://patch.msgid.link/20260407124349.1698552-2-
  sourabhjain@linux.ibm.com`
- No `Fixes:` tag in this commit. Absence is not a negative signal.

Record: bug description from the message: `kexec_sequence()` may call
`copy_page()` with the MMU disabled; on PowerPC Book3S this can enter
`copypage_power7.S`, which calls `enter_vmx_ops()`. If KASAN instruments
`enter_vmx_ops()`, the instrumentation may access shadow memory using
normal virtual translation, which is invalid with MMU off and can cause
an unrecoverable `bad_page_fault`/hang in kexec.

Record: hidden bug fix: yes. Although phrased as “avoid
instrumentation,” this fixes a real boot/hang failure in the kexec/kdump
path under KASAN.

## Phase 2: Diff Analysis
Record: one file changed: `arch/powerpc/lib/vmx-helper.c`, with 8
insertions and 1 deletion in the fetched v3 patch. The only functional
change is changing `int enter_vmx_ops(void)` to `int
__no_sanitize_address enter_vmx_ops(void)`; the remaining additions are
explanatory comments.

Record: modified function: `enter_vmx_ops()`.

Record: before behavior: `enter_vmx_ops()` could be KASAN-instrumented.
During kexec with MMU off, the function first checks `in_interrupt()`
and should return `0`, but KASAN prologue/body instrumentation can run
before or around normal code and touch shadow memory.

Record: after behavior: `__no_sanitize_address` suppresses KASAN
instrumentation for this function, preserving the intended early return
path when `preempt_count` contains `HARDIRQ_OFFSET`.

Record: bug category: sanitizer/real-mode correctness bug causing kexec
hang. This is a crash/hang class fix, not a cleanup.

Record: fix quality: small, surgical, and low risk. It does not alter
normal logic, public API, data structures, or userspace-visible
behavior. The only behavioral effect is disabling KASAN instrumentation
for one helper that can run in an MMU-off path.

## Phase 3: Git History Investigation
Record: local `HEAD` is a stable release commit, not the candidate. `git
log --grep` on current history, `master`, and `power-next` did not find
the candidate commit locally, so there was no commit hash available for
`b4 dig -c`.

Record: `git blame` on current `arch/powerpc/lib/vmx-helper.c` shows the
unannotated `enter_vmx_ops()` present in the local tree; due this
repository’s history shape, blame attributes the original lines to a
merge/root history point, so the exact original introduction commit was
not verifiable locally.

Record: no candidate `Fixes:` tag to follow. The companion patch in the
same series has `Fixes: 2ab2d5794f14 ("powerpc/kasan: Disable address
sanitization in kexec paths")`; `git show` confirms that commit disabled
sanitization for PowerPC kexec real-mode paths in 2022.

Record: related recent local history: `6bc9c0a905228` changed VMX
usercopy flow and added export context around the same file. That
affects hunk context for older stable trees, but not the actual one-line
fix.

Record: author context: `git log --author="Sourabh Jain" --
arch/powerpc/...` shows multiple PowerPC kexec/crash/fadump commits.
`MAINTAINERS` lists Madhavan Srinivasan and Michael Ellerman as PowerPC
maintainers; Madhavan signed off the candidate.

Record: dependencies: no source-level prerequisite for the annotation
itself. Function `enter_vmx_ops()` and `__no_sanitize_address` exist in
checked stable tags. Functional completeness is best with the companion
patch fixing `KASAN_SANITIZE_core_$(BITS).o`, because review/test
discussion says both patches together make KASAN kexec succeed.

## Phase 4: Mailing List And External Research
Record: `b4 am` for message id
`20260407124349.1698552-2-sourabhjain@linux.ibm.com` fetched a v3 two-
patch series. It reported total patches: 2, current tree apply clean,
and DKIM signature valid for patch 2.

Record: `b4 am -c` checked for newer revisions and did not report a
newer v4. v3 appears to be the latest fetched revision.

Record: `b4 mbox` fetched the v3 thread. Patch 2 was addressed to
`linuxppc-dev` and CC’d PowerPC/kexec stakeholders including Michael
Ellerman, Madhavan Srinivasan, Mahesh Salgaonkar, Hari Bathini, Daniel
Axtens, Venkat Rao Bagalkote, Aboorva Devarajan, and Ritesh Harjani.

Record: `WebFetch` of lore URLs was blocked by Anubis, but `b4` and the
`yhbt.net` lore mirror provided the thread content.

Record: v2 review discussion verified:
- Ritesh Harjani reviewed patch 2 and said “LGTM,” granting `Reviewed-
  by`.
- Aboorva Devarajan reported an actual KASAN-enabled kexec hang on
  pseries PowerVM: system reached “kexec: Starting switchover sequence”
  and then hung.
- Aboorva tested that “with both the patches applied, kexec completes
  successfully with KASAN enabled.”
- v1 annotated both `enter_vmx_ops()` and `exit_vmx_ops()`; v2 removed
  `exit_vmx_ops()` annotation and added the explanatory comment. This
  shows review-driven narrowing of the fix.

Record: stable-specific discussion: Ritesh explicitly suggested `Cc:
stable@vger.kernel.org` for patch 1. I did not find a direct stable
nomination for patch 2, but patch 2 was reviewed and tested as part of
the same two-patch functional fix.

## Phase 5: Code Semantic Analysis
Record: modified function: `enter_vmx_ops()`.

Record: callers found by exact search:
- `arch/powerpc/lib/copypage_power7.S`
- `arch/powerpc/lib/memcpy_power7.S`
- `arch/powerpc/lib/memcmp_64.S`

Record: relevant kexec call chain verified in code:
`reboot(LINUX_REBOOT_CMD_KEXEC)` -> `kernel_kexec()` ->
`machine_kexec()` -> `default_machine_kexec()` -> `kexec_sequence()` ->
`kexec_copy_flush()` -> `copy_segments()` -> `copy_page()` ->
`copypage_power7.S` -> `enter_vmx_ops()`.

Record: key callees/logic in `enter_vmx_ops()`: `in_interrupt()`,
`preempt_disable()`, and `enable_kernel_altivec()`. In the kexec MMU-off
path, `default_machine_kexec()` sets
`current_thread_info()->preempt_count = HARDIRQ_OFFSET`, and
`include/linux/preempt.h` defines `in_interrupt()` via `irq_count()`,
which observes the hardirq bits.

Record: reachability: reachable from privileged kexec/kdump paths. It is
not unprivileged-user reachable, but kdump reliability is operationally
important.

Record: similar patterns: PowerPC already disables KASAN for sensitive
real-mode/interrupt code in multiple Makefiles and uses
`__no_sanitize_address` in PowerPC interrupt/stack code, so the
attribute is consistent with local practice.

## Phase 6: Cross-Referencing And Stable Tree Analysis
Record: buggy code exists in stable tags checked: `v5.4`, `v5.10`,
`v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.18`, `v6.19`, and `v7.0` all have
`enter_vmx_ops()` without `__no_sanitize_address`.

Record: the kexec `copy_segments()` -> `copy_page()` path and
`preempt_count = HARDIRQ_OFFSET` were verified in `v5.4`, `v5.10`,
`v5.15`, `v6.1`, and current/v7.0-era code.

Record: `copypage_power7.S` calls `enter_vmx_ops()` in `v5.4`, `v5.10`,
`v5.15`, and current code.

Record: `__no_sanitize_address` exists in compiler headers in checked
stable tags, including `v5.4`, `v5.10`, `v6.1`, `v6.6`, and current.

Record: backport difficulty: clean on current `7.0.y` per `git apply
--check` and `b4`. Older stable trees may need a tiny context adjustment
because `EXPORT_SYMBOL(exit_vmx_usercopy)` is not present in older
versions, but the actual function signature is present and the backport
is straightforward.

Record: related fixes already in stable: not verified as already
present; local stable tags checked do not contain the candidate
annotation.

## Phase 7: Subsystem And Maintainer Context
Record: subsystem is PowerPC architecture library/kexec path:
`arch/powerpc/lib` and `arch/powerpc/kexec`.

Record: criticality: important/platform-specific. It affects PowerPC
systems using kexec/kdump with KASAN enabled, especially pseries/PowerVM
cases verified in review. It is not universal across all architectures.

Record: subsystem activity: local history shows recent PowerPC VMX
usercopy and kexec/crash/fadump activity, and the patch was handled
through the PowerPC maintainer path.

## Phase 8: Impact And Risk Assessment
Record: affected users: PowerPC Book3S/PowerVM-style systems using
kexec/kdump with KASAN-enabled kernels and VMX copy paths.

Record: trigger conditions: kexec/kdump switchover, MMU-off copy path,
KASAN enabled, and `copy_page()` selecting the Power7 VMX copy path. The
triggering operation is privileged, but the failure impacts crash dump
capture and reboot into the new kernel.

Record: failure mode: system hang during kexec/kdump. Review discussion
includes an observed hang after “kexec: Starting switchover sequence,”
and the commit message explains unrecoverable `bad_page_fault` risk with
MMU off. Severity: HIGH to CRITICAL for affected debug/crash-dump
deployments.

Record: benefit: high for affected PowerPC KASAN/kdump users because it
prevents a hard hang and restores kexec completion.

Record: risk: very low. One function annotation plus comment; no logic
change. The main concern is that stable maintainers should also take the
companion Makefile fix for full KASAN/kexec coverage.

## Phase 9: Final Synthesis
Record: evidence for backporting:
- Fixes a real, reviewed, and tested kexec hang with KASAN enabled.
- Aboorva Devarajan reported and tested the failure/fix.
- Ritesh Harjani reviewed the final approach.
- The fix is one function attribute and explanatory comment.
- It affects a serious operational path: kexec/kdump boot into a
  new/capture kernel.
- The buggy code and call path exist across active stable versions
  checked.
- Backport is clean for current `7.0.y` and trivial for older stable
  trees.

Record: evidence against backporting:
- The issue is config/platform specific: PowerPC plus KASAN plus
  kexec/kdump plus VMX copy path.
- Older stable trees may require minor context adjustment.
- The commit is part of a two-patch series; the companion Makefile KASAN
  fix should be included for the tested complete fix.

Record: unresolved questions:
- Exact original introduction commit for `enter_vmx_ops()` could not be
  verified from local history.
- Direct lore `WebFetch` was blocked by Anubis; I used `b4` and a lore
  mirror instead.
- I did not build-test the backport.

Stable rules checklist:
1. Obviously correct and tested: yes. The annotation directly suppresses
   KASAN instrumentation on the one helper that can execute with MMU
   off; tested-by is present.
2. Fixes a real bug: yes. Review discussion reports an actual kexec hang
   with KASAN.
3. Important issue: yes. Failure mode is kexec/kdump hang.
4. Small and contained: yes. One file, one function annotation.
5. No new features/APIs: yes.
6. Can apply to stable: yes for current `7.0.y`; older trees may need
   trivial context adjustment.

Exception category: not a device ID/quirk/build/doc exception. It is a
normal stability fix.

## Verification
- [Phase 1] Parsed the supplied commit message and fetched patch mbox;
  confirmed tags, no `Fixes:` tag in patch 2, and the linked message id.
- [Phase 2] Inspected fetched v3 diff; confirmed `arch/powerpc/lib/vmx-
  helper.c` has 8 insertions and 1 deletion, changing only
  `enter_vmx_ops()`.
- [Phase 3] Ran `git log --grep` on current history, `master`, and
  `power-next`; candidate not present locally.
- [Phase 3] Ran `git blame` around `enter_vmx_ops()`; local history
  could not identify true original introduction beyond repository
  history shape.
- [Phase 3] Ran `git show 2ab2d5794f14`; confirmed related PowerPC kexec
  KASAN sanitization commit from 2022.
- [Phase 4] Ran `b4 am` and `b4 am -c`; fetched v3 two-patch series, no
  newer revision reported, patch 2 DKIM valid.
- [Phase 4] Ran `b4 mbox`; confirmed original recipients and patch
  content.
- [Phase 4] Used lore mirror for v2 thread; confirmed Ritesh review,
  Aboorva tested-by/reported hang, and v1-to-v2 narrowing.
- [Phase 5] Searched call sites; confirmed `copypage_power7.S`,
  `memcpy_power7.S`, and `memcmp_64.S` call `enter_vmx_ops()`.
- [Phase 5] Read kexec and assembly code; confirmed kexec path reaches
  `copy_page()` with MMU-off logic and `preempt_count = HARDIRQ_OFFSET`.
- [Phase 6] Checked stable tags `v5.4` through `v7.0`; confirmed
  `enter_vmx_ops()` exists without the annotation and the relevant
  kexec/copy path exists in checked trees.
- [Phase 6] Ran `git apply --check` on current tree for patch 2 and the
  series; clean on current `7.0.y`.
- [Phase 7] Checked `MAINTAINERS`; confirmed PowerPC maintainers and
  that Madhavan Srinivasan is listed for PowerPC.
- [Phase 8] Verified failure mode from review discussion: KASAN-enabled
  kexec hangs after switchover; with both patches applied, kexec
  completes.

This should be backported, ideally together with the companion
`powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o` patch
for the tested complete KASAN/kexec fix.

**YES**

 arch/powerpc/lib/vmx-helper.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/lib/vmx-helper.c b/arch/powerpc/lib/vmx-helper.c
index 554b248002b4f..57e897b60db86 100644
--- a/arch/powerpc/lib/vmx-helper.c
+++ b/arch/powerpc/lib/vmx-helper.c
@@ -52,7 +52,14 @@ int exit_vmx_usercopy(void)
 }
 EXPORT_SYMBOL(exit_vmx_usercopy);
 
-int enter_vmx_ops(void)
+/*
+ * Can be called from kexec copy_page() path with MMU off. The kexec
+ * code sets preempt_count to HARDIRQ_OFFSET so we return early here.
+ * Since in_interrupt() is always inline, __no_sanitize_address on this
+ * function is sufficient to avoid KASAN shadow memory accesses in real
+ * mode.
+ */
+int __no_sanitize_address enter_vmx_ops(void)
 {
 	if (in_interrupt())
 		return 0;
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] ALSA: usb-audio: add min_mute quirk for Razer Nommo V2 X

[Sasha Levin]

From: Pauli Virtanen <pav@iki.fi>

[ Upstream commit ad39a189bfebb3de580f390bc000f9e121c6aca3 ]

ID 1532:055e Razer USA, Ltd Razer Nommo V2 X
is tested to have muted min playback volume. Apply quirk for that.

Link: https://gitlab.freedesktop.org/pipewire/pipewire/-/work_items/5235
Signed-off-by: Pauli Virtanen <pav@iki.fi>
Link: https://patch.msgid.link/94449577332d14d7974864903825f27e5824ddbc.1777579951.git.pav@iki.fi
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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 `ALSA: usb-audio`; action verb `add`; intent:
add a playback-minimum-is-mute quirk for USB ID `1532:055e`, Razer Nommo
V2 X.

Step 1.2 Record: tags in supplied message: `Link` to PipeWire work item,
`Signed-off-by: Pauli Virtanen`, `Link` to patch msgid, `Signed-off-by:
Takashi Iwai`. No `Fixes`, `Reported-by`, `Tested-by`, `Reviewed-by`,
`Acked-by`, or `Cc: stable`. The lore patch mbox verifies the Pauli SOB
and PipeWire link; Takashi replied “Applied now.”

Step 1.3 Record: bug description is device-specific: Razer Nommo V2 X
has muted minimum playback volume. Symptom: userspace may expose the
minimum playback volume as a normal low audible volume even though
hardware treats it as mute. Version info: none in commit message. Root
cause: device has nonstandard mixer semantics.

Step 1.4 Record: yes, hidden bug/hardware workaround. It is a quirk for
incorrect USB-audio volume semantics on real hardware.

## Phase 2: Diff Analysis
Step 2.1 Record: `sound/usb/quirks.c`, `+2/-0`, in
`quirk_flags_table[]`. Scope: single-file surgical hardware quirk.

Step 2.2 Record: before, USB ID `1532:055e` had no built-in quirk flag.
After, matching that device sets `QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE`.
Affected path is USB-audio device initialization and mixer control
construction.

Step 2.3 Record: bug category is hardware workaround / quirk table
entry. Mechanism: `snd_usb_init_quirk_flags_table()` ORs the flag into
`chip->quirk_flags`; `snd_usb_mixer_fu_apply_quirk()` sees that flag on
Playback controls and sets `cval->min_mute = 1`;
`snd_usb_mixer_vol_tlv()` then reports `SNDRV_CTL_TLVT_DB_MINMAX_MUTE`.

Step 2.4 Record: fix is obviously correct for kernels with this quirk
infrastructure: one ID-specific table entry, no public API, no locking
or lifetime changes. Regression risk is very low and limited to this
VID:PID.

## Phase 3: Git History Investigation
Step 3.1 Record: blame around the insertion area shows the surrounding
quirk table is longstanding, with the nearby `NeuralDSP Quad Cortex`
exception from `bc5b4e5ae1a67` and Denon entries from older Takashi Iwai
commits. The common min-mute quirk infrastructure comes from
`2c3ca8cc55a3` and follow-ups.

Step 3.2 Record: no `Fixes:` tag, so no introducing commit to follow.

Step 3.3 Record: recent `sound/usb/quirks.c` history contains many
similar device-specific quirk fixes. Related min-mute commits include
`2b929b6eec0c7` Logitech H390, `9af61fc91486c` MS LifeChat, and
`b98b69c38512c` SteelSeries Arctis.

Step 3.4 Record: Pauli Virtanen has prior USB-audio quirk commits in
this exact area, including Logitech H390, MS LifeChat, and SteelSeries
Arctis min-mute quirks.

Step 3.5 Record: dependency is the min-mute quirk infrastructure.
Present in current `7.0.y`; present in `v6.18` with
`QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE`; `v6.17` has older
`QUIRK_FLAG_MIXER_MIN_MUTE`; `v6.16`/`v6.12` did not show the generic
flag.

## Phase 4: Mailing List And External Research
Step 4.1 Record: no local commit hash was found, so `b4 dig -c` could
not be used successfully. `b4 am` and `b4 mbox` by message-id found a
single-patch thread at the supplied msgid. Thread has patch plus Takashi
Iwai reply: “Applied now.” No NAKs or concerns found in fetched thread.

Step 4.2 Record: original patch To/Cc from mbox: `linux-
sound@vger.kernel.org`, Pauli Virtanen, Jaroslav Kysela, Takashi Iwai,
`linux-kernel@vger.kernel.org`. Appropriate sound maintainers/lists were
included.

Step 4.3 Record: PipeWire link was blocked by Anubis via WebFetch, so
details could not be verified. GitHub OpenRazer issue independently
verifies device name and VID:PID `1532:055E`, but it is not the PipeWire
volume bug report.

Step 4.4 Record: thread is a standalone one-patch submission. Similar
prior min-mute quirk patches exist, but this patch does not depend on a
same-series patch.

Step 4.5 Record: lore stable search via WebFetch was blocked by Anubis;
local stable branch searches found no existing Razer Nommo V2 X commit.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: modified data object is `quirk_flags_table[]`; affected
functions are `snd_usb_init_quirk_flags_table()`,
`snd_usb_init_quirk_flags()`, `snd_usb_audio_create()`,
`snd_usb_mixer_fu_apply_quirk()`, and `snd_usb_mixer_vol_tlv()`.

Step 5.2 Record: `snd_usb_audio_create()` calls
`snd_usb_init_quirk_flags()` during USB audio card creation; that calls
`snd_usb_init_quirk_flags_table()`. `build_feature_ctl()` calls
`snd_usb_mixer_fu_apply_quirk()` while building mixer controls.

Step 5.3 Record: key callees/side effects are table lookup, setting
`chip->quirk_flags`, setting `cval->min_mute`, and TLV reporting through
`copy_to_user()`.

Step 5.4 Record: reachable when the specific USB audio device is
connected and its mixer controls are created. This is device-specific,
not universal.

Step 5.5 Record: many existing `QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE`
entries exist for similar USB audio devices, confirming this is an
established local pattern.

## Phase 6: Stable Tree Analysis
Step 6.1 Record: current `7.0.y` lacks the Razer entry and contains the
necessary infrastructure. `v6.18`/`v6.19` contain the named playback
min-mute flag. `v6.17` has the older generic
`QUIRK_FLAG_MIXER_MIN_MUTE`; `v6.16`/`v6.12` did not show the generic
flag.

Step 6.2 Record: `git apply --check` succeeds on current `7.0.y`. Older
trees may need minor contextual adjustment; `v6.17` would need the older
flag name. Older LTS trees without the common quirk infrastructure would
need a nontrivial backport or prerequisite series.

Step 6.3 Record: no related Razer Nommo V2 X fix found in local
`stable/linux-7.0.y`.

## Phase 7: Subsystem Context
Step 7.1 Record: subsystem is ALSA USB audio driver under `sound/usb`;
criticality is driver-specific/peripheral, but real hardware user-
visible behavior.

Step 7.2 Record: USB-audio quirks are active, with recent commits
adding/fixing device-specific quirks and min-mute behavior.

## Phase 8: Impact And Risk
Step 8.1 Record: affected population is users of Razer Nommo V2 X using
USB audio.

Step 8.2 Record: trigger is normal volume-control use on that device.
Unprivileged audio clients can read/use ALSA mixer metadata, but no
security impact was verified.

Step 8.3 Record: failure mode is functional audio control
misrepresentation: minimum playback volume is mute. Severity: medium for
affected hardware, not crash/corruption.

Step 8.4 Record: benefit is high for affected device users and low
system-wide; risk is very low because the change is a two-line VID:PID-
scoped quirk.

## Phase 9: Final Synthesis
Step 9.1 Record: evidence for backporting: real tested hardware quirk,
established USB-audio pattern, two-line scoped change, maintainer
applied, clean on `7.0.y`, no global behavior change. Evidence against:
not a crash/security/data-corruption fix; older stable trees may need
adjustment or prerequisites. Unresolved: PipeWire bug details
unavailable due Anubis; no upstream commit hash found locally for `b4
dig`.

Step 9.2 Record: stable rules: obviously correct: yes for trees with
infrastructure; fixes real user-visible hardware bug: yes; important
enough: yes under hardware-quirk exception; small/contained: yes, 2
lines; no new APIs/features: yes; applies to stable: clean on current
`7.0.y`, minor/unknown adjustments for older trees.

Step 9.3 Record: exception category applies: hardware quirk/workaround
for an existing driver and existing quirk mechanism.

Step 9.4 Record: decision is to backport to stable trees that contain
the min-mute quirk infrastructure, especially `7.0.y`/`6.19.y`/`6.18.y`;
older trees should only take it with the appropriate small backport
adjustment or prerequisites.

Verification: performed semantic search; inspected current HEAD and
branch state; read `sound/usb/quirks.c`, `usbaudio.h`, `mixer_quirks.c`,
`mixer.c`, and `card.c`; used `rg` for quirk usage/callers; used `git
blame`, `git log`, `git show`, `git merge-base`, and `git apply
--check`; fetched lore thread with `b4 am`/`b4 mbox`; attempted `b4 dig`
but no commit hash/local commit match was available; attempted WebFetch
for PipeWire/lore search but Anubis blocked; verified device VID:PID via
OpenRazer/WebSearch.

**YES**

 sound/usb/quirks.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index 4cfa24c06fcdf..148bf7e4e4d72 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -2307,6 +2307,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
 		   QUIRK_FLAG_IGNORE_CTL_ERROR),
 	DEVICE_FLG(0x152a, 0x880a, /* NeuralDSP Quad Cortex */
 		   0), /* Doesn't have the vendor quirk which would otherwise apply */
+	DEVICE_FLG(0x1532, 0x055e, /* Razer Nommo V2 X */
+		   QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE),
 	DEVICE_FLG(0x154e, 0x1002, /* Denon DCD-1500RE */
 		   QUIRK_FLAG_ITF_USB_DSD_DAC | QUIRK_FLAG_CTL_MSG_DELAY),
 	DEVICE_FLG(0x154e, 0x1003, /* Denon DA-300USB */
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] wifi: libertas: fix integer underflow in process_cmdrequest()

[Sasha Levin]

From: Amir Mohammad Jahangirzad <a.jahangirzad@gmail.com>

[ Upstream commit 3994b4afd521d60e47e012fe2ed7b606aaec370b ]

The existing validation only checks if recvlength exceeds
LBS_CMD_BUFFER_SIZE, but doesn't check the lower bound. When a
USB device sends a response shorter than MESSAGE_HEADER_LEN, the
subtraction (recvlength - MESSAGE_HEADER_LEN) wraps to a huge
value, causing memcpy to corrupt the heap.
Add the same lower bound check that libertas_tf already has.

Signed-off-by: Amir Mohammad Jahangirzad <a.jahangirzad@gmail.com>
Link: https://patch.msgid.link/20260418004247.368944-1-a.jahangirzad@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough
### Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem is `wifi: libertas`; action verb is `fix`;
claimed intent is to prevent integer underflow in
`process_cmdrequest()`.

Step 1.2 Record: Tags present are `Signed-off-by: Amir Mohammad
Jahangirzad`, `Link: https://patch.msgid.link/20260418004247.368944-1-
a.jahangirzad@gmail.com`, and `Signed-off-by: Johannes Berg`. No
`Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by`, or
`Cc: stable` tag was present in the supplied commit message or original
posted patch.

Step 1.3 Record: The commit body describes a concrete memory corruption
bug: `recvlength` is only checked against the upper bound, then
`recvlength - MESSAGE_HEADER_LEN` is stored in `priv->resp_len[i]` and
used as the `memcpy()` length. If a USB device supplies fewer than 4
bytes, the subtraction becomes negative and is converted to a huge
unsigned copy length. Symptom/failure mode: heap/driver memory
corruption from `memcpy()`. Version information: none in the message.
Root cause: missing lower-bound validation.

Step 1.4 Record: This is not hidden; it is explicitly a memory-safety
fix. It matches the same already-present guard in `libertas_tf`.

### Phase 2: Diff Analysis
Step 2.1 Record: One file changed:
`drivers/net/wireless/marvell/libertas/if_usb.c`, 3 insertions and 2
deletions. Modified function: `process_cmdrequest()`. Scope: single-file
surgical fix.

Step 2.2 Record: Before, `process_cmdrequest()` rejected only
`recvlength > LBS_CMD_BUFFER_SIZE`; lengths `1..3` passed and produced
`recvlength - MESSAGE_HEADER_LEN`. After, it rejects `recvlength <
MESSAGE_HEADER_LEN` as well as overlarge responses. This affects the USB
command-response receive path.

Step 2.3 Record: Bug category is memory safety, specifically integer
underflow leading to oversized `memcpy()`. Verified details:
`MESSAGE_HEADER_LEN` is 4, `resp_len` is `u32`, `resp_buf` is `u8
resp_buf[2][LBS_UPLD_SIZE]`, and `LBS_UPLD_SIZE` is 2312. A negative
subtraction assigned to `u32` becomes a huge length, far beyond the
destination buffer.

Step 2.4 Record: Fix quality is high: minimal bounds check, no API
change, no new behavior except rejecting malformed command responses.
Regression risk is very low; valid command responses must already
include the 4-byte command type/header.

### Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows the upper-bound check came from
`ddac452680a516` in the v2.6.25-rc1 era, and the `resp_len = recvlength
- MESSAGE_HEADER_LEN` plus `memcpy()` flow came from `7919b89c8276` in
the v2.6.26-rc1 era. This code is old and widely present.

Step 3.2 Record: No `Fixes:` tag is present in the candidate, so there
is no specific tagged introducing commit to follow. Blame nevertheless
identifies the relevant old code.

Step 3.3 Record: Recent file history includes unrelated cleanup/fix
commits such as `3968e81ba644` changing skb free placement and
`d66676e6ca96` fixing a warning in `usb_tx_block()`. I found no
prerequisite commit needed for this bounds check.

Step 3.4 Record: `git log --author='Amir Mohammad Jahangirzad'` found no
prior local commits in this Marvell wireless subtree. The final signoff
is from Johannes Berg; `MAINTAINERS` lists Johannes Berg as wireless
maintainer, while the Libertas driver itself is marked orphaned under
`linux-wireless` and `libertas-dev`.

Step 3.5 Record: Dependencies found: none. The patch uses existing local
constants and mirrors the already-existing `libertas_tf` check.

### Phase 4: Mailing List And External Research
Step 4.1 Record: No commit hash was available in local history, so `b4
dig -c` could not be used successfully; `b4 dig -c
20260418004247.368944-1-a.jahangirzad@gmail.com` failed because it
expects a commit. Fallback `b4 mbox` and the lore mirror found the
original patch at `https://yhbt.net/lore/lkml/20260418004247.368944-1-
a.jahangirzad@gmail.com/T/`. The thread has one message and no replies.
`b4 mbox -c` found no newer revision in the thread.

Step 4.2 Record: Original recipients included Johannes Berg, Kees Cook,
Ingo Molnar, Johan Hovold, `linux-wireless`, `libertas-dev`, and `linux-
kernel`. No reviewer replies, NAKs, or explicit stable nominations were
present in the fetched thread.

Step 4.3 Record: No `Reported-by` or bug-report link was present. I
found no separate public bug report for this exact issue. The message
itself provides the failure mechanism.

Step 4.4 Record: Related precedent exists: commit `3348ef6a6a126` fixed
the identical underflow in `libertas_tf: process_cmdrequest()`, with
message “If recvlength is less than MESSAGE_HEADER_LEN (4) we would end
up corrupting memory.” That analogous fix was later carried in stable
review postings for 4.19 and 3.16.

Step 4.5 Record: Web searches found the exact candidate posting and
stable history for the analogous `libertas_tf` fix, but no exact stable
discussion for this new `libertas` patch.

### Phase 5: Code Semantic Analysis
Step 5.1 Record: Modified function: `process_cmdrequest()`.

Step 5.2 Record: Caller is `if_usb_receive()`, reached as the receive
URB completion callback installed by `usb_fill_bulk_urb()` through
`if_usb_submit_rx_urb()`.

Step 5.3 Record: Key callees are `memcpy()`, `dev_kfree_skb_irq()`, and
`lbs_notify_command_response()`. The command response is later consumed
by the main thread through `lbs_process_command_response()`.

Step 5.4 Record: Reachability is verified through USB receive
completion: a Libertas USB device response with type `CMD_TYPE_REQUEST`
reaches `process_cmdrequest()`. The triggering input is device-
controlled USB receive data, so this is reachable with affected hardware
or a malicious/faulty USB device.

Step 5.5 Record: Similar pattern found in `libertas_tf`; that sibling
driver already has the exact lower-bound check. `if_sdio` and `if_spi`
use different response formats and do not subtract `MESSAGE_HEADER_LEN`
in the same way.

### Phase 6: Cross-Referencing And Stable Tree Analysis
Step 6.1 Record: Representative tags `v3.16`, `v4.14`, `v4.19`, `v5.4`,
`v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`, and newer `v6.13` through
`v6.17` all contain the buggy `process_cmdrequest()` pattern without the
lower-bound check. The bug dates back to at least the v2.6.26-rc1 era.

Step 6.2 Record: Expected backport difficulty is low for modern stable
trees: the same context is present in representative stable tags, and
`git apply --check` succeeds against the current tree. Very old trees
before the Marvell directory move may need path/context adjustment, as
verified by older tags using `drivers/net/wireless/libertas/if_usb.c`.

Step 6.3 Record: No exact related fix for `libertas` was found in local
history. The sibling `libertas_tf` fix exists and was stable-backported.

### Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: Subsystem is wireless driver code under
`drivers/net/wireless/marvell/libertas`. Criticality: driver-specific,
but memory corruption in a kernel USB receive path is high severity for
affected systems.

Step 7.2 Record: Subsystem activity is low-to-moderate; recent history
shows occasional fixes and cleanups. `MAINTAINERS` marks Marvell
Libertas as orphaned, with `linux-wireless` and `libertas-dev` lists.

### Phase 8: Impact And Risk Assessment
Step 8.1 Record: Affected population is config- and hardware-specific:
systems with `CONFIG_LIBERTAS_USB` and Marvell Libertas 8388 USB
devices, or systems exposed to a malicious USB device matching the
driver IDs.

Step 8.2 Record: Trigger condition is a USB command response shorter
than `MESSAGE_HEADER_LEN` but with `CMD_TYPE_REQUEST` dispatch. This is
device-controlled. I did not verify an unprivileged software-only
trigger; physical or device-level control is the verified trigger model.

Step 8.3 Record: Failure mode is heap/driver memory corruption from
oversized `memcpy()`. Severity: HIGH to CRITICAL, because kernel memory
corruption can crash the system and can have security implications.

Step 8.4 Record: Benefit is high for affected systems: prevents kernel
memory corruption from malformed USB responses. Risk is very low: 3-line
effective validation change in one driver function, with precedent in
sibling driver.

### Phase 9: Final Synthesis
Step 9.1 Record: Evidence for backporting: real memory corruption bug;
old code present across many stable release tags; tiny surgical fix; no
new API or feature; exact validation already used by `libertas_tf`;
analogous `libertas_tf` fix was stable-backported. Evidence against:
driver-specific and no external bug report or tested-by tag. Unresolved:
exact final upstream commit hash was not present in local history, so
`b4 dig -c <commit_hash>` could not be completed.

Step 9.2 Record:
1. Obviously correct and tested? Obviously correct by code inspection;
   no explicit `Tested-by`.
2. Fixes a real bug? Yes, verified underflow into oversized `memcpy()`.
3. Important issue? Yes, kernel memory corruption.
4. Small and contained? Yes, one function in one file.
5. No new features/APIs? Yes.
6. Can apply to stable trees? Yes for modern representative tags with
   likely clean/minor context; old pre-directory-move trees may need
   path adjustment.

Step 9.3 Record: No exception category such as device ID, quirk, DT,
build, or docs applies. This is a direct memory-safety bug fix.

Step 9.4 Record: Stable backport decision is YES. The fix prevents
kernel memory corruption in an old, stable-present USB driver path with
extremely low regression risk.

## Verification
- Phase 1: Parsed supplied tags and fetched original patch thread with
  `b4 mbox`; confirmed no `Fixes`, `Reported-by`, `Tested-by`,
  `Reviewed-by`, `Acked-by`, or stable tag.
- Phase 2: Read `drivers/net/wireless/marvell/libertas/if_usb.c`,
  `dev.h`, and `defs.h`; confirmed `MESSAGE_HEADER_LEN`, `resp_len`,
  `resp_buf`, and `memcpy()` behavior.
- Phase 3: Ran `git blame` on `process_cmdrequest()`; identified old
  introducing history around `ddac452680a516` and `7919b89c8276`.
- Phase 3: Ran `git describe --contains`; confirmed relevant code dates
  to v2.6.25/v2.6.26-era history.
- Phase 4: `b4 dig` with the message-id failed because no local commit
  hash was available; recorded as unresolved.
- Phase 4: `b4 mbox` fetched the patch thread; `b4 mbox -c` found one
  message and no newer revision.
- Phase 4: Fetched lore mirror and stable archive pages; confirmed
  analogous `libertas_tf` fix and stable review postings.
- Phase 5: Traced callers from `if_usb_receive()` through
  `usb_fill_bulk_urb()` and `if_usb_submit_rx_urb()`.
- Phase 6: Checked release tags from `v3.16` through representative
  active v6 tags; confirmed the buggy code exists broadly.
- Phase 6: Ran `git apply --check` against the current tree; patch
  applies cleanly there.
- Phase 7: Checked `MAINTAINERS`; confirmed Libertas is orphaned under
  wireless lists and Johannes Berg is listed for wireless maintenance.
- Phase 8: Verified trigger is USB device-controlled receive data; no
  unprivileged software-only trigger was verified.

**YES**

 drivers/net/wireless/marvell/libertas/if_usb.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/marvell/libertas/if_usb.c b/drivers/net/wireless/marvell/libertas/if_usb.c
index 8a6bf1365cfab..42d3fd32ece28 100644
--- a/drivers/net/wireless/marvell/libertas/if_usb.c
+++ b/drivers/net/wireless/marvell/libertas/if_usb.c
@@ -625,9 +625,10 @@ static inline void process_cmdrequest(int recvlength, uint8_t *recvbuff,
 	unsigned long flags;
 	u8 i;
 
-	if (recvlength > LBS_CMD_BUFFER_SIZE) {
+	if (recvlength < MESSAGE_HEADER_LEN ||
+	    recvlength > LBS_CMD_BUFFER_SIZE) {
 		lbs_deb_usbd(&cardp->udev->dev,
-			     "The receive buffer is too large\n");
+			     "The receive buffer is invalid: %d\n", recvlength);
 		kfree_skb(skb);
 		return;
 	}
-- 
2.53.0

[PATCH AUTOSEL 7.0] io_uring/wait: honour caller's time namespace for IORING_ENTER_ABS_TIMER

[Sasha Levin]

From: Maoyi Xie <maoyixie.tju@gmail.com>

[ Upstream commit 45d2b37a37ab98484693533496395c610a2cab96 ]

io_uring_enter() with IORING_ENTER_ABS_TIMER takes an absolute
timespec from the caller via ext_arg->ts. It arms an ABS mode
hrtimer in __io_cqring_wait_schedule(). The conversion path in
io_uring/wait.c parses ext_arg->ts inline rather than going
through io_parse_user_time(). It therefore does not pick up the
time namespace conversion added by the previous patch.

Apply timens_ktime_to_host() to the parsed time on the
IORING_ENTER_ABS_TIMER branch. This mirrors the IORING_TIMEOUT_ABS
fix in io_parse_user_time(). Use ctx->clockid as the clock id.
ctx->clockid is set either at ring creation or via
IORING_REGISTER_CLOCK.

timens_ktime_to_host() is a no-op for clocks not affected by time
namespaces. It is also a no-op for callers in the initial time
namespace. The fast path is unchanged.

Reproducer: in unshare --user --time, with a -10s monotonic
offset, call io_uring_enter with min_complete=1,
IORING_ENTER_ABS_TIMER, and ts = now + 1s. The call returns
-ETIME after <1ms instead of after the expected ~1s.

Suggested-by: Pavel Begunkov <asml.silence@gmail.com>
Suggested-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>
Link: https://patch.msgid.link/20260504153755.1293932-3-maoyi.xie@ntu.edu.sg
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

### Phase 1: Commit Message Forensics
Record: Subsystem `io_uring/wait`; action verb `honour`; intent is to
make `IORING_ENTER_ABS_TIMER` interpret caller absolute times in the
caller’s time namespace.

Record: Tags present:
`Suggested-by: Pavel Begunkov`, `Suggested-by: Jens Axboe`, author
`Signed-off-by: Maoyi Xie`, `Link:
https://patch.msgid.link/20260504153755.1293932-3-maoyi.xie@ntu.edu.sg`,
maintainer `Signed-off-by: Jens Axboe`. No `Fixes:`, `Reported-by:`,
`Tested-by:`, `Reviewed-by`, `Acked-by`, or `Cc: stable`.

Record: The commit describes a real userspace-visible bug:
`io_uring_enter()` with `IORING_ENTER_ABS_TIMER` parses `ext_arg->ts`
directly, then arms an absolute hrtimer without converting from the
caller’s time namespace to host time. The supplied reproducer in
`unshare --user --time` with a `-10s` monotonic offset returns `-ETIME`
in under 1 ms instead of about 1 second.

Record: This is not hidden cleanup. It is a direct correctness fix for
absolute timeout interpretation in time namespaces.

### Phase 2: Diff Analysis
Record: One file changed, `io_uring/wait.c`, 5 insertions and 1
deletion. Function modified: `io_cqring_wait()`. Scope: single-file
surgical fix.

Record: Before, `ext_arg->ts` was converted with
`timespec64_to_ktime()`. If `IORING_ENTER_ABS_TIMER` was unset, the code
added `start_time`; if set, it used the raw caller value as a host
absolute deadline. After, the absolute branch calls
`timens_ktime_to_host(ctx->clockid, iowq.timeout)`, while the relative
branch remains unchanged.

Record: Bug category is logic/correctness in time namespace handling.
The broken mechanism is that a namespaced absolute
`CLOCK_MONOTONIC`/`CLOCK_BOOTTIME` timestamp was fed to a host hrtimer
as if it were already in host time.

Record: Fix quality is strong: minimal, local, uses existing kernel
helper, and no new API. Regression risk is very low because
`timens_ktime_to_host()` is verified as a no-op for the initial time
namespace, for unsupported clocks, and when `CONFIG_TIME_NS` is
disabled.

### Phase 3: Git History Investigation
Record: `git blame` on the changed wait lines points to `0105b0562a5e`
(`io_uring: split out CQ waiting code into wait.c`) for the current file
location. The same logic predates the split; `2b8e976b9842` (`io_uring:
user registered clockid for wait timeouts`) shows this absolute-wait
path using `ctx->clockid` and is contained by `v6.12-rc1`.

Record: No `Fixes:` tag is present, so there was no tagged introducing
commit to follow. I inspected the companion parent commit instead:
`9cc6bac1bebf` fixes the same time-namespace issue for
`IORING_TIMEOUT_ABS`.

Record: Recent related history shows this is patch 2/2 after
`9cc6bac1bebf`. The candidate’s parent is exactly `9cc6bac1bebf`, but
this wait fix compiles independently as long as `timens_ktime_to_host()`
and `ctx->clockid` exist.

Record: Author history in `io_uring` before this commit only showed the
companion timeout fix. Jens Axboe applied the patch, and Pavel/Jens were
suggested-by/review participants.

Record: Dependencies: affected stable trees need `ctx->clockid` and
`timens_ktime_to_host()`. I verified both exist in local `for-
greg/6.12-100`; the same `IORING_ENTER_ABS_TIMER` buggy line exists in
`6.12`, `6.18`, `6.19`, and `7.0` local stable branches, but not in
`5.10`, `5.15`, `6.1`, or `6.6`.

### Phase 4: Mailing List And External Research
Record: `b4 dig -c 45d2b37a37ab...` found the original submission at `ht
tps://patch.msgid.link/20260504153755.1293932-3-maoyi.xie@ntu.edu.sg`.

Record: `b4 dig -a` found only v1 of the series. The thread shows Jens
applied both patches with commit IDs `9cc6bac1bebf` and `45d2b37a37ab`.

Record: `b4 dig -w` shows the right people/lists were included: Maoyi
Xie, Jens Axboe, Pavel Begunkov, `io-uring@vger.kernel.org`, and `linux-
kernel@vger.kernel.org`.

Record: Reviewer feedback was positive: Pavel wrote “both look good” and
requested a liburing test; Jens replied “+1” for the test and later
applied the series. No NAKs or objections found.

Record: No separate bug-report link exists beyond the patch
thread/reproducer. Stable-specific WebFetch was blocked by Anubis, and
local thread search found no stable nomination.

### Phase 5: Code Semantic Analysis
Record: Modified function: `io_cqring_wait()`.

Record: Callers: `io_uring_enter(2)` reaches `io_cqring_wait()` when
`IORING_ENTER_GETEVENTS` is set, after `io_get_ext_arg()` copies/parses
the userspace getevents argument. This is directly syscall-reachable.

Record: Key callees: `timespec64_to_ktime()`, `timens_ktime_to_host()`,
`ktime_add()`, `io_get_time()`, `io_cqring_schedule_timeout()`, and
hrtimer setup/start helpers.

Record: Call chain: userspace `io_uring_enter()` -> `io_get_ext_arg()`
-> `io_cqring_wait()` -> `io_cqring_wait_schedule()` ->
`__io_cqring_wait_schedule()` -> `io_cqring_schedule_timeout()` ->
absolute hrtimer. The buggy path is reachable from userspace with
`IORING_ENTER_GETEVENTS | IORING_ENTER_EXT_ARG |
IORING_ENTER_ABS_TIMER`.

Record: Similar patterns: the companion commit fixes
`io_parse_user_time()` for `IORING_TIMEOUT_ABS`; POSIX timers,
`clock_nanosleep`, alarm timers, and `timerfd` already use
`timens_ktime_to_host()` for absolute timers.

### Phase 6: Stable Tree Analysis
Record: Local stable-branch grep found the buggy
`IORING_ENTER_ABS_TIMER` code in `for-greg/6.12-100`, `for-
greg/6.18-100`, `for-greg/6.19-200`, and `for-greg/7.0-100`. It was
absent from `5.10`, `5.15`, `6.1`, and `6.6`.

Record: Backport difficulty: current `7.0.y` apply check succeeds
cleanly. `6.12`/`7.0` have `io_uring/wait.c`; `6.18`/`6.19` local
branches have the same logic in `io_uring/io_uring.c`, so those need a
path/context backport but not semantic rework.

Record: No related fix with this subject was found in the checked stable
candidate branches.

### Phase 7: Subsystem Context
Record: Subsystem is `io_uring`, a core async I/O syscall subsystem.
Criticality: IMPORTANT, not universal core MM/VFS, but directly
userspace-facing and widely used.

Record: Subsystem activity is high; recent `io_uring` history has many
fixes and feature changes. This specific change is small despite the
active subsystem.

### Phase 8: Impact And Risk
Record: Affected population: users of `io_uring_enter()` absolute CQ
wait timeouts inside non-initial time namespaces, especially container-
like environments. Branch-limited to stable trees that contain
`IORING_ENTER_ABS_TIMER`.

Record: Trigger: userspace can trigger via `io_uring_enter()` with
`IORING_ENTER_ABS_TIMER` and a timespec from a shifted time namespace.
The provided reproducer uses `unshare --user --time`; whether fully
unprivileged depends on system user-namespace policy.

Record: Failure mode: incorrect timeout behavior. With the reproduced
negative offset, the wait returns `-ETIME` immediately; with other
offsets, absolute waits can be delayed incorrectly. Severity: MEDIUM to
HIGH user-visible correctness bug, potential application timeout/hang
behavior, but not a kernel crash, memory corruption, or security fix.

Record: Benefit is moderate/high for affected containerized users
because it restores syscall semantics. Risk is very low: one local
conditional change plus an include, using established helper semantics.

### Phase 9: Final Synthesis
Record: Evidence for backporting: real reproduced bug, syscall-
reachable, affects stable branches with the feature, tiny patch,
maintainer-applied, positive reviewer feedback, matches established
time-namespace behavior elsewhere.

Record: Evidence against backporting: not a crash/security/data-
corruption fix; affects a narrower feature combination; no explicit
stable nomination; older stable trees do not contain the affected
feature.

Record: Unresolved: I did not run the reproducer locally. Lore WebFetch
was blocked by Anubis, but `b4` successfully fetched the thread. Exact
first upstream introduction of `IORING_ENTER_ABS_TIMER` was not cleanly
reconstructed from local blame alone, but affected stable branches were
directly verified by grep.

Stable rules:
1. Obviously correct and tested: yes by code inspection, reproducer, and
   positive review; no formal `Tested-by`.
2. Fixes a real bug: yes, reproduced wrong timeout result.
3. Important issue: yes for affected users, because absolute waits can
   return immediately or at the wrong time.
4. Small and contained: yes, 6-line single-function change.
5. No new features/APIs: yes.
6. Can apply to stable: yes for current `7.0.y`; minor path adjustment
   may be needed in some branches.

No automatic exception category applies.

## Verification
- [Phase 1] Parsed `git show` commit message and tags for
  `45d2b37a37ab98484693533496395c610a2cab96`.
- [Phase 2] Verified diff is one file, `io_uring/wait.c`, 5 insertions/1
  deletion in `io_cqring_wait()`.
- [Phase 3] Ran `git blame` on the changed lines; current file location
  comes from `0105b0562a5e`.
- [Phase 3] Inspected `2b8e976b9842`; verified `ctx->clockid`,
  `io_get_time(ctx)`, and selected-clock wait timeout support.
- [Phase 3] Inspected companion commit `9cc6bac1bebf`; verified same
  class of fix for `IORING_TIMEOUT_ABS`.
- [Phase 4] Ran `b4 dig`, `b4 dig -a`, `b4 dig -w`, and `b4 mbox`;
  verified v1-only series, correct recipients, positive feedback, and
  applied notice.
- [Phase 5] Read `io_uring_enter()` and `io_get_ext_arg()` call path;
  verified direct syscall reachability.
- [Phase 5] Verified `timens_ktime_to_host()` behavior in
  `include/linux/time_namespace.h` and `kernel/time/namespace.c`.
- [Phase 5] Verified similar established conversions in `kernel/time`
  and `fs/timerfd.c`.
- [Phase 6] Ran `git grep` on local stable branches; affected: `6.12`,
  `6.18`, `6.19`, `7.0`; unaffected: `5.10`, `5.15`, `6.1`, `6.6`.
- [Phase 6] Ran `git apply --check` for the candidate patch on current
  `7.0.y`; it applies cleanly.
- [Phase 8] Verified reproducer details from commit and mailing-list
  cover letter; did not execute it locally.

This should be backported to stable trees that contain
`IORING_ENTER_ABS_TIMER`, with the companion timeout patch strongly
recommended for complete io_uring absolute-timeout time-namespace
correctness.

**YES**

 io_uring/wait.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/io_uring/wait.c b/io_uring/wait.c
index 91df86ce0d18c..ec01e78a216d6 100644
--- a/io_uring/wait.c
+++ b/io_uring/wait.c
@@ -5,6 +5,7 @@
 #include <linux/kernel.h>
 #include <linux/sched/signal.h>
 #include <linux/io_uring.h>
+#include <linux/time_namespace.h>
 
 #include <trace/events/io_uring.h>
 
@@ -229,7 +230,10 @@ int io_cqring_wait(struct io_ring_ctx *ctx, int min_events, u32 flags,
 
 	if (ext_arg->ts_set) {
 		iowq.timeout = timespec64_to_ktime(ext_arg->ts);
-		if (!(flags & IORING_ENTER_ABS_TIMER))
+		if (flags & IORING_ENTER_ABS_TIMER)
+			iowq.timeout = timens_ktime_to_host(ctx->clockid,
+							    iowq.timeout);
+		else
 			iowq.timeout = ktime_add(iowq.timeout, start_time);
 	}
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] wifi: nl80211: require CAP_NET_ADMIN over the target netns in SET_WIPHY_NETNS

[Sasha Levin]

From: Maoyi Xie <maoyi.xie@ntu.edu.sg>

[ Upstream commit 15994bb0cbb8fc4879da7552ddd08c1896261c39 ]

NL80211_CMD_SET_WIPHY_NETNS dispatches with GENL_UNS_ADMIN_PERM, which
verifies that the caller has CAP_NET_ADMIN for the source netns. It
doesn't verify that the caller has CAP_NET_ADMIN over the target netns
selected by NL80211_ATTR_NETNS_FD or NL80211_ATTR_PID.

This diverges from the convention enforced in
net/core/rtnetlink.c::rtnl_get_net_ns_capable():

    /* For now, the caller is required to have CAP_NET_ADMIN in
     * the user namespace owning the target net ns.
     */
    if (!sk_ns_capable(sk, net->user_ns, CAP_NET_ADMIN))
        return ERR_PTR(-EACCES);

A user with CAP_NET_ADMIN in their own user namespace can therefore
push a wiphy into an arbitrary netns (including init_net) over which
they have no privilege.

Mirror the rtnetlink convention by requiring CAP_NET_ADMIN in the
target netns before calling cfg80211_switch_netns().

Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>
Link: https://patch.msgid.link/20260506064854.2207105-2-maoyixie.tju@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

### Phase 1: Commit Message Forensics
Record: `wifi: nl80211` subsystem; action verb `require`; intent is to
require `CAP_NET_ADMIN` over the target network namespace before
`NL80211_CMD_SET_WIPHY_NETNS` moves a wiphy.

Record: Tags in the provided commit message:
`Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>`, `Link: https://patch.
msgid.link/20260506064854.2207105-2-maoyixie.tju@gmail.com`, `Signed-
off-by: Johannes Berg <johannes.berg@intel.com>`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, `Reviewed-by:`, or `Cc: stable` tag was
present in the provided message.

Record: The described bug is an authorization gap. `GENL_UNS_ADMIN_PERM`
verifies `CAP_NET_ADMIN` for the netlink socket/source netns, but
`NL80211_ATTR_NETNS_FD` / `NL80211_ATTR_PID` selects a target netns that
was not separately checked. The b4-fetched cover letter includes a
concrete reproducer with `mac80211_hwsim`: a caller privileged only in
its own user namespace can move a delegated wiphy back into `init_net`.

Record: This is not a hidden cleanup fix; it is an explicit
security/permission bug fix.

### Phase 2: Diff Analysis
Record: One file changed, `net/wireless/nl80211.c`, with 13 insertions
in `nl80211_wiphy_netns()`. Scope is a single-function surgical fix.

Record: Before: after resolving the target netns and checking
`IS_ERR(net)`, the function directly called `cfg80211_switch_netns()` if
the wiphy was not already in that netns. After: it first checks
`ns_capable(net->user_ns, CAP_NET_ADMIN)`, drops the netns reference
with `put_net(net)`, and returns `-EPERM` on failure.

Record: Bug category is security authorization / logic correctness. The
missing check allowed a source-netns-capable caller to affect a
different target netns without privilege there.

Record: Fix quality is high: small, localized, follows the verified
rtnetlink convention in `rtnl_get_net_ns_capable()`, and preserves
reference cleanup. Regression risk is low and limited to denying
previously accepted unauthorized cross-netns moves.

### Phase 3: Git History Investigation
Record: `git blame` on the current stable checkout blamed the function
body to a repository snapshot-style commit, so it was not useful for
introduction history. `git log v2.6.29..v2.6.32 -S...` found the
command/function introduced by `463d018323851` (`cfg80211: make aware of
net namespaces`), first contained in `v2.6.32-rc1`.

Record: No `Fixes:` tag is present, so there was no tagged commit to
follow.

Record: Recent local `net/wireless/nl80211.c` history showed unrelated
wireless fixes/conversions and no existing equivalent target-netns
capability fix.

Record: No local prior `Maoyi Xie` commits were found under
`net/wireless`. `MAINTAINERS` verifies Johannes Berg as maintainer for
`802.11 (including CFG80211/NL80211)`, and the patch was addressed to
Johannes on linux-wireless.

Record: No code dependency was found for this patch. It is patch 1/2 in
the submitted series; patch 2 is related namespace hardening, but patch
1 is standalone for the direct permission bypass.

### Phase 4: Mailing List And External Research
Record: No commit hash was provided and the exact subject was not found
in local `master`, `wireless-next`, `net-next`, or `fixes-next`, so `b4
dig -c <commit>` was not applicable. I used the provided message-id with
`b4 am`/`b4 mbox`.

Record: `b4 am` found `[PATCH v3 0/2] wifi: nl80211: tighten netns
handling in SET_WIPHY_NETNS and dump continuation`, including this patch
as `v3 1/2`. `b4 am -c` did not report a newer revision. Attempts to
fetch v1/v2 directly with `b4 -v 1/-v 2` did not find those revisions,
but the v3 cover records that patch 1 was unchanged since v1.

Record: The full mbox contained three messages: cover, patch 1, patch 2.
It did not contain reviewer reply messages, but the cover records
Johannes review feedback about trailers/comment wording and says no code
changes since v2.

Record: Original recipients were Johannes Berg, `linux-
wireless@vger.kernel.org`, and `linux-kernel@vger.kernel.org`. No stable
nomination or NAK was found in the fetched mbox. Lore WebFetch searches
were blocked by Anubis, so stable-list discussion could not be
independently verified through WebFetch.

### Phase 5: Code Semantic Analysis
Record: Modified function: `nl80211_wiphy_netns()`.

Record: Caller surface: the only direct reference is the generic-netlink
op for `NL80211_CMD_SET_WIPHY_NETNS`; `genl_family_rcv_msg()` checks
`GENL_UNS_ADMIN_PERM` against `net->user_ns`, then
`genl_family_rcv_msg_doit()` calls `ops->doit()`, reaching
`nl80211_wiphy_netns()` from userspace netlink.

Record: Key callees: `get_net_ns_by_pid()`, `get_net_ns_by_fd()`, new
`ns_capable(net->user_ns, CAP_NET_ADMIN)`, `cfg80211_switch_netns()`,
and `put_net()`. `cfg80211_switch_netns()` moves associated wireless
netdevs with `dev_change_net_namespace()` and updates `wiphy_net_set()`.

Record: Reachability is verified by the op table and by the b4 cover’s
PoC. A userspace caller can trigger the path by sending
`NL80211_CMD_SET_WIPHY_NETNS` with target PID or netns fd.

Record: Similar convention verified in `rtnl_get_net_ns_capable()`,
which checks target `net->user_ns` before using another netns.

### Phase 6: Stable Tree Analysis
Record: The vulnerable handler/op shape exists in `v5.4`, `v5.10`,
`v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.19`, and current `7.0.y`, with no
`ns_capable(net->user_ns, CAP_NET_ADMIN)` check in the handler.

Record: `v3.18` has `NL80211_CMD_SET_WIPHY_NETNS`, but uses
`GENL_ADMIN_PERM`, so the unprivileged-user-namespace aspect is not the
same there. For active modern stable trees, the issue is present.

Record: `git apply --check` of the fetched v3 mbox succeeds on the
current `7.0.y` checkout. Older stable trees have line offsets and minor
surrounding differences, but the same local hunk context exists at least
in `v5.4`; expected backport difficulty is clean or minor-context-only.

Record: No related local fix already present was found by subject/grep
searches.

### Phase 7: Subsystem Context
Record: Subsystem is cfg80211/nl80211 wireless configuration.
Criticality is IMPORTANT: it is not core-mm/VFS, but it is a userspace-
facing network configuration and permission boundary.

Record: The wireless subsystem is active in local history, with recent
cfg80211/nl80211-adjacent fixes.

### Phase 8: Impact And Risk
Record: Affected users are systems with cfg80211/nl80211, network
namespaces/user namespaces, and a `WIPHY_FLAG_NETNS_OK` wiphy. Verified
examples include `mac80211` and drivers setting the flag such as
`brcmfmac`, `mwifiex`, and `qtnfmac`.

Record: Trigger requires the caller to hold a movable wiphy in its own
netns and pass a target netns fd or pid. The b4 cover verifies this is
reachable from an unprivileged user namespace after legitimate admin
delegation using `mac80211_hwsim`.

Record: Failure mode is a security/namespace isolation violation:
unauthorized movement of a wiphy into a netns, including `init_net`,
where the caller lacks privilege. Severity is HIGH because it bypasses
kernel namespace permission boundaries.

Record: Benefit is high for stable users because it closes a concrete
privilege boundary bug. Risk is low: 13 lines, one function, no new API,
no data structure change, and only unauthorized operations change
behavior.

### Phase 9: Final Synthesis
Record: Evidence for backporting: real security/authorization bug,
concrete PoC in the submitted cover, reachable userspace netlink
command, vulnerable code present across modern stable trees, small
contained fix, and it mirrors an existing rtnetlink convention.

Record: Evidence against backporting: no `Fixes:`/stable tag, no fetched
reviewer reply carrying an explicit stable nomination, and the exact
applied commit hash was not present in local searched branches. These do
not outweigh the verified technical issue.

Record: Unresolved: I could not verify the final applied commit object
or run `b4 dig -c` because no commit hash was provided and local branch
searches did not find the subject. WebFetch to lore/stable was blocked
by Anubis. I did not run the runtime PoC or a kernel build.

Stable rules checklist:
1. Obviously correct and tested: yes by inspection; PoC result described
   in b4 cover, though not locally rerun.
2. Fixes a real bug affecting users: yes, verified missing target-netns
   authorization.
3. Important issue: yes, security/namespace permission bypass.
4. Small and contained: yes, one function, 13 added lines.
5. No new features or APIs: yes.
6. Can apply to stable: yes for current `7.0.y`; older active stable
   trees likely clean/minor context based on matching code.

Exception category: none. This is not a device ID/quirk/build/doc fix;
it is a security permission fix.

## Verification
- [Phase 1] Parsed provided subject/tags and b4-fetched patch/cover;
  found no `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, or
  stable tag.
- [Phase 2] Compared provided diff and b4 mbox patch; confirmed 13 lines
  added to `nl80211_wiphy_netns()`.
- [Phase 3] `git blame -L` was not useful due snapshot-style history;
  `git log v2.6.29..v2.6.32 -S...` found `463d018323851`, first
  contained in `v2.6.32-rc1`.
- [Phase 3] `git log --author='Maoyi Xie' -- net/wireless` found no
  local prior commits.
- [Phase 3] `MAINTAINERS` confirms Johannes Berg maintains `802.11
  (including CFG80211/NL80211)`.
- [Phase 4] `b4 am` found v3 2-patch series and the supplied patch
  message-id.
- [Phase 4] `b4 am -c` found no newer revision.
- [Phase 4] `b4 mbox` saved the full 3-message thread; no stable
  nomination or NAK was present there.
- [Phase 5] `rg` confirmed `nl80211_wiphy_netns()` is reached via the
  `NL80211_CMD_SET_WIPHY_NETNS` generic-netlink op.
- [Phase 5] Read `genetlink.c`; confirmed `GENL_UNS_ADMIN_PERM` checks
  `net->user_ns` before calling `ops->doit()`.
- [Phase 5] Read `cfg80211_switch_netns()`; confirmed it moves wireless
  netdevs and changes the wiphy netns.
- [Phase 6] Checked `v5.4`, `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`,
  `v6.19`, and current `7.0.y`; all have the handler/op without the
  target `ns_capable()` check.
- [Phase 6] `git apply --check` of the b4 mbox succeeded on current
  `7.0.y`.
- [Phase 8] `rg WIPHY_FLAG_NETNS_OK` verified affected mac80211 and
  several wireless drivers expose movable wiphys.
- UNVERIFIED: exact final commit SHA and final applied-object metadata,
  because the subject was not found in local searched branches.
- UNVERIFIED: stable-list discussion via WebFetch, because lore WebFetch
  returned Anubis anti-bot pages.
- UNVERIFIED: local runtime PoC/build; not performed.

This should be backported to stable kernel trees that contain the
`GENL_UNS_ADMIN_PERM` version of `NL80211_CMD_SET_WIPHY_NETNS`,
especially active v5.4+ stable/LTS trees.

**YES**

 net/wireless/nl80211.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ce3121b1c3319..13c2943ad3e4b 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -13568,6 +13568,19 @@ static int nl80211_wiphy_netns(struct sk_buff *skb, struct genl_info *info)
 	if (IS_ERR(net))
 		return PTR_ERR(net);
 
+	/*
+	 * The caller already has CAP_NET_ADMIN over the source netns
+	 * (enforced by GENL_UNS_ADMIN_PERM on the genl op). Mirror the
+	 * convention used by net/core/rtnetlink.c::rtnl_get_net_ns_capable()
+	 * and require CAP_NET_ADMIN over the target netns as well, so that
+	 * a caller that is privileged in their own user namespace cannot
+	 * push a wiphy into a netns where they have no privilege.
+	 */
+	if (!ns_capable(net->user_ns, CAP_NET_ADMIN)) {
+		put_net(net);
+		return -EPERM;
+	}
+
 	err = 0;
 
 	/* check if anything to do */
-- 
2.53.0

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

[Sasha Levin]

From: Arnd Bergmann <arnd@arndb.de>

[ Upstream commit 23c39cb598977f10909a2387c5e5f34afc1d6933 ]

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: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

### Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem is `media: qcom: camss`; action verb is
`avoid`; claimed intent is to avoid a clang-22 format-string build
warning/error in `csiphy_match_clock_name()`.

Step 1.2 Record: Verified fetched commit
`2211e826bd69c041534093735241182013dde7bc` has:
- `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>`

The original lore submission also has `Fixes: 0727615fb975 ("media:
qcom: camss: Functionally decompose CSIPHY clock lookups")`. No
`Reported-by`, `Tested-by`, `Cc: stable`, or bug-report `Link` was
verified.

Step 1.3 Record: The body describes a clang-22 diagnostic promoted to
error: `[-Werror,-Wmissing-format-attribute]`. The root cause is that
`csiphy_match_clock_name()` takes a `const char *format` and passes it
to `snprintf()` with a fixed `int index`, but the helper itself lacks a
checkable printf-style prototype.

Step 1.4 Record: This is not a hidden runtime bug fix. It is a build-
warning/build-error fix for newer clang plus warning-as-error
configurations.

### Phase 2: Diff Analysis
Step 2.1 Record: One file changed:
`drivers/media/platform/qcom/camss/camss-csiphy.c`, `7 insertions(+), 3
deletions(-)`. One function modified: `csiphy_match_clock_name()`. Scope
is single-file surgical.

Step 2.2 Record: Before, the helper accepted `format, int index` and
called `snprintf(name, sizeof(name), format, index)`. After, it is
declared `__printf(2, 3)`, accepts varargs, uses `va_start()`,
`vsnprintf()`, and `va_end()`. Call sites remain unchanged.

Step 2.3 Record: Bug category is build fix / compiler diagnostic fix. It
does not fix memory safety, locking, refcounting, or runtime logic.

Step 2.4 Record: The fix is mechanically correct and minimal. Existing
callers pass literal format strings plus `csiphy->id`, so behavior is
preserved while allowing compiler format checking. Regression risk is
very low; the only meaningful risk is varargs misuse, but current call
sites were verified unchanged and simple.

### Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows the helper body was introduced by
`0727615fb975f6`, authored by Bryan O'Donoghue on 2023-09-25. `git
describe --contains` places it at `v6.7-rc1~51^2~149`.

Step 3.2 Record: The final fetched commit lacks a `Fixes:` trailer, but
the original lore submission includes `Fixes: 0727615fb975`. I inspected
that commit; it introduced the helper and the `snprintf(..., format,
index)` pattern.

Step 3.3 Record: Recent file history includes later CAMSS/CSIPHY
changes, especially `74cae7794341` changing callers to use `csiphy->id`.
No prerequisite for this format-warning fix was found beyond the helper
existing.

Step 3.4 Record: Arnd Bergmann has prior CAMSS build/undefined-behavior
fixes in history. Bryan O'Donoghue, who reviewed the patch, is listed as
a CAMSS maintainer in `MAINTAINERS`.

Step 3.5 Record: No dependent commits were found. The patch only needs
the existing helper and kernel `__printf`/`va_list` support, both
present in the checked tree.

### Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c 2211e826...` found the original patch at
`https://patch.msgid.link/20260320151828.3456863-1-arnd@kernel.org`. `b4
dig -a` found only v1.

Step 4.2 Record: `b4 dig -w` shows relevant maintainers/lists were
included: CAMSS maintainers, media maintainers, `linux-media`, `linux-
arm-msm`, `linux-kernel`, and `llvm`.

Step 4.3 Record: No separate bug report was present. The concrete report
is the compiler diagnostic embedded in the patch.

Step 4.4 Record: This is a standalone one-patch fix, not part of a
multi-patch series.

Step 4.5 Record: Direct lore stable search was blocked by Anubis; web
search did not find stable-specific discussion for this exact patch.

### Phase 5: Code Semantic Analysis
Step 5.1 Record: Modified function: `csiphy_match_clock_name()`.

Step 5.2 Record: Callers are only within `msm_csiphy_subdev_init()`, at
the three verified clock-name checks: `"csiphy%d_timer"`, `"csi%d_phy"`,
and `"csiphy%d"`.

Step 5.3 Record: The helper calls formatting and string comparison
functions: previously `snprintf()` and `strcmp()`, after patch
`vsnprintf()` and `strcmp()`.

Step 5.4 Record: The affected path is CAMSS device probe:
`camss_probe()` calls `camss_init_subdevices()`, which calls
`msm_csiphy_subdev_init()`. Runtime behavior remains equivalent for the
verified call sites.

Step 5.5 Record: Nearby CAMSS code has no other `const char *format`
helper or `vsnprintf()`/`__printf()` pattern matching this issue.

### Phase 6: Stable Tree Analysis
Step 6.1 Record: The buggy helper exists from `v6.7` onward. Verified
absent in `v6.6`, present in `v6.12`, and present in `v7.0`.

Step 6.2 Record: `git apply --check` succeeds against the current
`7.0.5` checkout. For `v6.12`, the same helper and `snprintf(name,
sizeof(name), format, index)` pattern are present, but I did not run a
separate worktree apply check.

Step 6.3 Record: No related stable-specific fix for this exact CAMSS
warning was found in local targeted searches or public web search.

### Phase 7: Subsystem Context
Step 7.1 Record: Subsystem is Qualcomm CAMSS media driver under
`drivers/media/platform/qcom/camss/`. Criticality is peripheral/driver-
specific, but build failures affect anyone building this driver or
COMPILE_TEST coverage.

Step 7.2 Record: CAMSS is actively developed; recent history shows many
CAMSS commits, including fixes and new platform support.

### Phase 8: Impact And Risk
Step 8.1 Record: Affected population is config-specific: builders with
`CONFIG_VIDEO_QCOM_CAMSS`, including `COMPILE_TEST`, using clang-22 with
`-Wmissing-format-attribute` and warnings-as-errors.

Step 8.2 Record: Trigger is build-time, not runtime.
`scripts/Makefile.warn` verifies `-Wmissing-format-attribute` is under
`W=1`; `-Werror` is enabled by `W=e` or `CONFIG_WERROR`.

Step 8.3 Record: Failure mode is build failure, not
crash/corruption/security. Severity is medium, but build fixes are an
accepted stable exception.

Step 8.4 Record: Benefit is moderate: keeps affected stable builds
working with newer clang warning behavior. Risk is very low: 10-line
single-function mechanical change, no API change, call sites unchanged.

### Phase 9: Final Synthesis
Evidence for backporting:
- Real build failure mode documented in commit and lore.
- Fits stable build-fix exception.
- Very small, contained, reviewed by CAMSS maintainer.
- Applies cleanly to current `7.0.5`; buggy code exists in `v6.12+` and
  `v7.0`.

Evidence against backporting:
- Not a runtime correctness, crash, data corruption, or security fix.
- Trigger requires specific compiler/warning-as-error build settings.
- Not relevant to `v6.6` and older because the helper is absent there.

Stable rules checklist:
1. Obviously correct and tested: yes for code review/readability; no
   local clang-22 build reproduction.
2. Fixes a real bug: yes, a verified build diagnostic/error path.
3. Important issue: medium; build failure, not runtime failure.
4. Small and contained: yes, one function, one file, 7+/3-.
5. No new feature/API: yes.
6. Can apply to stable: verified for current `7.0.5`; likely
   straightforward for `v6.12+`, not applicable to `v6.6` and older.

Exception category: Build fix.

## Verification
- Phase 1: `git show` verified candidate commit metadata and exact diff
  for `2211e826bd69...`.
- Phase 2: `git diff --shortstat` verified `1 file changed, 7
  insertions(+), 3 deletions(-)`.
- Phase 3: `git blame` verified helper introduced by `0727615fb975`;
  `git show` inspected that commit.
- Phase 3/6: `git describe --contains` and tag containment checks
  verified introduction in `v6.7`, presence in `v6.12+`, absence from
  `v6.6`.
- Phase 4: `b4 dig`, `b4 dig -a`, `b4 dig -w`, and saved mbox verified
  original lore thread, v1-only series, recipients, `Fixes:` trailer,
  and Bryan’s review.
- Phase 5: `rg` and file reads verified call sites and probe call chain.
- Phase 6: `git apply --check` verified clean apply to current `7.0.5`.
- Phase 7: `MAINTAINERS` verified Bryan O'Donoghue is a CAMSS
  maintainer.
- Phase 8: `scripts/Makefile.warn` verified when `-Wmissing-format-
  attribute` and `-Werror` are enabled.
- UNVERIFIED: I did not reproduce the clang-22 build failure locally.
- UNVERIFIED: I did not perform an actual `git apply --check` in a
  separate `v6.12` worktree.

This is stable-worthy as a low-risk build fix for stable trees that
contain the helper, especially `v6.12+`/`v7.0` era trees, and should be
skipped for older trees where the code does not exist.

**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 62623393f4144..78a1b568dbae6 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 7.0-5.10] scsi: scsi_dh_alua: Increase default ALUA timeout to maximum spec value

[Sasha Levin]

From: Brian Bunker <brian@purestorage.com>

[ Upstream commit 68c3a65a5a8e85643745fdde02cb63904e165620 ]

The ALUA handler maps a 0 value (no implicit transition timeout provided
by the target) to the ALUA_FAILOVER_TIMEOUT constant, currently 60
seconds. This means the kernel already does not accept an infinite
transition time.

However, 60 seconds is insufficient for some arrays that may take longer
to complete ALUA transitions. Since the highest value allowed by the
SCSI specification for the implicit transition timeout is a single byte
(255 seconds), change the default to 255. This way, when a target does
not provide an explicit transition timeout, we default to the maximum
value the spec allows rather than an arbitrary 60 second limit.

Co-developed-by: Krishna Kant <krishna.kant@purestorage.com>
Signed-off-by: Krishna Kant <krishna.kant@purestorage.com>
Co-developed-by: Riya Savla <rsavla@purestorage.com>
Signed-off-by: Riya Savla <rsavla@purestorage.com>
Signed-off-by: Brian Bunker <brian@purestorage.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Link: https://patch.msgid.link/20260416165512.26497-2-brian@purestorage.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis Walkthrough

Phase 1 Record: Subsystem is `scsi: scsi_dh_alua`; action is “increase”;
intent is to raise the default ALUA implicit transition timeout from 60s
to 255s. Tags verified from commit
`68c3a65a5a8e85643745fdde02cb63904e165620`: co-developed/SOB by Krishna
Kant and Riya Savla, SOB by Brian Bunker, `Reviewed-by: Hannes
Reinecke`, `Link:` to the v4 posting, SOB by Martin K. Petersen. No
`Fixes:`, `Reported-by:`, `Tested-by:`, or `Cc: stable`. Body describes
a real behavior problem: targets that omit an explicit ALUA transition
timeout get capped at 60s, which is too short for some arrays.

Phase 2 Record: One file changed,
`drivers/scsi/device_handler/scsi_dh_alua.c`, 1 insertion/1 deletion. No
function body is modified; only `ALUA_FAILOVER_TIMEOUT` changes. The
macro is used by `submit_rtpg()`, `submit_stpg()`, `alua_tur()`, and
`alua_rtpg()` for command and transition expiry timing. Before: missing
target timeout defaults to 60s. After: defaults to 255s. Bug category is
logic/correctness for storage failover timing. Fix quality is very small
and obvious; main regression risk is slower failure detection for arrays
that omit timeout and remain stuck.

Phase 3 Record: `git blame` shows the 60s default came from
`3588c5a21aef8c` (`[SCSI] scsi_dh_alua: implement 'implied transition
timeout'`), first contained in `v3.6`. That original commit added the
implicit transition timeout machinery and made 60s the finite fallback.
Recent local history shows ALUA-related fixes but no prerequisite for
this one. Author Brian Bunker previously authored ALUA transition-state
fix `6056a92ceb2a7`, so this is from a contributor with direct ALUA
history. No standalone dependency was found.

Phase 4 Record: `b4 dig -c 68c3a65a5a8e8` found the v4 lore submission
at
`https://patch.msgid.link/20260416165512.26497-2-brian@purestorage.com`.
`b4 dig -a` found v3 and v4; v4 is the applied revision. `b4 dig -w`
shows Brian Bunker, `linux-scsi`, Hannes Reinecke, Krishna Kant, and
Riya Savla were included. The v4 thread has Hannes’s `Reviewed-by` and
Martin Petersen’s “Applied to 7.1/scsi-staging”. Earlier v2 discussion
verified Hannes objected to tying ALUA transition timeout to device
command timeout, and the patch evolved into the simpler 255s default. I
found no stable-list discussion.

Phase 5 Record: Modified function list is empty, but impacted code paths
are the ALUA RTPG/STPG/TUR and transition expiry paths. Call tracing
verified `alua_rtpg_work()` calls `alua_tur()` and `alua_rtpg()`,
`alua_activate()` queues RTPG from dm-multipath activation,
`alua_check_sense()` is invoked from SCSI error handling, and
`alua_prep_fn()` is called from SCSI request setup. This is reachable
from SCSI disk/device-handler attach, error handling, and dm-multipath
path activation. Similar pattern search found the same 60s fallback in
active stable tags.

Phase 6 Record: The buggy 60s default exists in `v4.14`, `v4.19`,
`v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.16`, `v6.17`, and `v7.0`
tags in this repo. The exact macro line is present, so backport
difficulty should be clean or trivial for those trees. `b4 am` also
reported the v4 patch “applies clean to current tree.” No alternate
stable fix was found.

Phase 7 Record: Subsystem is SCSI device handler / ALUA multipath
storage. Criticality is IMPORTANT: it affects systems using ALUA-capable
SCSI storage, especially enterprise multipath arrays. MAINTAINERS
verifies SCSI is maintained by James Bottomley and Martin Petersen, and
the patch was committed by Martin Petersen.

Phase 8 Record: Affected users are config/hardware-specific: ALUA SCSI
disk users, commonly multipath enterprise storage. Trigger is an ALUA
transition where the target omits an explicit transition timeout and
takes more than 60s. Failure mode is premature transition expiry,
leading `alua_rtpg()` to mark the port group standby and return I/O/path
failure. Severity is HIGH for affected systems because it can break
failover or storage availability. Benefit is high for affected storage
users; risk is low because this is a one-line bounded timeout increase
and 255s matches the implementation’s `unsigned char`/`buff[5]` timeout
representation.

Phase 9 Record: Evidence for backporting: real storage failover
correctness issue, long-lived bug since v3.6, affects many stable trees,
one-line bounded fix, reviewed by Hannes Reinecke, committed by SCSI
maintainer Martin Petersen, no new API or feature. Evidence against: no
formal `Reported-by` or `Tested-by`; behavior may wait longer before
declaring a nonresponsive target failed. Stable checklist: obviously
correct yes; real bug yes; important issue yes for storage
availability/path failure; small and contained yes; no new APIs yes;
applies to stable trees yes/trivial. Exception category: none, this is
not a device ID/quirk/build/doc fix.

## Verification

- Phase 1: `git show 68c3a65a5a8e8` verified commit message, tags,
  author, committer, and one-line diff.
- Phase 2: `git show` and source read verified only
  `ALUA_FAILOVER_TIMEOUT` changes from `60` to `255`.
- Phase 3: `git blame` verified the 60s default came from
  `3588c5a21aef8c`; `git describe --contains` verified `v3.6` ancestry.
- Phase 4: `b4 dig`, `b4 dig -a`, `b4 dig -w`, and saved mboxes verified
  v3/v4 review history, Hannes review, and Martin’s apply note. Direct
  WebFetch of lore was blocked/timed out; b4 succeeded.
- Phase 5: `git grep` and file reads verified ALUA call paths through
  SCSI request setup, SCSI error handling, and dm-multipath activation.
- Phase 6: `git grep` against stable tags verified the 60s default
  exists across listed stable releases.
- Phase 7: `MAINTAINERS` search verified SCSI maintainer/list context.
- Phase 8: Source inspection verified the failure path: timeout expiry
  in `alua_rtpg()` changes transitioning state handling to standby/I/O
  error.
- Unverified: I did not independently fetch the SCSI SPC text; the “255
  maximum spec value” claim is supported by the reviewed commit text and
  by the kernel implementation storing the timeout as a single byte.

This should be backported: it fixes a real ALUA multipath storage
availability problem with a tiny, bounded, maintainer-reviewed change
and minimal regression risk.

**YES**

 drivers/scsi/device_handler/scsi_dh_alua.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c b/drivers/scsi/device_handler/scsi_dh_alua.c
index efb08b9b145a1..80ab0ff921d43 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -37,7 +37,7 @@
 #define TPGS_MODE_EXPLICIT		0x2
 
 #define ALUA_RTPG_SIZE			128
-#define ALUA_FAILOVER_TIMEOUT		60
+#define ALUA_FAILOVER_TIMEOUT		255	/* max 255 (8-bit value) */
 #define ALUA_FAILOVER_RETRIES		5
 #define ALUA_RTPG_DELAY_MSECS		5
 #define ALUA_RTPG_RETRY_DELAY		2
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] Bluetooth: hci_uart: Fix NULL deref in recv callbacks when priv is uninitialized

[Sasha Levin]

From: Aurelien DESBRIERES <aurelien@hackers.camp>

[ Upstream commit 902fe40bce7059722f7ffa1c378e577675cf1918 ]

When a fault is injected during hci_uart line discipline setup, the
proto open() callback may fail leaving hu->priv as NULL. A subsequent
TIOCSTI ioctl can trigger the recv() callback before priv is
initialized, causing a NULL pointer dereference.

Fix all four affected HCI UART protocol drivers by adding a NULL check
on hu->priv at the start of their recv() callbacks: h4, h5, ath and
bcsp.

Reported-by: syzbot+ff30eeab8e07b37d524e@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=ff30eeab8e07b37d524e
Signed-off-by: Aurelien DESBRIERES <aurelien@hackers.camp>
Assisted-by: Claude:claude-sonnet-4-6
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
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 `Bluetooth: hci_uart`; action verb `Fix`;
intent is to prevent NULL dereference in HCI UART protocol `recv()`
callbacks when `hu->priv` is not initialized.

Step 1.2 Record: Tags found: `Reported-by:
syzbot+ff30eeab8e07b37d524e@syzkaller.appspotmail.com`; `Closes:
https://syzkaller.appspot.com/bug?extid=ff30eeab8e07b37d524e`; `Signed-
off-by: Aurelien DESBRIERES`; `Assisted-by: Claude:claude-sonnet-4-6`;
`Signed-off-by: Luiz Augusto von Dentz`. No `Fixes:` tag. Notable
pattern: syzbot report with reproducer and KASAN NULL-deref crash.

Step 1.3 Record: The commit describes a `hu->priv == NULL` path during
HCI UART setup followed by received data via `TIOCSTI`, causing a NULL
pointer dereference. The syzkaller report verifies a KASAN NULL-
deref/general protection fault in `h4_recv`, with call chain `tty_ioctl
-> tiocsti -> hci_uart_tty_receive -> h4_recv`.

Step 1.4 Record: This is not hidden cleanup; it is an explicit memory-
safety crash fix. The added checks prevent dereferencing protocol-
private state when setup/error handling leaves it absent.

## Phase 2: Diff Analysis
Step 2.1 Record: Four files changed, all in `drivers/bluetooth`:
`hci_ath.c` `+3/-0`, `hci_bcsp.c` `+3/-0`, `hci_h4.c` `+3/-0`,
`hci_h5.c` `+3/-0`; total `12` insertions. Modified functions:
`ath_recv`, `bcsp_recv`, `h4_recv`, `h5_recv`. Scope: small multi-file
surgical driver fix.

Step 2.2 Record: Each hunk previously assigned `hu->priv` to a protocol-
private pointer and then dereferenced it. After the patch, each callback
returns `-ENODEV` if that pointer is NULL. The affected path is receive
handling through the HCI UART line discipline, including data injected
by `TIOCSTI`.

Step 2.3 Record: Bug category is NULL pointer dereference / memory
safety. Specific mechanism: `hci_uart_tty_receive()` calls
`hu->proto->recv()`, and these callbacks dereference `hu->priv`; if
setup/error handling leaves `hu->priv` NULL, the callback crashes. The
fix adds direct NULL guards before first dereference.

Step 2.4 Record: Fix quality is high: simple, local, obviously correct,
no API/data structure changes. Regression risk is very low; it only
changes an invalid crash path to `-ENODEV`.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` on the vulnerable lines showed the current
callback bodies come from long-standing Bluetooth UART code, with recent
edits such as `b489556a856d` for `h4_recv_buf()` usage and
`ca94b2b036c2` adding the BCSP registered guard. The vulnerable pattern
exists in `v6.19.14` and `v7.0.5`.

Step 3.2 Record: No `Fixes:` tag, so no tagged introducing commit to
follow.

Step 3.3 Record: Related recent commits include `0ffac654e95c` / stable
backport `981b4fd2baf3` removing the `HCI_UART_REGISTERED` guard from
`h4_recv`, and `0c3cd7a0b862` fixing a related HCI UART NULL deref in
write work. Another related upstream commit, `68d39ea5e0ad`, clears
`HCI_UART_PROTO_INIT` on register error but is present in `v7.1-rc*`,
not in checked `v6.19.14`/`v7.0.5`.

Step 3.4 Record: No prior Bluetooth commits by Aurelien DESBRIERES were
found in this checkout. The patch was committed/applied by Bluetooth
maintainer Luiz Augusto von Dentz.

Step 3.5 Record: No functional prerequisite is required for this patch
in affected trees; it applies cleanly to current `v7.0.5`. It is most
relevant to trees with the `HCI_UART_PROTO_INIT` receive path and the
recent H4 initialization-race changes, such as checked `v6.19.y` and
`v7.0.y`.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c 902fe40bce70` found the original thread:
`https://patch.msgid.link/20260421135331.15425-1-aurelien@hackers.camp`.
`b4 dig -a` found only v1; the committed patch matches the submitted
revision.

Step 4.2 Record: `b4 dig -w` showed recipients included `linux-
bluetooth`, Marcel Holtmann, Johan Hedberg, Luiz Dentz, `linux-kernel`,
and syzbot. The patchwork bot reported it was applied to
`bluetooth/bluetooth-next.git` by Luiz Augusto von Dentz.

Step 4.3 Record: Syzkaller bug page verifies: “general protection fault
in h4_recv”, KASAN NULL-ptr-deref, C and syz reproducers, and fix commit
`902fe40bce70`.

Step 4.4 Record: No multi-patch series was found; only v1 of this one-
patch submission.

Step 4.5 Record: Direct lore stable fetch was blocked by Anubis; web
search found no stable-specific discussion. This does not affect the
decision because the syzbot crash and code path are verified elsewhere.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: Modified functions: `ath_recv`, `bcsp_recv`, `h4_recv`,
`h5_recv`.

Step 5.2 Record: Exact call path verified: protocol structs assign
`.recv = h4_recv/ath_recv/bcsp_recv/h5_recv`; `hci_uart_tty_receive()`
calls `hu->proto->recv(hu, data, count)`; `tiocsti()` calls the line
discipline `receive_buf`.

Step 5.3 Record: Key callees include `h4_recv_buf()`,
`hci_recv_frame()`, `h5_reset_rx()`, `bcsp_unslip_one_byte()`, and skb
cleanup helpers. The first unsafe operation in each changed function was
a dereference of the private pointer.

Step 5.4 Record: Reachability is verified from userspace ioctl in the
syzkaller trace and reproducer: `openat("/dev/ptmx")`, `TIOCSETD` to
`N_HCI`, `HCIUARTSETPROTO` with fault injection, then `TIOCSTI`.

Step 5.5 Record: Similar HCI UART receive callbacks exist; some, like
`qca_recv` and `ll_recv`, still have `HCI_UART_REGISTERED` guards before
dereferencing private data. The candidate focuses on the four callbacks
identified in the accepted patch.

## Phase 6: Stable Tree Analysis
Step 6.1 Record: Checked `v6.19.14` and `v7.0.5`: the four callbacks
exist without the new NULL checks. These trees also have
`hci_uart_tty_receive()` accepting `HCI_UART_PROTO_INIT`. Checked
`v6.6`/`v6.12`: older receive gating differs, so the exact trigger is
less clearly present there.

Step 6.2 Record: `git apply --check` of the candidate diff succeeds on
the current `v7.0.5` checkout. Expected backport difficulty for similar
affected trees is clean or trivial.

Step 6.3 Record: No equivalent recv-callback NULL guard was found in
`v6.19.14` or `v7.0.5`. A related central cleanup exists upstream as
`68d39ea5e0ad`, but not in those checked stable tags.

## Phase 7: Subsystem Context
Step 7.1 Record: Subsystem is Bluetooth HCI UART, a driver subsystem
under `drivers/bluetooth`. Criticality: important for systems using
UART-attached Bluetooth controllers; not universal core kernel code.

Step 7.2 Record: Bluetooth UART code is actively changing in this range,
with recent initialization-race and NULL-deref fixes in the same area.

## Phase 8: Impact And Risk
Step 8.1 Record: Affected users are systems with `N_HCI` / HCI UART
Bluetooth line discipline enabled, especially with H4/H5/ATH/BCSP
protocol paths.

Step 8.2 Record: Trigger verified by syzkaller requires HCI UART line
discipline setup, fault/error during protocol setup, then received data
through `TIOCSTI`. The reproducer uses fault injection and ioctl access;
unprivileged exploitability was not established.

Step 8.3 Record: Failure mode is kernel oops/general protection fault
from KASAN NULL dereference in `h4_recv`; severity HIGH to CRITICAL
because it crashes the kernel.

Step 8.4 Record: Benefit is high for affected stable trees because it
prevents a reproducible kernel crash. Risk is very low: 12 added lines,
no new feature, no locking changes, no API changes.

## Phase 9: Final Synthesis
Step 9.1 Record: Evidence for backporting: syzbot report with
reproducer, KASAN NULL deref, syscall-triggered path, small surgical
patch, accepted by Bluetooth maintainer, applies cleanly to checked
stable tree. Evidence against: trigger appears tied to setup
failure/fault injection and may not affect older stable trees with
different HCI UART initialization flow. Unresolved: exact applicability
to every older LTS branch was not fully verified.

Step 9.2 Record: Stable rules checklist: obviously correct: yes; fixes
real bug: yes, syzbot crash; important issue: yes, kernel oops; small
and contained: yes, 12 insertions in four driver callbacks; no new
features/APIs: yes; applies to stable: yes for checked `v7.0.5`, likely
trivial for affected `v6.19.y`.

Step 9.3 Record: No exception category needed; this is a direct crash
fix, not a device ID/quirk/build/doc patch.

Step 9.4 Record: Decision is to backport to affected stable trees,
especially those containing the `HCI_UART_PROTO_INIT` receive path and
recent HCI UART initialization fixes. The benefit/risk ratio is strongly
favorable.

## Verification
- Phase 1: Parsed commit `902fe40bce7059722f7ffa1c378e577675cf1918` with
  `git show`; verified syzbot and Closes tags.
- Phase 2: Verified diff stat: four files, 12 insertions, only NULL
  guards in recv callbacks.
- Phase 3: Ran `git blame` on changed callback lines and inspected
  related commits `0ffac654e95c`, `981b4fd2baf3`, `0c3cd7a0b862`, and
  `68d39ea5e0ad`.
- Phase 4: Ran `b4 dig -c`, `-a`, and `-w`; fetched mirror thread and
  syzkaller bug/reproducer.
- Phase 5: Verified call path with source reads and exact searches:
  `tiocsti()` -> line discipline `receive_buf` ->
  `hci_uart_tty_receive()` -> protocol `.recv`.
- Phase 6: Checked `v6.19.14`, `v7.0.5`, `v6.12`, and `v6.6` snippets;
  verified patch applies to current `v7.0.5` with `git apply --check`.
- Phase 8: Verified failure mode from syzkaller crash log: KASAN NULL-
  ptr-deref/general protection fault in `h4_recv`.
- UNVERIFIED: Exact applicability to every active older stable/LTS
  branch; older branches with different HCI UART gating may not need
  this patch.

**YES**

 drivers/bluetooth/hci_ath.c  | 3 +++
 drivers/bluetooth/hci_bcsp.c | 3 +++
 drivers/bluetooth/hci_h4.c   | 3 +++
 drivers/bluetooth/hci_h5.c   | 3 +++
 4 files changed, 12 insertions(+)

diff --git a/drivers/bluetooth/hci_ath.c b/drivers/bluetooth/hci_ath.c
index fa679ad0acdfa..8201fa7f61e84 100644
--- a/drivers/bluetooth/hci_ath.c
+++ b/drivers/bluetooth/hci_ath.c
@@ -191,6 +191,9 @@ static int ath_recv(struct hci_uart *hu, const void *data, int count)
 {
 	struct ath_struct *ath = hu->priv;
 
+	if (!ath)
+		return -ENODEV;
+
 	ath->rx_skb = h4_recv_buf(hu, ath->rx_skb, data, count,
 				  ath_recv_pkts, ARRAY_SIZE(ath_recv_pkts));
 	if (IS_ERR(ath->rx_skb)) {
diff --git a/drivers/bluetooth/hci_bcsp.c b/drivers/bluetooth/hci_bcsp.c
index b386f91d8b46d..db56eead27ceb 100644
--- a/drivers/bluetooth/hci_bcsp.c
+++ b/drivers/bluetooth/hci_bcsp.c
@@ -585,6 +585,9 @@ static int bcsp_recv(struct hci_uart *hu, const void *data, int count)
 	if (!test_bit(HCI_UART_REGISTERED, &hu->flags))
 		return -EUNATCH;
 
+	if (!bcsp)
+		return -ENODEV;
+
 	BT_DBG("hu %p count %d rx_state %d rx_count %ld",
 	       hu, count, bcsp->rx_state, bcsp->rx_count);
 
diff --git a/drivers/bluetooth/hci_h4.c b/drivers/bluetooth/hci_h4.c
index a889a66a326f7..7673727074985 100644
--- a/drivers/bluetooth/hci_h4.c
+++ b/drivers/bluetooth/hci_h4.c
@@ -109,6 +109,9 @@ static int h4_recv(struct hci_uart *hu, const void *data, int count)
 {
 	struct h4_struct *h4 = hu->priv;
 
+	if (!h4)
+		return -ENODEV;
+
 	h4->rx_skb = h4_recv_buf(hu, h4->rx_skb, data, count,
 				 h4_recv_pkts, ARRAY_SIZE(h4_recv_pkts));
 	if (IS_ERR(h4->rx_skb)) {
diff --git a/drivers/bluetooth/hci_h5.c b/drivers/bluetooth/hci_h5.c
index cfdf75dc28475..d353837182125 100644
--- a/drivers/bluetooth/hci_h5.c
+++ b/drivers/bluetooth/hci_h5.c
@@ -587,6 +587,9 @@ static int h5_recv(struct hci_uart *hu, const void *data, int count)
 	struct h5 *h5 = hu->priv;
 	const unsigned char *ptr = data;
 
+	if (!h5)
+		return -ENODEV;
+
 	BT_DBG("%s pending %zu count %d", hu->hdev->name, h5->rx_pending,
 	       count);
 
-- 
2.53.0

[PATCH AUTOSEL 7.0] ALSA: hda/realtek: Add mute LED fixup for HP Pavilion 15-cs1xxx

[Sasha Levin]

From: Rodrigo Faria <rodrigofilipefaria@gmail.com>

[ Upstream commit 01801e20d69346e1e6cec0d908f1cea3a49e51b5 ]

Add a new fixup for the mute LED on the HP Pavilion 15-cs1xxx series
using the VREF on NID 0x1b.

The BIOS on these models (tested up to F.32) incorrectly reports
the mute LED on NID 0x18 via DMI OEM strings, which lacks VREF
capabilities. This fixup overrides the LED pin to the correct
NID 0x1b.

Signed-off-by: Rodrigo Faria <rodrigofilipefaria@gmail.com>
Link: https://patch.msgid.link/20260505185518.23625-1-rodrigofilipefaria@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Decision Summary
This should be backported. It is a small, model-specific ALSA HDA
Realtek hardware workaround for an HP Pavilion 15-cs1xxx BIOS quirk: the
BIOS reports the mute LED on NID `0x18`, but that pin lacks VREF
capability; the patch routes the existing HP VREF mute-LED handling to
NID `0x1b`. It affects only systems matching PCI SSID `103c:856a`.

## Phase Walkthrough
### Phase 1: Commit Message Forensics
Record: Subsystem is `ALSA: hda/realtek`; action is `Add`; intent is
adding a mute LED fixup for HP Pavilion 15-cs1xxx.

Record: Tags present: `Signed-off-by: Rodrigo Faria
<rodrigofilipefaria@gmail.com>`, `Link: https://patch.msgid.link/2026050
5185518.23625-1-rodrigofilipefaria@gmail.com`, `Signed-off-by: Takashi
Iwai <tiwai@suse.de>`. No `Fixes:`, `Reported-by:`, `Tested-by:`,
`Reviewed-by`, or `Cc: stable`.

Record: Bug described is incorrect BIOS/DMI OEM mute LED pin reporting.
Symptom is mute LED control using the wrong NID, so the mute LED does
not work correctly on this model. Version info: BIOS tested up to F.32.
Root cause: reported NID `0x18` lacks VREF capability; correct NID is
`0x1b`.

Record: This is a hardware quirk/fixup, not a hidden memory-safety bug.
It fixes incorrect hardware description/firmware behavior.

### Phase 2: Diff Analysis
Record: One file changed: `sound/hda/codecs/realtek/alc269.c`, 21
insertions, no removals. Modified areas: new helper
`alc295_fixup_hp_pavilion_mute_led_1b`, enum entry, fixup table entry,
PCI SSID quirk entry. Scope: single-file, surgical driver quirk.

Record: Before: HP vendor/DMI mute LED handling could derive the wrong
LED NID from BIOS OEM string. After: for PCI SSID `103c:856a`, the
driver selects a dedicated fixup that calls existing
`alc269_fixup_hp_mute_led()` and then overrides `spec->mute_led_nid =
0x1b`.

Record: Bug category is hardware workaround / quirk. Specific mechanism:
reuse existing VREF mute LED cdev setup, but force the pin to the
verified VREF-capable NID.

Record: Fix quality is good: small, contained, uses existing Realtek HDA
LED infrastructure, only selected for one HP subsystem ID. Regression
risk is very low and limited to that model.

### Phase 3: Git History Investigation
Record: Local exact-subject `git log` found no commit hash in this
checkout, so `b4 dig -c <hash>` could not be run against the target
commit. The patch was analyzed by message-id instead.

Record: `git blame` on nearby current-tree lines shows this repository’s
Realtek split file was imported through a grafted/snapshot-style commit,
so blame was not useful for the original upstream introduction of the
generic HP LED code.

Record: Related local history contains similar model-specific HP
Pavilion mute LED quirk commits: `2f388b4e8fdd6`, `068641bc9dc3d`, and
`ab2be3af8c4ea`, each one-line Pavilion mute LED quirk additions.

Record: Author history for Rodrigo Faria in this file returned no local
commits. Maintainer handling was verified from the mailing-list thread:
Takashi Iwai replied “Applied now.”

Record: Dependencies: no hard functional dependency beyond existing
Realtek HDA HP mute LED infrastructure. That infrastructure exists in
checked stable tags, though older trees use
`sound/pci/hda/patch_realtek.c` and may need manual path/context
backporting.

### Phase 4: Mailing List And External Research
Record: `b4 am` by message-id found `[PATCH v3] ALSA: hda/realtek: Add
mute LED fixup for HP Pavilion 15-cs1xxx`, 1 patch, 2 messages in
thread, DKIM-signed.

Record: Full thread shows the patch was sent to Takashi Iwai, Jaroslav
Kysela, `linux-sound`, and `linux-kernel`; Takashi replied “Applied
now.” No NAKs, objections, or stable nomination were found in the
fetched thread.

Record: `b4 am -v 2` could not find revision 2 from this message-id; web
searches also did not locate earlier cs1xxx revisions. The subject says
v3, but earlier revision discussion remains unverified.

Record: External search found public evidence of HP Pavilion 15-cs-
series systems using ALC295 audio, but no separate cs1xxx-specific bug
report was found.

Record: Stable-list searches found no cs1xxx-specific stable discussion,
but did find similar ALSA Realtek HP Pavilion mute LED quirks appearing
in stable discussion/results.

### Phase 5: Code Semantic Analysis
Record: Modified/added key function:
`alc295_fixup_hp_pavilion_mute_led_1b`.

Record: Callers: the new function is referenced from `alc269_fixups[]`;
that fixup is selected by `snd_hda_pick_fixup()` during Realtek codec
probe, using the PCI SSID quirk table. This is device
probe/configuration path, not a syscall hot path.

Record: Callees: `alc269_fixup_hp_mute_led()` scans HP DMI OEM strings,
sets LED polarity/NID, registers the mute LED cdev through
`snd_hda_gen_add_mute_led_cdev()`, and installs `led_power_filter`. The
new helper then overrides `spec->mute_led_nid`.

Record: Reachability: affected path is reachable during HDA codec probe
on matching HP hardware and later through the LED audio mute
trigger/cdev callback.

Record: Similar patterns: many existing HP Realtek quirks use
`ALC269_FIXUP_HP_MUTE_LED_MIC3`, `ALC295_FIXUP_HP_MUTE_LED_COEFBIT11`,
and related model-specific entries.

### Phase 6: Stable Tree Analysis
Record: Checked tags `v6.19`, `v6.18`, `v6.17`, `v6.16`, `v6.12`, and
`v6.6` exist locally.

Record: `v6.19` and `v6.18` use `sound/hda/codecs/realtek/alc269.c`;
`v6.6` uses older `sound/pci/hda/patch_realtek.c`.

Record: Generic HP VREF mute LED infrastructure exists in `v6.6` and
newer checked tags. `ALC295_FIXUP_HP_MUTE_LED_COEFBIT11` exists in
`v6.16+`, but not in `v6.12`/`v6.6`; the new fixup itself does not
depend on that helper, only on nearby placement/context.

Record: `git apply --check` succeeds on current `7.0.5` checkout. It
fails on a temporary `v6.18` worktree due to context drift, so stable
backports likely need minor manual adjustment. Older stable trees need
path adjustment to `sound/pci/hda/patch_realtek.c`.

### Phase 7: Subsystem And Maintainer Context
Record: Subsystem is ALSA HDA Realtek codec driver under sound.
Criticality: peripheral/driver-specific, affecting HP Pavilion 15-cs1xxx
users.

Record: The file is actively maintained and frequently receives model-
specific quirks. Recent local history includes multiple ALSA Realtek
HP/Lenovo/ASUS/Samsung quirk commits.

### Phase 8: Impact And Risk
Record: Affected users are specific to HP Pavilion 15-cs1xxx / PCI SSID
`103c:856a` with Realtek ALC295-class HDA audio.

Record: Trigger condition is normal codec probe and mute LED operation
on that hardware. No evidence found that unprivileged users can trigger
a crash or security issue; the user-visible effect is
incorrect/nonfunctional mute LED.

Record: Failure severity is LOW to MEDIUM: not a crash or data
corruption issue, but a real hardware functionality regression/quirk.

Record: Benefit is medium for affected users because it restores correct
mute LED behavior. Risk is very low because the quirk is model-specific
and uses existing LED control paths.

### Phase 9: Final Synthesis
Record: Evidence for backporting: hardware quirk category, fixes real
BIOS misreporting, limited to one PCI SSID, small patch, uses
established ALSA Realtek fixup patterns, accepted by ALSA maintainer,
and similar HP mute LED quirks are common stable material.

Record: Evidence against backporting: no crash/security/data corruption;
no explicit stable tag; current patch does not apply cleanly to at least
`v6.18` without minor context adjustment; older trees need file-
path/context adjustment.

Record: Stable rules: obviously correct enough by inspection; fixes a
real hardware bug; small and contained; no new public API; no new
feature beyond hardware-specific workaround; stable application may
require minor backport edits.

Record: Exception category applies: hardware-specific quirk/workaround
in an existing driver.

## Verification
- [Phase 1] Parsed subject, body, and tags from supplied commit message
  and fetched mbox.
- [Phase 2] Verified patch is 21 insertions in
  `sound/hda/codecs/realtek/alc269.c`.
- [Phase 3] Ran local `git log` by exact subject: no matching commit
  hash found.
- [Phase 3] Ran `git blame` around affected code: local history is
  snapshot/grafted, limiting original-introduction analysis.
- [Phase 4] Ran `b4 am` by message-id: found v3 patch, 2-message thread,
  DKIM-signed.
- [Phase 4] Read full mbox: Takashi Iwai replied “Applied now”; no
  objections found.
- [Phase 5] Traced quirk selection through `snd_hda_pick_fixup()` and
  Realtek probe path.
- [Phase 6] Checked stable tags and paths: `v6.18+` split path, `v6.6`
  old `patch_realtek.c` path.
- [Phase 6] Checked relevant symbols in stable tags: HP VREF LED
  infrastructure exists in checked stable trees.
- [Phase 6] Ran `git apply --check`: applies to current checkout, not
  cleanly to `v6.18` due context drift.
- [Phase 8] Verified failure mode from commit body and code: wrong LED
  NID affects mute LED behavior, not memory safety.
- UNVERIFIED: exact applied upstream commit SHA, because it was not
  present in local `git log`.
- UNVERIFIED: earlier v1/v2 review discussion, because `b4` and web
  search did not locate those revisions.
- UNVERIFIED: exact applicability to every active older LTS tree beyond
  the checked tags.

**YES**

 sound/hda/codecs/realtek/alc269.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index 29dafa3f1d15a..9daf7a12bf95d 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -1676,6 +1676,21 @@ static void alc295_fixup_hp_mute_led_coefbit11(struct hda_codec *codec,
 	}
 }
 
+/* Override wrong pin to NID 0x1b (F.32 BIOS reports 0x18 via DMI OEM string)
+ * on HP pavilion 15-cs1xxx laptops
+ */
+static void alc295_fixup_hp_pavilion_mute_led_1b(struct hda_codec *codec,
+						 const struct hda_fixup *fix,
+						 int action)
+{
+	struct alc_spec *spec = codec->spec;
+
+	alc269_fixup_hp_mute_led(codec, fix, action);
+
+	if (action == HDA_FIXUP_ACT_PRE_PROBE)
+		spec->mute_led_nid = 0x1b;
+}
+
 static void alc233_fixup_lenovo_coef_micmute_led(struct hda_codec *codec,
 				const struct hda_fixup *fix, int action)
 {
@@ -3859,6 +3874,7 @@ enum {
 	ALC290_FIXUP_SUBWOOFER,
 	ALC290_FIXUP_SUBWOOFER_HSJACK,
 	ALC295_FIXUP_HP_MUTE_LED_COEFBIT11,
+	ALC295_FIXUP_HP_PAVILION_MUTE_LED_1B,
 	ALC269_FIXUP_THINKPAD_ACPI,
 	ALC269_FIXUP_LENOVO_XPAD_ACPI,
 	ALC269_FIXUP_DMIC_THINKPAD_ACPI,
@@ -5701,6 +5717,10 @@ static const struct hda_fixup alc269_fixups[] = {
 		.type = HDA_FIXUP_FUNC,
 		.v.func = alc295_fixup_hp_mute_led_coefbit11,
 	},
+	[ALC295_FIXUP_HP_PAVILION_MUTE_LED_1B] = {
+		.type = HDA_FIXUP_FUNC,
+		.v.func = alc295_fixup_hp_pavilion_mute_led_1b,
+	},
 	[ALC298_FIXUP_SAMSUNG_AMP] = {
 		.type = HDA_FIXUP_FUNC,
 		.v.func = alc298_fixup_samsung_amp,
@@ -6894,6 +6914,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x103c, 0x8537, "HP ProBook 440 G6", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
 	SND_PCI_QUIRK(0x103c, 0x8548, "HP EliteBook x360 830 G6", ALC285_FIXUP_HP_GPIO_LED),
 	SND_PCI_QUIRK(0x103c, 0x854a, "HP EliteBook 830 G6", ALC285_FIXUP_HP_GPIO_LED),
+	SND_PCI_QUIRK(0x103c, 0x856a, "HP Pavilion 15-cs1xxx", ALC295_FIXUP_HP_PAVILION_MUTE_LED_1B),
 	SND_PCI_QUIRK(0x103c, 0x85c6, "HP Pavilion x360 Convertible 14-dy1xxx", ALC295_FIXUP_HP_MUTE_LED_COEFBIT11),
 	SND_PCI_QUIRK(0x103c, 0x85de, "HP Envy x360 13-ar0xxx", ALC285_FIXUP_HP_ENVY_X360),
 	SND_PCI_QUIRK(0x103c, 0x8603, "HP Omen 17-cb0xxx", ALC285_FIXUP_HP_MUTE_LED),
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.15] ALSA: usb-audio: Add quirk flags for AlphaTheta EUPHONIA

[Sasha Levin]

From: Anton Swart <anton.swart.jhb@gmail.com>

[ Upstream commit f80785888f7c0980a49545b87a80e3817c9ed7c6 ]

The AlphaTheta EUPHONIA (VID 0x2b73, PID 0x0047) is a USB Audio
Class 2 DJ mixer that requires implicit feedback for full-duplex
operation. The capture endpoint (0x83 IN, interface 2) acts as the
implicit feedback source for the playback endpoint (0x03 OUT,
interface 1), and the device firmware does not send isochronous
data on the capture endpoint unless the host is simultaneously
sending data on the playback endpoint, i.e. playback must be
started first.

Without QUIRK_FLAG_PLAYBACK_FIRST the kernel waits for capture URBs
before submitting playback URBs, creating a deadlock: the device
waits for playback data and the host waits for capture data.
Without QUIRK_FLAG_GENERIC_IMPLICIT_FB the kernel does not detect
the implicit feedback relationship between the two interfaces.

The same flag combination is already used for the Behringer UMC202HD,
UMC204HD and UMC404HD (0x1397:0x0507/0x0508/0x0509), which exhibit
the identical implicit-feedback topology.

Tested on Raspberry Pi 5 with kernel 6.12.75; continuous full-duplex
streaming at 96 kHz / 24-bit, zero XRUNs.

Signed-off-by: Anton Swart <anton.swart.jhb@gmail.com>
Link: https://patch.msgid.link/20260503211517.14332-1-anton.swart.jhb@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

### Step 1.1: Subject
Record: Subsystem: `ALSA: usb-audio`. Action verb: `Add`. Claimed
intent: add device-specific quirk flags for AlphaTheta EUPHONIA.

### Step 1.2: Tags
Record:
- `Signed-off-by: Anton Swart <anton.swart.jhb@gmail.com>`: author
  signoff.
- `Link: https://patch.msgid.link/20260503211517.14332-1-
  anton.swart.jhb@gmail.com`: original patch submission.
- `Signed-off-by: Takashi Iwai <tiwai@suse.de>`: supplied commit message
  says ALSA maintainer applied/signed off.
- No `Fixes:` tag.
- No `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, or `Cc:
  stable@vger.kernel.org` tags.
- The patch body says it was tested on Raspberry Pi 5 with kernel
  `6.12.75`, but this is not a formal `Tested-by:` tag.

### Step 1.3: Commit Body
Record: The bug is a device-specific full-duplex startup deadlock for
AlphaTheta EUPHONIA USB Audio Class 2 mixer `VID:PID 0x2b73:0x0047`. The
capture endpoint is the implicit feedback source, but firmware does not
emit capture isochronous data until playback is already sending.
Symptom: full-duplex streaming cannot start because host waits for
capture feedback while device waits for playback data. Version info:
tested on `6.12.75`. Root cause: kernel does not both detect generic
implicit feedback and start playback first for this device.

### Step 1.4: Hidden Bug Fix
Record: Yes. Although phrased as “Add quirk flags”, this is a hardware
workaround fixing real device malfunction. It falls under the stable
hardware-quirk exception.

## Phase 2: Diff Analysis

### Step 2.1: Inventory
Record:
- File changed: `sound/usb/quirks.c`
- Scope: 2 lines added, 0 removed.
- Function/data object modified: `quirk_flags_table[]`.
- Classification: single-file, table-only, surgical hardware quirk.

### Step 2.2: Code Flow Change
Record:
- Before: device `0x2b73:0x0047` had no built-in quirk flag entry.
- After: matching USB audio devices get `QUIRK_FLAG_PLAYBACK_FIRST |
  QUIRK_FLAG_GENERIC_IMPLICIT_FB`.
- Affected path: USB audio device probe initializes `chip->quirk_flags`
  from `quirk_flags_table[]`; stream parsing and endpoint start then use
  those flags.
- Path type: initialization/probe plus later stream-start behavior.

### Step 2.3: Bug Mechanism
Record:
- Category: hardware workaround / USB audio implicit feedback startup
  ordering.
- `QUIRK_FLAG_GENERIC_IMPLICIT_FB` is verified in `sound/usb/implicit.c`
  to trigger `add_generic_implicit_fb()` when the generic implicit-
  feedback flag is set.
- `QUIRK_FLAG_PLAYBACK_FIRST` is verified in `sound/usb/endpoint.c` to
  skip the normal “do not submit playback URBs until feedback arrives”
  behavior for implicit-feedback sinks.
- Together they fix the described stream-start deadlock for this device.

### Step 2.4: Fix Quality
Record: The fix is obviously minimal and consistent with existing
entries. The same exact flag combination is already present for
Behringer UMC202HD/UMC204HD/UMC404HD in `sound/usb/quirks.c`. Regression
risk is very low because the new behavior is limited to exact USB ID
`0x2b73:0x0047`.

## Phase 3: Git History Investigation

### Step 3.1: Blame Changed Area
Record: `git blame` on the insertion area showed neighboring quirk
entries are longstanding table entries, including Fiero SC-01 entries
introduced by `668abe6dc7b619` (`ALSA: usb-audio: Sort quirk table
entries`). Local history is partly grafted, so I did not rely on graft-
boundary blame for introduction of the whole mechanism.

### Step 3.2: Fixes Tag
Record: Not applicable. There is no `Fixes:` tag.

### Step 3.3: File History
Record: Recent `sound/usb/quirks.c` history contains many similar
device-specific quirk additions/fixes. No prerequisite patch is
referenced by the commit message. This patch is standalone for trees
that already have `QUIRK_FLAG_GENERIC_IMPLICIT_FB` and
`QUIRK_FLAG_PLAYBACK_FIRST`.

### Step 3.4: Author History
Record: `git log --author='Anton Swart' -10 -- sound/usb` found no local
prior commits. `MAINTAINERS` verifies Takashi Iwai is a listed `SOUND`
maintainer, and the supplied commit message has his signoff.

### Step 3.5: Dependencies
Record: The patch depends on existing `QUIRK_FLAG_GENERIC_IMPLICIT_FB`
and `QUIRK_FLAG_PLAYBACK_FIRST` infrastructure. Verified present in
`v6.1`, `v6.6`, `v6.12`, and `v7.0.5`. Verified `v5.15` has
`PLAYBACK_FIRST` but not `GENERIC_IMPLICIT_FB`, so this exact patch is
not directly applicable to `5.15.y`.

## Phase 4: Mailing List And External Research

### Step 4.1: Original Discussion
Record: No upstream commit hash was available locally, so `b4 dig -c
<commit>` could not be used. I used the supplied message-id link with
`b4 am`. It found the patch at `https://lore.kernel.org/all/202605032115
17.14332-1-anton.swart.jhb@gmail.com/`, one patch, two messages in
thread, zero code-review messages analyzed, DKIM signed by Gmail.
`WebFetch` to lore was blocked by Anubis.

### Step 4.2: Reviewers / Recipients
Record: `b4 am --cc-trailers` showed recipients: `alsa-devel@alsa-
project.org`, Jaroslav Kysela, Takashi Iwai, and `linux-
kernel@vger.kernel.org`. These are appropriate ALSA/kernel recipients.
No reviewer trailers were found in the b4-processed thread.

### Step 4.3: Bug Report
Record: No separate bug report or `Reported-by:` tag found. The patch
itself gives a concrete device topology, failure mode, and test result.
Web search found AlphaTheta product/support pages but no separate kernel
bug report for this quirk.

### Step 4.4: Related Series
Record: `b4 am` found a single-patch submission, not a multi-patch
series. No series dependency found.

### Step 4.5: Stable Mailing List
Record: `WebFetch` searches for lore stable/all were blocked by Anubis.
Web search did not find stable-list discussion for this exact patch. No
evidence found of a stable-specific objection.

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Functions/Data
Record: Modified object: `quirk_flags_table[]`. Affected functions
verified:
- `snd_usb_init_quirk_flags_table()`
- `snd_usb_init_quirk_flags()`
- `snd_usb_audio_create()`
- `audioformat_playback_quirk()`
- `add_generic_implicit_fb()`
- `snd_usb_endpoint_start()`

### Step 5.2: Callers
Record: `usb_audio_probe()` calls `snd_usb_audio_create()`, which
initializes quirk flags. ALSA PCM ops call `snd_usb_pcm_prepare()` and
playback/capture trigger callbacks, which call `start_endpoints()`,
which calls `snd_usb_endpoint_start()`.

### Step 5.3: Callees
Record: `snd_usb_init_quirk_flags_table()` scans `quirk_flags_table[]`
and ORs flags into `chip->quirk_flags`. `audioformat_playback_quirk()`
calls `add_generic_implicit_fb()` when `QUIRK_FLAG_GENERIC_IMPLICIT_FB`
is set. `snd_usb_endpoint_start()` changes URB submission behavior based
on `QUIRK_FLAG_PLAYBACK_FIRST`.

### Step 5.4: Call Chain / Reachability
Record: Reachable when the matching USB audio device is probed and
userspace opens/starts ALSA PCM full-duplex streams. I did not verify
whether an unprivileged user can trigger it on a given distribution;
ALSA device permissions are policy-dependent.

### Step 5.5: Similar Patterns
Record: Verified existing exact flag combination for Behringer
`0x1397:0x0507`, `0x0508`, and `0x0509`. Verified
`QUIRK_FLAG_GENERIC_IMPLICIT_FB` appears in ten quirk-table entries in
current `7.0.y`.

## Phase 6: Stable Tree Analysis

### Step 6.1: Buggy Code Exists
Record:
- `v7.0.5`: quirk infrastructure exists; EUPHONIA entry absent.
- `v6.12.75`: quirk infrastructure exists; EUPHONIA entry absent.
- `v6.6`: quirk infrastructure exists; EUPHONIA entry absent.
- `v6.1`: quirk infrastructure exists; EUPHONIA entry absent.
- `v5.15`: `GENERIC_IMPLICIT_FB` flag absent, so this exact patch is not
  applicable.

### Step 6.2: Backport Difficulty
Record:
- `v7.0.5`: index-only `git apply --check` passes.
- `v6.12.75`: index-only `git apply --check` passes.
- `v6.6` and `v6.1`: exact patch does not apply because nearby context
  differs, but the same table and flags exist; expected minor context-
  only backport.
- `v5.15`: exact patch does not apply and lacks required generic flag
  infrastructure.

### Step 6.3: Related Fixes Already Stable
Record: No existing `0x2b73:0x0047` or `AlphaTheta EUPHONIA` entry found
in the local tree. No local history match for this device.

## Phase 7: Subsystem Context

### Step 7.1: Subsystem Criticality
Record: Subsystem is ALSA USB audio, under `sound/usb`. Criticality:
important for users of affected USB audio hardware, but not
universal/core kernel.

### Step 7.2: Activity
Record: `sound/usb` is actively maintained; recent history shows
multiple ALSA USB fixes and quirk updates. Maintainer context verified
through `MAINTAINERS`.

## Phase 8: Impact And Risk

### Step 8.1: Affected Users
Record: Driver/hardware-specific: users of AlphaTheta EUPHONIA USB audio
mixer on kernels with this usb-audio quirk infrastructure.

### Step 8.2: Trigger Conditions
Record: Trigger is full-duplex streaming where capture endpoint acts as
implicit feedback and playback must start first. The commit message
reports testing continuous full-duplex 96 kHz / 24-bit on Raspberry Pi 5
with kernel `6.12.75`.

### Step 8.3: Failure Severity
Record: Failure mode is a device/stream-start deadlock: audio full-
duplex streaming does not start. Severity: medium-high for affected
hardware users. It is not verified as a system-wide kernel
deadlock/panic.

### Step 8.4: Risk / Benefit
Record: Benefit is high for affected hardware because it makes full-
duplex operation work. Risk is very low: exact USB-ID match, 2-line
table addition, no API or shared logic change.

## Phase 9: Final Synthesis

### Step 9.1: Evidence
Record: Evidence for backporting:
- Real hardware malfunction with concrete topology and failure mode.
- Hardware quirk category is explicitly stable-suitable.
- 2-line exact-device table addition.
- Existing identical flag combination for similar implicit-feedback
  devices.
- Tested on `6.12.75`.
- Appropriate ALSA maintainers/lists were CC’d; supplied commit has
  Takashi Iwai signoff.

Evidence against:
- No separate `Reported-by:` or formal `Tested-by:` tag.
- `v6.6`/`v6.1` need minor context backport.
- `v5.15` lacks `QUIRK_FLAG_GENERIC_IMPLICIT_FB`, so this exact patch
  should not be applied there without additional analysis/prerequisites.

Unresolved:
- Lore web UI could not be fetched due Anubis.
- No upstream commit hash was available locally, so `b4 dig -c` could
  not be performed.
- No independent bug report was found.

### Step 9.2: Stable Rules
Record:
1. Obviously correct and tested: yes, for applicable trees; 2-line
   exact-ID quirk and patch body reports testing.
2. Fixes a real bug: yes, full-duplex stream startup deadlock for
   specific hardware.
3. Important issue: yes for affected hardware; device full-duplex
   operation is broken without it.
4. Small and contained: yes, one file, two lines.
5. No new APIs/features: yes. This is a hardware quirk, not a new
   interface.
6. Applies to stable trees: cleanly to `v7.0.5` and `v6.12.75`; minor
   context backport for `v6.6`/`v6.1`; not directly to `v5.15`.

### Step 9.3: Exception Category
Record: Hardware quirk/workaround for a broken/nonstandard USB audio
device. This is one of the strong stable-appropriate exception
categories.

### Step 9.4: Decision
This should be backported to stable trees that already have the generic
implicit-feedback quirk flag infrastructure, especially `6.12.y`,
`6.6.y`, `6.1.y`, and `7.0.y` if applicable. For `5.15.y`, do not apply
this exact patch without separate prerequisite/backport work because the
required `QUIRK_FLAG_GENERIC_IMPLICIT_FB` flag is absent.

## Verification

- Phase 1: Parsed supplied subject, body, and tags; verified original
  patch body with `b4 am` mbox.
- Phase 2: Verified diff is 2 insertions in `sound/usb/quirks.c`.
- Phase 2/5: Read `sound/usb/quirks.c`, `sound/usb/usbaudio.h`,
  `sound/usb/implicit.c`, `sound/usb/endpoint.c`, `sound/usb/card.c`,
  `sound/usb/pcm.c`, and `sound/usb/stream.c`.
- Phase 3: Ran `git blame` around the insertion area and similar
  Behringer entries; noted grafted history limits.
- Phase 3: Ran file and author history searches without `--all`.
- Phase 4: Ran `b4 am` on the supplied patch link; found one patch and
  DKIM-signed submission.
- Phase 4: Ran `b4 am --cc-trailers`; verified ALSA maintainers/lists
  were CC’d.
- Phase 4: Tried `WebFetch` for lore and stable queries; blocked by
  Anubis.
- Phase 4: Ran web searches; found no separate stable discussion or
  independent bug report.
- Phase 5: Verified caller path from USB probe to quirk flag
  initialization and from ALSA PCM prepare/trigger to endpoint start.
- Phase 5: Verified same flag combination already exists for Behringer
  UMC202HD/UMC204HD/UMC404HD.
- Phase 6: Checked `v7.0.5`, `v6.12.75`, `v6.6`, `v6.1`, and `v5.15` for
  relevant flags/context.
- Phase 6: Ran index-only apply checks: applies to `v7.0.5` and
  `v6.12.75`; does not apply as-is to `v6.6`, `v6.1`, or `v5.15`.
- Phase 7: Verified `MAINTAINERS` lists Takashi Iwai as a `SOUND`
  maintainer.
- Phase 8: Failure mode and tested hardware/kernel are verified from the
  patch message; unprivileged triggerability is unverified.

**YES**

 sound/usb/quirks.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index 148bf7e4e4d72..2ffc69b57ab49 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -2401,6 +2401,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
 		   QUIRK_FLAG_GENERIC_IMPLICIT_FB),
 	DEVICE_FLG(0x2b53, 0x0031, /* Fiero SC-01 (firmware v1.1.0) */
 		   QUIRK_FLAG_GENERIC_IMPLICIT_FB),
+	DEVICE_FLG(0x2b73, 0x0047, /* AlphaTheta EUPHONIA */
+		   QUIRK_FLAG_PLAYBACK_FIRST | QUIRK_FLAG_GENERIC_IMPLICIT_FB),
 	DEVICE_FLG(0x2d95, 0x8011, /* VIVO USB-C HEADSET */
 		   QUIRK_FLAG_CTL_MSG_DELAY_1M),
 	DEVICE_FLG(0x2d95, 0x8021, /* VIVO USB-C-XE710 HEADSET */
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] ALSA: hda/realtek: Add codec SSID quirk for Lenovo Yoga Pro 9 16IMH9

[Sasha Levin]

From: Rámon van Raaij <ramon@vanraaij.eu>

[ Upstream commit 56722cfbb78d7eb41756cd78dc5192d08bd14f3d ]

The Yoga Pro 9 16IMH9 (codec SSID 17aa:38d6) shares PCI audio device
subsystem ID 17aa:3811 with the Legion S7 15IMH05. The existing
SND_PCI_QUIRK entry for the Legion routes both machines to
ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS, which does not bind the TAS2781
smart amplifiers, resulting in near-silent built-in speakers.

Add an HDA_CODEC_QUIRK entry immediately before the conflicting PCI quirk
that matches the Yoga Pro 9's unique codec SSID and routes it to
ALC287_FIXUP_TAS2781_I2C. Codec quirks are evaluated after PCI quirks and
take precedence, leaving the Legion S7 15IMH05 entry unaffected.

This follows the same pattern used to disambiguate PCI SSID 17aa:3847
(shared between Yoga Pro 7 14IMH9 and Legion 7 16ACHG6), where a
HDA_CODEC_QUIRK for codec SSID 17aa:38cf resolves the conflict.

Signed-off-by: Rámon van Raaij <ramon@vanraaij.eu>
Link: https://patch.msgid.link/20260430191224.patch1-ramon@vanraaij.eu
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough
### Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem is `ALSA: hda/realtek`; action is `Add`;
claimed intent is adding a codec-SSID quirk so Lenovo Yoga Pro 9 16IMH9
uses the TAS2781 fixup instead of the Legion S7 PCI-SSID fixup.

Step 1.2 Record: Tags present are `Signed-off-by: Rámon van Raaij
<ramon@vanraaij.eu>`, `Link:
https://patch.msgid.link/20260430191224.patch1-ramon@vanraaij.eu`, and
`Signed-off-by: Takashi Iwai <tiwai@suse.de>`. No `Fixes:`, `Reported-
by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, or `Cc:
stable@vger.kernel.org` tag is present.

Step 1.3 Record: The commit describes a real hardware misidentification:
Yoga Pro 9 16IMH9 has codec SSID `17aa:38d6` but shares PCI audio SSID
`17aa:3811` with Legion S7 15IMH05, causing
`ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS` to be selected. The stated
symptom is near-silent built-in speakers because TAS2781 smart
amplifiers are not bound.

Step 1.4 Record: This is a bug fix disguised as an “add quirk” change.
It is a hardware-specific workaround for wrong quirk selection, one of
the standard stable exception categories.

### Phase 2: Diff Analysis
Step 2.1 Record: One file changed: `sound/hda/codecs/realtek/alc269.c`,
4 insertions, 0 deletions. No function body is changed; the modified
object is `alc269_fixup_tbl`. Scope is single-file, table-only,
surgical.

Step 2.2 Record: Before, a Yoga Pro 9 16IMH9 with PCI SSID `17aa:3811`
would hit the existing Legion S7 `SND_PCI_QUIRK` and get
`ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS`. After, the earlier
`HDA_CODEC_QUIRK(0x17aa, 0x38d6, ..., ALC287_FIXUP_TAS2781_I2C)` matches
by codec SSID first due table order and routes that machine to the
TAS2781 I2C fixup.

Step 2.3 Record: Bug category is hardware workaround / logic
correctness. The broken mechanism is ambiguous PCI SSID reuse; the fix
uses the more specific codec SSID.

Step 2.4 Record: Fix quality is high. It is a 4-line exact-match quirk,
no API change, no broad behavior change. Regression risk is very low and
limited to devices reporting codec SSID `17aa:38d6`.

### Phase 3: Git History
Step 3.1 Record: `git blame` shows the conflicting
`SND_PCI_QUIRK(0x17aa, 0x3811, "Legion S7 15IMH05", ...)` came from
`67f4c61a73e9b` by Eric Naim. `git describe --contains 67f4c61a73e9b`
reports `v7.1-rc1~166^2~6`; candidate `56722cfbb78d` is contained by
`v7.1-rc3~27^2~13`.

Step 3.2 Record: No `Fixes:` tag is present, so there is no tagged
introducer to follow. Manual blame identifies the relevant prior Legion
quirk.

Step 3.3 Record: Recent file history is mostly audio quirk additions.
Related commit `217d5bc9f9627` adds the same codec-SSID disambiguation
pattern for Yoga Pro 7 14IMH9 versus Legion 7 16ACHG6.

Step 3.4 Record: `git log --author='Rámon van Raaij' ... master --
sound/hda/codecs/realtek/alc269.c` returned no earlier matching commits
in this local history. Maintainer Takashi Iwai committed the patch.

Step 3.5 Record: Dependencies are the existing `HDA_CODEC_QUIRK`
infrastructure, `ALC287_FIXUP_TAS2781_I2C`, and the conflicting Legion
`17aa:3811` entry. All exist in the checked 7.0 tree; `git apply
--check` of the candidate diff against current `HEAD` succeeded.

### Phase 4: Mailing List / External Research
Step 4.1 Record: `b4 dig -c 56722cfbb78d -a` found one revision, v1, at
`https://patch.msgid.link/20260430191224.patch1-ramon@vanraaij.eu`. No
newer revision for this exact patch was found.

Step 4.2 Record: `b4 dig -c 56722cfbb78d -w` shows recipients were Rámon
van Raaij, `linux-sound@vger.kernel.org`, `alsa-devel@alsa-project.org`,
and Takashi Iwai. The maintainer replied “Applied now. Thanks.”

Step 4.3 Record: No separate bug report link or `Reported-by` tag is in
the candidate. Web search found public Yoga Pro 9i/TIAS2781/ALC287 audio
issue reports, but I did not use those as primary evidence for the exact
`17aa:38d6` SSID.

Step 4.4 Record: `b4 mbox -c` showed a later related patch for codec
SSID `17aa:38d5`, referencing this candidate commit and the same
hardware class. It is related context, not a prerequisite.

Step 4.5 Record: Web search for stable-specific discussion of
`56722cfbb78d` did not find a stable-thread result. Lore `WebFetch` was
blocked by anti-bot HTML, but `b4` access succeeded.

### Phase 5: Semantic Code Analysis
Step 5.1 Record: No function is modified. Key affected symbols are
`alc269_fixup_tbl`, `snd_hda_pick_fixup`, `HDA_CODEC_QUIRK`,
`ALC287_FIXUP_TAS2781_I2C`, and `ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS`.

Step 5.2 Record: `alc269_probe()` calls `snd_hda_pick_fixup(codec,
alc269_fixup_models, alc269_fixup_tbl, alc269_fixups)`.
`hda_codec_driver_probe()` calls the codec driver probe op, so this is
reached during HDA codec binding/probe.

Step 5.3 Record: `HDA_CODEC_QUIRK` sets `.match_codec_ssid = true`.
`snd_hda_pick_fixup()` checks such entries against
`codec->core.subsystem_id`; the TAS2781 fixup calls
`comp_generic_fixup(..., "i2c", "TIAS2781", ...)`. The Legion fixup is
HDA verb/coefficient based and does not call the TAS2781 component
binding helper.

Step 5.4 Record: Reachability is hardware probe path: HDA controller
probes codecs, Realtek codec driver probes, `alc269_probe()` picks the
fixup. The bug is not syscall/security-triggered; it affects audio
functionality on matching hardware.

Step 5.5 Record: Similar patterns exist in the same table, especially
`HDA_CODEC_QUIRK(0x17aa, 0x38cf, "Lenovo Yoga Pro 7 14IMH9", ...)`
immediately before a conflicting Legion PCI SSID entry.

### Phase 6: Stable Tree Analysis
Step 6.1 Record: In checked local refs, `HEAD` and `pending-6.18`
contain the conflicting `17aa:3811` Legion quirk and do not contain the
candidate `HDA_CODEC_QUIRK(0x17aa, 0x38d6, ...)`. Older checked pending
refs did not show the conflicting line in the `git grep` run.

Step 6.2 Record: Backport difficulty is clean for current `HEAD`: `git
apply --check` succeeded. For older trees without `HDA_CODEC_QUIRK` or
without the Legion `17aa:3811` quirk, this patch is either not
applicable or would need prerequisites.

Step 6.3 Record: No equivalent `17aa:38d6` codec quirk was found in
checked stable refs. Existing `SND_PCI_QUIRK(0x17aa, 0x38d6, ...)`
entries are PCI-SSID entries and do not fix the reported Yoga Pro 9 case
where the PCI SSID is `17aa:3811`.

### Phase 7: Subsystem Context
Step 7.1 Record: Subsystem is ALSA HDA Realtek codec support under
`sound/hda/codecs/realtek`. Criticality is driver-specific/important for
affected laptop users, not core-kernel-wide.

Step 7.2 Record: The subsystem is actively maintained; recent history
shows many Realtek laptop quirk additions and related fixes. Takashi
Iwai applied the patch.

### Phase 8: Impact / Risk
Step 8.1 Record: Affected population is Lenovo Yoga Pro 9 16IMH9 units
with codec SSID `17aa:38d6` on stable trees containing the Legion
`17aa:3811` quirk.

Step 8.2 Record: Trigger is normal boot/device probe and use of built-in
speakers. It is hardware/config specific, not unprivileged exploitation.

Step 8.3 Record: Failure mode is broken built-in speaker output,
described as near-silent speakers. Severity is high for affected
hardware functionality, though not crash/data-corruption/security
severity.

Step 8.4 Record: Benefit is high for affected laptops and also prevents
a regression caused by the shared PCI SSID quirk. Risk is very low: 4
lines, exact match, no new API, no shared logic changes.

### Phase 9: Synthesis
Step 9.1 Record: Evidence for backporting: real user-visible hardware
breakage, standard stable hardware-quirk category, tiny table-only
patch, maintainer-applied, exact existing pattern, clean apply to
current checked stable tree. Evidence against: no `Tested-by`, no `Cc:
stable`, no separate bug-report link in the commit, and not applicable
to trees lacking the prerequisite Legion quirk or `HDA_CODEC_QUIRK`
infrastructure. Unresolved: I did not independently verify the physical
uniqueness of codec SSID `17aa:38d6` beyond the submitted patch and
maintainer acceptance.

Step 9.2 Record: Stable rules: already upstream/mainline yes; obviously
correct yes by code inspection and `checkpatch`; fixes a real bug yes,
wrong quirk causing near-silent speakers; important enough yes as a
hardware quirk / broken device functionality; small and contained yes, 4
insertions; no new feature/API yes; applies cleanly to current checked
stable `HEAD`, with older-tree applicability depending on prerequisites.

Step 9.3 Record: Exception category applies: hardware quirk/workaround
for a specific laptop audio configuration.

Step 9.4 Record: Decision is YES for stable trees that contain the
conflicting Legion S7 `17aa:3811` quirk and the
`HDA_CODEC_QUIRK`/TAS2781 infrastructure. It should not be forced into
older trees where the buggy conflicting quirk is absent.

## Verification
- [Phase 1] Parsed commit `56722cfbb78d7eb41756cd78dc5192d08bd14f3d`
  with `git show`; confirmed tags and message.
- [Phase 2] Inspected diff: `sound/hda/codecs/realtek/alc269.c`, 4
  insertions.
- [Phase 3] Ran `git blame` around the conflicting quirk; confirmed
  `67f4c61a73e9b` introduced `17aa:3811`.
- [Phase 3] Ran `git show 67f4c61a73e9b`; confirmed it adds the Legion
  S7 quirk.
- [Phase 4] Ran `b4 dig -c 56722cfbb78d -a` and `-w`; found v1
  submission, recipients, and maintainer application.
- [Phase 5] Read `snd_hda_pick_fixup()`, `HDA_CODEC_QUIRK`,
  `alc269_probe()`, TAS2781 fixup, and Legion fixup paths.
- [Phase 6] Ran `git grep` across checked stable refs; found conflict in
  `HEAD` and `pending-6.18`, and no candidate codec quirk there.
- [Phase 6] Ran `git apply --check`; candidate applies to current
  checked `HEAD`.
- [Phase 8] Ran `scripts/checkpatch.pl --no-tree`; 0 errors, 0 warnings.
- UNVERIFIED: No runtime test on Lenovo Yoga Pro 9 16IMH9 hardware; no
  full build performed; exact affected stable branch set beyond checked
  local refs not exhaustively proven because broad branch containment
  checks were too slow and stopped.

**YES**

 sound/hda/codecs/realtek/alc269.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index 3c02f50626ed4..29dafa3f1d15a 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -7606,6 +7606,10 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x17aa, 0x3801, "Lenovo Yoga9 14IAP7", ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN),
 	HDA_CODEC_QUIRK(0x17aa, 0x3802, "DuetITL 2021", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS),
 	SND_PCI_QUIRK(0x17aa, 0x3802, "Lenovo Yoga Pro 9 14IRP8", ALC287_FIXUP_TAS2781_I2C),
+	/* Yoga Pro 9 16IMH9 shares PCI SSID 17aa:3811 with Legion S7 15IMH05;
+	 * use codec SSID to distinguish them
+	 */
+	HDA_CODEC_QUIRK(0x17aa, 0x38d6, "Lenovo Yoga Pro 9 16IMH9", ALC287_FIXUP_TAS2781_I2C),
 	SND_PCI_QUIRK(0x17aa, 0x3811, "Legion S7 15IMH05", ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS),
 	SND_PCI_QUIRK(0x17aa, 0x3813, "Legion 7i 15IMHG05", ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS),
 	SND_PCI_QUIRK(0x17aa, 0x3818, "Lenovo C940 / Yoga Duet 7", ALC298_FIXUP_LENOVO_C940_DUET7),
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] fbdev: ipu-v3: clean up kernel-doc warnings

[Sasha Levin]

From: Randy Dunlap <rdunlap@infradead.org>

[ Upstream commit f1fb23a0a0fcbdb66672da51d7d63a259f6396ca ]

Correct all kernel-doc warnings:
- fix a typedef kernel-doc comment
- mark a list_head as private
- use Returns: for function return values

Warning: include/video/imx-ipu-image-convert.h:31 struct member 'list' not
 described in 'ipu_image_convert_run'
Warning: include/video/imx-ipu-image-convert.h:40 function parameter
 'ipu_image_convert_cb_t' not described in 'void'
Warning: include/video/imx-ipu-image-convert.h:40 expecting prototype for
 ipu_image_convert_cb_t(). Prototype was for void() instead
Warning: include/video/imx-ipu-image-convert.h:66 No description found for
 return value of 'ipu_image_convert_verify'
Warning: include/video/imx-ipu-image-convert.h:90 No description found for
 return value of 'ipu_image_convert_prepare'
Warning: include/video/imx-ipu-image-convert.h:125 No description found for
 return value of 'ipu_image_convert_queue'
Warning: include/video/imx-ipu-image-convert.h:163 No description found for
 return value of 'ipu_image_convert'

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Helge Deller <deller@gmx.de>
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 `fbdev: ipu-v3`; action verb `clean up`;
intent is to correct kernel-doc warnings in `include/video/imx-ipu-
image-convert.h`.

Step 1.2 Record: tags in committed message are `Signed-off-by: Randy
Dunlap <rdunlap@infradead.org>`, `Reviewed-by: Philipp Zabel
<p.zabel@pengutronix.de>`, and `Signed-off-by: Helge Deller
<deller@gmx.de>`. No `Fixes:`, `Reported-by:`, `Tested-by:`, `Acked-
by:`, `Link:`, or `Cc: stable@vger.kernel.org` tag is present in the
committed message.

Step 1.3 Record: the described problem is seven kernel-doc warnings: one
undocumented/private list member, malformed typedef documentation, and
missing `Returns:` sections. The visible symptom is documentation
tooling warnings, not a runtime crash, hang, data corruption, or
security issue. No affected kernel version is stated. Root cause is
incorrect kernel-doc comment syntax.

Step 1.4 Record: this is not a hidden runtime bug fix. The body and diff
both show a documentation/comment-only cleanup.

## Phase 2: Diff Analysis
Step 2.1 Record: one file changed: `include/video/imx-ipu-image-
convert.h`, 11 insertions and 5 deletions. Modified documentation covers
`struct ipu_image_convert_run`, `ipu_image_convert_cb_t`,
`ipu_image_convert_verify()`, `ipu_image_convert_prepare()`,
`ipu_image_convert_queue()`, and `ipu_image_convert()`. Scope is single-
file, header-only, surgical.

Step 2.2 Record: hunk behavior:
- `struct ipu_image_convert_run`: before, `list` was documented neither
  as a member nor private; after, `/* private: */` tells kernel-doc to
  ignore it as an API member.
- `ipu_image_convert_cb_t`: before, kernel-doc treated the typedef
  comment as a function prototype mismatch; after, it is marked as a
  typedef comment.
- Return docs: before, several returns were plain prose or missing;
  after, they use kernel-doc `Returns:` syntax.
- `ipu_image_convert_prepare()`: before, the V4L2 usage note followed
  the return prose; after, the return section is last and formatted for
  kernel-doc.

Step 2.3 Record: bug category is documentation/kernel-doc warning
cleanup. No error-path, synchronization, refcount, memory-safety,
initialization, type, logic, or hardware workaround change exists.

Step 2.4 Record: fix quality is high for the stated documentation issue:
small, obviously correct kernel-doc syntax changes. Runtime regression
risk is effectively zero because no C declarations, types, function
bodies, data layout, or APIs are changed. Documentation rendering risk
is very low.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows the affected header comments and
declarations came from `cd98e85a6b786d` by Steve Longerbeam, dated
2016-09-17. `git describe --contains cd98e85a6b786d` reports it as
present by `v4.9-rc1~41^2~24^2`.

Step 3.2 Record: no `Fixes:` tag is present, so there is no tagged
introducing commit to follow. Blame identifies `cd98e85a6b786d` as the
source of the documented preimage; `git show` confirms that commit added
queued IPU image conversion support and the API documentation.

Step 3.3 Record: recent local history for the file shows `96e9d754b35e8`
removing unused `ipu_image_convert_*` functions, `c942fddf8793b` adding
SPDX boilerplate conversion, and `cd98e85a6b786d` adding the header/API.
No prerequisite commit is needed for this documentation-only patch.

Step 3.4 Record: `git log --author='Randy Dunlap'` under fbdev/include
areas shows Randy has related cleanup/documentation work such as `fbdev:
hgafb: fix kernel-doc comments` and `fbdev: fbmon: fix function name in
kernel-doc`. The patch was reviewed by Philipp Zabel and committed by
Helge Deller, verified from the commit and lore thread.

Step 3.5 Record: no dependencies found. The diff changes only comments
and applies locally with `git apply --check`.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c f1fb23a0a0fcbdb66672da51d7d63a259f6396ca`
failed to find a lore match by patch-id, author/subject, or in-body
From. External fetch found the v3 discussion at
`https://yhbt.net/lore/dri-
devel/20260427183236.656902-1-rdunlap@infradead.org/T/`. The v3 thread
has Helge Deller replying “applied to fbdev git tree.” Web search/fetch
also found v2 and a v2 ping. No NAKs or objections were found.

Step 4.2 Record: `b4 dig -w` also failed for the same reason. The v3
lore mirror shows recipients included `dri-devel`, Philipp Zabel, DRM
maintainers, `imx`, `linux-arm-kernel`, Helge Deller, and `linux-fbdev`.

Step 4.3 Record: no `Reported-by:` or bug-report `Link:` tags exist. No
external crash/security bug report applies.

Step 4.4 Record: this is a standalone one-patch documentation cleanup.
v2 added the reviewed-by and updated Cc list; v3 rebased and resent.

Step 4.5 Record: direct `lore.kernel.org/stable` fetch was blocked by
Anubis. Web search for the exact subject plus `stable` found patch-
thread results but no stable-specific discussion or stable nomination.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: modified documented symbols are
`ipu_image_convert_run`, `ipu_image_convert_cb_t`,
`ipu_image_convert_verify()`, `ipu_image_convert_prepare()`,
`ipu_image_convert_queue()`, and `ipu_image_convert()`.

Step 5.2 Record: `rg` found callers in `drivers/staging/media/imx/imx-
media-csc-scaler.c` for `ipu_image_convert_abort()`,
`ipu_image_convert_queue()`, `ipu_image_convert_adjust()`,
`ipu_image_convert_unprepare()`, and `ipu_image_convert_prepare()`.
Runtime callers are unaffected because only comments changed.

Step 5.3 Record: reading `drivers/gpu/ipu-v3/ipu-image-convert.c`
confirms the documented functions perform image format
adjustment/verification, context allocation, queueing, abort/unprepare,
and single conversion setup. None of those function bodies are touched.

Step 5.4 Record: runtime path is reachable through IPU image conversion
users, but the patch changes no runtime path. The affected path for the
fix is kernel-doc/documentation generation.

Step 5.5 Record: no related same-header kernel-doc fix was found by `git
log --grep='kernel-doc' -- include/video/imx-ipu-image-convert.h`.

## Phase 6: Stable Tree Analysis
Step 6.1 Record: version tags `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`,
`v6.15`, `v6.16`, and `v6.17` all contain `include/video/imx-ipu-image-
convert.h` with the old kernel-doc text. The API was introduced before
`v4.9-rc1`, so active stable trees checked contain the documentation
issue.

Step 6.2 Record: expected backport difficulty is clean or minor. `git
apply --check` succeeds against the current local tree, and the checked
stable tags contain representative preimage lines. Full per-stable
worktree application was not run.

Step 6.3 Record: no related stable fix for this header was found in
local `git log --grep` searches.

## Phase 7: Subsystem Context
Step 7.1 Record: subsystem is fbdev/gpu IPU-v3 image conversion
documentation in an include header. Runtime criticality is
peripheral/driver-specific; documentation-build criticality is low.

Step 7.2 Record: local subsystem history shows ongoing cleanup/removal
activity in `drivers/gpu/ipu-v3` and the header, including unused-
function removals and treewide cleanup. This patch is not part of a
required functional series.

## Phase 8: Impact And Risk
Step 8.1 Record: affected population is kernel documentation builders,
maintainers, and users consuming generated kernel-doc. Runtime users of
IPU-v3 are not affected by behavior.

Step 8.2 Record: trigger is running kernel-doc/documentation tooling
over this header. It is not triggered by boot, device probe, syscalls,
or ordinary runtime use. Unprivileged runtime trigger does not apply.

Step 8.3 Record: failure mode is documentation warnings only. Severity
is LOW. I did not verify any configuration where these warnings are
fatal, so that does not drive the decision.

Step 8.4 Record: benefit is low but real under the documentation-fix
exception: it makes stable documentation builds cleaner. Risk is
extremely low because only comments change. Risk/benefit is favorable if
stable accepts documentation corrections.

## Phase 9: Final Synthesis
Step 9.1 Record: evidence for backporting: pure documentation
correction, explicitly fixes listed kernel-doc warnings, tiny single-
file patch, reviewed by Philipp Zabel, applied by Helge Deller, old text
exists in active stable tags checked, and documentation/comment fixes
are an allowed stable exception. Evidence against: no runtime bug, no
crash/security/data-corruption impact, no stable nomination found, and
b4 could not match the thread. Unresolved: direct stable-lore search was
blocked; full apply checks on every stable branch were not run.

Step 9.2 Record:
1. Obviously correct and tested? Mostly yes for documentation syntax;
   reviewed and applied, but no `Tested-by`.
2. Fixes a real bug that affects users? Yes, a real kernel-doc warning
   issue; not a runtime bug.
3. Important issue? No runtime severity; LOW documentation-build
   severity.
4. Small and contained? Yes, 11 additions and 5 deletions in one header.
5. No new features or APIs? Yes, comments only.
6. Can apply to stable trees? Likely yes; local apply check passed and
   stable tags checked contain the preimage.

Step 9.3 Record: exception category applies: documentation/comment fix.
This is the main reason to accept despite lack of runtime impact.

Step 9.4 Decision: backporting is appropriate under the stable
documentation-fix exception. It is not a stability/security fix, but it
is a correct, reviewed, zero-runtime-risk cleanup of real kernel-doc
warnings in code present across active stable trees.

## Verification
- Phase 1: fetched and inspected committed metadata for
  `f1fb23a0a0fcbdb66672da51d7d63a259f6396ca`; confirmed tags and
  message.
- Phase 2: `git show --stat --patch` confirmed one header, 11
  insertions, 5 deletions, comments only.
- Phase 3: `git blame` confirmed changed comment preimage from
  `cd98e85a6b786d`; `git describe --contains` placed it before
  `v4.9-rc1`; `git show cd98e85a6b786d` confirmed original API addition.
- Phase 3: `git log` on the header/subsystem found no prerequisite
  functional series.
- Phase 4: `b4 dig`, `b4 dig -a`, and `b4 dig -w` all failed to match;
  recorded as a tool limitation/failure.
- Phase 4: WebFetch of the v3 lore mirror confirmed the patch thread and
  Helge Deller’s applied reply; Spinics fetch confirmed v2 and a later
  ping.
- Phase 5: `rg` found runtime users; `ReadFile` of implementation
  confirmed function bodies exist but are not changed.
- Phase 6: tag checks confirmed the header and old doc text in `v5.10`,
  `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.15`, `v6.16`, and `v6.17`; `git
  apply --check` succeeded locally.
- Phase 8: severity/risk assessment is derived from the verified
  comments-only diff.
- UNVERIFIED: direct `lore.kernel.org/stable` search content was blocked
  by Anubis; no actual `make htmldocs` run was performed; full patch
  application against every individual stable branch was not performed.

**YES**

 include/video/imx-ipu-image-convert.h | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/include/video/imx-ipu-image-convert.h b/include/video/imx-ipu-image-convert.h
index 003b3927ede5c..6b77968a6a150 100644
--- a/include/video/imx-ipu-image-convert.h
+++ b/include/video/imx-ipu-image-convert.h
@@ -27,12 +27,13 @@ struct ipu_image_convert_run {
 
 	int status;
 
+	/* private: */
 	/* internal to image converter, callers don't touch */
 	struct list_head list;
 };
 
 /**
- * ipu_image_convert_cb_t - conversion callback function prototype
+ * typedef ipu_image_convert_cb_t - conversion callback function prototype
  *
  * @run:	the completed conversion run pointer
  * @ctx:	a private context pointer for the callback
@@ -60,7 +61,7 @@ void ipu_image_convert_adjust(struct ipu_image *in, struct ipu_image *out,
  * @out:	output image format
  * @rot_mode:	rotation mode
  *
- * Returns 0 if the formats and rotation mode meet IPU restrictions,
+ * Returns: 0 if the formats and rotation mode meet IPU restrictions,
  * -EINVAL otherwise.
  */
 int ipu_image_convert_verify(struct ipu_image *in, struct ipu_image *out,
@@ -77,11 +78,11 @@ int ipu_image_convert_verify(struct ipu_image *in, struct ipu_image *out,
  * @complete:	run completion callback
  * @complete_context:	a context pointer for the completion callback
  *
- * Returns an opaque conversion context pointer on success, error pointer
+ * In V4L2, drivers should call ipu_image_convert_prepare() at streamon.
+ *
+ * Returns: an opaque conversion context pointer on success, error pointer
  * on failure. The input/output formats and rotation mode must already meet
  * IPU retrictions.
- *
- * In V4L2, drivers should call ipu_image_convert_prepare() at streamon.
  */
 struct ipu_image_convert_ctx *
 ipu_image_convert_prepare(struct ipu_soc *ipu, enum ipu_ic_task ic_task,
@@ -122,6 +123,8 @@ void ipu_image_convert_unprepare(struct ipu_image_convert_ctx *ctx);
  * In V4L2, drivers should call ipu_image_convert_queue() while
  * streaming to queue the conversion of a received input buffer.
  * For example mem2mem devices this would be called in .device_run.
+ *
+ * Returns: 0 on success or -errno on error.
  */
 int ipu_image_convert_queue(struct ipu_image_convert_run *run);
 
@@ -155,6 +158,9 @@ void ipu_image_convert_abort(struct ipu_image_convert_ctx *ctx);
  * On successful return the caller can queue more run requests if needed, using
  * the prepared context in run->ctx. The caller is responsible for unpreparing
  * the context when no more conversion requests are needed.
+ *
+ * Returns: pointer to the created &struct ipu_image_convert_run that has
+ * been queued on success; an ERR_PTR(errno) on error.
  */
 struct ipu_image_convert_run *
 ipu_image_convert(struct ipu_soc *ipu, enum ipu_ic_task ic_task,
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.6] ASoC: amd: yc: Add DMI quirk for MSI Bravo 15 C7VE

[Sasha Levin]

From: Bob Song <songxiebing@kylinos.cn>

[ Upstream commit 0e60d96616640ffcf51b81a87c71e30d92385a93 ]

The laptop requires a quirk ID to enable its internal microphone. Add
it to the DMI quirk table.

Reported-by: gannovera <gannovera@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218402
Signed-off-by: Bob Song <songxiebing@kylinos.cn>
Link: https://patch.msgid.link/20260430014920.141276-1-songxiebing@kylinos.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Stable Backport Review

### Phase 1: Commit Message Forensics
Record 1.1: Subsystem is `ASoC: amd: yc`; action verb is `Add`; claimed
intent is adding a DMI quirk for MSI Bravo 15 C7VE internal microphone
enablement.

Record 1.2: Tags found: `Reported-by: gannovera <gannovera@gmail.com>`,
`Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218402`, `Signed-
off-by: Bob Song <songxiebing@kylinos.cn>`, `Link: https://patch.msgid.l
ink/20260430014920.141276-1-songxiebing@kylinos.cn`, `Signed-off-by:
Mark Brown <broonie@kernel.org>`. No `Fixes:` tag and no explicit `Cc:
stable`.

Record 1.3: The message states the laptop requires a quirk ID to enable
its internal microphone. Symptom is missing internal microphone support
on MSI Bravo 15 C7VE. Version info is not stated. Root cause described
is absence from `yc_acp_quirk_table`.

Record 1.4: This is a hardware quirk fix, not a hidden cleanup bug. It
fits the stable exception category for DMI quirks/workarounds.

### Phase 2: Diff Analysis
Record 2.1: One file changed: `sound/soc/amd/yc/acp6x-mach.c`, 7
insertions, 0 deletions. Modified object is the static
`yc_acp_quirk_table[]`. Scope is a single-file surgical quirk addition.

Record 2.2: Before: the DMI table matched nearby MSI models such as
`Bravo 15 B7ED` and `Bravo 15 C7VF`, but not `Bravo 15 C7VE`. After:
exact vendor/product match for `Micro-Star International Co., Ltd.` and
`Bravo 15 C7VE` maps to `&acp6x_card`. Affected path is platform probe
hardware matching.

Record 2.3: Bug category is hardware workaround / DMI quirk. Mechanism:
`acp6x_probe()` calls `dmi_first_match(yc_acp_quirk_table)` and, on
match, sets platform driver data to `acp6x_card`; without a match, the
driver can return `-ENODEV` if ACPI did not already enable the card.

Record 2.4: Fix quality is high: it adds only one exact DMI table entry
using an existing pattern and no new logic. Regression risk is very low
and limited to machines reporting that exact DMI product/vendor pair.

### Phase 3: Git History Investigation
Record 3.1: `git blame` around adjacent MSI entries in the checked-out
7.0 tree traced those lines to the local merge base, not a useful
original introducer. The “bug” is absence of this model entry, not a bad
line introduced by a known commit. Verified file absent in `v5.15` and
present in `v5.16`, `v6.1`, `v6.6`, and `v6.12`.

Record 3.2: No `Fixes:` tag, so no introducing commit to follow.

Record 3.3: Recent history of `sound/soc/amd/yc/acp6x-mach.c` contains
many similar DMI quirk additions, including HP, ASUS, MSI Thin/Vector
entries. No prerequisite refactor was identified for this specific
7-line addition.

Record 3.4: Author history in the fetched maintainer branch showed Bob
Song’s related commits for this path consist of this patch. The patch
was committed by Mark Brown, the ASoC maintainer.

Record 3.5: Dependency check found the needed symbols and structure
already exist in stable-relevant trees: `yc_acp_quirk_table`,
`acp6x_card`, and `dmi_first_match()` are present in `v6.1`;
`SND_SOC_AMD_YC_MACH` exists in `v6.1` and `v6.6`. The exact submitted
hunk applies cleanly to the current 7.0 tree; older trees such as `v6.1`
lack the nearby MSI `Bravo 15 B7ED` anchor and would need a simple
context adjustment.

### Phase 4: Mailing List And External Research
Record 4.1: `b4 dig -c 0e60d96616640ffcf51b81a87c71e30d92385a93` found
the lore thread at `https://patch.msgid.link/20260430014920.141276-1-
songxiebing@kylinos.cn`. `b4 dig -a` found two same-subject submissions
dated 2026-04-22 and 2026-04-30; the April 30 version is the applied
one.

Record 4.2: `b4 dig -w` showed the April 30 submission included Takashi
Iwai, Jaroslav Kysela, Liam Girdwood, Mark Brown, Vijendar Mukunda,
`linux-sound`, `linux-kernel`, and the reporter.

Record 4.3: Direct `WebFetch` of Bugzilla was blocked by Anubis. Search
results and the lore thread corroborate that Bugzilla #218402 is tied to
this MSI Bravo 15 C7VE microphone issue.

Record 4.4: Related pattern found: a similar MSI Bravo 17 C7VE quirk
thread describes the same ACP6x DMIC not-enabled problem on a related
MSI model. No dependency between that patch and this one was found.

Record 4.5: Stable-list search found no stable-specific discussion for
`Bravo 15 C7VE`.

### Phase 5: Code Semantic Analysis
Record 5.1: Modified object is `yc_acp_quirk_table[]`; key consuming
function is `acp6x_probe()`.

Record 5.2: `acp6x_probe()` is the `.probe` callback of platform driver
`acp6x_mach_driver`. The platform device named `acp_yc_mach` is
registered by `snd_acp6x_probe()` in `pci-acp6x.c` when ACP6x PDM mode
is set.

Record 5.3: Key callees in `acp6x_probe()` are ACPI property checks,
`_WOV` evaluation, `dmi_first_match()`, `platform_set_drvdata()`,
`platform_get_drvdata()`, and `devm_snd_soc_register_card()`.

Record 5.4: Reachability is hardware enumeration/probe on AMD Yellow
Carp ACP systems, not a syscall-triggered path. For the affected laptop,
the issue is encountered at boot/device probe when the internal DMIC
card is not registered.

Record 5.5: Similar pattern is widespread in the same table: many
laptop-specific entries all set `.driver_data = &acp6x_card`.

### Phase 6: Stable Tree Analysis
Record 6.1: `v5.15` lacks `sound/soc/amd/yc/acp6x-mach.c`; `v5.16`,
`v6.1`, `v6.6`, and `v6.12` contain it. This is relevant to stable trees
with the AMD YC machine driver, especially `v6.1+`.

Record 6.2: Current 7.0 tree accepts the patch cleanly via `git apply
--check`. `v6.6`, `v6.12`, `v6.18`, `v6.19`, and HEAD have nearby MSI
entries; `v6.1` has the quirk machinery but not the same adjacent MSI
context, so it needs minor manual placement.

Record 6.3: Searches found no existing `Bravo 15 C7VE` entry in current
HEAD, `v6.6`, `v6.12`, `v6.18`, or `v6.19`.

### Phase 7: Subsystem Context
Record 7.1: Subsystem is ALSA SoC / AMD YC machine driver under
`sound/`. Criticality is peripheral but user-visible: it affects audio
capture on a specific laptop model.

Record 7.2: The subsystem/file is actively receiving DMI quirk
additions, verified by recent history listing multiple ASoC AMD YC quirk
commits.

### Phase 8: Impact And Risk
Record 8.1: Affected users are MSI Bravo 15 C7VE owners using kernels
with `CONFIG_SND_SOC_AMD_YC_MACH`.

Record 8.2: Trigger condition is device probing on that hardware when
firmware/ACPI does not otherwise enable the DMIC path. It is not an
unprivileged-user-triggered security issue.

Record 8.3: Failure mode is loss of internal microphone functionality,
not crash, data corruption, or security impact. Severity is medium for
affected users.

Record 8.4: Benefit is high for affected hardware because it restores
the internal microphone. Risk is very low because the patch is seven
lines, exact-DMI-scoped, and uses existing driver data.

### Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: real user report, Bugzilla closure
tag, accepted by ASoC maintainer, exact hardware quirk, tiny scope, no
API/behavior change outside the matching laptop, and stable rules
explicitly allow hardware quirks. Evidence against: no explicit `Cc:
stable`, no `Tested-by`, Bugzilla direct fetch blocked, and `v6.1` needs
trivial context adjustment. None of these outweigh the quirk benefit.

Record 9.2: Stable rules: obviously correct yes; fixes a real user-
visible hardware bug yes; important enough for affected users yes,
though not crash-level; small and contained yes; no new APIs/features
yes; applies cleanly to current 7.0 and should be straightforward for
stable trees containing the driver.

Record 9.3: Exception category applies: hardware-specific DMI
quirk/workaround in an existing driver.

Record 9.4: Decision is to backport to stable trees that contain the AMD
YC machine driver, with minor context adjustment where needed.

## Verification
- [Phase 1] Parsed fetched commit
  `0e60d96616640ffcf51b81a87c71e30d92385a93`: confirmed subject, tags,
  author, committer, and 7-line stat.
- [Phase 2] Read `sound/soc/amd/yc/acp6x-mach.c`: confirmed
  `yc_acp_quirk_table[]` and `acp6x_probe()` DMI behavior.
- [Phase 3] Ran local history/blame checks: nearby blame was not useful
  for original introduction; verified file absent in `v5.15` and present
  in `v5.16+`.
- [Phase 4] Ran `b4 dig -c`, `-a`, `-w`, and saved/read mbox: confirmed
  lore thread, two submissions, maintainer recipients, and Mark Brown
  application to `for-7.1`.
- [Phase 5] Read `pci-acp6x.c`: confirmed PCI probe registers
  `acp_yc_mach`, which invokes the machine driver probe.
- [Phase 6] Checked stable tags and entries: no `Bravo 15 C7VE` in
  checked stable/current trees; patch applies cleanly to current 7.0
  tree.
- [Phase 7] Checked Kconfig/Makefile: confirmed `SND_SOC_AMD_YC_MACH` is
  the relevant config and exists in `v6.1`/`v6.6`.
- [Phase 8] Impact assessment is based on verified probe flow plus the
  commit’s reported Bugzilla/user report.
- UNVERIFIED: Direct Bugzilla contents could not be fetched due Anubis.
  Exact original file introduction commit was not determined from local
  history, but tag presence verifies stable relevance.

**YES**

 sound/soc/amd/yc/acp6x-mach.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c
index aa62009331825..0fa2f694f3d30 100644
--- a/sound/soc/amd/yc/acp6x-mach.c
+++ b/sound/soc/amd/yc/acp6x-mach.c
@@ -472,6 +472,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = {
 			DMI_MATCH(DMI_PRODUCT_NAME, "Bravo 15 B7ED"),
 		}
 	},
+	{
+		.driver_data = &acp6x_card,
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "Micro-Star International Co., Ltd."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "Bravo 15 C7VE"),
+		}
+	},
 	{
 		.driver_data = &acp6x_card,
 		.matches = {
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.1] powerpc/pasemi: Drop redundant res assignment

[Sasha Levin]

From: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

[ Upstream commit f583bd5f64d40e083dde5bb22846c4d93e59d471 ]

Return value of pas_add_bridge() is not used, so code can be simplified
to fix W=1 clang warnings:

  arch/powerpc/platforms/pasemi/pci.c:275:6: error: variable 'res' set but not used [-Werror,-Wunused-but-set-variable]

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260317130823.240279-4-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

### Phase 1: Commit Message Forensics
Record 1.1: Subsystem `powerpc/pasemi`; action verb `Drop`; intent is to
remove an unused local variable assignment in PA Semi PCI init.

Record 1.2: Tags found: `Signed-off-by: Krzysztof Kozlowski`, `Signed-
off-by: Madhavan Srinivasan`, `Link: https://patch.msgid.link/2026031713
0823.240279-4-krzysztof.kozlowski@oss.qualcomm.com`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, or `Cc:
stable`.

Record 1.3: The commit explicitly describes a Clang `W=1` build warning
promoted to an error: `variable 'res' set but not used
[-Werror,-Wunused-but-set-variable]`. No runtime symptom, crash, data
corruption, or user-visible functional failure is described.

Record 1.4: This is not a hidden runtime bug fix. It is a build-warning
cleanup that can matter when building powerpc with warning-as-error
settings.

### Phase 2: Diff Analysis
Record 2.1: One file changed: `arch/powerpc/platforms/pasemi/pci.c`, `1
insertion(+), 2 deletions(-)`. Only `pas_pci_init()` is modified. Scope
is single-file surgical.

Record 2.2: Before: `pas_pci_init()` declared `int res;` and assigned
`res = pas_add_bridge(np);`, then never read `res`. After: it still
calls `pas_add_bridge(np);` but does not assign the return value. The
execution path and side effects are unchanged.

Record 2.3: Bug category: build warning/build error under specific
compiler options. Mechanism: remove unused-but-set variable. No resource
lifetime, locking, memory safety, reference counting, or logic behavior
changes.

Record 2.4: Fix quality is obviously correct by inspection: the function
call remains, only the unused local storage is removed. Regression risk
is very low because runtime behavior is unchanged.

### Phase 3: Git History Investigation
Record 3.1: `git blame` on current stable code shows the exact changed
lines are present in the checked-out stable tree. Deeper history shows
the unused `res` assignment was introduced by `250a93501d626`
(`powerpc/pasemi: Search for PCI root bus by compatible property`),
first described by `git describe` as `v4.19-rc1~110^2~83`.

Record 3.2: No `Fixes:` tag is present. Manual history identified
`250a93501d626` as the introducing commit for the exact unused
assignment pattern.

Record 3.3: Recent file history shows only the candidate commit and
unrelated treewide allocation changes in `next-20260508`; no
prerequisite pasemi PCI refactor was found.

Record 3.4: The author has other powerpc cleanup commits nearby,
including the sibling PS3 warning fix. `MAINTAINERS` identifies Madhavan
Srinivasan and Michael Ellerman as powerpc maintainers; Madhavan
committed this patch.

Record 3.5: The sibling commit `8333e4916040e` is part of the same
cleanup series but is independent. This pasemi patch applies standalone
to the current 7.0.5 checkout.

### Phase 4: Mailing List And External Research
Record 4.1: `b4 dig -c f583bd5f64d40` found the original submission by
patch-id. It found the January submission and the March resend
corresponding to the commit `Link:`. Direct WebFetch to
lore/patch.msgid.link was blocked by Anubis.

Record 4.2: `b4 dig -w` showed appropriate powerpc maintainers and
LLVM/compiler-warning stakeholders were copied: Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy, Nathan Chancellor,
LLVM list, linuxppc-dev, and others.

Record 4.3: No bug report link or reporter tag exists. The thread
describes a compiler warning/build-cleanliness issue, not a runtime bug
report.

Record 4.4: The patch is part of a two-patch series with `powerpc/ps3:
Drop redundant result assignment`; the other patch is the same class of
cleanup and is not a dependency.

Record 4.5: The downloaded thread contains no `stable` mention. A direct
lore stable search was attempted but blocked by Anubis, so no stable-
list archive result could be independently verified.

### Phase 5: Code Semantic Analysis
Record 5.1: Modified function: `pas_pci_init()`.

Record 5.2: Callers: `pas_pci_init()` is assigned to `.discover_phbs` in
the PA Semi machine descriptor in
`arch/powerpc/platforms/pasemi/setup.c`. `pas_add_bridge()` is static
and, in `next-20260508`, is called only from `pas_pci_init()`.

Record 5.3: Relevant callees in the affected path include
`pci_set_flags()`, `of_find_compatible_node()`, `pas_add_bridge()`, and
`of_node_put()`. `pas_add_bridge()` allocates/configures the PCI
controller and scans OF ranges/ISA bridge state.

Record 5.4: Reachability is boot-time/platform-init only for PA Semi
systems. It is not syscall-reachable and has no unprivileged runtime
trigger.

Record 5.5: Similar pattern found: sibling commit `8333e4916040e`
removes an unused assignment in PS3 platform code for the same warning
class.

### Phase 6: Stable Tree Analysis
Record 6.1: The exact unused `res = pas_add_bridge(np);` pattern exists
in verified tags `v4.19`, `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`,
`v6.17`, `v6.18`, `v6.19`, and `v7.0`. It was not present in the same
form in `v4.14` or `v4.9`.

Record 6.2: Backport difficulty is clean for the current 7.0.5 tree,
verified by `git format-patch -1 --stdout f583bd5f64d40 | git apply
--check`. Older stable trees may need minor context adjustment because
surrounding code differs in older releases.

Record 6.3: No earlier same-subject fix exists in `v7.0`; related same-
series warning fixes were found only in `next-20260508`.

### Phase 7: Subsystem Context
Record 7.1: Subsystem is `arch/powerpc/platforms/pasemi`, a platform-
specific powerpc PCI init path. Criticality is peripheral/platform-
specific, not core kernel.

Record 7.2: Recent pasemi file history is low churn. This is mature
platform code with little recent activity.

### Phase 8: Impact And Risk
Record 8.1: Affected population: PA Semi powerpc platform builders,
especially Clang `W=1` builds with powerpc `-Werror` behavior.

Record 8.2: Trigger condition is build-time only. No runtime trigger and
no unprivileged-user trigger were verified.

Record 8.3: Failure mode is build failure under specific warning/error
settings, not crash/corruption/deadlock. Severity is medium for affected
builders, low for runtime users.

Record 8.4: Benefit is narrow but real under the stable build-fix
exception. Risk is extremely low because the generated runtime behavior
should be unchanged: the same function call remains and only an unused
local assignment is removed.

### Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: fixes a verified compiler
warning/error class; code exists across many stable-era releases; patch
is tiny, standalone, and behavior-preserving; applies cleanly to current
stable checkout. Evidence against: no runtime bug, no default-build
failure was verified, no stable nomination, platform-specific impact.
Unresolved: direct stable lore search was blocked, and I did not run a
full Clang `W=1` build.

Record 9.2: Stable rules checklist: obviously correct: yes by
inspection; tested: no explicit `Tested-by` and no local full build;
fixes a real issue: yes as a build-warning/error issue under specific
settings; important: only under build-fix exception, not runtime-
critical; small/contained: yes, 3-line single-function change; no new
feature/API: yes; applies to stable: current 7.0.5 yes, older trees
likely simple but not all tested.

Record 9.3: Exception category: build fix. This is the only reason to
take it; it is not a runtime bug fix.

Record 9.4: Decision: backport as a low-risk build fix for Clang
`W=1`/powerpc warning-as-error builds. The benefit is narrow, but the
patch is minimal, standalone, and behavior-preserving.

## Verification
- [Phase 1] `git show --format=fuller --stat --patch f583bd5f64d40`
  verified commit message, tags, and exact diff.
- [Phase 2] Diff verified one file, one function, `1 insertion`, `2
  deletions`.
- [Phase 3] `git blame` and `git show 250a93501d626` verified the unused
  assignment pattern was introduced by `250a93501d626`, described as
  before `v4.19-rc1`.
- [Phase 4] `b4 dig -c`, `-a`, `-w`, and `b4 mbox` verified the patch
  submission, resend, recipients, and lack of candidate-specific stable
  tags in the downloaded thread.
- [Phase 5] `rg` and `git grep` verified `pas_pci_init()` call placement
  and `pas_add_bridge()` call sites.
- [Phase 6] `git grep` verified the pattern in `v4.19`, `v5.10`,
  `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.17`, `v6.18`, `v6.19`, and
  `v7.0`; `git apply --check` verified clean apply to current 7.0.5.
- [Phase 7] `MAINTAINERS` verified powerpc maintainers and subsystem
  ownership.
- [Phase 8] `arch/powerpc/Kconfig.debug` and `arch/powerpc/Kbuild`
  verified powerpc warning-as-error configuration exists.
- UNVERIFIED: I did not run a full Clang `W=1` build, and direct lore
  stable search was blocked by Anubis.

**YES**

 arch/powerpc/platforms/pasemi/pci.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/pasemi/pci.c b/arch/powerpc/platforms/pasemi/pci.c
index 60f990a336c47..2df9552746529 100644
--- a/arch/powerpc/platforms/pasemi/pci.c
+++ b/arch/powerpc/platforms/pasemi/pci.c
@@ -272,13 +272,12 @@ void __init pas_pci_init(void)
 {
 	struct device_node *root = of_find_node_by_path("/");
 	struct device_node *np;
-	int res;
 
 	pci_set_flags(PCI_SCAN_ALL_PCIE_DEVS);
 
 	np = of_find_compatible_node(root, NULL, "pasemi,rootbus");
 	if (np) {
-		res = pas_add_bridge(np);
+		pas_add_bridge(np);
 		of_node_put(np);
 	}
 	of_node_put(root);
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.15] scsi: smartpqi: Silence a recursive lock warning

[Sasha Levin]

From: Tomas Henzl <thenzl@redhat.com>

[ Upstream commit d65efdf467ff935e35dfe6aa9a7ab93f17ac07ee ]

On systems with multiple controllers debug kernel shows

  WARNING: possible recursive locking detected

during shutdown.

Each controller does have its own ctrl_info (and mutex) and that isn't
correctly recognized by debug kernel.  Suppress the warning by releasing
the mutex at the end of pqi_shutdown().

Signed-off-by: Tomas Henzl <thenzl@redhat.com>
Acked-by: Don Brace <don.brace@microchip.com>
Link: https://patch.msgid.link/20260414124118.23661-1-thenzl@redhat.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Decision Summary
Backport this to stable trees that contain the mutex-based
`pqi_ctrl_block_device_reset()` shutdown path, verified in `v5.15`,
`v6.1`, `v6.6`, `v6.12`, `v6.16`, and `v6.19`. Do not apply it as-is to
`v5.10`, where that helper only sets `block_device_reset = true` and no
`pqi_ctrl_unblock_device_reset()` helper exists.

This is a one-line fix for an imbalanced `lun_reset_mutex` lock in
`pqi_shutdown()`. The direct user-visible symptom is a lockdep “possible
recursive locking detected” warning during shutdown/reboot on systems
with multiple smartpqi controllers. The impact is mostly debug-kernel
noise rather than data loss or a production crash, but the patch
corrects real locking hygiene, is tiny, subsystem-reviewed, and has very
low risk.

## Phase Walkthrough
Phase 1:
- Record 1.1: subsystem `scsi: smartpqi`; action `Silence`; intent is to
  stop a recursive lock warning during shutdown.
- Record 1.2: tags present: `Signed-off-by: Tomas Henzl`, `Acked-by: Don
  Brace`, `Link:
  https://patch.msgid.link/20260414124118.23661-1-thenzl@redhat.com`,
  `Signed-off-by: Martin K. Petersen`. No `Fixes:`, no `Reported-by:`,
  no `Cc: stable`.
- Record 1.3: message describes debug kernels warning on multi-
  controller systems because distinct per-controller mutexes are not
  recognized as distinct after shutdown leaves one held.
- Record 1.4: hidden bug fix: yes. It is described as silencing a
  warning, but the code adds a missing unlock for a mutex acquired
  earlier in the same function.

Phase 2:
- Record 2.1: one file, `drivers/scsi/smartpqi/smartpqi_init.c`, one
  insertion in `pqi_shutdown()`. Single-file surgical fix.
- Record 2.2: before, `pqi_shutdown()` locked
  `ctrl_info->lun_reset_mutex` via `pqi_ctrl_block_device_reset()` and
  returned after `pqi_reset()` without unlocking. After, it unlocks via
  `pqi_ctrl_unblock_device_reset()`.
- Record 2.3: bug category is synchronization/lock balancing. The
  changed helper is verified as
  `mutex_unlock(&ctrl_info->lun_reset_mutex)`.
- Record 2.4: fix quality is high: one existing helper call, no new API,
  no refactor. Main risk is allowing a reset waiter to proceed late in
  shutdown; Tomas explicitly discussed this risk on-list and said he
  checked it.

Phase 3:
- Record 3.1: blame shows the shutdown call to
  `pqi_ctrl_block_device_reset()` is old, but `9fa8202336096` changed
  the helper to a mutex-based block/unblock model. That is the relevant
  introduction point for the missing unlock.
- Record 3.2: no `Fixes:` tag, so no tagged introducing commit to
  follow.
- Record 3.3: recent file history shows normal smartpqi churn, including
  fixes and device-ID updates; no prerequisite for this one-line helper
  call was identified for v5.15+ style code.
- Record 3.4: Tomas Henzl has SCSI commits in history but no recent
  smartpqi commits found; Don Brace is listed as smartpqi maintainer and
  acked the patch.
- Record 3.5: dependency is the existing
  `pqi_ctrl_unblock_device_reset()` helper. It exists in v5.15+ verified
  tags, not in v5.10.

Phase 4:
- Record 4.1: candidate commit hash was not available locally, so `b4
  dig -c` could not be used for this candidate. `b4 mbox` and `b4 am`
  using the Link fetched the original thread.
- Record 4.2: original recipients were `linux-scsi` and Don Brace; Don
  Brace acked it; Martin Petersen applied it.
- Record 4.3: external thread and an earlier related LKML post show a
  real lockdep splat with call trace through `__do_sys_reboot ->
  device_shutdown -> pci_device_shutdown -> pqi_shutdown`.
- Record 4.4: no newer v2/v3 was reported by `b4 mbox -c`; thread had
  six messages. A separate 2025 lockdep-key proposal for the same
  warning was found, but it is not present in this tree.
- Record 4.5: web search found no relevant stable-list discussion.

Phase 5:
- Record 5.1: modified function: `pqi_shutdown()`.
- Record 5.2: caller is PCI driver `.shutdown = pqi_shutdown`; this is
  reached from PCI/device shutdown during reboot/poweroff paths.
- Record 5.3: relevant callees are `pqi_wait_until_ofa_finished()`,
  `pqi_scsi_block_requests()`, `pqi_ctrl_block_device_reset()`,
  `pqi_ctrl_block_requests()`, `pqi_ctrl_wait_until_quiesced()`,
  `pqi_flush_cache()`, `pqi_crash_if_pending_command()`, `pqi_reset()`,
  and now `pqi_ctrl_unblock_device_reset()`.
- Record 5.4: verified external call trace reaches `pqi_shutdown()` from
  reboot. Trigger requires multiple smartpqi controllers and a
  debug/lockdep kernel.
- Record 5.5: similar lock/unlock pairing exists in OFA and
  suspend/resume paths; shutdown was the unmatched case.

Phase 6:
- Record 6.1: verified `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.16`, and
  `v6.19` have mutex-based block/unblock helpers and shutdown lacks the
  final unblock. Verified `v5.10` does not have the mutex helper.
- Record 6.2: expected backport difficulty is clean or trivial for
  v5.15+ style trees because the exact helper and shutdown context
  exist. v5.10 is not applicable as-is.
- Record 6.3: no related fix already present in the checked local tree;
  `lun_reset_key` proposal is absent.

Phase 7:
- Record 7.1: subsystem is SCSI storage driver, `smartpqi`; criticality
  is driver-specific but storage-related.
- Record 7.2: subsystem is active; recent history shows ongoing fixes,
  device IDs, and driver updates.

Phase 8:
- Record 8.1: affected users are systems with Microchip/Microsemi
  SmartPQI controllers, especially multiple controllers with
  debug/lockdep kernels.
- Record 8.2: trigger is shutdown/reboot. The verified external trace
  shows reboot path; unprivileged triggerability was not verified.
- Record 8.3: failure mode is lockdep warning/lock imbalance, severity
  medium-low in production terms but valid for debug-kernel correctness.
- Record 8.4: benefit is moderate for affected systems and CI/debug
  kernels; risk is very low because this is one line using an existing
  helper after a matching lock.

Phase 9:
- Record 9.1: evidence for backporting: real lock imbalance,
  reproducible lockdep warning, one-line fix, maintainer ack, existing
  helper, verified affected stable baselines v5.15+. Evidence against:
  symptom is mainly debug warning, not crash/data corruption; v5.10 not
  applicable as-is.
- Record 9.2: stable rules: obviously correct yes; fixes a real bug yes;
  important issue borderline but acceptable due lockdep warning and tiny
  risk; small/contained yes; no new features/APIs yes; applies to v5.15+
  style trees likely clean/trivial.
- Record 9.3: no exception category applies.
- Record 9.4: risk-benefit favors backporting for applicable stable
  trees.

## Verification
- Phase 1: Parsed supplied commit message and `b4 am` output; confirmed
  tags and absence of `Fixes:`/stable/Reported-by.
- Phase 2: Read `smartpqi_init.c`; confirmed
  `pqi_ctrl_block_device_reset()` is `mutex_lock()` and
  `pqi_ctrl_unblock_device_reset()` is `mutex_unlock()`.
- Phase 3: Used `git blame`, `git show 0530736e40a069`, and `git show
  9fa8202336096d`; confirmed helper semantics changed to mutex model in
  the shutdown/suspend update.
- Phase 4: `WebFetch` to `patch.msgid.link` was blocked by Anubis; `b4
  mbox`/`b4 am` fetched the lore thread successfully. `b4 am` reported
  the patch applies cleanly to current tree.
- Phase 4: Read lore mirror; confirmed Bart’s “patch looks fine”
  comment, Tomas’s risk discussion, Don Brace’s ack, and Martin
  Petersen’s apply notice.
- Phase 5: Used exact searches and file reads to trace `.shutdown =
  pqi_shutdown`, SCSI reset handlers, and related lock users.
- Phase 6: Used version tags to verify affected code in `v5.15+` and
  non-applicability to `v5.10`.
- Phase 7: Checked `MAINTAINERS`; confirmed Don Brace maintains
  smartpqi.
- Phase 8: External LKML mirror provided the concrete lockdep call trace
  and trigger conditions.
- Unverified: I did not build-test the patch and did not verify stable
  branch-specific conflicts beyond version-tag code presence.

**YES**

 drivers/scsi/smartpqi/smartpqi_init.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/smartpqi/smartpqi_init.c b/drivers/scsi/smartpqi/smartpqi_init.c
index b4ed991976d06..2026ac645d6ab 100644
--- a/drivers/scsi/smartpqi/smartpqi_init.c
+++ b/drivers/scsi/smartpqi/smartpqi_init.c
@@ -9427,6 +9427,7 @@ static void pqi_shutdown(struct pci_dev *pci_dev)
 
 	pqi_crash_if_pending_command(ctrl_info);
 	pqi_reset(ctrl_info);
+	pqi_ctrl_unblock_device_reset(ctrl_info);
 }
 
 static void pqi_process_lockup_action_param(void)
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] powerpc/pseries/htmdump: Free the global buffers in htmdump module exit

[Sasha Levin]

From: Athira Rajeev <atrajeev@linux.ibm.com>

[ Upstream commit 54d54f33813d7911555226b4220737177a2ba8d6 ]

htmdump modules uses global memory buffers to capture
details like capabilities, status of specified HTM, read the
trace buffer. These are initialized during module init and
hence needs to be freed in module exit.

Patch adds freeing of the memory in module exit. The change
also includes minor clean up for the variable name. The
read call back for the debugfs interface file saves filp->private_data
to local variable name which is same as global variable
name for the memory buffers. Rename these local variable
names.

Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260314132432.25581-1-atrajeev@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Summary
This commit fixes a real resource leak in
`arch/powerpc/platforms/pseries/htmdump.c`: `htm_status_buf`,
`htm_info_buf`, and `htm_caps_buf` are each allocated with
`kmalloc(PAGE_SIZE, GFP_KERNEL)` during module/debugfs initialization,
but only `htm_buf` is freed in `htmdump_exit()`. The patch adds the
three missing `kfree()` calls. The local-variable renames are cleanup
and are also used by the following two patches in the same posted
series.

The benefit is modest because the leak is on module unload, not a hot
path, and the feature is PowerPC pseries/debugfs-specific. But it is a
real leak in a `default m` module, the fix is trivial, isolated, and low
risk. For stable trees that contain the v6.16-era `htmstatus`,
`htminfo`, and `htmcaps` additions, this is suitable.

## Phase Walkthrough
### Phase 1: Commit Message Forensics
Record 1.1: Subsystem is `powerpc/pseries/htmdump`; action verb is
`Free`; claimed intent is freeing global HTM debugfs buffers during
module exit.

Record 1.2: Tags in the supplied commit message: `Signed-off-by: Athira
Rajeev <atrajeev@linux.ibm.com>`, `Signed-off-by: Madhavan Srinivasan
<maddy@linux.ibm.com>`, `Link:
https://patch.msgid.link/20260314132432.25581-1-atrajeev@linux.ibm.com`.
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`,
or `Cc: stable@vger.kernel.org` tag was present in this commit.

Record 1.3: The body describes global memory buffers initialized in
module init and not freed in module exit. The user-visible symptom is
unreclaimed kernel memory after unloading the module. No crash, stack
trace, reporter, affected-version statement, or reproducer is given.

Record 1.4: This is a hidden cleanup-style bug fix: the functional
change is missing resource release on module exit.

### Phase 2: Diff Analysis
Record 2.1: One file changed:
`arch/powerpc/platforms/pseries/htmdump.c`, 17 insertions and 14
deletions in the posted patch. Modified functions are `htmdump_read()`,
`htmstatus_read()`, `htminfo_read()`, `htmcaps_read()`, and
`htmdump_exit()`. Scope is single-file surgical.

Record 2.2: The read-callback hunks rename local variables from names
shadowing globals to `*_data`; behavior is unchanged. The exit hunk
changes `htmdump_exit()` from freeing only `htm_buf` to freeing
`htm_buf`, `htm_status_buf`, `htm_info_buf`, and `htm_caps_buf`.

Record 2.3: Bug category is resource leak. Verified allocations are
three `PAGE_SIZE` buffers for status/info/caps in
`htmdump_init_debugfs()` without corresponding frees before this patch.

Record 2.4: Fix quality is high: `kfree(NULL)` is safe, the buffers are
global module-owned allocations, and debugfs removal already happens
before freeing. Regression risk is very low. The only non-functional
churn is local-variable rename.

### Phase 3: Git History Investigation
Record 3.1: `git blame` on the current stable checkout points the
relevant lines at the repository boundary merge `f3f5edc5e41e0`, so I
followed explicit commit objects. `htm_status_buf` was added by
`627cf584f4c3`, `htm_info_buf` by `dea7384e14e7`, and `htm_caps_buf` by
`143a2584627c`, all described by `git describe --contains`/history as
v6.16-rc1-era commits.

Record 3.2: Candidate has no `Fixes:` tag, so no direct Fixes target
applies. Related series patches 2/3 and 3/3 have `Fixes:` tags for
`dea7384e14e7` and `627cf584f4c3`, but this patch does not depend on
those fixes.

Record 3.3: Recent `htmdump` history shows the v6.16 additions for
status/info/setup/flags/caps and a header include fix. The candidate is
patch 1/3 in a series; patch 1 is standalone, while patches 2/3 and 3/3
textually build on its variable renames.

Record 3.4: Author Athira Rajeev authored the original htmdump expansion
commits; Madhavan Srinivasan committed them. This was verified from `git
show` for the status/info/caps commits.

Record 3.5: No prerequisite is needed for patch 1 beyond the buffers
existing. An isolated `git apply --check` of patch 1 succeeds on the
current 7.0 stable checkout.

### Phase 4: Mailing List And External Research
Record 4.1: `b4 dig` could not be meaningfully run because the candidate
commit object/hash is not present in the checked-out refs; `b4 dig -h`
confirmed it requires `-c <commitish>`. I used `b4 mbox -c` with
message-id `20260314132432.25581-1-atrajeev@linux.ibm.com`; it fetched a
3-message thread and reported no newer revision.

Record 4.2: Original recipients from the mbox were
`maddy@linux.ibm.com`, `linuxppc-dev@lists.ozlabs.org`, and CCs
including `hbathini`, `sshegde`, and IBM HTM-related recipients. No
review replies, NAKs, or stable nominations were present in the fetched
mbox.

Record 4.3: No `Reported-by` or bug-report link exists for this
candidate. `WebFetch` to lore/patch.msgid was blocked by Anubis, but `b4
mbox` successfully fetched the thread.

Record 4.4: The patch is part of a 3-patch series. Patch 1 fixes exit
cleanup; patch 2 fixes `htminfo_read()` offset handling; patch 3 fixes
`htmstatus_read()` offset handling. Patch 1 can apply standalone, and
later patches depend textually on its renames.

Record 4.5: Stable-specific lore WebFetch was blocked by Anubis.
WebSearch for the exact subject and stable context found no specific
stable discussion. Local `git log --grep` checks of `v6.18`, `v6.19`,
`v7.0`, and `linux-rolling-stable` found no exact-subject match.

### Phase 5: Code Semantic Analysis
Record 5.1: Modified functions are `htmdump_read()`, `htmstatus_read()`,
`htminfo_read()`, `htmcaps_read()`, and `htmdump_exit()`.

Record 5.2: Callers/entry points are verified through file operations
and module macros: `htmdump_exit()` is registered with `module_exit()`,
reads are reached through debugfs files created by
`debugfs_create_file()` with the corresponding fops.

Record 5.3: Key callees are `debugfs_remove_recursive()`, `kfree()`,
`htm_hcall_wrapper()`, `virt_to_phys()`, and
`simple_read_from_buffer()`. The functional fix only adds `kfree()`
calls in exit.

Record 5.4: Reachability is module lifecycle and debugfs based. The leak
triggers on module unload after successful allocation of the
status/info/caps buffers. Unprivileged triggering was not verified and
is not relied on; Kconfig shows `HTMDUMP` is `tristate`, `default m`,
and depends on `PPC_PSERIES && DEBUG_FS`.

Record 5.5: Similar pattern found: `htm_buf` was already freed in
`htmdump_exit()`, while the three later-added global buffers were not.

### Phase 6: Stable Tree Analysis
Record 6.1: `v6.15` has `htmdump.c` with only `htm_buf`; `v6.16`,
`v6.17`, `v6.18`, `v6.19`, and `v7.0` have the three additional buffers
and only free `htm_buf`. So the bug affects stable trees containing the
v6.16 htmdump expansions, not older trees lacking those buffers.

Record 6.2: Backport difficulty is low for affected trees. The patch’s
base blob matches `v6.16`/`v6.17`/current 7.0 content for the relevant
file, and isolated patch 1 applies cleanly to the current checkout.

Record 6.3: No exact-subject related fix was found in checked `v6.18`,
`v6.19`, `v7.0`, or `linux-rolling-stable`.

### Phase 7: Subsystem And Maintainer Context
Record 7.1: Subsystem is PowerPC pseries platform driver/debugfs
support. Criticality is peripheral/platform-specific, not core kernel-
wide.

Record 7.2: `git log -20 v7.0 -- arch/powerpc/platforms/pseries` shows
active pseries development, but this particular fix is contained to
`htmdump.c`.

### Phase 8: Impact And Risk
Record 8.1: Affected users are PowerPC pseries users with
`CONFIG_HTMDUMP` enabled, primarily using the debugfs HTM dump module.

Record 8.2: Trigger is successful module initialization followed by
module exit/unload. Repeated load/unload can accumulate unreclaimed
pages until reboot. This is not verified as unprivileged-triggerable.

Record 8.3: Failure mode is kernel memory/resource leak, three
`PAGE_SIZE` allocations per unload for the later buffers. Severity is
medium: real and persistent until reboot, but not a crash/security/data-
corruption fix and not a hot path.

Record 8.4: Benefit is moderate for affected stable users; risk is very
low because the functional change is only three `kfree()` calls after
debugfs removal.

### Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: real resource leak, affects stable
trees v6.16 and newer that contain the expanded htmdump module, fix is
tiny and obviously correct, isolated patch applies cleanly. Evidence
against: peripheral platform-specific module, leak occurs on module
unload rather than common runtime path, no reporter/testing/stable tags
in this patch. Unresolved: no full lore review discussion was available
beyond the 3-patch mbox; direct WebFetch lore pages were blocked.

Record 9.2: Stable rules checklist: obviously correct yes; fixes a real
bug yes; important enough is borderline but acceptable as a real
resource leak with very low regression risk; small and contained yes; no
new feature/API yes; applies to affected stable trees yes for current
7.0 and likely cleanly where file matches v6.16+.

Record 9.3: No automatic exception category applies: this is not a
device ID, quirk, DT update, build fix, or documentation-only fix.

Record 9.4: Decision is YES for stable trees that contain
`htm_status_buf`, `htm_info_buf`, and `htm_caps_buf`.

## Verification
- Phase 1: Parsed supplied commit message and b4-fetched patch 1;
  confirmed no `Fixes:`, `Reported-by`, `Tested-by`, review, or stable
  tag in patch 1.
- Phase 2: Read `arch/powerpc/platforms/pseries/htmdump.c`; confirmed
  allocations and missing frees; inspected patch hunks from
  `/tmp/htmdump-20260314.mbx`.
- Phase 3: Ran `git blame -L 410,485`; followed explicit commits
  `627cf584f4c3`, `dea7384e14e7`, and `143a2584627c` with `git show`;
  checked author/subsystem history.
- Phase 4: `b4 mbox -c` fetched the 3-message thread; direct `WebFetch`
  lore URLs were blocked; WebSearch found no exact stable discussion.
- Phase 5: Used `rg`, `ReadFile`, and Kconfig/Makefile/docs to verify
  module/debugfs reachability and `CONFIG_HTMDUMP` as `tristate`,
  `default m`.
- Phase 6: Checked `v6.15`, `v6.16`, `v6.17`, `v6.18`, `v6.19`, and
  `v7.0` file contents; isolated patch 1 passed `git apply --check`.
- Phase 8: Verified failure mode from concrete `kmalloc(PAGE_SIZE)`
  allocations and missing matching `kfree()` calls.
- Unverified: whether every downstream stable branch has identical
  context; direct stable-list lore search was blocked by Anubis.

**YES**

 arch/powerpc/platforms/pseries/htmdump.c | 31 +++++++++++++-----------
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/htmdump.c b/arch/powerpc/platforms/pseries/htmdump.c
index 742ec52c9d4df..93f0cc2dc7fb6 100644
--- a/arch/powerpc/platforms/pseries/htmdump.c
+++ b/arch/powerpc/platforms/pseries/htmdump.c
@@ -86,7 +86,7 @@ static ssize_t htm_return_check(long rc)
 static ssize_t htmdump_read(struct file *filp, char __user *ubuf,
 			     size_t count, loff_t *ppos)
 {
-	void *htm_buf = filp->private_data;
+	void *htm_buf_data = filp->private_data;
 	unsigned long page, read_size, available;
 	loff_t offset;
 	long rc, ret;
@@ -100,7 +100,7 @@ static ssize_t htmdump_read(struct file *filp, char __user *ubuf,
 	 * - last three values are address, size and offset
 	 */
 	rc = htm_hcall_wrapper(htmflags, nodeindex, nodalchipindex, coreindexonchip,
-				   htmtype, H_HTM_OP_DUMP_DATA, virt_to_phys(htm_buf),
+				   htmtype, H_HTM_OP_DUMP_DATA, virt_to_phys(htm_buf_data),
 				   PAGE_SIZE, page);
 
 	ret = htm_return_check(rc);
@@ -112,7 +112,7 @@ static ssize_t htmdump_read(struct file *filp, char __user *ubuf,
 	available = PAGE_SIZE;
 	read_size = min(count, available);
 	*ppos += read_size;
-	return simple_read_from_buffer(ubuf, count, &offset, htm_buf, available);
+	return simple_read_from_buffer(ubuf, count, &offset, htm_buf_data, available);
 }
 
 static const struct file_operations htmdump_fops = {
@@ -226,7 +226,7 @@ static int htmstart_get(void *data, u64 *val)
 static ssize_t htmstatus_read(struct file *filp, char __user *ubuf,
 			     size_t count, loff_t *ppos)
 {
-	void *htm_status_buf = filp->private_data;
+	void *htm_status_data = filp->private_data;
 	long rc, ret;
 	u64 *num_entries;
 	u64 to_copy;
@@ -238,7 +238,7 @@ static ssize_t htmstatus_read(struct file *filp, char __user *ubuf,
 	 * - last three values as addr, size and offset
 	 */
 	rc = htm_hcall_wrapper(htmflags, nodeindex, nodalchipindex, coreindexonchip,
-				   htmtype, H_HTM_OP_STATUS, virt_to_phys(htm_status_buf),
+				   htmtype, H_HTM_OP_STATUS, virt_to_phys(htm_status_data),
 				   PAGE_SIZE, 0);
 
 	ret = htm_return_check(rc);
@@ -255,13 +255,13 @@ static ssize_t htmstatus_read(struct file *filp, char __user *ubuf,
 	 * So total count to copy is:
 	 * 32 bytes (for first 7 fields) + (number of HTM entries * entry size)
 	 */
-	num_entries = htm_status_buf + 0x10;
+	num_entries = htm_status_data + 0x10;
 	if (htmtype == 0x2)
 		htmstatus_flag = 0x8;
 	else
 		htmstatus_flag = 0x6;
 	to_copy = 32 + (be64_to_cpu(*num_entries) * htmstatus_flag);
-	return simple_read_from_buffer(ubuf, count, ppos, htm_status_buf, to_copy);
+	return simple_read_from_buffer(ubuf, count, ppos, htm_status_data, to_copy);
 }
 
 static const struct file_operations htmstatus_fops = {
@@ -273,7 +273,7 @@ static const struct file_operations htmstatus_fops = {
 static ssize_t htminfo_read(struct file *filp, char __user *ubuf,
 			     size_t count, loff_t *ppos)
 {
-	void *htm_info_buf = filp->private_data;
+	void *htm_info_data = filp->private_data;
 	long rc, ret;
 	u64 *num_entries;
 	u64 to_copy;
@@ -284,7 +284,7 @@ static ssize_t htminfo_read(struct file *filp, char __user *ubuf,
 	 * - last three values as addr, size and offset
 	 */
 	rc = htm_hcall_wrapper(htmflags, nodeindex, nodalchipindex, coreindexonchip,
-				   htmtype, H_HTM_OP_DUMP_SYSPROC_CONF, virt_to_phys(htm_info_buf),
+				   htmtype, H_HTM_OP_DUMP_SYSPROC_CONF, virt_to_phys(htm_info_data),
 				   PAGE_SIZE, 0);
 
 	ret = htm_return_check(rc);
@@ -301,15 +301,15 @@ static ssize_t htminfo_read(struct file *filp, char __user *ubuf,
 	 * So total count to copy is:
 	 * 32 bytes (for first 5 fields) + (number of HTM entries * entry size)
 	 */
-	num_entries = htm_info_buf + 0x10;
+	num_entries = htm_info_data + 0x10;
 	to_copy = 32 + (be64_to_cpu(*num_entries) * 16);
-	return simple_read_from_buffer(ubuf, count, ppos, htm_info_buf, to_copy);
+	return simple_read_from_buffer(ubuf, count, ppos, htm_info_data, to_copy);
 }
 
 static ssize_t htmcaps_read(struct file *filp, char __user *ubuf,
 			     size_t count, loff_t *ppos)
 {
-	void *htm_caps_buf = filp->private_data;
+	void *htm_caps_data = filp->private_data;
 	long rc, ret;
 
 	/*
@@ -319,7 +319,7 @@ static ssize_t htmcaps_read(struct file *filp, char __user *ubuf,
 	 *   and zero
 	 */
 	rc = htm_hcall_wrapper(htmflags, nodeindex, nodalchipindex, coreindexonchip,
-				   htmtype, H_HTM_OP_CAPABILITIES, virt_to_phys(htm_caps_buf),
+				   htmtype, H_HTM_OP_CAPABILITIES, virt_to_phys(htm_caps_data),
 				   0x80, 0);
 
 	ret = htm_return_check(rc);
@@ -328,7 +328,7 @@ static ssize_t htmcaps_read(struct file *filp, char __user *ubuf,
 		return ret;
 	}
 
-	return simple_read_from_buffer(ubuf, count, ppos, htm_caps_buf, 0x80);
+	return simple_read_from_buffer(ubuf, count, ppos, htm_caps_data, 0x80);
 }
 
 static const struct file_operations htminfo_fops = {
@@ -482,6 +482,9 @@ static void __exit htmdump_exit(void)
 {
 	debugfs_remove_recursive(htmdump_debugfs_dir);
 	kfree(htm_buf);
+	kfree(htm_status_buf);
+	kfree(htm_info_buf);
+	kfree(htm_caps_buf);
 }
 
 module_init(htmdump_init);
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] i2c: acpi: Add ELAN0678 to i2c_acpi_force_100khz_device_ids

[Sasha Levin]

From: Niels Franke <nielsfranke@gmail.com>

[ Upstream commit 9998e388be9930c106eb5904c23ecf2162407527 ]

The ELAN0678 touchpad (04F3:3195) found in the Lenovo ThinkPad X13
exhibits excessive smoothing when the I2C bus runs at 400KHz, making
the touchpad feel sluggish when plugged into AC power. This is the
same issue previously fixed for ELAN06FA.

The device's ACPI table (Lenovo TP-R22) specifies 0x00061A80 (400KHz)
for the I2cSerialBusV2 descriptor. Forcing the bus to 100KHz eliminates
the sluggish behavior.

Signed-off-by: Niels Franke <nielsfranke@gmail.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
[wsa: kept the sorting]
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

Step 1.1 - Subject:
Record: Subsystem `i2c: acpi`; action verb `Add`; intent is to add ACPI
HID `ELAN0678` to the existing 100 kHz forced-speed quirk table.

Step 1.2 - Tags:
Record: `Signed-off-by: Niels Franke <nielsfranke@gmail.com>`; `Acked-
by: Mika Westerberg <mika.westerberg@linux.intel.com>`; maintainer note
`[wsa: kept the sorting]`; `Signed-off-by: Wolfram Sang
<wsa+renesas@sang-engineering.com>`. No `Fixes:`, `Reported-by:`,
`Tested-by:`, `Link:`, or `Cc: stable@vger.kernel.org` tags.

Step 1.3 - Body:
Record: The bug is real hardware misbehavior: ELAN0678 touchpad
`04F3:3195` on Lenovo ThinkPad X13 becomes sluggish/excessively smoothed
when ACPI-described I2C speed is 400 kHz. The commit says forcing 100
kHz eliminates it. Root cause is a bad/not-working speed choice for this
device, matching the earlier ELAN06FA workaround.

Step 1.4 - Hidden bug fix:
Record: Yes. Although phrased as “Add”, this is a hardware
workaround/quirk for a user-visible input-device malfunction, not new
feature work.

## Phase 2: Diff Analysis

Step 2.1 - Inventory:
Record: One file changed: `drivers/i2c/i2c-core-acpi.c`, `+1/-0`. It
adds `{ "ELAN0678", 0 }` to `i2c_acpi_force_100khz_device_ids`. Scope is
a single-file, one-line hardware quirk.

Step 2.2 - Code flow:
Record: Before, ELAN0678 used the normal ACPI/min-speed path and could
run at the 400 kHz speed from firmware. After, when
`i2c_acpi_lookup_speed()` sees an ACPI device matching `ELAN0678`, it
sets `lookup->force_speed = I2C_MAX_STANDARD_MODE_FREQ`, causing
`i2c_acpi_find_bus_speed()` to return 100 kHz.

Step 2.3 - Bug mechanism:
Record: Hardware workaround. The broken condition is a known-not-working
I2C bus speed for a specific ACPI HID. The fix reuses the existing
forced-100-kHz mechanism.

Step 2.4 - Fix quality:
Record: Obviously correct and minimal. It only affects machines exposing
ACPI HID `ELAN0678`. Regression risk is very low: affected devices will
run slower I2C, intentionally matching the verified workaround; all
other devices are unchanged.

## Phase 3: Git History

Step 3.1 - Blame:
Record: `git blame` on `origin/master` shows the new line is commit
`9998e388be993`; the 100 kHz table and `ELAN06FA` handling came from
`bfd74cd1fbc026`, first contained around `v6.14-rc1`; `DLL0945` came
from `0b7c9528facdb5`, first contained around `v6.17-rc1`.

Step 3.2 - Fixes tag:
Record: Not applicable; no `Fixes:` tag is present.

Step 3.3 - File history:
Record: Recent file history shows related quirks `ELAN06FA` and
`DLL0945`, plus unrelated treewide allocation conversions. No
prerequisite structural change is needed where the 100 kHz table already
exists.

Step 3.4 - Author context:
Record: Local history shows Niels Franke has this one I2C commit on
`origin/master`. The patch was acked by Mika Westerberg, listed in
`MAINTAINERS` as I2C ACPI maintainer, and committed by Wolfram Sang.

Step 3.5 - Dependencies:
Record: Standalone for stable branches that already have
`i2c_acpi_force_100khz_device_ids`. For branches lacking the table, it
depends on the earlier ELAN06FA forced-100-kHz infrastructure.

## Phase 4: Mailing List And External Research

Step 4.1 - Original discussion:
Record: `b4 dig -c 9998e388be993` found the original submission at
`https://patch.msgid.link/20260418053719.15766-1-nielsfranke@gmail.com`.
The mirror thread shows v1 only, Mika Westerberg acked it, and Wolfram
Sang applied it to `for-current` while keeping sort order. No objections
or NAKs found.

Step 4.2 - Reviewers/recipients:
Record: `b4 dig -w` shows recipients included Niels Franke,
`westeri@kernel.org`, Wolfram Sang, `linux-i2c`, `linux-acpi`, and
`linux-kernel`. This reached the relevant I2C ACPI maintainer and lists.

Step 4.3 - Bug report:
Record: No separate `Reported-by` or bug tracker link in the commit. The
commit message itself documents affected hardware, ACPI table speed, and
the tested workaround. Web search also found unrelated ELAN0678 user
reports, but I did not rely on those for the final decision.

Step 4.4 - Series context:
Record: `b4 dig -a` shows a single v1 patch, not a multi-patch series.

Step 4.5 - Stable discussion:
Record: Direct lore stable fetch was blocked by Anubis; web search found
no specific stable-list discussion for ELAN0678. Stable branch git logs
sampled do not yet contain ELAN0678.

## Phase 5: Code Semantic Analysis

Step 5.1 - Key functions:
Record: The diff changes only the ACPI ID table, but behavior flows
through `i2c_acpi_lookup_speed()` and `i2c_acpi_find_bus_speed()`.

Step 5.2 - Callers:
Record: `i2c_acpi_find_bus_speed()` is called by multiple I2C bus
drivers, including DesignWare, USBIO, SynQuacer, LS2X, Zhaoxin, and AMD
MP2. For DesignWare, `dw_i2c_plat_probe()` and PCI probe paths call
`i2c_dw_fw_parse_and_configure()`, which calls the ACPI speed lookup
during controller setup.

Step 5.3 - Callees:
Record: The relevant code calls `acpi_walk_namespace()`,
`i2c_acpi_do_lookup()`, and `acpi_match_device_ids()`; if matched, it
returns the forced speed to bus-driver timing configuration.

Step 5.4 - Reachability:
Record: Reachable during I2C adapter/controller initialization on ACPI
systems. On affected Lenovo hardware, this path controls the bus speed
used for the touchpad.

Step 5.5 - Similar patterns:
Record: Verified sibling quirks `ELAN06FA` and `DLL0945` in the same
table, both addressing touchpad sluggishness at higher I2C speed.

## Phase 6: Stable Tree Analysis

Step 6.1 - Buggy code in stable:
Record: Sampled stable branches `5.10.y`, `5.15.y`, `6.6.y`, `6.12.y`,
`6.15.y` through `7.0.y` already contain the 100 kHz quirk table with
`ELAN06FA`/`DLL0945`, but not `ELAN0678`. `5.4.y` has ACPI speed lookup
but not the forced-100-kHz table in the sampled state.

Step 6.2 - Backport difficulty:
Record: Clean or trivial for branches with both `DLL0945` and `ELAN06FA`
adjacent. Branches lacking `DLL0945` or the table may need a trivial
context adjustment or dependency backport.

Step 6.3 - Related fixes already stable:
Record: Stable branches sampled already carry related ELAN06FA/DLL0945
quirks, but no ELAN0678 equivalent.

## Phase 7: Subsystem Context

Step 7.1 - Subsystem:
Record: `drivers/i2c/i2c-core-acpi.c`, I2C ACPI support. Criticality is
important for affected ACPI laptop hardware, but not universal/core.

Step 7.2 - Activity:
Record: File history shows active maintenance and recent hardware quirk
additions. The patch was accepted through the I2C maintainer path.

## Phase 8: Impact And Risk

Step 8.1 - Affected users:
Record: Users of systems exposing the ELAN0678 ACPI touchpad,
specifically verified by commit message for Lenovo ThinkPad X13.

Step 8.2 - Trigger:
Record: Triggered when the I2C bus is configured at 400 kHz for this
device, including via the Lenovo TP-R22 ACPI `I2cSerialBusV2`
descriptor. This is normal boot/device setup, not an obscure manual
path.

Step 8.3 - Severity:
Record: Medium severity user-visible hardware malfunction: sluggish
touchpad/input behavior. Not a crash, security issue, or data
corruption.

Step 8.4 - Risk-benefit:
Record: Benefit is high for affected laptops because it restores usable
touchpad behavior. Risk is very low because it is a one-line ACPI HID-
specific quirk using existing logic.

## Phase 9: Final Synthesis

Step 9.1 - Evidence:
Record: For backporting: real hardware bug, existing quirk mechanism,
one-line scoped change, maintainer ack, accepted by I2C maintainer,
stable branches already carry analogous quirks. Against backporting: no
explicit stable tag, no separate bug report link, not a critical
crash/security fix. Unresolved: exact applicability to every older
stable branch; `5.4.y` would need more than this one-line context.

Step 9.2 - Stable rules:
Record: Obviously correct: yes. Tested: commit states forcing 100 kHz
eliminates the issue, though no `Tested-by` tag. Real bug: yes, touchpad
sluggishness. Important enough: yes under hardware quirk/workaround
practice. Small/contained: yes, one line. No new APIs/features: yes.
Applies to stable: yes for branches with the existing table; trivial
adjustment/dependency for older divergent branches.

Step 9.3 - Exception:
Record: This falls squarely under the stable hardware quirk/workaround
exception.

Step 9.4 - Decision:
Record: Backport. The risk is tiny and the fix is exactly the sort of
targeted hardware workaround stable trees routinely carry.

## Verification

- Phase 1: Parsed `git show --format=fuller --stat --patch
  9998e388be993`; confirmed subject, body, tags, and one-line diff.
- Phase 2: Read `drivers/i2c/i2c-core-acpi.c`; confirmed
  `i2c_acpi_force_100khz_device_ids` is checked by
  `i2c_acpi_lookup_speed()` and returns 100 kHz through
  `i2c_acpi_find_bus_speed()`.
- Phase 3: Ran `git blame` on the relevant lines; confirmed commits for
  `ELAN06FA`, `DLL0945`, and `ELAN0678`.
- Phase 3: Ran `git describe --contains`; confirmed first-containing
  release positions for related mainline commits.
- Phase 4: Ran `b4 dig -c`, `b4 dig -a`, and `b4 dig -w`; found original
  v1 submission, no later revisions, and relevant recipients.
- Phase 4: Fetched the public mirror thread; confirmed Mika Westerberg’s
  ack and Wolfram Sang’s application note.
- Phase 5: Used semantic search, `rg`, and file reads; confirmed
  DesignWare and other I2C bus drivers call `i2c_acpi_find_bus_speed()`.
- Phase 6: Used `git grep` and stable branch logs; confirmed sampled
  stable branches contain related forced-speed quirks but not ELAN0678.
- Phase 8: Failure mode is verified from the commit message and lore
  thread: sluggish/excessively smoothed touchpad at 400 kHz, fixed by
  100 kHz.
- UNVERIFIED: Direct `lore.kernel.org/stable` content was blocked by
  Anubis, so I could not independently inspect stable-list discussion
  there.

**YES**

 drivers/i2c/i2c-core-acpi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c
index 2cbd31f77667a..28c0e4884a7f2 100644
--- a/drivers/i2c/i2c-core-acpi.c
+++ b/drivers/i2c/i2c-core-acpi.c
@@ -371,6 +371,7 @@ static const struct acpi_device_id i2c_acpi_force_100khz_device_ids[] = {
 	 * a 400KHz frequency. The root cause of the issue is not known.
 	 */
 	{ "DLL0945", 0 },
+	{ "ELAN0678", 0 },
 	{ "ELAN06FA", 0 },
 	{}
 };
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] iommu/amd: Use maximum Event log buffer size when SNP is enabled on Family 0x19

[Sasha Levin]

From: Vasant Hegde <vasant.hegde@amd.com>

[ Upstream commit 58c0ac6125d89bf6ec65a521eaeb52a0e8e20a9f ]

Due to CVE-2023-20585, the Event log buffer must use the maximum supported
size (512K) on Milan/Genoa (Family 0x19) systems when SNP is enabled,
to mitigate a potential security vulnerability. All other systems continue to
use the default Event log buffer size (8K).

Apply the errata fix by making the following changes:

* Introduce new global variable (amd_iommu_evtlog_size) to have event log
  buffer size. Adjust variable size for family 0x19.

* Since 'iommu_snp_enable()' must be called after the core IOMMU subsystem
  is initialized, it cannot be moved to the early init stage. The SNP errata
  must also be applied after the 'iommu_snp_enable()' check. Therefore,
  'alloc_event_buffer()' and 'iommu_enable_event_buffer()' are now called
  in the IOMMU_ENABLED state, after the errata is applied.

* Adjust alloc_event_buffer() and iommu_enable_event_buffer() to handle
  all IOMMU instances.

* Also rename EVT_* macros to make it more readable.

Link: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3016.html
Cc: Borislav Petkov <bp@alien8.de>
Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Cc: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
Tested-by: Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Conclusion
This commit should be backported to stable trees that carry AMD IOMMU
SNP host support. It is a security mitigation for `CVE-2023-20585`,
scoped to AMD Family `0x19` systems with SNP enabled, and it keeps all
other systems on the existing 8K event log size.

The patch is not feature enablement in the stable sense; it is a
hardware erratum/security workaround. The main concern is backport
mechanics: it applies cleanly to `stable/linux-7.0.y`, but failed a
direct apply check on `6.12.y`, `6.18.y`, and `6.19.y`, so those need
backport adjustment. For Genoa, the companion PPR-log patch should also
be considered for the full series mitigation.

## Phase Walkthrough
Phase 1 Record:
- Subject subsystem/action: `iommu/amd`, action is “Use maximum”, intent
  is to use a 512K AMD IOMMU event log buffer for SNP on Family `0x19`.
- Tags: `Link` to AMD-SB-3016, `Cc` to AMD/IOMMU maintainers, `Signed-
  off-by` Vasant Hegde, `Tested-by` Dheeraj Kumar Srivastava, `Signed-
  off-by` Joerg Roedel. No `Fixes:` tag.
- Body: describes `CVE-2023-20585`, requiring max supported event log
  buffer size on Milan/Genoa with SNP enabled; all other systems remain
  at 8K.
- Hidden bug fix: yes. This is phrased partly as buffer
  sizing/refactoring, but the purpose is a CVE security mitigation.

Phase 2 Record:
- Files changed: `drivers/iommu/amd/amd_iommu.h`, `amd_iommu_types.h`,
  `init.c`, `iommu.c`; fetched commit stat is 86 insertions, 38
  deletions.
- Functions modified/added: `alloc_event_buffer`,
  `iommu_enable_event_buffer`, `remap_event_buffer`,
  `early_enable_iommu`, `early_enable_iommus`, `amd_iommu_resume`, new
  `amd_iommu_apply_erratum_snp`, `state_next`, `amd_iommu_snp_disable`,
  `iommu_poll_events`.
- Code flow: event buffer allocation/enable moves from early per-IOMMU
  setup to after `iommu_snp_enable()`, allowing the erratum decision to
  set 512K before allocation/programming. Polling and SNP shutdown now
  use the variable size.
- Bug category: hardware security erratum/workaround.
- Fix quality: contained to AMD IOMMU event-log handling. Regression
  risk is medium-low because init ordering changes, but it is subsystem-
  contained, tested, and keeps non-SNP/non-Family-0x19 behavior at 8K.

Phase 3 Record:
- Blame/history: fixed 8K event buffer logic is long-standing; SNP
  integration relevant to the erratum is present from the v6.9 era and
  later. `6.12.y`, `6.18.y`, `6.19.y`, and `7.0.y` contain the
  integrated SNP enable commit checked locally; `5.15.y`, `6.1.y`, and
  `6.6.y` do not.
- `Fixes:` tag: none, so no direct original-bug commit to follow.
- Related file history: companion commit `1f44aab79bac3` does the same
  for the PPR log. Patch 2 depends conceptually/codewise on patch 1;
  patch 1 stands on its own for the event log.
- Author context: Vasant Hegde has multiple recent AMD IOMMU fixes in
  the fetched IOMMU fixes branch; Joerg Roedel committed the patch.
- Dependencies: no semantic dependency on the NUMA log-buffer allocation
  commit, but older stable branches have context differences requiring
  backport edits.

Phase 4 Record:
- `b4 dig -c 58c0ac6125d89`: found the original lore submission at `http
  s://patch.msgid.link/20260420084204.12263-2-vasant.hegde@amd.com`.
- `b4 dig -a`: only v1 found.
- `b4 dig -w`: original recipients included `iommu@lists.linux.dev`,
  Joerg Roedel, Will Deacon, Robin Murphy, Suravee Suthikulpanit, and
  Borislav Petkov.
- Lore thread: Dheeraj Kumar Srivastava replied `Tested-by`; Joerg
  Roedel replied “Applied to fixes”.
- AMD bulletin: AMD-SB-3016 confirms potential SNP guest integrity loss
  from an IOMMU host buffer out-of-bounds condition and says OS updates
  are required along with firmware.

Phase 5 Record:
- Callers: event interrupt path uses `amd_iommu_int_thread_evtlog()` ->
  `amd_iommu_handle_irq()` -> `iommu_poll_events()`. Interrupt setup is
  via AMD IOMMU MSI/INTCAPXT setup in `init.c`.
- Callees: allocation uses `iommu_alloc_4k_pages()`, which handles SNP
  4K page setup; enable writes `MMIO_EVT_BUF_OFFSET`, head/tail
  registers, and `CONTROL_EVT_LOG_EN`.
- Reachability: reachable on AMD IOMMU systems through hardware event
  interrupts and SNP init/shutdown paths, not through a direct userspace
  syscall.
- Similar pattern: companion PPR log patch in the same series mirrors
  the variable-size/max-buffer handling.

Phase 6 Record:
- Stable code existence: `6.12.y`, `6.18.y`, `6.19.y`, and `7.0.y` have
  the relevant AMD IOMMU SNP/event-log code. `5.15.y`, `6.1.y`, and
  `6.6.y` lack the integrated SNP enable commit I checked; `6.6.y` has
  an exported old SNP enable function but no in-tree caller was found.
- Backport difficulty: clean on `7.0.y`; direct apply failed on
  `6.12.y`, `6.18.y`, and `6.19.y`, so those need manual backporting.
- Related stable discussion: no stable-list-specific discussion for this
  CVE/patch was found by `lei`.

Phase 7 Record:
- Subsystem: AMD IOMMU driver under `drivers/iommu/amd`.
- Criticality: important platform/virtualization security code,
  affecting AMD EPYC SNP hosts rather than all systems.
- Activity: actively maintained; recent AMD IOMMU fixes and the
  maintainer-applied fixes branch confirm ongoing subsystem work.

Phase 8 Record:
- Affected users: AMD Family `0x19` Milan/Genoa systems with SNP
  enabled.
- Trigger/security conditions: AMD bulletin describes a privileged
  attacker with a compromised hypervisor triggering an out-of-bounds
  condition without RMP checks.
- Failure severity: security integrity impact for confidential SNP
  guests; AMD rates it Medium, but stable rules treat CVE/security
  mitigations as strong candidates.
- Benefit/risk: high benefit for affected SNP hosts; medium-low
  regression risk due to contained but non-trivial init-order and
  buffer-size changes.

Phase 9 Record:
- Evidence for: CVE/security mitigation, AMD bulletin requires OS
  update, tested-by, maintainer applied to fixes, scoped to AMD IOMMU,
  default behavior preserved for unaffected systems.
- Evidence against/concerns: patch is larger than a trivial one-liner,
  moves event buffer allocation/enable timing, and needs backport
  adjustments for several stable branches. Genoa full mitigation also
  needs the PPR companion patch.
- Stable rules: fixes a real security issue; important; no new userspace
  API; contained to one driver; tested; applies cleanly to `7.0.y` and
  can be backported with adjustments elsewhere.
- Exception category: hardware erratum/security workaround.

## Verification
- [Phase 1] Parsed fetched commit `58c0ac6125d89`: confirmed subject,
  tags, `Tested-by`, no `Fixes:`, and AMD-SB-3016 link.
- [Phase 2] Inspected diff/stat from fetched commit: 4 AMD IOMMU files,
  86 insertions, 38 deletions.
- [Phase 3] Ran `git blame` on event allocation, enable, SNP init, and
  polling paths; confirmed relevant code history.
- [Phase 3] Checked stable branch ancestry: `6.12.y+` contain integrated
  SNP enable; `5.15.y`, `6.1.y`, `6.6.y` do not.
- [Phase 4] Ran `b4 dig -c 58c0ac6125d89`, `-a`, and `-w`; found one v1
  submission, maintainers/recipients, and lore URL.
- [Phase 4] Fetched lore thread; confirmed `Tested-by` reply and
  maintainer “Applied to fixes”.
- [Phase 4] Fetched AMD bulletin; confirmed CVE impact and OS update
  requirement.
- [Phase 5] Traced event interrupt call path with source search/read:
  `amd_iommu_int_thread_evtlog()` to `iommu_poll_events()`.
- [Phase 6] Ran apply checks: clean on `stable/linux-7.0.y`; failed
  direct apply on `6.12.y`, `6.18.y`, and `6.19.y`.
- UNVERIFIED: I did not build-test the backport or test on AMD Family
  `0x19` SNP hardware.

**YES**

 drivers/iommu/amd/amd_iommu.h       |   2 +
 drivers/iommu/amd/amd_iommu_types.h |  10 ++-
 drivers/iommu/amd/init.c            | 110 +++++++++++++++++++---------
 drivers/iommu/amd/iommu.c           |   2 +-
 4 files changed, 86 insertions(+), 38 deletions(-)

diff --git a/drivers/iommu/amd/amd_iommu.h b/drivers/iommu/amd/amd_iommu.h
index 1342e764a5486..f1c486dcf0f38 100644
--- a/drivers/iommu/amd/amd_iommu.h
+++ b/drivers/iommu/amd/amd_iommu.h
@@ -11,6 +11,8 @@
 
 #include "amd_iommu_types.h"
 
+extern int amd_iommu_evtlog_size;
+
 irqreturn_t amd_iommu_int_thread(int irq, void *data);
 irqreturn_t amd_iommu_int_thread_evtlog(int irq, void *data);
 irqreturn_t amd_iommu_int_thread_pprlog(int irq, void *data);
diff --git a/drivers/iommu/amd/amd_iommu_types.h b/drivers/iommu/amd/amd_iommu_types.h
index c685d3771436a..c3430c09bc5c9 100644
--- a/drivers/iommu/amd/amd_iommu_types.h
+++ b/drivers/iommu/amd/amd_iommu_types.h
@@ -15,6 +15,7 @@
 #include <linux/mutex.h>
 #include <linux/msi.h>
 #include <linux/list.h>
+#include <linux/sizes.h>
 #include <linux/spinlock.h>
 #include <linux/pci.h>
 #include <linux/iommufd.h>
@@ -141,7 +142,6 @@
 #define MMIO_STATUS_GALOG_INT_MASK		BIT(10)
 
 /* event logging constants */
-#define EVENT_ENTRY_SIZE	0x10
 #define EVENT_TYPE_SHIFT	28
 #define EVENT_TYPE_MASK		0xf
 #define EVENT_TYPE_ILL_DEV	0x1
@@ -259,8 +259,12 @@
 #define MMIO_CMD_BUFFER_TAIL(x) FIELD_GET(MMIO_CMD_TAIL_MASK, (x))
 
 /* constants for event buffer handling */
-#define EVT_BUFFER_SIZE		8192 /* 512 entries */
-#define EVT_LEN_MASK		(0x9ULL << 56)
+#define EVTLOG_ENTRY_SIZE	0x10
+#define EVTLOG_SIZE_SHIFT	56
+#define EVTLOG_SIZE_DEF		SZ_8K /* 512 entries */
+#define EVTLOG_LEN_MASK_DEF	(0x9ULL << EVTLOG_SIZE_SHIFT)
+#define EVTLOG_SIZE_MAX		SZ_512K /* 32K entries */
+#define EVTLOG_LEN_MASK_MAX	(0xFULL << EVTLOG_SIZE_SHIFT)
 
 /* Constants for PPR Log handling */
 #define PPR_LOG_ENTRIES		512
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index f3fd7f39efb48..74effb847f488 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -132,6 +132,8 @@ struct ivhd_entry {
 	u8 uid;
 } __attribute__((packed));
 
+int amd_iommu_evtlog_size = EVTLOG_SIZE_DEF;
+
 /*
  * An AMD IOMMU memory definition structure. It defines things like exclusion
  * ranges for devices and regions that should be unity mapped.
@@ -864,35 +866,47 @@ void *__init iommu_alloc_4k_pages(struct amd_iommu *iommu, gfp_t gfp,
 }
 
 /* allocates the memory where the IOMMU will log its events to */
-static int __init alloc_event_buffer(struct amd_iommu *iommu)
+static int __init alloc_event_buffer(void)
 {
-	iommu->evt_buf = iommu_alloc_4k_pages(iommu, GFP_KERNEL,
-					      EVT_BUFFER_SIZE);
+	struct amd_iommu *iommu;
 
-	return iommu->evt_buf ? 0 : -ENOMEM;
+	for_each_iommu(iommu) {
+		iommu->evt_buf = iommu_alloc_4k_pages(iommu, GFP_KERNEL,
+						      amd_iommu_evtlog_size);
+		if (!iommu->evt_buf)
+			return -ENOMEM;
+	}
+
+	return 0;
 }
 
-static void iommu_enable_event_buffer(struct amd_iommu *iommu)
+static void iommu_enable_event_buffer(void)
 {
+	struct amd_iommu *iommu;
 	u64 entry;
 
-	BUG_ON(iommu->evt_buf == NULL);
+	for_each_iommu(iommu) {
+		BUG_ON(iommu->evt_buf == NULL);
 
-	if (!is_kdump_kernel()) {
-		/*
-		 * Event buffer is re-used for kdump kernel and setting
-		 * of MMIO register is not required.
-		 */
-		entry = iommu_virt_to_phys(iommu->evt_buf) | EVT_LEN_MASK;
-		memcpy_toio(iommu->mmio_base + MMIO_EVT_BUF_OFFSET,
-			    &entry, sizeof(entry));
-	}
+		if (!is_kdump_kernel()) {
+			/*
+			 * Event buffer is re-used for kdump kernel and setting
+			 * of MMIO register is not required.
+			 */
+			entry = iommu_virt_to_phys(iommu->evt_buf);
+			entry |= (amd_iommu_evtlog_size == EVTLOG_SIZE_DEF) ?
+				EVTLOG_LEN_MASK_DEF : EVTLOG_LEN_MASK_MAX;
+
+			memcpy_toio(iommu->mmio_base + MMIO_EVT_BUF_OFFSET,
+				    &entry, sizeof(entry));
+		}
 
-	/* set head and tail to zero manually */
-	writel(0x00, iommu->mmio_base + MMIO_EVT_HEAD_OFFSET);
-	writel(0x00, iommu->mmio_base + MMIO_EVT_TAIL_OFFSET);
+		/* set head and tail to zero manually */
+		writel(0x00, iommu->mmio_base + MMIO_EVT_HEAD_OFFSET);
+		writel(0x00, iommu->mmio_base + MMIO_EVT_TAIL_OFFSET);
 
-	iommu_feature_enable(iommu, CONTROL_EVT_LOG_EN);
+		iommu_feature_enable(iommu, CONTROL_EVT_LOG_EN);
+	}
 }
 
 /*
@@ -981,15 +995,20 @@ static int __init alloc_cwwb_sem(struct amd_iommu *iommu)
 	return 0;
 }
 
-static int __init remap_event_buffer(struct amd_iommu *iommu)
+static int __init remap_event_buffer(void)
 {
+	struct amd_iommu *iommu;
 	u64 paddr;
 
 	pr_info_once("Re-using event buffer from the previous kernel\n");
-	paddr = readq(iommu->mmio_base + MMIO_EVT_BUF_OFFSET) & PM_ADDR_MASK;
-	iommu->evt_buf = iommu_memremap(paddr, EVT_BUFFER_SIZE);
+	for_each_iommu(iommu) {
+		paddr = readq(iommu->mmio_base + MMIO_EVT_BUF_OFFSET) & PM_ADDR_MASK;
+		iommu->evt_buf = iommu_memremap(paddr, amd_iommu_evtlog_size);
+		if (!iommu->evt_buf)
+			return -ENOMEM;
+	}
 
-	return iommu->evt_buf ? 0 : -ENOMEM;
+	return 0;
 }
 
 static int __init remap_command_buffer(struct amd_iommu *iommu)
@@ -1041,10 +1060,6 @@ static int __init alloc_iommu_buffers(struct amd_iommu *iommu)
 		ret = remap_command_buffer(iommu);
 		if (ret)
 			return ret;
-
-		ret = remap_event_buffer(iommu);
-		if (ret)
-			return ret;
 	} else {
 		ret = alloc_cwwb_sem(iommu);
 		if (ret)
@@ -1053,10 +1068,6 @@ static int __init alloc_iommu_buffers(struct amd_iommu *iommu)
 		ret = alloc_command_buffer(iommu);
 		if (ret)
 			return ret;
-
-		ret = alloc_event_buffer(iommu);
-		if (ret)
-			return ret;
 	}
 
 	return 0;
@@ -2890,7 +2901,6 @@ static void early_enable_iommu(struct amd_iommu *iommu)
 	iommu_init_flags(iommu);
 	iommu_set_device_table(iommu);
 	iommu_enable_command_buffer(iommu);
-	iommu_enable_event_buffer(iommu);
 	iommu_set_exclusion_range(iommu);
 	iommu_enable_gt(iommu);
 	iommu_enable_ga(iommu);
@@ -2954,7 +2964,6 @@ static void early_enable_iommus(void)
 			iommu_disable_event_buffer(iommu);
 			iommu_disable_irtcachedis(iommu);
 			iommu_enable_command_buffer(iommu);
-			iommu_enable_event_buffer(iommu);
 			iommu_enable_ga(iommu);
 			iommu_enable_xt(iommu);
 			iommu_enable_irtcachedis(iommu);
@@ -3067,6 +3076,7 @@ static void amd_iommu_resume(void *data)
 	for_each_iommu(iommu)
 		early_enable_iommu(iommu);
 
+	iommu_enable_event_buffer();
 	amd_iommu_enable_interrupts();
 }
 
@@ -3396,6 +3406,23 @@ static __init void iommu_snp_enable(void)
 #endif
 }
 
+static void amd_iommu_apply_erratum_snp(void)
+{
+#ifdef CONFIG_KVM_AMD_SEV
+	if (!amd_iommu_snp_en)
+		return;
+
+	/* Errata fix for Family 0x19 */
+	if (boot_cpu_data.x86 != 0x19)
+		return;
+
+	/* Set event log buffer size to max */
+	amd_iommu_evtlog_size = EVTLOG_SIZE_MAX;
+	pr_info("Applying erratum: Increase Event log size to 0x%x\n",
+		amd_iommu_evtlog_size);
+#endif
+}
+
 /****************************************************************************
  *
  * AMD IOMMU Initialization State Machine
@@ -3432,6 +3459,21 @@ static int __init state_next(void)
 	case IOMMU_ENABLED:
 		register_syscore(&amd_iommu_syscore);
 		iommu_snp_enable();
+
+		amd_iommu_apply_erratum_snp();
+
+		/* Allocate/enable event log buffer */
+		if (is_kdump_kernel())
+			ret = remap_event_buffer();
+		else
+			ret = alloc_event_buffer();
+
+		if (ret) {
+			init_state = IOMMU_INIT_ERROR;
+			break;
+		}
+		iommu_enable_event_buffer();
+
 		ret = amd_iommu_init_pci();
 		init_state = ret ? IOMMU_INIT_ERROR : IOMMU_PCI_INIT;
 		break;
@@ -4034,7 +4076,7 @@ int amd_iommu_snp_disable(void)
 		return 0;
 
 	for_each_iommu(iommu) {
-		ret = iommu_make_shared(iommu->evt_buf, EVT_BUFFER_SIZE);
+		ret = iommu_make_shared(iommu->evt_buf, amd_iommu_evtlog_size);
 		if (ret)
 			return ret;
 
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 760d5f4623b55..02b5eaae6843d 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -1009,7 +1009,7 @@ static void iommu_poll_events(struct amd_iommu *iommu)
 		iommu_print_event(iommu, iommu->evt_buf + head);
 
 		/* Update head pointer of hardware ring-buffer */
-		head = (head + EVENT_ENTRY_SIZE) % EVT_BUFFER_SIZE;
+		head = (head + EVTLOG_ENTRY_SIZE) % amd_iommu_evtlog_size;
 		writel(head, iommu->mmio_base + MMIO_EVT_HEAD_OFFSET);
 	}
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] ALSA: usb-audio: add clock quirk for Motu 1248

[Sasha Levin]

From: Nicola Lunghi <nick83ola@gmail.com>

[ Upstream commit 320e55722ca466a7d40dd69e1aea982cb6189006 ]

The Motu 1248 (and probably other older Motu AVB interfaces) take more
than 2 seconds to switch clock. During the clock switching process the
device return that the clock is not valid. This is similar to what
already implemented for the Microbook II interface. Add the Motu
1248 usb id to the existing Motu quirk.

Signed-off-by: Nicola Lunghi <nick83ola@gmail.com>
Link: https://patch.msgid.link/20260504144520.699522-2-nick83ola@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

Phase 1:
- Record 1.1: Subsystem `ALSA: usb-audio`; action verb `add`; intent is
  to add Motu 1248 USB ID `07fd:0005` to an existing clock-validity
  delay quirk.
- Record 1.2: Tags: `Signed-off-by: Nicola Lunghi`, `Link:
  https://patch.msgid.link/20260504144520.699522-2-nick83ola@gmail.com`,
  `Signed-off-by: Takashi Iwai`. No `Fixes:`, `Reported-by:`, `Tested-
  by:`, `Reviewed-by:`, or `Cc: stable`.
- Record 1.3: Commit body describes Motu 1248 returning clock-invalid
  for more than 2 seconds while switching clock, causing the existing
  ALSA clock validation to fail too early. No kernel-version range
  given.
- Record 1.4: This is a hardware quirk fix, not a hidden
  memory/synchronization bug.

Phase 2:
- Record 2.1: One file changed: `sound/usb/clock.c`, `+11/-4`. Modified
  function: `uac_clock_source_is_valid_quirk()`. Single-file surgical
  hardware quirk.
- Record 2.2: Before: the 5-second retry loop applied only to
  `USB_ID(0x07fd, 0x0004)`. After: the same loop also applies to
  `USB_ID(0x07fd, 0x0005)`, with comments expanded.
- Record 2.3: Bug category is hardware workaround/device quirk.
  Mechanism: ALSA rechecks clock validity up to 50 times with
  `msleep(100)` instead of failing on the initial transient invalid
  response.
- Record 2.4: Fix quality is high: it reuses existing code and only
  widens the device match. Regression risk is very low and limited to
  MOTU product ID `0x0005`.

Phase 3:
- Record 3.1: `git blame` shows the existing MOTU retry quirk was
  introduced by `2edb84e3047b9` in 2020. Later nearby changes came from
  clock refactoring and multi-control-interface support, but the retry
  logic remains the same.
- Record 3.2: No `Fixes:` tag, so no introducing commit to follow.
- Record 3.3: Recent `sound/usb/clock.c` history shows related clock
  fixes/refactors, but this patch is standalone and only changes the
  device match.
- Record 3.4: Author has prior usb-audio quirk commits in local history;
  Takashi Iwai applied the patch and is the ALSA maintainer/committer
  for this area.
- Record 3.5: No functional dependencies found. The patch applies
  cleanly to checked pending stable branches.

Phase 4:
- Record 4.1: `b4 dig -c 320e55722ca46` found the original submission at
  the patch.msgid.link URL. `b4 dig -a` showed only `v1`; no newer
  revision found.
- Record 4.2: `b4 dig -w` showed Nicola Lunghi, Jaroslav Kysela, Takashi
  Iwai, `linux-sound`, `linux-kernel`, and `linux-usb` were included.
- Record 4.3: `b4 mbox` showed Takashi replied “Applied now. Thanks.” No
  objections or review concerns appeared in the two-message thread.
  WebFetch of lore was blocked by Anubis.
- Record 4.4: No multi-patch series or related required patches found.
- Record 4.5: Stable-list web search was blocked by Anubis; no stable-
  specific discussion was found through the available local/b4 data.

Phase 5:
- Record 5.1: Key function: `uac_clock_source_is_valid_quirk()`.
- Record 5.2: Call path verified: `uac_clock_source_is_valid()` calls
  the quirk when the device reports invalid clock;
  `__uac_clock_find_source()` and `set_sample_rate_v2v3()` call clock
  validation; setup is reached from format parsing, stream setup,
  endpoint preparation, and sample-rate initialization.
- Record 5.3: Key callees are `snd_usb_ctl_msg()`,
  `snd_usb_find_ctrl_interface()`, `snd_usb_find_clock_source()`, and
  `msleep(100)`.
- Record 5.4: Reachability is real for users of affected USB audio
  devices during sample-rate/clock setup and PCM endpoint preparation.
- Record 5.5: Similar existing pattern is the MicroBook IIc quirk for
  the same vendor and same delayed clock-validity behavior.

Phase 6:
- Record 6.1: The existing quirk code exists in checked pending stable
  branches `pending-5.4`, `pending-5.10`, `pending-5.15`, `pending-6.1`,
  `pending-6.6`, `pending-6.12`, and `pending-7.0`.
- Record 6.2: Backport difficulty is clean: `git apply --check`
  succeeded on all those pending branches.
- Record 6.3: No alternative Motu 1248 fix was found in local
  stable/current history.

Phase 7:
- Record 7.1: Subsystem is ALSA USB audio driver. Criticality: IMPORTANT
  for users of affected MOTU hardware, not core-wide.
- Record 7.2: Subsystem is active; recent history contains multiple usb-
  audio fixes and quirks.

Phase 8:
- Record 8.1: Affected users are driver/hardware-specific: Motu 1248 and
  likely related older MOTU AVB/hybrid devices with product ID `0x0005`.
- Record 8.2: Trigger is changing sample rate or clock source, or
  validation during device/audio setup. Unprivileged trigger depends on
  local audio-device permissions; I did not verify distro policy.
- Record 8.3: Failure mode is ALSA failing clock validation early,
  returning errors such as `-ENXIO` from the code path and preventing
  successful audio setup. Severity: MEDIUM for the kernel generally,
  HIGH for affected hardware usability.
- Record 8.4: Benefit is high for affected hardware; risk is very low
  because this only enables an existing quirk for one USB product ID.

Phase 9:
- Record 9.1: Evidence for backporting: real hardware quirk, existing
  stable-accepted mechanism, small single-file change, maintainer-
  applied, cleanly applies to stable branches, external CCRMA
  documentation corroborates MOTU 1248 Linux sample-rate failures that
  succeed after waiting. Evidence against: no crash/security/data-
  corruption, no explicit stable tag, and no direct reporter/tested-by
  tag.
- Record 9.2: Stable rules: obviously correct yes; fixes real user-
  visible hardware failure yes; important enough under hardware-quirk
  exception yes; small/contained yes; no new API/features yes; applies
  cleanly yes.
- Record 9.3: Exception category: hardware quirk/workaround for broken
  device timing behavior.
- Record 9.4: Decision: backport. This is exactly the kind of low-risk
  device-specific quirk stable trees routinely take.

## Verification

- Phase 1: Parsed commit `320e55722ca46` with `git show
  --format=fuller`; verified tags and message.
- Phase 2: Verified diff with `git show --find-renames` and `--numstat`:
  `sound/usb/clock.c`, `+11/-4`.
- Phase 3: Ran `git blame -L 179,240 -- sound/usb/clock.c`; identified
  existing quirk origin `2edb84e3047b9`.
- Phase 3: Checked recent file history with `git log --oneline -20 --
  sound/usb/clock.c`.
- Phase 4: Ran `b4 dig -c 320e55722ca46`, `-a`, and `-w`; confirmed v1
  patch, recipients, and lore URL.
- Phase 4: Ran `b4 mbox`; confirmed Takashi’s “Applied now” reply and no
  objections in the fetched thread.
- Phase 5: Used `rg` and file reads to trace callers through `clock.c`,
  `format.c`, `endpoint.c`, `stream.c`, and `quirks.c`.
- Phase 6: Checked quirk presence in pending stable branches and
  verified `git apply --check` cleanly on `pending-5.4`, `pending-5.10`,
  `pending-5.15`, `pending-6.1`, `pending-6.6`, `pending-6.12`, and
  `pending-7.0`.
- Phase 8: Used WebFetch of CCRMA MOTU 1248 documentation; it reports
  Linux output/sample-rate attempts may fail initially and succeed after
  5-10 seconds.
- UNVERIFIED: Exact USB ID mapping for every model listed in the new
  comment beyond the commit’s own statement.

**YES**

 sound/usb/clock.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/sound/usb/clock.c b/sound/usb/clock.c
index 842ba5b801eae..2e0c18e352812 100644
--- a/sound/usb/clock.c
+++ b/sound/usb/clock.c
@@ -208,11 +208,18 @@ static bool uac_clock_source_is_valid_quirk(struct snd_usb_audio *chip,
 	}
 
 	/*
-	 * MOTU MicroBook IIc
-	 * Sample rate changes takes more than 2 seconds for this device. Clock
-	 * validity request returns false during that period.
+	 * Quirk for older MOTU AVB / hybrid interfaces
+	 *
+	 * These devices take more than 2 seconds to switch sample rate or
+	 * clock source. During this period the clock validity request
+	 * returns false, causing ALSA to fail prematurely.
+	 *
+	 * Affected models (all use vendor 0x07fd):
+	 *   - MicroBook IIc          → 0x0004
+	 *   - 1248, 624, 8A, UltraLite AVB, 8M, 16A, ... → 0x0005
 	 */
-	if (chip->usb_id == USB_ID(0x07fd, 0x0004)) {
+	if (chip->usb_id == USB_ID(0x07fd, 0x0004) ||  /* MicroBook IIc */
+	    chip->usb_id == USB_ID(0x07fd, 0x0005)) {  /* 1248 / 624 / 8A / UltraLite AVB / ... */
 		count = 0;
 
 		while ((!ret) && (count < 50)) {
-- 
2.53.0

[PATCH AUTOSEL 7.0] ASoC: sdw_utils: avoid the SDCA companion function not supported failure

[Sasha Levin]

From: Derek Fang <derek.fang@realtek.com>

[ Upstream commit 56d5a9eaf60af5c824a33a83e1468aa143627a62 ]

Treat the companion amp as generic AMP until full support for companion
amp is added.

Signed-off-by: Derek Fang <derek.fang@realtek.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20260430121043.552241-1-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@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 `ASoC: sdw_utils`; action verb `avoid`;
claimed intent is to avoid SDCA companion amp being treated as
unsupported.

Step 1.2 Record: tags present:
- `Signed-off-by: Derek Fang <derek.fang@realtek.com>`
- `Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>`
- `Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>`
- `Link: https://patch.msgid.link/20260430121043.552241-1-yung-
  chuan.liao@linux.intel.com`
- `Signed-off-by: Mark Brown <broonie@kernel.org>`
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Acked-by:`, or `Cc:
stable@vger.kernel.org` tags were present.

Step 1.3 Record: the body says companion amps should be treated as
generic amps until full companion-amp support exists. The user-visible
symptom implied by the subject and code is an SDCA companion amp being
classified as unsupported. No stack trace, crash, version statement, or
bug report is included.

Step 1.4 Record: this is a hidden bug fix. The verb “avoid” plus the
one-line mapping change fixes incorrect handling of a valid SDCA
function type that was already accepted elsewhere in the SDCA code.

## Phase 2: Diff Analysis
Step 2.1 Record: one file changed,
`sound/soc/sdw_utils/soc_sdw_utils.c`, one line added. Modified
function: `asoc_sdw_get_dai_type()`. Scope: single-file surgical logic
fix.

Step 2.2 Record: before the patch, `SDCA_FUNCTION_TYPE_COMPANION_AMP`
fell through to `default` and returned `-EINVAL`. After the patch, it
returns `SOC_SDW_DAI_TYPE_AMP`, like smart and simple amp function
types. This affects SDCA endpoint detection and SOF SoundWire endpoint
construction paths that call `asoc_sdw_get_dai_type()`.

Step 2.3 Record: bug category is logic/correctness plus hardware
compatibility. The broken mechanism is that a valid SDCA companion amp
function type was known to SDCA parsing code but not known to the SDW
DAI-type mapper, so amp endpoint matching could fail.

Step 2.4 Record: the fix is obviously small and locally correct:
“companion amp” is mapped into the existing amp class. Regression risk
is very low; the only behavior change is for devices reporting
`SDCA_FUNCTION_TYPE_COMPANION_AMP`.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` on the pre-fix switch shows
`asoc_sdw_get_dai_type()` and its default `-EINVAL` mapping came from
`4f8ef33dd44a3d` (“ASoC: soc_sdw_utils: skip the endpoint that doesn't
present”), first contained from v6.16. The actual companion-amp exposure
came later from `f5cb3ee251b4f` (“ASoC: SDCA: Add companion amp
Function”), first contained from v6.19.

Step 3.2 Record: no `Fixes:` tag is present, so no tag target exists to
follow. The likely prerequisite/regression source was verified
separately as `f5cb3ee251b4f`, which added
`SDCA_FUNCTION_TYPE_COMPANION_AMP` to `include/sound/sdca_function.h`
and `sound/soc/sdca/sdca_functions.c`.

Step 3.3 Record: recent history for `soc_sdw_utils.c` shows active
SDCA/SoundWire endpoint work. Related commits include `506cbe36a2ac7b`
exporting `asoc_sdw_get_dai_type()`, `f5cb3ee251b4f` adding the
companion amp function type, and later SDCA/sdw_utils fixes. This patch
is standalone except that it only applies meaningfully to trees already
containing the companion-amp enum.

Step 3.4 Record: Derek Fang has multiple Realtek ASoC codec commits,
including the RT1017 SDCA amplifier driver. Bard Liao has many
SDW/SOF/ASoC commits in this area and is listed as an SDCA reviewer in
`MAINTAINERS`.

Step 3.5 Record: dependency identified:
`SDCA_FUNCTION_TYPE_COMPANION_AMP` must exist. It is present in v6.19
and v7.0, absent in v6.18. The patch should not be applied to older
trees unless that enum support is also present.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c 56d5a9eaf60a` matched the original patch by
exact patch-id at the supplied patch link. `b4 dig -a` found only v1 of
a single-patch series. No newer revision was found.

Step 4.2 Record: `b4 dig -w` showed the original recipients included
Bard Liao, Mark Brown, Takashi Iwai, `linux-sound@vger.kernel.org`,
Intel/Realtek audio contributors, and Derek Fang. The patch carries
`Reviewed-by: Charles Keepax`, who is listed as an SDCA maintainer.

Step 4.3 Record: no bug-report link or `Reported-by` tag exists.
Web/lore fetches for the search pages were blocked by Anubis, but `b4`
successfully fetched the actual thread. No syzbot or user bug report was
found.

Step 4.4 Record: `b4 dig -a` shows this is not part of a multi-patch
series. Local related-patch search found `f5cb3ee251b4f` as the
companion-amp type addition, which is the important dependency/context.

Step 4.5 Record: no stable-specific discussion was found in local stable
tag history or web search. No reviewer stable nomination was found in
the fetched thread.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: modified function: `asoc_sdw_get_dai_type()`.

Step 5.2 Record: callers found:
- `is_sdca_endpoint_present()` in `sound/soc/sdw_utils/soc_sdw_utils.c`,
  used while parsing SoundWire endpoints for ASoC machine drivers.
- `is_endpoint_present()` in `sound/soc/sof/intel/hda.c`, present in
  v7.0 and later, used while building default SoundWire machine
  descriptions from detected peripherals.

Step 5.3 Record: key callees/side effects: `is_sdca_endpoint_present()`
gets a SoundWire device by name, checks `slave->sdca_data`, loops over
firmware-provided SDCA functions, and skips endpoints if no matching DAI
type is found. The SOF HDA path similarly checks
`sdw_device->sdca_data.function[]` before adding endpoints.

Step 5.4 Record: reachability is verified through machine-driver setup
paths: Intel `sof_sdw`, AMD ACP SDW SOF, and AMD ACP SDW legacy machine
drivers call `asoc_sdw_parse_sdw_endpoints()`. The HDA default machine
path calls `find_acpi_adr_device()` during SoundWire machine selection.
This is boot/probe-time hardware enumeration, not an unprivileged
syscall path.

Step 5.5 Record: similar pattern search found
`SDCA_FUNCTION_TYPE_COMPANION_AMP` handled in the SDCA name parser but
missing from the DAI-type mapper before this patch. No other
`asoc_sdw_get_dai_type()` companion mapping existed before the fix.

## Phase 6: Stable Tree Analysis
Step 6.1 Record: v6.18 has `asoc_sdw_get_dai_type()` but no
`SDCA_FUNCTION_TYPE_COMPANION_AMP`. v6.19 and v7.0 contain the companion
enum/name support but lack this mapper case. v7.1-rc3 contains the fix.
Therefore the affected stable trees are v6.19.y and v7.0.y, not older
trees lacking `f5cb3ee251b4f`.

Step 6.2 Record: `git apply --check` of the target patch succeeded on
the current checkout, which is v7.0.5. The v6.19 helper context around
`SDCA_FUNCTION_TYPE_SIMPLE_AMP` matches the same missing-case pattern,
so expected v6.19 backport difficulty is clean or trivial.

Step 6.3 Record: local stable history checks for v6.19.y and v7.0.y
found no existing stable commit with this subject. v7.1-rc3 contains
`56d5a9eaf60a`.

## Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: subsystem is ASoC SoundWire/SDCA audio support.
Criticality is driver/platform-specific, important for affected
SoundWire laptop/audio hardware but not universal core kernel code.

Step 7.2 Record: subsystem activity is high; recent history shows many
SDCA and `sdw_utils` changes across v6.19 to v7.1. This is a newer,
actively evolving area, which reinforces the dependency check.

## Phase 8: Impact And Risk Assessment
Step 8.1 Record: affected users are systems with SoundWire SDCA devices
reporting companion amp functions, especially Intel/AMD SoundWire laptop
audio configurations using these helper paths.

Step 8.2 Record: trigger condition is hardware/firmware enumeration
where `slave->sdca_data.function[i].type` is
`SDCA_FUNCTION_TYPE_COMPANION_AMP`. It happens during boot/probe/machine
selection, not from unprivileged userspace.

Step 8.3 Record: failure mode is endpoint/DAI detection failure: the
companion amp can be treated as unsupported and skipped or not included
in generated SoundWire endpoint data. Severity is medium for the general
kernel, high for affected hardware because it can break audio amp
availability.

Step 8.4 Record: benefit is high for affected hardware and low-risk
globally. Risk is very low: one added switch case, no new API, no
locking, no memory lifetime changes, and no behavior change for other
function types.

## Phase 9: Final Synthesis
Step 9.1 Record: evidence for backporting:
- Fixes real incorrect handling of an already-defined SDCA companion amp
  type.
- Prevents affected SoundWire audio endpoints from being classified
  unsupported.
- One-line, single-function, single-file change.
- Reviewed by Charles Keepax; applied by Mark Brown; relevant
  maintainers/lists were included.
- Applies to stable trees that already contain `f5cb3ee251b4f`, verified
  for v6.19/v7.0 presence.

Evidence against backporting:
- No crash, data corruption, security issue, syzbot report, or explicit
  stable tag.
- It is hardware/functionality enablement rather than a core reliability
  fix.
- It must not be applied to trees without
  `SDCA_FUNCTION_TYPE_COMPANION_AMP`.

Unresolved questions:
- No external user bug report was found, so exact affected product count
  is unverified.
- I did not run a full v6.19 worktree apply test, but verified matching
  context and dependency presence.

Step 9.2 Stable rules:
1. Obviously correct and tested? Yes for correctness by code inspection;
   no explicit `Tested-by` on this patch.
2. Fixes a real bug? Yes, incorrect mapping of a valid SDCA companion
   amp function.
3. Important issue? Yes for affected hardware audio functionality,
   though not crash/security.
4. Small and contained? Yes, one line in one function.
5. No new feature/API? Yes, it uses an existing enum and existing DAI
   type.
6. Can apply to stable? Yes for v7.0.5 verified; expected trivial for
   v6.19.y; not applicable to older trees lacking the enum.

Step 9.3 Exception category: closest category is hardware
compatibility/workaround for existing SoundWire SDCA audio support. It
is not a new driver or new userspace API.

Step 9.4 Decision: backport to stable trees that already include
`f5cb3ee251b4f` (`SDCA_FUNCTION_TYPE_COMPANION_AMP`), notably v6.19.y
and v7.0.y. Do not backport to older trees unless that prerequisite is
intentionally present.

## Verification
- [Phase 1] Parsed commit `56d5a9eaf60a` with `git show`; confirmed
  subject, body, tags, and one-file/one-line patch.
- [Phase 2] Inspected diff; confirmed only `asoc_sdw_get_dai_type()`
  adds `SDCA_FUNCTION_TYPE_COMPANION_AMP` to the amp cases.
- [Phase 3] `git blame 56d5a9eaf60a^` showed the mapper switch came from
  `4f8ef33dd44a3d`; `git show f5cb3ee251b4f` confirmed companion amp
  enum/name support was added later.
- [Phase 3] `git tag --contains f5cb3ee...` showed companion amp support
  starts at v6.19; `git grep` confirmed absent in v6.18 and present in
  v6.19/v7.0.
- [Phase 4] `b4 dig -c 56d5a9eaf60a` found the original patch thread;
  `b4 dig -a` showed only v1; `b4 dig -w` showed original recipients.
- [Phase 4] Fetched the mbox with `b4`; confirmed Mark Brown applied it
  to `sound.git for-7.1` and no NAK/objection appeared in the fetched
  thread.
- [Phase 5] `rg` found callers in `is_sdca_endpoint_present()` and SOF
  HDA `is_endpoint_present()`; file reads verified endpoint filtering
  behavior.
- [Phase 6] `git grep` across v6.18/v6.19/v7.0/v7.1-rc3 verified where
  the enum and fix exist.
- [Phase 6] `git apply --check` verified the patch applies cleanly to
  current v7.0.5.
- [Phase 7] `MAINTAINERS` verified Mark Brown as ASoC maintainer and
  Charles Keepax/Bard Liao as SDCA maintainer/reviewer contacts.
- [Phase 8] Failure mode was verified from code paths that skip
  endpoints when no matching DAI type is found.
- UNVERIFIED: exact real-world affected laptop/device count; no public
  bug report was found.

**YES**

 sound/soc/sdw_utils/soc_sdw_utils.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/sdw_utils/soc_sdw_utils.c b/sound/soc/sdw_utils/soc_sdw_utils.c
index 0e67d9f34cba3..2b4b54e8241e6 100644
--- a/sound/soc/sdw_utils/soc_sdw_utils.c
+++ b/sound/soc/sdw_utils/soc_sdw_utils.c
@@ -1400,6 +1400,7 @@ int asoc_sdw_get_dai_type(u32 type)
 	switch (type) {
 	case SDCA_FUNCTION_TYPE_SMART_AMP:
 	case SDCA_FUNCTION_TYPE_SIMPLE_AMP:
+	case SDCA_FUNCTION_TYPE_COMPANION_AMP:
 		return SOC_SDW_DAI_TYPE_AMP;
 	case SDCA_FUNCTION_TYPE_SMART_MIC:
 	case SDCA_FUNCTION_TYPE_SIMPLE_MIC:
-- 
2.53.0

Re: [PATCH AUTOSEL 7.0] io_uring/wait: honour caller's time namespace for IORING_ENTER_ABS_TIMER

[Jens Axboe]

On 5/11/26 4:19 PM, Sasha Levin wrote:
> From: Maoyi Xie <maoyixie.tju@gmail.com>
> 
> [ Upstream commit 45d2b37a37ab98484693533496395c610a2cab96 ]

If you auto-pick this one, please also do the other one in the
series, 9cc6bac1bebf8310d2950d1411a91479e86d69a1. Makes no sense
to do just one of them.

-- 
Jens Axboe