[PATCH AUTOSEL 7.0-5.15] remoteproc: qcom: Fix minidump out-of-bounds access on subsystems array

[PATCH AUTOSEL 7.0-5.15] remoteproc: qcom: Fix minidump out-of-bounds access on subsystems array

[Sasha Levin]

From: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>

[ Upstream commit 743cfae79d2458e241b06ed523c28a09f1449b75 ]

MAX_NUM_OF_SS was hardcoded to 10 in the minidump_global_toc struct,
which is a direct overlay on an SMEM item allocated by the firmware.
Newer Qualcomm SoC firmware allocates space for more subsystems, while
older firmware only allocates space for 10. Bumping the constant would
cause Linux to read/write beyond the SMEM item boundary on older
platforms.

Fix this by converting subsystems[] to a flexible array member and
deriving the actual number of subsystems at runtime from the size
returned by qcom_smem_get(). Add a bounds check on minidump_id against
the derived count before indexing into the array.

Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260331171243.1962067-1-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have enough information to complete my analysis.

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1 - Subject Line Parse:**
Record: Subsystem `remoteproc: qcom:`; action verb `Fix`; summary: fix
out-of-bounds access on minidump subsystems array.

**Step 1.2 - Tags:**
Record:
- `Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>` (author,
  Qualcomm/remoteproc contributor)
- `Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>` (subsystem
  contributor)
- `Link: https://lore.kernel.org/r/20260331171243.1962067-1-
  mukesh.ojha@oss.qualcomm.com`
- `Signed-off-by: Bjorn Andersson <andersson@kernel.org>` (remoteproc
  co-maintainer)
- No `Cc: stable@vger.kernel.org`, no `Fixes:` tag (expected for review
  candidates)

**Step 1.3 - Commit Body:**
Record: Bug description: `MAX_NUM_OF_SS` hardcoded to 10 but
`minidump_global_toc` overlays SMEM item allocated by firmware; newer
firmware allocates more subsystems; bumping constant would overflow SMEM
on older platforms. Fix: convert to flexible array, derive count at
runtime from `qcom_smem_get()` size, add bounds check.

**Step 1.4 - Hidden Fix:**
Record: Explicit bug fix ("Fix ... out-of-bounds access") - not hidden.

## PHASE 2: DIFF ANALYSIS

**Step 2.1 - Inventory:**
Record: Single file `drivers/remoteproc/qcom_common.c`; +14/-3 lines;
modifies `qcom_minidump()` function and `struct minidump_global_toc`;
surgical, single-file fix.

**Step 2.2 - Code Flow:**
Record: Before: `qcom_smem_get(...,NULL)` ignores size; directly indexes
`toc->subsystems[minidump_id]` which is declared `[MAX_NUM_OF_SS=10]`.
After: requests actual SMEM size via `&toc_size`; computes `num_ss` from
`(toc_size - offsetof(...,subsystems))/sizeof(subsystem)`; returns early
with error if `minidump_id >= num_ss`.

**Step 2.3 - Bug Mechanism:**
Record: Category: **memory safety / out-of-bounds access**. With
`MAX_NUM_OF_SS=10`, accessing `toc->subsystems[20]` (as done for SA8775p
CDSP1) is out-of-bounds per the C array type. Fix converts to flexible
array member and validates index at runtime.

**Step 2.4 - Fix Quality:**
Record: Obviously correct; minimal/surgical; preserves behavior for
valid indexes (< actual count); no regression risk for existing devices
using minidump_id 3/4/5/7; depends on `qcom_smem_get()` reporting
accurate size which is its contract.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1 - Blame:**
Record: `MAX_NUM_OF_SS=10` was introduced by `8ed8485c4f056
("remoteproc: qcom: Add capability to collect minidumps")` in Nov 2020
(v5.11). The buggy code has been present since v5.11.

**Step 3.2 - Fixes Tag:**
Record: No `Fixes:` tag present. The bug was technically present since
minidump was added in v5.11, but only becomes an observable OOB when a
device's `minidump_id` exceeds 9.

**Step 3.3 - File History:**
Record: The file has been minimally modified. Key related commits:
- `9091225ba28c0` ("remoteproc: qcom: pas: Add support for SA8775p ADSP,
  CDSP and GPDSP") in v6.12-rc1 added `minidump_id = 20, 21, 22` for
  sa8775p CDSP1, GPDSP0, GPDSP1 → this is when the bug becomes
  triggerable.
- `318da1371246f` ("remoteproc: qcom: Expand MD_* as MINIDUMP_*") - same
  author, minidump cleanup
- Standalone fix, not part of a series.

**Step 3.4 - Author Context:**
Record: Mukesh Ojha is a regular Qualcomm remoteproc contributor and the
primary author of minidump-related work (multiple minidump cleanup
commits). Fix from a knowledgeable author.

**Step 3.5 - Dependencies:**
Record: Only dependency is that `qcom_smem_get()` supports returning
size via pointer, which it has done since inception (verified in all
stable trees).

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1 - b4 dig:**
Record: Found at `https://lore.kernel.org/all/20260331171243.1962067-1-
mukesh.ojha@oss.qualcomm.com/`. Only v2 was applied.

**Step 4.2 - Reviewers:**
Record: Sent to Bjorn Andersson (co-maintainer), Mathieu Poirier (co-
maintainer), linux-arm-msm, linux-remoteproc. Reviewed/Acked by Konrad
Dybcio.

**Step 4.3 - History - v1 Discussion:**
Record: Fetched v1 thread
(`20250808164417.4105659-1-mukesh.ojha@oss.qualcomm.com`). V1 was a
naïve fix bumping `MAX_NUM_OF_SS` from 10 to 30. Bjorn Andersson
objected: "this number is used to size the minidump_global_toc struct...
Doesn't this imply that on older platforms you've now told Linux (and
your debugger) that it's fine to write beyond the smem item?" and
suggested "check the returned size of the qcom_smem_get() call." Author
Mukesh specifically asked **"do you think it should a fix (cc
stable)?"**. V2 implemented exactly Bjorn's suggestion, received Ack,
and was applied.

**Step 4.4 - Series:**
Record: Standalone single-patch submission.

**Step 4.5 - Stable Mailing List:**
Record: No separate stable discussion visible; author explicitly
considered it a stable fix but final v2 lacks Cc:stable tag.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1 - Key Functions:**
Record: `qcom_minidump()` is the modified function; `struct
minidump_global_toc` is the modified type.

**Step 5.2 - Callers:**
Record: `qcom_minidump()` is called from exactly one place -
`qcom_pas_minidump()` in `drivers/remoteproc/qcom_q6v5_pas.c:151`. This
is registered as `.coredump` callback in `qcom_pas_minidump_ops` (line
531), which is invoked by `rproc_boot_recovery()` in
`remoteproc_core.c:1798` when a crashed remoteproc is being recovered.

**Step 5.3 - Callees:**
Record: Calls `qcom_smem_get()` (SMEM item retrieval), `dev_err()`, and
then `rproc_coredump()` or `qcom_add_minidump_segments()` +
`rproc_coredump_using_sections()`.

**Step 5.4 - Call Chain / Reachability:**
Record: Reachable from remoteproc crash recovery: remoteproc crash →
`rproc_boot_recovery()` → `rproc->ops->coredump()` →
`qcom_pas_minidump()` → `qcom_minidump(rproc, pas->minidump_id, ...)`.
With `pas->minidump_id = 20/21/22`, this triggers OOB on
`toc->subsystems[20]` indexing. This path is triggered automatically
when the remoteproc crashes (real-world trigger, not obscure).

**Step 5.5 - Similar Patterns:**
Record: Verified the file contains only this one use of the
`subsystems[]` array. Checked `minidump_id` values in `qcom_q6v5_pas.c`:
values 3, 4, 5, 7, 20, 21, 22 are used. The 20/21/22 are all for
`sa8775p` CDSP1/GPDSP0/GPDSP1 resources.

## PHASE 6: CROSS-REFERENCING STABLE TREES

**Step 6.1 - Does Buggy Code Exist?**
Record: Verified by inspecting each stable branch:

| Stable | MAX_NUM_OF_SS=10 | minidump_id 20/21/22 | Bug triggers? |
|--------|------------------|----------------------|---------------|
| p-6.1  | Yes              | No                   | No (harmless) |
| p-6.6  | Yes              | Yes (3 entries)      | **Yes**       |
| p-6.12 | Yes              | Yes (3 entries)      | **Yes**       |
| p-6.15 | Yes              | Yes (3 entries)      | **Yes**       |
| p-6.16 | Yes              | Yes (3 entries)      | **Yes**       |
| p-6.17 | Yes              | Yes (3 entries)      | **Yes**       |

Stable 6.6.y through 6.17.y all have the buggy configuration. 6.1.y has
the limit but no triggering minidump_ids, so safe.

**Step 6.2 - Backport Complications:**
Record: Diffed `qcom_common.c` across p-6.12, p-6.15, p-6.17 - file is
identical across these stable trees. Fix should apply cleanly. For p-6.6
the surrounding code is functionally identical. `qcom_smem_get()`
signature with `size_t *size` parameter is unchanged across all trees
(verified in p-6.6).

**Step 6.3 - Related Fixes in Stable:**
Record: No prior fix for this specific issue exists in stable trees; the
MAX_NUM_OF_SS limit has been 10 since minidump was added.

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1 - Subsystem:**
Record: `drivers/remoteproc/qcom_common.c` - PERIPHERAL (Qualcomm-
specific remoteproc common helpers, affects only Qualcomm SoC users,
primarily SA8775p automotive).

**Step 7.2 - Activity:**
Record: Actively maintained subsystem with recent activity.

## PHASE 8: IMPACT AND RISK

**Step 8.1 - Affected Users:**
Record: Driver-specific - SA8775p SoC users (Qualcomm automotive
platform) using remoteproc/minidump for CDSP1, GPDSP0, or GPDSP1
subsystems.

**Step 8.2 - Trigger:**
Record: Triggered when a SA8775p CDSP1/GPDSP0/GPDSP1 remoteproc crashes
and `rproc_boot_recovery()` invokes the coredump callback. Cannot be
triggered by unprivileged users directly; occurs on hardware/firmware-
induced remoteproc crashes.

**Step 8.3 - Failure Severity:**
Record: With `MAX_NUM_OF_SS=10` and `minidump_id=20`,
`&toc->subsystems[20]` reads past the declared struct end. On SA8775p
the firmware's SMEM item is sized for 23+ entries, so reads land within
SMEM but access memory not described by the Linux struct (UBSAN would
flag this). With a UBSAN-enabled kernel → WARN/report. Without UBSAN →
reads memory bytes 320+ from struct start, potentially interprets them
as `status`/`enabled`/`regions_baseptr`. If `regions_baseptr` has non-
zero bits from surrounding SMEM, the code proceeds to
`qcom_add_minidump_segments()` which calls `ioremap()` with attacker-
uncontrolled but wrong values, and `rproc_coredump_add_custom_segment`
with garbage `da`/`size`. Severity: **MEDIUM-HIGH** - not a routine
crash but a real OOB in crash-recovery path that can cause incorrect
behavior, broken minidump collection, and potentially ioremap of wrong
addresses.

**Step 8.4 - Risk-Benefit:**
Record:
- Benefit: Fixes real OOB on SA8775p automotive SoC users; enables
  correct minidump collection on these subsystems.
- Risk: Very low - fix is +14/-3 lines, surgical, only affects the path
  that was broken; does not change behavior for valid minidump_ids (<
  real count); doesn't alter the SMEM overlay layout (flexible array
  occupies the same offset as the previous fixed array).
- Assessment: Positive risk-benefit.

## PHASE 9: FINAL SYNTHESIS

**Step 9.1 - Evidence:**
For:
- Real OOB bug reachable from remoteproc crash path on SA8775p
- Verified triggering config (minidump_id 20/21/22) is present in stable
  trees 6.6.y–6.17.y
- Small, contained fix (single file, single function, ~17 lines)
- Reviewed and Acked by subsystem contributor
- Author explicitly considered it stable-worthy
- Applied cleanly across stable trees (file identical across
  6.12/6.15/6.17)
- Fix doesn't change behavior for existing working configurations
- Addresses exact concern raised by maintainer Bjorn in v1 review

Against:
- No `Cc: stable` tag on final patch
- No explicit `Fixes:` tag
- Only affects SA8775p users (peripheral driver)
- Crash-recovery path, not hot path

Unresolved: None material.

**Step 9.2 - Stable Rules Checklist:**
1. Obviously correct? Yes - proper size-derivation from SMEM + bounds
   check.
2. Fixes real bug? Yes - OOB access verified via source inspection.
3. Important issue? Medium - OOB with potential for misbehavior in crash
   recovery.
4. Small/contained? Yes - +14/-3 in one file.
5. No new features? Correct - pure bug fix.
6. Applies to stable? Yes - verified file identical in 6.12/6.15/6.17;
   p-6.6 is compatible.

**Step 9.3 - Exceptions:**
Not a device ID/quirk/DT/build/doc exception; a standard bug fix.

**Step 9.4 - Decision:**
YES - this fixes a real, verifiable out-of-bounds memory access
reachable in a realistic path (remoteproc crash recovery on SA8775p). It
satisfies all stable kernel rules.

## Verification

- [Phase 1] Parsed commit message: confirmed Acked-by Konrad, SoB from
  Bjorn Andersson, Link to lore; no stable/Fixes tag (expected).
- [Phase 2] Read the diff: verified `MAX_NUM_OF_SS` removed,
  `subsystems[]` changed to flexible array, `qcom_smem_get()` now
  requests `toc_size`, `num_ss` derived via `offsetof`, and bounds check
  added.
- [Phase 3.1] Ran `git blame` on lines 30-35 of
  `drivers/remoteproc/qcom_common.c`: confirmed `MAX_NUM_OF_SS`
  originated from `8ed8485c4f056` (Siddharth Gupta, 2020-11-19).
- [Phase 3.1] `git describe --contains 8ed8485c4f056` →
  `v5.11-rc1~148^2~10`: minidump feature introduced in v5.11.
- [Phase 3.3] `git log -S "minidump_id = 20"` → `9091225ba28c0` (SA8775p
  support) in v6.12-rc1 (`git describe --contains`).
- [Phase 3.3] `git show 9091225ba28c0` confirmed minidump_id = 20, 21,
  22 added for sa8775p CDSP1/GPDSP0/GPDSP1.
- [Phase 4.1] `b4 dig -c 743cfae79d245` → found at lore v2 URL; `-a`
  shows only v2 in this series.
- [Phase 4.3] `b4 mbox` on v1 URL `20250808164417.4105659-1-...`:
  retrieved v1 discussion; confirmed Bjorn objected to v1's naïve
  constant bump and suggested the exact approach used in v2; author
  asked about Cc: stable.
- [Phase 5.2] `grep "qcom_minidump"` in drivers/remoteproc: confirmed
  single caller in `qcom_q6v5_pas.c:151` via
  `qcom_pas_minidump_ops.coredump`.
- [Phase 5.2] `grep "coredump"` in remoteproc_core.c: confirmed
  invocation from `rproc_boot_recovery()` line 1798.
- [Phase 5.5] `grep "minidump_id = "` in `qcom_q6v5_pas.c`: confirmed
  values 3, 4, 5, 7, 20, 21, 22 - three are out-of-bounds for
  MAX_NUM_OF_SS=10.
- [Phase 6.1] `git show p-6.X:drivers/remoteproc/qcom_common.c | grep
  MAX_NUM_OF_SS`: all stable branches (6.1, 6.6, 6.12, 6.15, 6.16, 6.17)
  have `MAX_NUM_OF_SS=10`.
- [Phase 6.1] `git show p-6.X:drivers/remoteproc/qcom_q6v5_pas.c | grep
  -c "minidump_id = 2[012]"`: p-6.1=0, p-6.6=3, p-6.12=3, p-6.15=3,
  p-6.16=3, p-6.17=3. So bug triggers in 6.6.y through 6.17.y.
- [Phase 6.2] Diffed `qcom_common.c` between p-6.12, p-6.15, p-6.17 -
  files identical, fix should apply cleanly.
- [Phase 6.2] `git show p-6.6:drivers/soc/qcom/smem.c | grep
  qcom_smem_get`: `qcom_smem_get(unsigned host, unsigned item, size_t
  *size)` signature present.
- [Phase 6.2] Verified p-6.6 qcom_minidump function structure matches
  mainline pre-fix version.
- [Phase 8.3] Confirmed callers of `qcom_minidump`: only
  `qcom_pas_minidump`, invoked on remoteproc recovery - real reachable
  path.
- UNVERIFIED: Could not empirically reproduce UBSAN output or observe a
  crash; severity assessment based on code reading and standard C
  semantics.

**YES**

 drivers/remoteproc/qcom_common.c | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/remoteproc/qcom_common.c b/drivers/remoteproc/qcom_common.c
index 6c31140268acb..fd2b6824ad265 100644
--- a/drivers/remoteproc/qcom_common.c
+++ b/drivers/remoteproc/qcom_common.c
@@ -28,7 +28,6 @@
 #define to_ssr_subdev(d) container_of(d, struct qcom_rproc_ssr, subdev)
 #define to_pdm_subdev(d) container_of(d, struct qcom_rproc_pdm, subdev)
 
-#define MAX_NUM_OF_SS           10
 #define MAX_REGION_NAME_LENGTH  16
 #define SBL_MINIDUMP_SMEM_ID	602
 #define MINIDUMP_REGION_VALID		('V' << 24 | 'A' << 16 | 'L' << 8 | 'I' << 0)
@@ -80,7 +79,7 @@ struct minidump_global_toc {
 	__le32				status;
 	__le32				md_revision;
 	__le32				enabled;
-	struct minidump_subsystem	subsystems[MAX_NUM_OF_SS];
+	struct minidump_subsystem	subsystems[];
 };
 
 struct qcom_ssr_subsystem {
@@ -151,9 +150,11 @@ void qcom_minidump(struct rproc *rproc, unsigned int minidump_id,
 	int ret;
 	struct minidump_subsystem *subsystem;
 	struct minidump_global_toc *toc;
+	unsigned int num_ss;
+	size_t toc_size;
 
 	/* Get Global minidump ToC*/
-	toc = qcom_smem_get(QCOM_SMEM_HOST_ANY, SBL_MINIDUMP_SMEM_ID, NULL);
+	toc = qcom_smem_get(QCOM_SMEM_HOST_ANY, SBL_MINIDUMP_SMEM_ID, &toc_size);
 
 	/* check if global table pointer exists and init is set */
 	if (IS_ERR(toc) || !toc->status) {
@@ -161,6 +162,16 @@ void qcom_minidump(struct rproc *rproc, unsigned int minidump_id,
 		return;
 	}
 
+	/* Derive the number of subsystems from the actual SMEM item size */
+	num_ss = (toc_size - offsetof(struct minidump_global_toc, subsystems)) /
+		 sizeof(struct minidump_subsystem);
+
+	if (minidump_id >= num_ss) {
+		dev_err(&rproc->dev, "Minidump id %d is out of range: %d\n",
+			minidump_id, num_ss);
+		return;
+	}
+
 	/* Get subsystem table of contents using the minidump id */
 	subsystem = &toc->subsystems[minidump_id];
 
-- 
2.53.0

[PATCH AUTOSEL 6.18] arm64: dts: qcom: monaco: Reserve full Gunyah metadata region

[Sasha Levin]

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

[ Upstream commit 85d98669fa7f1d3041d962515e45ee6e392db6f8 ]

We observe spurious "Synchronous External Abort" exceptions
(ESR=0x96000010) and kernel crashes on Monaco-based platforms.
These faults are caused by the kernel inadvertently accessing
hypervisor-owned memory that is not properly marked as reserved.

>From boot log, The Qualcomm hypervisor reports the memory range
at 0x91a80000 of size 0x80000 (512 KiB) as hypervisor-owned:
qhee_hyp_assign_remove_memory: 0x91a80000/0x80000 -> ret 0

However, the EFI memory map provided by firmware only reserves the
subrange 0x91a40000–0x91a87fff (288 KiB). The remaining portion
(0x91a88000–0x91afffff) is incorrectly reported as conventional
memory (from efi debug):
efi:   0x000091a40000-0x000091a87fff [Reserved...]
efi:   0x000091a88000-0x0000938fffff [Conventional...]

As a result, the allocator may hand out PFNs inside the hypervisor
owned region, causing fatal aborts when the kernel accesses those
addresses.

Add a reserved-memory carveout for the Gunyah hypervisor metadata
at 0x91a80000 (512 KiB) and mark it as no-map so Linux does not
map or allocate from this area.

For the record:
Hyp version: gunyah-e78adb36e debug (2025-11-17 05:38:05 UTC)
UEFI Ver: 6.0.260122.BOOT.MXF.1.0.c1-00449-KODIAKLA-1

Fixes: 7be190e4bdd2 ("arm64: dts: qcom: add QCS8300 platform")
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260302142603.1113355-1-loic.poulain@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 arch/arm64/boot/dts/qcom/qcs8300.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/qcs8300.dtsi b/arch/arm64/boot/dts/qcom/qcs8300.dtsi
index b8d4a75baee22..7a4c3e872d8ee 100644
--- a/arch/arm64/boot/dts/qcom/qcs8300.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs8300.dtsi
@@ -756,6 +756,11 @@ smem_mem: smem@90900000 {
 			hwlocks = <&tcsr_mutex 3>;
 		};
 
+		gunyah_md_mem: gunyah-md-region@91a80000 {
+			reg = <0x0 0x91a80000 0x0 0x80000>;
+			no-map;
+		};
+
 		lpass_machine_learning_mem: lpass-machine-learning-region@93b00000 {
 			reg = <0x0 0x93b00000 0x0 0xf00000>;
 			no-map;
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] firmware: qcom: scm: Allow QSEECOM on Lenovo IdeaCentre Mini X

[Sasha Levin]

From: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>

[ Upstream commit a31ad9339eff4ce401dec816b01a94b4e3c47898 ]

The Hamoa-based Lenovo IdeaCentre Mini X provides the same UEFI variable
access through uefisecapp as other Hamoa devices, add it to the
allowlist.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260401-ideacentre-v2-3-5745fe2c764e@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have a thorough picture. Let me compile the analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `firmware: qcom: scm`
- Action verb: "Allow" (enable a device on an allowlist)
- Summary: Adds the Lenovo IdeaCentre Mini X to the QSEECOM allowlist
  for UEFI variable access.

**Step 1.2: Tags**
- `Reviewed-by: Dmitry Baryshkov` — Qualcomm maintainer reviewed it
- `Signed-off-by: Bjorn Andersson` — both as author and as committer;
  he's the Qualcomm SCM subsystem maintainer
- `Link:` to lore.kernel.org for the v2 series
- No `Fixes:` tag (expected for a device ID / allowlist addition)
- No `Cc: stable`

**Step 1.3: Commit Body**
The commit explains this is a Hamoa-based device that provides the same
UEFI variable access (through `uefisecapp`) as other Hamoa devices
already on the allowlist. The purpose is to enable UEFI variable access
on this specific hardware.

**Step 1.4: Hidden Bug Fix?**
This is not a hidden bug fix. It's a straightforward device allowlist
addition — enabling existing, validated functionality on a new machine.

Record: This is a device allowlist addition, akin to adding a device ID.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file changed: `drivers/firmware/qcom/qcom_scm.c`
- 1 line added: `{ .compatible = "lenovo,ideacentre-mini-01q8x10" }`
- No lines removed (other than context shift)
- Function affected: static array `qcom_scm_qseecom_allowlist[]`

**Step 2.2: Code Flow Change**
Before: The Lenovo IdeaCentre Mini X is not in the allowlist →
`qcom_scm_qseecom_machine_is_allowed()` returns false →
QSEECOM/uefisecapp is not initialized → no UEFI variable access on this
device.
After: The device is matched → QSEECOM is enabled → UEFI variable access
works.

**Step 2.3: Bug Mechanism**
Category: Hardware enablement / device ID addition. This is analogous to
adding a PCI/USB device ID to an existing driver. The driver and feature
exist; only the allowlist entry is new.

**Step 2.4: Fix Quality**
- Trivially correct — a single compatible string added alphabetically to
  an existing table
- Zero regression risk — only affects this specific machine
- Minimal change (1 line)

## PHASE 3: GIT HISTORY

**Step 3.1: Blame**
The allowlist was introduced by `00b1248606ba39` (Maximilian Luz,
2023-08-27) with just ThinkPad X13s. It has been incrementally expanded
since then with many similar one-line additions. The table has existed
since approximately v6.7.

**Step 3.2: No Fixes: tag** — expected for allowlist additions.

**Step 3.3: File History**
Many similar QSEECOM allowlist additions have been committed: Dell XPS
13, Surface Pro, HP Omnibook, ASUS Vivobook, Lenovo Thinkbook 16, etc.
This is a well-established pattern. Each is a standalone one-liner.

**Step 3.4: Author**
Bjorn Andersson is the Qualcomm SCM subsystem maintainer and the main
committer for this driver. High trust level.

**Step 3.5: Dependencies**
No dependencies. This is a self-contained one-line addition to an
existing table.

## PHASE 4: MAILING LIST

b4 dig failed to find the commit (it's not yet in the tree as a
committed hash). The lore link was blocked by anti-bot protection.
However, the Link: tag shows this is v2 of the series, reviewed by
Dmitry Baryshkov, confirming proper review.

Record: Could not fetch lore discussion due to anti-scraping protection.
The commit has proper review tags.

## PHASE 5: CODE SEMANTIC ANALYSIS

The allowlist is checked by `qcom_scm_qseecom_machine_is_allowed()`
which is called during `qcom_scm_qseecom_init()`. This function gates
whether the QSEECOM/uefisecapp platform device is created. Without the
allowlist entry, the specific machine gets an "untested machine,
skipping" message and UEFI variable access is completely unavailable.

This is critical for the device: without this entry, the user cannot
access UEFI variables at all (including boot configuration).

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Code existence in stable**
- v6.6: The allowlist does NOT exist (0 matches) → Not applicable
- v6.8+: The allowlist exists (3 matches found)
- The allowlist has been present and growing since approximately
  v6.7/v6.8

The commit is relevant for stable trees v6.8+. However, the current file
in mainline has additional entries that may not all be in older stable
trees. The diff should apply cleanly or with trivial context adjustment
since it's just inserting one line in alphabetical order in a table.

**Step 6.2: Backport complications**
Minor context differences possible (some entries in the list may not be
present in older stables), but since this is adding a line to a simple
table, a backport is trivial — worst case requires manual insertion at
the right alphabetical position.

## PHASE 7: SUBSYSTEM CONTEXT

- Subsystem: Qualcomm firmware / SCM (Secure Channel Manager)
- Criticality: IMPORTANT for Qualcomm ARM laptop users. The QSEECOM
  interface provides UEFI variable access, which is essential for boot
  configuration on these devices.
- Very active subsystem with regular allowlist additions.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
Users of the Lenovo IdeaCentre Mini X (Snapdragon/Hamoa-based). Without
this entry, they have no UEFI variable access.

**Step 8.2: Trigger**
Every boot — the allowlist is checked during driver initialization.

**Step 8.3: Severity**
Without this fix: the user cannot access UEFI variables on their
hardware. This is a functional hardware enablement issue.

**Step 8.4: Risk-Benefit**
- Benefit: HIGH — enables essential functionality on real hardware
- Risk: VERY LOW — 1-line addition to a device table, affects only one
  specific machine
- Ratio: Excellent — high benefit, near-zero risk

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- This is a device allowlist addition — directly analogous to adding a
  device ID, which is an established exception category for stable
- 1-line change, trivially correct, zero regression risk
- Written and committed by the subsystem maintainer (Bjorn Andersson)
- Reviewed by Qualcomm maintainer (Dmitry Baryshkov)
- Follows a well-established pattern (20+ similar commits in history)
- Enables essential UEFI variable access on real shipping hardware

**Evidence AGAINST backporting:**
- The allowlist doesn't exist in v6.6 and earlier (limits applicability
  to v6.8+ stable trees)
- This is technically "new hardware enablement" rather than a "bug fix"

**Decision:** This falls squarely into the **device ID / hardware
allowlist addition** exception category. It's a single-line addition to
an existing allowlist table in an existing driver, enabling known-good
functionality on a new machine. The pattern is identical to adding
PCI/USB device IDs. It has proper review, is written by the maintainer,
and carries essentially zero risk.

## Verification

- [Phase 1] Parsed tags: Reviewed-by Dmitry Baryshkov, Signed-off-by
  Bjorn Andersson (2x — author and committer)
- [Phase 2] Diff: 1 line added to `qcom_scm_qseecom_allowlist[]` array —
  a compatible string
- [Phase 3] git blame: allowlist created by commit `00b1248606ba39`
  (v6.7 era, 2023-08-27)
- [Phase 3] git tag --contains: allowlist first in `next-20251219`, not
  in v6.6
- [Phase 3] v6.8 check: allowlist exists with 3 references (confirmed
  with `git show v6.8:...`)
- [Phase 3] git log: 20+ similar QSEECOM allowlist additions in history
  (established pattern)
- [Phase 4] b4 dig: failed to find commit (not yet in tree); lore
  blocked by anti-bot
- [Phase 5] Allowlist checked in `qcom_scm_qseecom_machine_is_allowed()`
  → gates QSEECOM init → without entry, device prints "untested machine,
  skipping" and UEFI access is disabled
- [Phase 6] Applicable to v6.8+ stable trees only; trivial backport
  (table insertion)
- [Phase 8] Risk: VERY LOW (1 line, only affects one machine); Benefit:
  HIGH (enables UEFI access)
- UNVERIFIED: Exact lore discussion content (anti-bot blocked); does not
  affect decision

**YES**

 drivers/firmware/qcom/qcom_scm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index f06bed79666b9..4450741b8221b 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -2301,6 +2301,7 @@ static const struct of_device_id qcom_scm_qseecom_allowlist[] __maybe_unused = {
 	{ .compatible = "hp,omnibook-x14" },
 	{ .compatible = "huawei,gaokun3" },
 	{ .compatible = "lenovo,flex-5g" },
+	{ .compatible = "lenovo,ideacentre-mini-01q8x10" },
 	{ .compatible = "lenovo,thinkbook-16" },
 	{ .compatible = "lenovo,thinkpad-t14s" },
 	{ .compatible = "lenovo,thinkpad-x13s", },
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] ASoC: codecs: wcd-clsh: Always update buck/flyback on transitions on transitions

[Sasha Levin]

From: Cédric Bellegarde <cedric.bellegarde@adishatz.org>

[ Upstream commit f8d51e903a6c97d8d298f14d9f8b4fff808670e3 ]

The WCD934x audio outputs (earpiece, headphone, speaker) share two power
supply converters, a buck and a flyback, managed by reference counters
(buck_users, flyback_users) in the Class-H controller.

The early return in wcd_clsh_ctrl_set_state() when nstate == ctrl->state
prevented _wcd_clsh_ctrl_set_state() from being called when switching
between outputs sharing the same state value. As a result, the buck and
flyback reference counters were never decremented on disable, leaving the
converters active and their counters out of sync with the actual hardware
state.

This caused audible distortion on the earpiece output and spurious MBHC
over-current protection interrupts on HPHL/HPHR during output switching.

Remove the early return so that CLSH_REQ_ENABLE and CLSH_REQ_DISABLE are
always dispatched, keeping the buck and flyback reference counters
consistent on every state transition.

Signed-off-by: Cédric Bellegarde <cedric.bellegarde@adishatz.org>
Link: https://patch.msgid.link/20260304141006.280894-1-cedric.bellegarde@adishatz.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information I need. Let me compile the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem:** ASoC: codecs: wcd-clsh
- **Action verb:** "Always update" (implies something was incorrectly
  not being updated = bug fix)
- **Summary:** Remove an incorrect early return that prevented
  buck/flyback power supply reference counters from being updated during
  audio output transitions.

### Step 1.2: Tags
- **Signed-off-by:** Cédric Bellegarde (author)
- **Link:** https://patch.msgid.link/20260304141006.280894-1-
  cedric.bellegarde@adishatz.org
- **Signed-off-by:** Mark Brown (ASoC maintainer, applied the patch)
- No Fixes: tag, no Reported-by, no Cc: stable — all expected for
  candidate review.

### Step 1.3: Commit Body Analysis
The commit message is detailed and clearly explains:
- **Bug:** Early return in `wcd_clsh_ctrl_set_state()` when `nstate ==
  ctrl->state` prevented `_wcd_clsh_ctrl_set_state()` from being called
  during disable transitions.
- **Root cause:** Each audio output (earpiece, HPHL, HPHR) calls
  `set_state` with the same `nstate` for both enable (PRE_DAC) and
  disable (POST_PA). The early return silently skips the disable call.
- **Symptom:** Buck/flyback reference counters never decremented →
  converters left active → audible distortion on earpiece + spurious
  MBHC over-current interrupts on HPHL/HPHR.
- **Fix:** Remove the 3-line early return.

### Step 1.4: Hidden Bug Fix?
No — this is explicitly described as a bug fix with clear user-visible
symptoms. The commit message thoroughly explains the bug mechanism.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files changed:** 1 (`sound/soc/codecs/wcd-clsh-v2.c`)
- **Lines:** -3, +0 (pure deletion)
- **Function modified:** `wcd_clsh_ctrl_set_state()`
- **Scope:** Single-file, surgical fix

### Step 2.2: Code Flow Change
**Before:** When `nstate == ctrl->state`, the function returns
immediately without calling `_wcd_clsh_ctrl_set_state()`. This means
neither CLSH_REQ_ENABLE nor CLSH_REQ_DISABLE is dispatched.

**After:** The function always proceeds to the switch on `clsh_event`,
dispatching either CLSH_REQ_ENABLE or CLSH_REQ_DISABLE to
`_wcd_clsh_ctrl_set_state()`.

### Step 2.3: Bug Mechanism
This is a **reference counting bug**. Looking at the actual call pattern
in wcd934x.c:

1. **Enable EAR** (PRE_PMU): `set_state(ctrl, PRE_DAC,
   WCD_CLSH_STATE_EAR, CLS_H_NORMAL)` → state=EAR, buck_users++,
   flyback_users++
2. **Disable EAR** (POST_PMD): `set_state(ctrl, POST_PA,
   WCD_CLSH_STATE_EAR, CLS_H_NORMAL)` → nstate=EAR == ctrl->state=EAR →
   **EARLY RETURN!** Buck/flyback never decremented.

The same pattern affects ALL outputs (HPHL, HPHR, LO, AUX) across ALL
WCD codec drivers (wcd9335, wcd934x, wcd937x, wcd938x, wcd939x).

### Step 2.4: Fix Quality
- **Obviously correct:** Yes. The early return was clearly wrong — the
  function uses `clsh_event` (enable vs disable) to dispatch different
  operations, and the early return bypasses this dispatch.
- **Minimal/surgical:** Maximum surgical — 3-line deletion.
- **Regression risk:** Very low. The removed check was a premature
  optimization that incorrectly assumed same nstate means no-op. The
  `_wcd_clsh_ctrl_set_state` sub-functions use reference counting
  (buck_users, flyback_users) which already handles idempotency
  correctly.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
The buggy early return at line 851-852 was introduced in commit
`cc2e324d39b26` ("ASoC: wcd9335: add CLASS-H Controller support") by
Srinivas Kandagatla, merged in **v5.1-rc1**. This code has been present
since the initial creation of the file.

### Step 3.2: Fixes Tag
No Fixes: tag present. However, the bug was clearly introduced by
`cc2e324d39b26` (v5.1-rc1).

### Step 3.3: File History
9 commits to `wcd-clsh-v2.c` since initial creation. Changes have been
minor: unused function removal, new codec version support, symbol
renaming, GENMASK fixes. No prior fix to this early return logic.

### Step 3.4: Author
Cédric Bellegarde has one other commit in the tree (ASoC: qcom: q6asm:
drop DSP responses for closed data streams). Not the subsystem
maintainer, but the patch was accepted by Mark Brown (ASoC maintainer).

### Step 3.5: Dependencies
None. This is a standalone 3-line deletion with no dependencies on other
patches.

---

## PHASE 4: MAILING LIST RESEARCH

### Step 4.1: Original Discussion
Found via web search at yhbt.net/lore mirror. The patch was submitted on
2026-03-04 and applied by Mark Brown on 2026-03-16 to `broonie/sound
for-7.1` (commit `f8d51e903a6c`).

### Step 4.2: Reviewer Feedback
Mark Brown applied directly with no review comments or objections — a
clean accept from the ASoC subsystem maintainer. No NAKs or concerns
raised.

### Step 4.3: Bug Report
No separate bug report; the author discovered this through direct
debugging (audio distortion and spurious interrupts during output
switching).

### Step 4.4: Series Context
Single standalone patch, not part of any series.

### Step 4.5: Stable Discussion
No stable-specific discussion found.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Modified Function
`wcd_clsh_ctrl_set_state()` — exported function, the main API for the
Class-H controller.

### Step 5.2: Callers
`wcd_clsh_ctrl_set_state()` is called from **5 different WCD codec
drivers**:
- `wcd9335.c` — 8 call sites (EAR, HPHL, HPHR, LO)
- `wcd934x.c` — 8 call sites (EAR, HPHL, HPHR, LO)
- `wcd937x.c` — 8 call sites (EAR, HPHL, HPHR, AUX)
- `wcd938x.c` — 10 call sites (EAR, HPHL, HPHR, AUX)
- `wcd939x.c` — 6 call sites (EAR, HPHL, HPHR)

All follow the same pattern: PRE_DAC enable on PMU, POST_PA disable on
PMD.

### Step 5.3-5.4: Call Chain
These are called from DAPM widget event handlers, triggered during
normal audio routing changes. Every user who plays audio through
earpiece, headphones, or speaker on a Qualcomm WCD93xx-based device
triggers this code path.

### Step 5.5: Similar Patterns
The reference counting pattern in `wcd_clsh_buck_ctrl()` and
`wcd_clsh_flyback_ctrl()` (and v3 variants) all use increment-on-
enable/decrement-on-disable with `buck_users`/`flyback_users`. The early
return prevented the decrement path from ever executing.

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Buggy Code in Stable
The bug was introduced in `cc2e324d39b26` (v5.1-rc1). This code exists
in **all active stable trees**: 5.10.y, 5.15.y, 6.1.y, 6.6.y, 6.12.y,
and any other LTS/stable branches.

### Step 6.2: Backport Complications
The file has had only minor changes (renaming, cleanup). The patch is a
simple 3-line deletion that should apply cleanly to all stable trees.

### Step 6.3: Related Fixes
No prior fix for this issue in any stable tree.

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem
- **Path:** sound/soc/codecs/
- **Subsystem:** ASoC (Audio System on Chip) — audio codec drivers
- **Criticality:** IMPORTANT — affects audio on all Qualcomm WCD93xx
  codec-based phones and devices (many Android devices, some embedded
  systems)

### Step 7.2: Activity
Moderately active subsystem with steady fixes and improvements.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Users
All users of Qualcomm WCD93xx-series audio codecs (WCD9335, WCD934x,
WCD937x, WCD938x, WCD939x). This includes many Android phones and
Qualcomm-based embedded systems.

### Step 8.2: Trigger Conditions
- **Trigger:** Any normal audio output switching (e.g., call on
  earpiece, then play music through headphones) — extremely common
  operation.
- **Unprivileged trigger:** Yes — any userspace audio playback triggers
  this.

### Step 8.3: Failure Mode Severity
- **Audible distortion** on earpiece — MEDIUM-HIGH (user-perceivable
  audio quality issue)
- **Spurious MBHC over-current interrupts** — MEDIUM (can cause spurious
  headphone detection events)
- **Power supply reference counter leak** — MEDIUM (converters left
  active, wasted power, potential for undefined hardware behavior)
- Overall severity: **HIGH** — directly affects audio functionality

### Step 8.4: Risk-Benefit Ratio
- **Benefit:** HIGH — fixes audio distortion and spurious interrupts on
  a wide class of devices, bug present since v5.1
- **Risk:** VERY LOW — 3-line deletion, obviously correct, no regression
  risk (the removed check was always wrong)
- **Ratio:** Very favorable for backporting

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Compilation

**FOR backporting:**
- Fixes a real, user-visible bug: audio distortion and spurious
  interrupts
- Reference counting bug — buck/flyback users never decremented on
  disable
- Affects ALL WCD93xx codec users (5 codec drivers, ~40 call sites)
- Bug present since v5.1-rc1 — affects all active stable trees
- Fix is minimal: 3-line deletion, obviously correct
- Applied by ASoC maintainer Mark Brown with no concerns
- No dependencies — standalone fix
- Will apply cleanly to all stable trees

**AGAINST backporting:**
- No Fixes: tag (expected — that's why it's under manual review)
- Author is not the subsystem maintainer
- No formal Reported-by (author found it themselves)

### Step 9.2: Stable Rules Checklist
1. **Obviously correct and tested?** YES — 3-line deletion, logic
   clearly wrong, applied by maintainer
2. **Fixes a real bug?** YES — audio distortion, spurious interrupts,
   reference counter leak
3. **Important issue?** YES — user-perceivable audio quality degradation
   on common hardware
4. **Small and contained?** YES — 3 lines removed from 1 file, 1
   function
5. **No new features or APIs?** YES — pure bug fix
6. **Can apply to stable?** YES — clean apply expected

### Step 9.3: Exception Categories
Not applicable — this is a straightforward bug fix, not an exception
category.

### Step 9.4: Decision
This is a clear, minimal fix for a real reference counting bug that
causes audible audio distortion on all Qualcomm WCD93xx codec-based
devices. The bug has existed since v5.1. The fix is a 3-line deletion
that is obviously correct and was accepted by the ASoC maintainer.

---

## Verification

- [Phase 1] Parsed tags: Signed-off-by (author + Mark Brown), Link to
  patch.msgid.link
- [Phase 2] Diff analysis: 3 lines removed from
  `wcd_clsh_ctrl_set_state()`, removes incorrect early return
- [Phase 2] Verified bug mechanism: PRE_DAC sets state=EAR, POST_PA
  passes same nstate=EAR, early return prevents DISABLE dispatch
- [Phase 2] Verified reference counting: `wcd_clsh_buck_ctrl()` (line
  182-183) and `wcd_clsh_flyback_ctrl()` (line 231-232) use
  increment/decrement of `buck_users`/`flyback_users`
- [Phase 3] git blame: buggy code introduced in cc2e324d39b26 (v5.1-rc1)
  — present since file creation
- [Phase 3] git log: only 9 commits to this file since creation, no
  prior fix for this issue
- [Phase 4] Found original submission at yhbt.net lore mirror: single
  patch, clean accept by Mark Brown for-7.1
- [Phase 4] No NAKs, no review concerns raised
- [Phase 5] Verified callers: 5 codec drivers (wcd9335, wcd934x,
  wcd937x, wcd938x, wcd939x), ~40 call sites, all follow enable/disable
  pattern
- [Phase 6] Code exists in all active stable trees (v5.1+)
- [Phase 6] File has minimal changes — clean apply expected
- [Phase 8] Failure mode: audio distortion + spurious interrupts,
  severity HIGH

**YES**

 sound/soc/codecs/wcd-clsh-v2.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/sound/soc/codecs/wcd-clsh-v2.c b/sound/soc/codecs/wcd-clsh-v2.c
index 13d07296916f6..62ca22ea0f3b6 100644
--- a/sound/soc/codecs/wcd-clsh-v2.c
+++ b/sound/soc/codecs/wcd-clsh-v2.c
@@ -848,9 +848,6 @@ int wcd_clsh_ctrl_set_state(struct wcd_clsh_ctrl *ctrl,
 {
 	struct snd_soc_component *comp = ctrl->comp;
 
-	if (nstate == ctrl->state)
-		return 0;
-
 	if (!wcd_clsh_is_state_valid(nstate)) {
 		dev_err(comp->dev, "Class-H not a valid new state:\n");
 		return -EINVAL;
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.1] drm/msm/dpu: fix vblank IRQ registration before atomic_mode_set

[Sasha Levin]

From: Cédric Bellegarde <cedric.bellegarde@adishatz.org>

[ Upstream commit 961c900628fef77ad07b4bc4c868e47b9a1269c7 ]

dpu_encoder_toggle_vblank_for_crtc() can call control_vblank_irq()
at any time in response to a userspace vblank request, independently
of the atomic commit sequence. If this happens before the encoder's
first atomic_mode_set(), irq[INTR_IDX_RDPTR] is still zero.

Passing irq_idx=0 to dpu_core_irq_register_callback() is treated as
invalid, and DPU_IRQ_REG(0) and DPU_IRQ_BIT(0) produce misleading
values of 134217727 and 31 respectively due to unsigned wraparound
in the (irq_idx - 1) macros, resulting in the confusing error:

  [dpu error]invalid IRQ=[134217727, 31]

Since irq[INTR_IDX_RDPTR] will be properly populated by
atomic_mode_set() and registered by irq_enable() as part of the
normal modeset sequence, silently skip the vblank IRQ registration
when the index has not yet been initialized. This matches the
existing pattern of the master encoder check above it.

Signed-off-by: Cédric Bellegarde <cedric.bellegarde@adishatz.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/712752/
Link: https://lore.kernel.org/r/20260318171700.394945-1-cedric.bellegarde@adishatz.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a complete analysis. Let me
synthesize the findings.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1**: Subject: `drm/msm/dpu:` subsystem prefix. Action verb:
`fix`. Summary: Fix vblank IRQ registration when called before
atomic_mode_set() initializes the IRQ index.

**Step 1.2**: Tags:
- `Signed-off-by: Cédric Bellegarde` (author)
- `Reviewed-by: Dmitry Baryshkov` (subsystem maintainer - strong quality
  signal)
- `Patchwork: https://patchwork.freedesktop.org/patch/712752/`
- `Link: https://lore.kernel.org/r/20260318171700.394945-1-
  cedric.bellegarde@adishatz.org`
- `Signed-off-by: Dmitry Baryshkov` (merged by maintainer)
- No Fixes: tag, no Cc: stable, no Reported-by. Absence of these tags is
  expected.

**Step 1.3**: The commit body explains:
- Bug: `dpu_encoder_toggle_vblank_for_crtc()` can call
  `control_vblank_irq()` at any time via a vblank workqueue,
  independently of the atomic commit sequence.
- Root cause: Before the encoder's first `atomic_mode_set()`,
  `irq[INTR_IDX_RDPTR]` is zero.
- Symptom: Passing irq_idx=0 to `dpu_core_irq_register_callback()`
  produces confusing error: `[dpu error]invalid IRQ=[134217727, 31]` due
  to unsigned wraparound in `(irq_idx - 1)` macros.
- Fix approach: Early return when irq index is 0, matching the existing
  master encoder check pattern.

**Step 1.4**: This is explicitly labeled as a fix, not hidden.

## PHASE 2: DIFF ANALYSIS

**Step 2.1**: Single file changed: `dpu_encoder_phys_cmd.c`. +6 lines
added (including blank line). One function modified:
`dpu_encoder_phys_cmd_control_vblank_irq()`. Scope: single-file surgical
fix.

**Step 2.2**: The change inserts a guard check between the slave encoder
check and the refcount-negative check:
- **Before**: If `irq[INTR_IDX_RDPTR]` is 0, the code proceeds to call
  `dpu_core_irq_register_callback(dpu_kms, 0, ...)`, which fails with
  confusing error messages.
- **After**: The new check catches irq_idx=0 early, returns -EINVAL via
  `goto end`, skipping the confusing `dpu_core_irq_register_callback()`
  error path.

**Step 2.3**: Bug category: **Logic/correctness fix** (missing guard for
uninitialized state). The function can be called via the vblank
workqueue before IRQs are initialized. The macros `DPU_IRQ_REG(0) =
(0-1)/32 = 134217727` and `DPU_IRQ_BIT(0) = (0-1)%32 = 31` produce
wildly misleading error values.

**Step 2.4**: Fix quality: Obviously correct. The check
`!phys_enc->irq[INTR_IDX_RDPTR]` is the simplest possible guard. No
regression risk - returns the same -EINVAL that the existing code path
produces (via `dpu_core_irq_is_valid(0)` returning false), just without
the confusing intermediate error message. Follows the pattern of the
slave encoder check above it.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1**: `git blame` shows the `control_vblank_irq()` function was
introduced by Jeykumar Sankaran in commit `25fdd5933e4c0f` (June 2018),
the original DPU driver submission. The function has been present since
v5.1.

**Step 3.2**: No Fixes: tag present.

**Step 3.3**: Related commits:
- `d13f638c9b88e` (v6.9): Dropped `atomic_mode_set()`, moving IRQ init
  to `irq_enable()` — introduced the bug more acutely
- `35322c39a653c` (v6.11): Reverted the above, re-adding
  `atomic_mode_set()` — partially fixed the issue
- The current fix addresses the remaining race window even after the
  revert, since `control_vblank_irq()` can be called before the first
  `atomic_mode_set()`

**Step 3.4**: The author (Cédric Bellegarde) is not the maintainer but
the patch is reviewed and merged by Dmitry Baryshkov, who is the DPU
subsystem maintainer.

**Step 3.5**: No prerequisites needed. The fix applies to the code as it
exists in the current tree. For older stable trees, the
`vblank_ctl_lock` mutex (added in v6.8 by `45284ff733e4c`) must exist
for the `goto end` pattern to work correctly.

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1**: Both lore.kernel.org and patchwork.freedesktop.org were
blocked by anti-bot protection. The b4 dig search didn't find the commit
directly. However, the patchwork link in the commit metadata
(`patch/712752/`) and the lore link confirm it was submitted and
reviewed through the normal DRM/MSM workflow.

**Step 4.2**: Reviewed by Dmitry Baryshkov (DPU subsystem maintainer),
who also merged the patch. This is the appropriate reviewer.

**Step 4.3-4.5**: Could not fully verify due to anti-bot protections on
lore/patchwork.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1**: Modified function:
`dpu_encoder_phys_cmd_control_vblank_irq()`

**Step 5.2**: Call chain traced:
1. Userspace vblank request → DRM framework
2. `msm_crtc_enable_vblank()` → `vblank_ctrl_queue_work()` (queues work
   item)
3. `vblank_ctrl_worker()` (async workqueue) →
   `kms->funcs->enable_vblank()`
4. `dpu_kms_enable_vblank()` → `dpu_crtc_vblank()` →
   `dpu_encoder_toggle_vblank_for_crtc()`
5. → `phys->ops.control_vblank_irq(phys, enable)` (the function being
   fixed)

This is a common user-reachable path — any userspace app requesting
vblank events.

**Step 5.3-5.4**: The vblank worker runs asynchronously. If it fires
before the first `atomic_mode_set()` in the atomic commit path,
`irq[INTR_IDX_RDPTR]` is still zero. Confirmed at line 159:

```149:163:drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
static void dpu_encoder_phys_cmd_atomic_mode_set(
                struct dpu_encoder_phys *phys_enc,
                struct drm_crtc_state *crtc_state,
                struct drm_connector_state *conn_state)
{
        // ... sets irq[INTR_IDX_RDPTR] here
        if (phys_enc->has_intf_te)
                phys_enc->irq[INTR_IDX_RDPTR] =
phys_enc->hw_intf->cap->intr_tear_rd_ptr;
        else
                phys_enc->irq[INTR_IDX_RDPTR] =
phys_enc->hw_pp->caps->intr_rdptr;
        // ...
}
```

**Step 5.5**: The video encoder
(`dpu_encoder_phys_vid_control_vblank_irq`) has a similar pattern with
`INTR_IDX_VSYNC` but lacks this guard. Potentially a related issue
exists there too.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1**: The buggy code (`control_vblank_irq` without the guard)
exists in all stable trees since v5.1. The async vblank workqueue path
that triggers it also exists in all DPU-capable stable trees.

**Step 6.2**: Backport complications:
- v6.12.y and later: Should apply cleanly (mutex locking exists since
  v6.8)
- v6.6.y: The `vblank_ctl_lock` mutex doesn't exist; function uses
  different locking. Would need adaptation.

**Step 6.3**: The related revert `35322c39a653c` (v6.11) fixed the acute
version of this problem but didn't address the remaining race window
this fix covers.

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1**: Subsystem: `drivers/gpu/drm/msm/disp/dpu1/` — DPU display
driver for Qualcomm SoCs. Criticality: IMPORTANT. Used in Qualcomm-based
phones, Chromebooks, and development boards (Dragonboard, Robotics RB
series).

**Step 7.2**: Active subsystem with regular commits from Dmitry
Baryshkov and other contributors.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1**: Affects users of Qualcomm command-mode DSI panels (common
in mobile devices and some Chromebooks).

**Step 8.2**: Trigger: Userspace requesting vblank events before the
first atomic modeset completes. This can happen during display
initialization if applications request vblank timing early. The vblank
workqueue makes this asynchronous and timing-dependent.

**Step 8.3**: Failure mode: Confusing error messages in dmesg (`invalid
IRQ=[134217727, 31]`). Not a crash, not data corruption, not a security
issue. Severity: **MEDIUM** — the error messages are misleading and can
cause confusion during debugging, but the system still functions
correctly because `dpu_core_irq_is_valid(0)` catches the invalid index.

**Step 8.4**:
- **Benefit**: MEDIUM — eliminates confusing error messages for CMD DSI
  panel users; makes the code path cleaner and more intentional
- **Risk**: VERY LOW — 5 lines, obviously correct guard check, returns
  same error code, no change in functional behavior
- **Ratio**: Favorable — low risk fix with meaningful user-facing
  improvement

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- Small, surgical fix (5 lines in one function)
- Obviously correct — simple NULL/zero check before use
- Reviewed and merged by subsystem maintainer (Dmitry Baryshkov)
- Fixes a real race condition between async vblank workqueue and atomic
  commit
- Eliminates confusing error messages (`invalid IRQ=[134217727, 31]`)
  caused by unsigned wraparound
- Follows existing code pattern in the same function (master encoder
  guard)
- Affects real hardware (Qualcomm CMD DSI panels in mobile/Chromebook)
- No regression risk — returns same error as existing path

**Evidence AGAINST backporting:**
- Not fixing a crash, security issue, or data corruption
- Primarily an error message cleanup (existing code already handles
  irq_idx=0 correctly via `dpu_core_irq_is_valid`)
- May need adaptation for older stable trees (v6.6.y lacks mutex)

**Stable rules checklist:**
1. Obviously correct and tested? **YES** — trivial guard, reviewed by
   maintainer
2. Fixes a real bug? **YES** — race condition producing confusing errors
3. Important issue? **MEDIUM** — not crash/security, but user-visible
   error messages on real hardware
4. Small and contained? **YES** — 5 lines in one function
5. No new features or APIs? **YES**
6. Can apply to stable trees? **YES** for v6.12.y+; needs adaptation for
   v6.6.y

## Verification

- [Phase 1] Parsed tags: Reviewed-by Dmitry Baryshkov (maintainer), Link
  to lore, Patchwork link. No Fixes/Cc:stable (expected).
- [Phase 2] Diff analysis: 5 lines added to
  `dpu_encoder_phys_cmd_control_vblank_irq()`, guards against
  irq[INTR_IDX_RDPTR]==0 before calling dpu_core_irq_register_callback.
- [Phase 2] Verified DPU_IRQ_REG/DPU_IRQ_BIT macros at
  `dpu_hw_interrupts.h:40-41`: `(irq_idx - 1) / 32` and `(irq_idx - 1) %
  32` — confirmed unsigned wraparound when irq_idx=0.
- [Phase 2] Verified `dpu_core_irq_is_valid(0)` at
  `dpu_hw_interrupts.c:289-292`: returns false, so existing code catches
  it but after printing confusing values.
- [Phase 3] git blame: `control_vblank_irq()` introduced by
  `25fdd5933e4c0f` (v5.1, June 2018), present in all stable trees.
- [Phase 3] git show `35322c39a653c`: Confirmed revert of
  `d13f638c9b88e`, with identical call trace showing the same race
  condition this fix addresses.
- [Phase 3] `d13f638c9b88e` (v6.9) dropped atomic_mode_set;
  `35322c39a653c` (v6.11) reverted it. Current fix addresses remaining
  race window.
- [Phase 4] Lore/patchwork blocked by anti-bot protection — could not
  verify full discussion.
- [Phase 5] Traced full call chain: `msm_crtc_enable_vblank →
  vblank_ctrl_queue_work → vblank_ctrl_worker → dpu_kms_enable_vblank →
  dpu_crtc_vblank → dpu_encoder_toggle_vblank_for_crtc →
  control_vblank_irq`. Confirmed async workqueue makes this race
  realistic.
- [Phase 5] Verified `atomic_mode_set()` at line 149-164 initializes
  `irq[INTR_IDX_RDPTR]` — confirmed it's the only place this IRQ index
  is set.
- [Phase 5] Verified `dpu_encoder_toggle_vblank_for_crtc()` ignores the
  return value from `control_vblank_irq()`.
- [Phase 6] `vblank_ctl_lock` mutex added in v6.8 (`45284ff733e4c`) —
  confirmed this dependency for backport to v6.6.y.
- [Phase 7] Confirmed active subsystem with regular Dmitry Baryshkov
  contributions.
- [Phase 8] Failure mode: confusing error messages, no crash/corruption.
  Severity: MEDIUM.
- UNVERIFIED: Full mailing list discussion (lore blocked). Cannot
  confirm if stable was discussed or if there are NAKs.

The fix is small, obviously correct, reviewed by the maintainer, and
addresses a real race condition on Qualcomm command-mode DSI panels.
While the primary impact is eliminating confusing error messages rather
than preventing crashes, the fix improves code robustness with
negligible regression risk.

**YES**

 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index 93db1484f6069..45079ee59cf67 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -257,6 +257,12 @@ static int dpu_encoder_phys_cmd_control_vblank_irq(
 	if (!dpu_encoder_phys_cmd_is_master(phys_enc))
 		goto end;
 
+	/* IRQ not yet initialized */
+	if (!phys_enc->irq[INTR_IDX_RDPTR]) {
+		ret = -EINVAL;
+		goto end;
+	}
+
 	/* protect against negative */
 	if (!enable && refcount == 0) {
 		ret = -EINVAL;
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] firmware: qcom: scm: Allow QSEECOM on ECS LIVA QC710

[Sasha Levin]

From: Val Packett <val@packett.cool>

[ Upstream commit 34a49e8508b5d00816d25fe3758b474471e7e051 ]

Allow this machine to access efivars through qseecom/uefisecapp.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Val Packett <val@packett.cool>
Link: https://lore.kernel.org/r/20260120234029.419825-11-val@packett.cool
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have a clear picture. Let me finalize my analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `firmware: qcom: scm`
- Action: "Allow" — enabling hardware functionality
- Summary: Add ECS LIVA QC710 to the QSEECOM allowlist for EFI variable
  access.

**Step 1.2: Tags**
- `Reviewed-by: Dmitry Baryshkov` — Qualcomm subsystem reviewer
- `Signed-off-by: Val Packett` — patch author
- `Link:` to lore (message-id:
  `20260120234029.419825-11-val@packett.cool`) — patch 11 of a series
- `Signed-off-by: Bjorn Andersson` — subsystem maintainer who merged it
- No Fixes: tag (expected for an allowlist addition)
- No Cc: stable (expected for this review)

**Step 1.3: Commit Body**
The body is a single sentence: "Allow this machine to access efivars
through qseecom/uefisecapp." Without this entry, the ECS LIVA QC710
cannot access UEFI EFI variables, which are needed for firmware settings
and boot configuration.

**Step 1.4: Hidden Bug Fix Detection**
This is not a hidden bug fix. It is a straightforward hardware
enablement / device ID addition.

Record: This is a device allowlist addition, enabling EFI variable
access on a specific Qualcomm-based machine.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file changed: `drivers/firmware/qcom/qcom_scm.c`
- 1 line added: `{ .compatible = "ecs,liva-qc710" },`
- Function: N/A — it's a static data table entry
- Scope: Trivially small, single-line addition to an allowlist array

**Step 2.2: Code Flow Change**
Before: ECS LIVA QC710 is not in the allowlist, so
`qcom_scm_qseecom_init()` prints "untested machine, skipping" and
QSEECOM/uefisecapp is not initialized.
After: The machine is matched, QSEECOM is initialized, and EFI variables
become accessible.

**Step 2.3: Bug Mechanism**
Category: Hardware enablement / device ID addition. Not a bug fix per
se, but enables critical firmware functionality (EFI variable access) on
a specific machine.

**Step 2.4: Fix Quality**
- Obviously correct — adding one compatible string to a sorted allowlist
- Minimal / surgical — one line
- Zero regression risk — only affects the specific machine by compatible
  string match
- Reviewed by Qualcomm reviewer, merged by subsystem maintainer

## PHASE 3: GIT HISTORY

**Step 3.1: Blame**
The allowlist was introduced in commit `00b1248606ba39` ("Add support
for Qualcomm Secure Execution Environment SCM interface"), tagged
`v6.6-rc1-2`, which means it appeared in v6.7. Multiple similar entries
have been added since.

**Step 3.3: File History**
There are 17+ similar "Allow QSEECOM on <machine>" commits — this is a
well-established pattern.

**Step 3.5: Dependencies**
The diff also shows `asus,vivobook-s15-x1p4` and `qcom,purwa-iot-evk`
entries that don't exist in the current tree. These come from other
patches in the same series (patch 11 of a multi-patch series). However,
the `ecs,liva-qc710` line itself is independent — it's just an addition
to an alphabetically-sorted list with no dependencies on other entries.

## PHASE 4: MAILING LIST

The Link header references `20260120234029.419825-11-val@packett.cool`,
indicating this is patch 11 of a larger series. The patch was reviewed
by Dmitry Baryshkov (Qualcomm reviewer) and merged by Bjorn Andersson
(the subsystem maintainer).

## PHASE 5: CODE SEMANTIC ANALYSIS

The allowlist is used in `qcom_scm_qseecom_init()` which checks
`of_machine_device_match(qcom_scm_qseecom_allowlist)` (in mainline) or
`qcom_scm_qseecom_machine_is_allowed()` (in older stable trees). If the
machine isn't in the list, QSEECOM is skipped entirely. The change only
affects the specific ECS LIVA QC710 machine.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Code Existence in Stable Trees**
- v6.6: Does NOT have the allowlist (code doesn't exist) — not
  applicable
- v6.7 through v6.13+: DO have the allowlist
- Active stable trees with this code: 6.12.y and any other LTS ≥ 6.7

**Step 6.2: Backport Complications**
The one-line addition should apply cleanly. In older stable trees, the
surrounding list entries may differ slightly (fewer entries), but the
addition of a new compatible string to the sorted list is trivial to
resolve if there's a minor context conflict. The function mechanism (old
`qcom_scm_qseecom_machine_is_allowed` vs new `of_machine_device_match`)
doesn't matter — only the data table is modified.

## PHASE 7: SUBSYSTEM CONTEXT

- Subsystem: Qualcomm SCM firmware interface
- Criticality: PERIPHERAL — affects users of specific Qualcomm ARM
  platforms
- This is an actively developed subsystem with many contributors adding
  machine support

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Who is Affected**
Only users of the ECS LIVA QC710 (Qualcomm-based mini PC).

**Step 8.2: Trigger**
Every boot — without this entry, EFI variables are completely
inaccessible on this machine.

**Step 8.3: Failure Mode**
Without the fix: EFI variables are inaccessible, which means users
cannot manage boot configuration, firmware settings, or Secure Boot
through the standard Linux efivars interface. Severity: MEDIUM-HIGH for
users of this specific hardware.

**Step 8.4: Risk-Benefit Ratio**
- BENEFIT: Enables critical firmware functionality for a specific
  machine
- RISK: Essentially zero — only a data table entry, only affects the
  specific machine by exact compatible string match
- Assessment: Very favorable ratio

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- Classic device ID / allowlist addition pattern — exception category
  that is routinely backported
- One-line change with zero regression risk
- Enables critical firmware functionality (EFI variable access)
- Well-reviewed by subsystem reviewer and maintainer
- Established pattern with 17+ identical precedent commits

**Evidence AGAINST backporting:**
- This is hardware enablement, not a bug fix in the traditional sense
- Only affects a single specific machine
- The allowlist doesn't exist in v6.6.y (oldest active LTS)

**Stable Rules Checklist:**
1. Obviously correct? YES — single allowlist entry
2. Fixes a real bug? It enables required functionality — comparable to a
   device ID addition
3. Important issue? Medium-important for affected hardware users
4. Small and contained? YES — 1 line
5. No new features? Correct — just enables existing feature on
   additional hardware
6. Can apply to stable? YES for 6.12.y and later stable trees

**Exception Category:** Device ID / hardware allowlist addition to
existing driver — this is an explicitly allowed exception for stable
trees.

## Verification

- [Phase 1] Parsed tags: Reviewed-by Dmitry Baryshkov, Link to lore,
  Signed-off-by Bjorn Andersson (maintainer)
- [Phase 2] Diff: Single line `{ .compatible = "ecs,liva-qc710" }` added
  to allowlist table
- [Phase 3] git blame: allowlist introduced in 00b1248606ba39 at
  v6.6-rc1-2, present from v6.7+
- [Phase 3] git log: 17+ identical "Allow QSEECOM on <machine>" commits
  exist as precedent
- [Phase 4] b4 dig for similar commit (30ee285f1e3cd): confirmed review
  and merge pattern
- [Phase 5] Allowlist controls access in qcom_scm_qseecom_init(), only
  matched machine is affected
- [Phase 6] Allowlist exists in v6.7+ (verified via git show for v6.6
  through v6.13); not in v6.6
- [Phase 6] v6.12 uses `qcom_scm_qseecom_machine_is_allowed()` — data
  table change applies regardless
- [Phase 8] Risk: zero — one-line data table entry, only affects
  specific machine by exact compatible match

This is a textbook device ID / allowlist addition. It's a single line,
zero-risk, enables important firmware functionality for a specific
machine, and follows a long-established pattern of identical commits
that are routinely backported.

**YES**

 drivers/firmware/qcom/qcom_scm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index 2fe1632f06e90..f06bed79666b9 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -2296,6 +2296,7 @@ static const struct of_device_id qcom_scm_qseecom_allowlist[] __maybe_unused = {
 	{ .compatible = "dell,inspiron-14-plus-7441" },
 	{ .compatible = "dell,latitude-7455" },
 	{ .compatible = "dell,xps13-9345" },
+	{ .compatible = "ecs,liva-qc710" },
 	{ .compatible = "hp,elitebook-ultra-g1q" },
 	{ .compatible = "hp,omnibook-x14" },
 	{ .compatible = "huawei,gaokun3" },
-- 
2.53.0

[PATCH AUTOSEL 6.18] arm64: dts: qcom: hamoa/x1: fix idle exit latency

[Sasha Levin]

From: Daniel J Blueman <daniel@quora.org>

[ Upstream commit 3ecea84d2b90bbf934d5ca75514fa902fd71e03f ]

Designs based on the Qualcomm X1 Hamoa reference platform report:
driver: Idle state 1 target residency too low

This is because the declared X1 idle entry plus exit latency of 680us
exceeds the declared minimum 600us residency time:
  entry-latency-us = <180>;
  exit-latency-us = <500>;
  min-residency-us = <600>;

Fix this to be 320us so the sum of the entry and exit latencies matches
the downstream 500us exit latency, as directed by Maulik.

Tested on a Lenovo Yoga Slim 7x with Qualcomm X1E-80-100.

Fixes: 2e65616ef07f ("arm64: dts: qcom: x1e80100: Update C4/C5 residency/exit numbers")
Signed-off-by: Daniel J Blueman <daniel@quora.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260220124626.8611-1-daniel@quora.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 arch/arm64/boot/dts/qcom/x1e80100.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
index 6d97329995fe7..efe8d5e7079fe 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
@@ -281,7 +281,7 @@ cluster_c4: cpu-sleep-0 {
 				idle-state-name = "ret";
 				arm,psci-suspend-param = <0x00000004>;
 				entry-latency-us = <180>;
-				exit-latency-us = <500>;
+				exit-latency-us = <320>;
 				min-residency-us = <600>;
 			};
 		};
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] firmware: qcom: scm: allow QSEECOM on ASUS Vivobook X1P42100 variant

[Sasha Levin]

From: Jens Glathe <jens.glathe@oldschoolsolutions.biz>

[ Upstream commit 26b86610650eaac17bf6574f34d9119151b95483 ]

Enables access to EFI variables on this machine.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Tested-by: Colin K. Williams <colin@li-nk.org>
Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Link: https://lore.kernel.org/r/20260214-b4-vivobook-v3-2-3c88065bbf77@oldschoolsolutions.biz
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Here is my complete analysis:

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `firmware: qcom: scm`
- Action verb: "allow" — enabling a device on an existing allowlist
- Summary: Add ASUS Vivobook X1P42100 variant to the QSEECOM allowlist

**Step 1.2: Tags**
- `Reviewed-by: Dmitry Baryshkov` — a well-known Qualcomm subsystem
  reviewer
- `Tested-by: Colin K. Williams` — independently tested by another
  person
- `Signed-off-by: Jens Glathe` — author, also contributed multiple other
  QSEECOM allowlist entries (HP Omnibook X14, Lenovo Thinkbook 16,
  Windows Dev Kit 2023)
- `Signed-off-by: Bjorn Andersson` — subsystem maintainer who accepted
  the patch
- `Link:` to lore.kernel.org (v3 of the patch series)
- No syzbot, no Fixes: tag (expected)

**Step 1.3: Body**
- "Enables access to EFI variables on this machine."
- Without this entry, the ASUS Vivobook X1P42100 variant cannot access
  EFI variables, which is a fundamental firmware interface needed for
  boot configuration and UEFI operations.

**Step 1.4: Hidden Bug Fix?**
This is not a disguised bug fix — it's an explicit hardware allowlist
addition.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file changed: `drivers/firmware/qcom/qcom_scm.c`
- 1 line added: `{ .compatible = "asus,vivobook-s15-x1p4" },`
- Function: static data table `qcom_scm_qseecom_allowlist[]`

**Step 2.2: Code Flow**
- Before: The allowlist does not include the X1P42100 variant;
  `qcom_scm_qseecom_init()` skips QSEECOM initialization on this
  machine, printing "untested machine, skipping"
- After: The allowlist includes the variant; QSEECOM is initialized,
  enabling EFI variable access

**Step 2.3: Bug Mechanism**
Category: Hardware enablement — adding a device compatible string to an
existing allowlist table. This is functionally identical to adding a
PCI/USB device ID.

**Step 2.4: Fix Quality**
- Obviously correct: a single compatible string added to a static array
- Minimal/surgical: 1 line
- Regression risk: effectively zero — only affects the specific ASUS
  Vivobook X1P42100 variant
- Pattern is well-established: the allowlist has had dozens of similar
  additions

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
The allowlist was created in commit `00b1248606ba39` (2023-08-27) and
first appeared in v6.7. The table structure has been unchanged; only new
entries have been added over time.

**Step 3.2: No Fixes: tag** — expected.

**Step 3.3: File History**
Many identical one-line QSEECOM allowlist additions have been made:
Dell, HP, Lenovo, Microsoft Surface, Huawei, Medion, etc. This is a
well-trodden pattern.

**Step 3.4: Author**
Jens Glathe has contributed 3 other QSEECOM allowlist entries (HP
Omnibook X14, Lenovo Thinkbook 16, Windows Dev Kit 2023). They are a
regular contributor to this subsystem.

**Step 3.5: Dependencies**
None. This is a self-contained one-line table addition with no code
dependencies.

## PHASE 4: MAILING LIST RESEARCH

The Link tag shows this is v3 of the series
(`20260214-b4-vivobook-v3-2-...`), meaning it went through review
iterations. The patch was reviewed by Dmitry Baryshkov (prominent
Qualcomm maintainer) and tested by an independent tester (Colin K.
Williams). The subsystem maintainer Bjorn Andersson applied it.

Lore was unreachable via WebFetch (Anubis protection), but b4 dig
confirmed the pattern matches other QSEECOM allowlist additions.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1-5.4:** The `qcom_scm_qseecom_allowlist` is used in
`qcom_scm_qseecom_init()` which calls
`of_machine_device_match(qcom_scm_qseecom_allowlist)` (v6.19+) or the
open-coded equivalent in earlier kernels. If the machine's compatible
string isn't in the list, QSEECOM is not initialized, and EFI variable
access is unavailable.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1:** The allowlist was introduced in v6.7. It exists in stable
trees v6.12.y and later. It does NOT exist in v6.6.y or earlier.

**Step 6.2:** Backport should be clean for v6.12.y+ since the table
format is identical. The only difference is that v6.19 introduced
`of_machine_device_match()` instead of the open-coded function, but that
doesn't affect the table entries.

**Step 6.3:** No related fixes already in stable.

## PHASE 7: SUBSYSTEM CONTEXT

- Subsystem: `firmware/qcom` — Qualcomm firmware interface, used by
  Qualcomm Snapdragon ARM64 laptops
- Criticality: IMPORTANT — these are real consumer laptops (ASUS
  Vivobook line)
- The subsystem is active with regular QSEECOM allowlist additions

## PHASE 8: IMPACT AND RISK

**Step 8.1:** Affected users: owners of ASUS Vivobook X1P42100 variant
laptops running Linux
**Step 8.2:** Trigger: every boot — without this entry, EFI variables
are inaccessible on this hardware
**Step 8.3:** Failure mode: no EFI variable access = unable to manage
boot entries, firmware settings. Severity: MEDIUM-HIGH for affected
users
**Step 8.4:**
- Benefit: HIGH — enables core firmware functionality on real consumer
  hardware
- Risk: VERY LOW — 1 line, only affects the specific machine
- Ratio: Excellent

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR:**
- Classic device ID / allowlist addition — explicitly listed as an
  exception in stable rules
- 1-line change, zero regression risk to any other machine
- Reviewed by Qualcomm subsystem reviewer, tested independently,
  accepted by maintainer
- Well-established pattern with dozens of identical precedents
- Enables fundamental functionality (EFI variable access) on real
  consumer hardware
- Author is a known contributor to this exact subsystem

**Evidence AGAINST:**
- None significant. The only caveat is it doesn't apply to v6.6.y or
  earlier (the allowlist didn't exist then)

**Stable Rules Checklist:**
1. Obviously correct? YES — single compatible string in a static table
2. Fixes real issue? YES — enables EFI access on real hardware
3. Important? YES — EFI variables are fundamental for boot management
4. Small and contained? YES — 1 line
5. No new features? CORRECT — enables existing feature on additional
   hardware
6. Applies to stable? YES — clean for v6.12.y+

**Exception Category: Device ID / hardware allowlist addition** —
explicitly allowed.

## Verification

- [Phase 1] Parsed tags: Reviewed-by Dmitry Baryshkov, Tested-by Colin
  K. Williams, maintainer SOB Bjorn Andersson
- [Phase 2] Diff analysis: 1 line added to static
  `qcom_scm_qseecom_allowlist[]` table
- [Phase 3] git blame: allowlist created in `00b1248606ba39` (v6.7,
  2023-08-27), table structure unchanged
- [Phase 3] git log --grep="QSEECOM": confirmed ~18 similar allowlist
  additions over time
- [Phase 3] git log --author="Jens Glathe": author has 3 prior QSEECOM
  allowlist contributions
- [Phase 4] b4 dig: lore thread found for similar commits confirming
  review pattern
- [Phase 4] Link tag shows v3 — patch went through review iterations
- [Phase 5] Grep: `qcom_scm_qseecom_allowlist` used in
  `qcom_scm_qseecom_init()` at line 2352
- [Phase 6] `git tag --contains 00b1248606ba39`: first in v6.7, exists
  in v6.12.y+ stable trees
- [Phase 6] `f83b42705782c` (Simplify with of_machine_device_match) is
  v6.19+, does not affect table format
- [Phase 8] 1-line change with zero cross-machine risk, enables EFI on
  specific hardware

**YES**

 drivers/firmware/qcom/qcom_scm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index 8fbc96693a55f..2fe1632f06e90 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -2290,6 +2290,7 @@ EXPORT_SYMBOL_GPL(qcom_scm_qseecom_app_send);
  */
 static const struct of_device_id qcom_scm_qseecom_allowlist[] __maybe_unused = {
 	{ .compatible = "asus,vivobook-s15" },
+	{ .compatible = "asus,vivobook-s15-x1p4" },
 	{ .compatible = "asus,zenbook-a14-ux3407qa" },
 	{ .compatible = "asus,zenbook-a14-ux3407ra" },
 	{ .compatible = "dell,inspiron-14-plus-7441" },
-- 
2.53.0

[PATCH AUTOSEL 6.18] arm64: dts: qcom: qcm6490-idp: Fix WCD9370 reset GPIO polarity

[Sasha Levin]

From: Ravi Hothi <ravi.hothi@oss.qualcomm.com>

[ Upstream commit b7df21c59739cceb7b866c6c5e8a6ba03875ab71 ]

The WCD9370 audio codec reset line on QCM6490 IDP should be active-low, but
the device tree described it as active-high. As a result, the codec is
kept in reset and fails to reset the SoundWire, leading to timeouts
and ASoC card probe failure (-ETIMEDOUT).

Fix the reset GPIO polarity to GPIO_ACTIVE_LOW so the codec can properly
initialize.

Fixes: aa04c298619f ("arm64: dts: qcom: qcm6490-idp: Add WSA8830 speakers and WCD9370 headset codec")
Signed-off-by: Ravi Hothi <ravi.hothi@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260220090220.2992193-1-ravi.hothi@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/qcm6490-idp.dts b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
index 73fce639370cd..214671b462770 100644
--- a/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
+++ b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
@@ -177,7 +177,7 @@ wcd9370: audio-codec-0 {
 		pinctrl-0 = <&wcd_default>;
 		pinctrl-names = "default";
 
-		reset-gpios = <&tlmm 83 GPIO_ACTIVE_HIGH>;
+		reset-gpios = <&tlmm 83 GPIO_ACTIVE_LOW>;
 
 		vdd-buck-supply = <&vreg_l17b_1p7>;
 		vdd-rxtx-supply = <&vreg_l18b_1p8>;
-- 
2.53.0

[PATCH AUTOSEL 6.18] soc: qcom: pd-mapper: Fix element length in servreg_loc_pfr_req_ei

[Sasha Levin]

From: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>

[ Upstream commit 641f6fda143b879da1515f821ee475073678cf2a ]

It looks element length declared in servreg_loc_pfr_req_ei for reason
not matching servreg_loc_pfr_req's reason field due which we could
observe decoding error on PD crash.

  qmi_decode_string_elem: String len 81 >= Max Len 65

Fix this by matching with servreg_loc_pfr_req's reason field.

Fixes: 1ebcde047c54 ("soc: qcom: add pd-mapper implementation")
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Tested-by: Nikita Travkin <nikita@trvn.ru>
Link: https://lore.kernel.org/r/20260129152320.3658053-2-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 drivers/soc/qcom/pdr_internal.h | 2 +-
 drivers/soc/qcom/qcom_pdr_msg.c | 2 +-
 include/linux/soc/qcom/pdr.h    | 1 +
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/qcom/pdr_internal.h b/drivers/soc/qcom/pdr_internal.h
index 039508c1bbf7d..047c0160b6178 100644
--- a/drivers/soc/qcom/pdr_internal.h
+++ b/drivers/soc/qcom/pdr_internal.h
@@ -84,7 +84,7 @@ struct servreg_set_ack_resp {
 
 struct servreg_loc_pfr_req {
 	char service[SERVREG_NAME_LENGTH + 1];
-	char reason[257];
+	char reason[SERVREG_PFR_LENGTH + 1];
 };
 
 struct servreg_loc_pfr_resp {
diff --git a/drivers/soc/qcom/qcom_pdr_msg.c b/drivers/soc/qcom/qcom_pdr_msg.c
index ca98932140d87..02022b11ecf05 100644
--- a/drivers/soc/qcom/qcom_pdr_msg.c
+++ b/drivers/soc/qcom/qcom_pdr_msg.c
@@ -325,7 +325,7 @@ const struct qmi_elem_info servreg_loc_pfr_req_ei[] = {
 	},
 	{
 		.data_type = QMI_STRING,
-		.elem_len = SERVREG_NAME_LENGTH + 1,
+		.elem_len = SERVREG_PFR_LENGTH + 1,
 		.elem_size = sizeof(char),
 		.array_type = VAR_LEN_ARRAY,
 		.tlv_type = 0x02,
diff --git a/include/linux/soc/qcom/pdr.h b/include/linux/soc/qcom/pdr.h
index 83a8ea612e69a..2b7691e47c2a9 100644
--- a/include/linux/soc/qcom/pdr.h
+++ b/include/linux/soc/qcom/pdr.h
@@ -5,6 +5,7 @@
 #include <linux/soc/qcom/qmi.h>
 
 #define SERVREG_NAME_LENGTH	64
+#define SERVREG_PFR_LENGTH	256
 
 struct pdr_service;
 struct pdr_handle;
-- 
2.53.0

[PATCH AUTOSEL 6.18] arm64: dts: qcom: monaco: Fix UART10 pinconf

[Sasha Levin]

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

[ Upstream commit 5b2a16ab0dbd090dc545c05ee79a077cc7a9c1e0 ]

UART10 RTS and TX pins were incorrectly mapped to gpio84 and gpio85.
Correct them to gpio85 (RTS) and gpio86 (TX) to match the hardware
I/O mapping.

Fixes: 467284a3097f ("arm64: dts: qcom: qcs8300: Add QUPv3 configuration")
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260202155611.1568-1-loic.poulain@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 arch/arm64/boot/dts/qcom/qcs8300.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/qcs8300.dtsi b/arch/arm64/boot/dts/qcom/qcs8300.dtsi
index 8d78ccac411e4..b8d4a75baee22 100644
--- a/arch/arm64/boot/dts/qcom/qcs8300.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs8300.dtsi
@@ -5430,12 +5430,12 @@ qup_uart10_cts: qup-uart10-cts-state {
 			};
 
 			qup_uart10_rts: qup-uart10-rts-state {
-				pins = "gpio84";
+				pins = "gpio85";
 				function = "qup1_se2";
 			};
 
 			qup_uart10_tx: qup-uart10-tx-state {
-				pins = "gpio85";
+				pins = "gpio86";
 				function = "qup1_se2";
 			};
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] drm: gpu: msm: forbid mem reclaim from reset

[Sasha Levin]

From: Sergey Senozhatsky <senozhatsky@chromium.org>

[ Upstream commit 4625fe5bbdaccd45be274c30ff0a42e30d4e38cf ]

We sometimes get into a situtation where GPU hangcheck fails to
recover GPU:

[..]
msm_dpu ae01000.display-controller: [drm:hangcheck_handler] *ERROR* (IPv4: 1): hangcheck detected gpu lockup rb 0!
msm_dpu ae01000.display-controller: [drm:hangcheck_handler] *ERROR* (IPv4: 1): completed fence: 7840161
msm_dpu ae01000.display-controller: [drm:hangcheck_handler] *ERROR* (IPv4: 1): submitted fence: 7840162
msm_dpu ae01000.display-controller: [drm:hangcheck_handler] *ERROR* (IPv4: 1): hangcheck detected gpu lockup rb 0!
msm_dpu ae01000.display-controller: [drm:hangcheck_handler] *ERROR* (IPv4: 1): completed fence: 7840162
msm_dpu ae01000.display-controller: [drm:hangcheck_handler] *ERROR* (IPv4: 1): submitted fence: 7840163
[..]

The problem is that msm_job worker is blocked on gpu->lock

INFO: task ring0:155 blocked for more than 122 seconds.
Not tainted 6.6.99-08727-gaac38b365d2c #1
task:ring0 state:D stack:0 pid:155 ppid:2 flags:0x00000008
Call trace:
__switch_to+0x108/0x208
schedule+0x544/0x11f0
schedule_preempt_disabled+0x30/0x50
__mutex_lock_common+0x410/0x850
__mutex_lock_slowpath+0x28/0x40
mutex_lock+0x5c/0x90
msm_job_run+0x9c/0x140
drm_sched_main+0x514/0x938
kthread+0x114/0x138
ret_from_fork+0x10/0x20

which is owned by recover worker, which is waiting for DMA fences
from a memory reclaim path, under the very same gpu->lock

INFO: task ring0:155 is blocked on a mutex likely owned by task gpu-worker:154.
task:gpu-worker state:D stack:0 pid:154 ppid:2 flags:0x00000008
Call trace:
__switch_to+0x108/0x208
schedule+0x544/0x11f0
schedule_timeout+0x1f8/0x770
dma_fence_default_wait+0x108/0x218
dma_fence_wait_timeout+0x6c/0x1c0
dma_resv_wait_timeout+0xe4/0x118
active_purge+0x34/0x98
drm_gem_lru_scan+0x1d0/0x388
msm_gem_shrinker_scan+0x1cc/0x2e8
shrink_slab+0x228/0x478
shrink_node+0x380/0x730
try_to_free_pages+0x204/0x510
__alloc_pages_direct_reclaim+0x90/0x158
__alloc_pages_slowpath+0x1d4/0x4a0
__alloc_pages+0x9f0/0xc88
vm_area_alloc_pages+0x17c/0x260
__vmalloc_node_range+0x1c0/0x420
kvmalloc_node+0xe8/0x108
msm_gpu_crashstate_capture+0x1e4/0x280
recover_worker+0x1c0/0x638
kthread_worker_fn+0x150/0x2d8
kthread+0x114/0x138

So no one can make any further progress.

Forbid recover/fault worker to enter memory reclaim (under
gpu->lock) to address this deadlock scenario.

Cc: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Reviewed-by: Rob Clark <rob.clark@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/700978/
Message-ID: <20260127073341.2862078-1-senozhatsky@chromium.org>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have a complete picture. Let me compile the final analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `drm: gpu: msm` (Qualcomm MSM GPU driver)
- Action verb: "forbid" — preventing a dangerous code path
- Summary: Prevent memory reclaim from GPU reset/fault handlers to avoid
  deadlock

**Step 1.2: Tags**
- `Cc: Tomasz Figa <tfiga@chromium.org>` — ChromeOS stakeholder
- `Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>` —
  author, ChromeOS/mm developer
- `Reviewed-by: Rob Clark <rob.clark@oss.qualcomm.com>` — MSM subsystem
  maintainer
- `Patchwork: https://patchwork.freedesktop.org/patch/700978/`
- `Message-ID: <20260127073341.2862078-1-senozhatsky@chromium.org>`
- `Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>` —
  committer/maintainer
- No Fixes: tag (expected for manual review candidates)

**Step 1.3: Body Analysis**
The commit message contains detailed stack traces showing:
1. A GPU lockup detected by hangcheck, triggering `recover_worker`
2. `recover_worker` holds `gpu->lock` and is blocked trying to allocate
   memory
3. The allocation triggers `__alloc_pages_direct_reclaim` ->
   `shrink_slab` -> `msm_gem_shrinker_scan` -> `active_purge` ->
   `dma_fence_default_wait`
4. The DMA fences cannot complete because the GPU is hung and
   `gpu->lock` is held
5. Deadlock: `msm_job_run` needs `gpu->lock` (owned by `recover_worker`)
   and `recover_worker` is stuck in reclaim waiting on DMA fences that
   can't signal

**Step 1.4: Hidden Bug Fix Detection**
This is an explicit deadlock fix, not disguised.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Single file: `drivers/gpu/drm/msm/msm_gpu.c`
- 1 include added, ~10 lines of actual logic across 2 functions
- Functions modified: `recover_worker()`,
  `msm_gpu_fault_crashstate_capture()`

**Step 2.2: Code Flow Change**
In both functions, the pattern is identical:
- BEFORE: crashstate capture runs with default GFP flags, allowing
  reclaim
- AFTER: `memalloc_noreclaim_save()` called before crashstate capture,
  `memalloc_noreclaim_restore()` called after, preventing the kernel
  from entering memory reclaim while `gpu->lock` is held

**Step 2.3: Bug Mechanism**
Category: **Deadlock**. The mechanism:
1. `recover_worker` acquires `gpu->lock`
2. `msm_gpu_crashstate_capture()` calls `kvmalloc()` (line 239 in
   `msm_gpu_crashstate_get_bo`)
3. Under memory pressure, `kvmalloc` -> `__alloc_pages_slowpath` ->
   `try_to_free_pages` -> `shrink_slab`
4. `msm_gem_shrinker_scan` -> `active_purge` -> `wait_for_idle` ->
   `dma_resv_wait_timeout`
5. DMA fences can't signal because the GPU is hung — recovery needs
   `gpu->lock` which is already held

**Step 2.4: Fix Quality**
- Minimal and surgical: only adds `memalloc_noreclaim_save/restore`
  bracketing
- Well-established kernel pattern (used in amdgpu, i915)
- Regression risk: extremely low — only changes allocation behavior
  within a narrow scope
- Review: accepted by Rob Clark (MSM maintainer)

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
- `recover_worker` structure dates back to Rob Clark 2013, with
  gpu->lock added in c28e2f2b417ed7 (v5.16, 2021-11-09)
- `msm_gpu_crashstate_capture` added in c0fec7f562ec76 (v4.20/v5.0,
  2018-07-24)
- `msm_gpu_fault_crashstate_capture` introduced in e25e92e08e32c6
  (v5.15, 2021-06-10), refactored in 0c5fea1eb0dc2 (v7.0)
- The deadlock has existed since v5.16 when gpu->lock was introduced
  alongside crashstate capture

**Step 3.2: No Fixes tag to follow**

**Step 3.3: Related Changes**
- Commit 4bea53b9c7c72 "drm/msm: Reduce fallout of fence signaling vs
  reclaim hangs" (2023-11-17) — Rob Clark reduced shrinker timeout from
  1000ms to 10ms as a *partial* workaround for this exact class of
  deadlock. This confirms the issue was known.

**Step 3.4: Author**
- Sergey Senozhatsky is a well-known kernel developer (mm subsystem,
  compression, ChromeOS)
- Rob Clark is the MSM subsystem maintainer who reviewed and committed
  the fix

**Step 3.5: Dependencies**
- Standalone fix, no dependencies on other patches
- The `#include <linux/sched/mm.h>` header is available in all relevant
  stable trees
- `memalloc_noreclaim_save/restore` available since at least v4.x

## PHASE 4: MAILING LIST

**Step 4.1-4.2:** Patchwork link confirms this was reviewed through the
freedesktop.org DRM process. Rob Clark (subsystem maintainer) provided
`Reviewed-by` and committed the patch.

**Step 4.3:** No specific bug report link, but the commit includes real
stack traces from a production system running kernel 6.6.99, indicating
this was hit on ChromeOS devices.

**Step 4.4:** Single standalone patch (not part of a series).

**Step 4.5:** Could not verify stable-specific discussion due to anti-
bot protections on lore.kernel.org.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1:** Modified functions: `recover_worker()`,
`msm_gpu_fault_crashstate_capture()`

**Step 5.2:** `recover_worker` is queued by `hangcheck_handler` (timer
callback) whenever a GPU lockup is detected.
`msm_gpu_fault_crashstate_capture` is called from IOMMU fault handlers.

**Step 5.3:** Both call `msm_gpu_crashstate_capture` which calls
`kvmalloc` (via `msm_gpu_crashstate_get_bo`), the trigger for the
deadlock.

**Step 5.4:** Call chain: `hangcheck_timer` -> `hangcheck_handler` ->
`kthread_queue_work(recover_work)` -> `recover_worker`. This is the
standard GPU hang recovery path triggered automatically.

**Step 5.5:** Similar pattern exists in amdgpu and i915 where
`memalloc_noreclaim_save` is used to prevent reclaim deadlocks in GPU
driver paths.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1:** The buggy code exists in all stable trees from v5.16+
(when `gpu->lock` was introduced). In older trees (v6.6),
`recover_worker` and `fault_worker` have the same deadlock pattern. The
code confirmed in v6.6 and v6.12 stable branches.

**Step 6.2:** The patch won't apply cleanly to older trees (v6.6) due
to:
- VM_BIND code differences in `recover_worker`
- `fault_worker` vs `msm_gpu_fault_crashstate_capture` name change
- `msm_gpu_crashstate_capture` has 4 args in v6.6 vs 5 in v7.0
But the fix concept is trivially adaptable. For v7.0.y it should apply
cleanly.

**Step 6.3:** Only the partial workaround (4bea53b9c7c72, timeout
reduction) has been applied previously.

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1:** `drivers/gpu/drm/msm/` — Qualcomm Adreno GPU driver.
Criticality: **IMPORTANT** — used on millions of Qualcomm SoC devices
(Chromebooks, phones, embedded systems).

**Step 7.2:** Actively developed subsystem with many recent commits.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1:** Affects all Qualcomm Adreno GPU users running with the MSM
DRM driver.

**Step 8.2:** Trigger: GPU hang + memory pressure. GPU hangs occur in
real-world usage. Under memory pressure (common on memory-constrained
mobile/embedded devices), the deadlock triggers. The stack trace shows
it was reproduced on a ChromeOS device.

**Step 8.3:** Failure mode: **DEADLOCK** — the system hangs completely
(GPU recovery blocked for >122 seconds, tasks blocked indefinitely).
Severity: **CRITICAL**.

**Step 8.4:**
- **Benefit:** HIGH — prevents complete system deadlock on common
  hardware
- **Risk:** VERY LOW — adds ~10 lines of well-established
  `memalloc_noreclaim_save/restore` pattern, reviewed by subsystem
  maintainer

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- Fixes a real, documented deadlock with stack traces
- Observed on production hardware (ChromeOS, kernel 6.6.99)
- Small, surgical fix (~10 lines of real changes)
- Uses well-established kernel pattern (`memalloc_noreclaim_save`)
- Reviewed by Rob Clark (MSM subsystem maintainer)
- Previous partial workaround (4bea53b9c7c72) confirms the issue was
  known
- Affects widely-deployed Qualcomm hardware
- Bug present in all stable trees since v5.16

**Evidence AGAINST backporting:**
- May need minor adaptation for older stable trees (different function
  names/signatures)
- No explicit Cc: stable tag (expected for review candidates)

**Stable rules checklist:**
1. Obviously correct and tested? YES — well-established pattern,
   reviewed by maintainer, real stack traces
2. Fixes a real bug? YES — documented deadlock
3. Important issue? YES — system deadlock (CRITICAL severity)
4. Small and contained? YES — single file, ~10 lines of logic
5. No new features/APIs? YES — purely a fix
6. Can apply to stable? YES for v7.0.y (clean), needs minor rework for
   v6.6.y

## Verification

- [Phase 1] Parsed tags: Reviewed-by Rob Clark (MSM maintainer), Cc
  Tomasz Figa, Patchwork link
- [Phase 2] Diff analysis: ~10 lines added across `recover_worker()` and
  `msm_gpu_fault_crashstate_capture()`, adds
  `memalloc_noreclaim_save/restore` bracketing around crashstate capture
- [Phase 3] git blame: `recover_worker` with `gpu->lock` since
  c28e2f2b417ed7 (v5.16), crashstate capture since c0fec7f562ec76
  (v4.20)
- [Phase 3] Related fix 4bea53b9c7c72: Rob Clark acknowledged this
  deadlock class, applied partial workaround (timeout reduction)
- [Phase 3] No dependencies found; standalone patch
- [Phase 4] Patchwork link confirms DRM review process; anti-bot
  protection prevented lore fetch
- [Phase 5] `recover_worker` called from hangcheck timer path;
  `msm_gpu_crashstate_capture` allocates memory via `kvmalloc` in
  `msm_gpu_crashstate_get_bo`
- [Phase 6] Confirmed buggy code exists in v6.6 (line 354+, 449+) and
  v6.12 (line 355+, 478+)
- [Phase 6] v7.0.y: should apply cleanly; older trees need minor
  adaptation
- [Phase 7] MSM GPU driver — IMPORTANT subsystem (Qualcomm Adreno,
  millions of devices)
- [Phase 8] Failure mode: system deadlock (CRITICAL), triggered by GPU
  hang + memory pressure
- [Phase 8] Stack trace from real ChromeOS device running kernel 6.6.99

**YES**

 drivers/gpu/drm/msm/msm_gpu.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 84d6c7f50c8df..67033bb01a9b0 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -17,6 +17,7 @@
 #include <linux/string_helpers.h>
 #include <linux/devcoredump.h>
 #include <linux/sched/task.h>
+#include <linux/sched/mm.h>
 
 /*
  * Power Management:
@@ -468,6 +469,7 @@ static void recover_worker(struct kthread_work *work)
 	struct msm_gem_submit *submit;
 	struct msm_ringbuffer *cur_ring = gpu->funcs->active_ring(gpu);
 	char *comm = NULL, *cmd = NULL;
+	unsigned int noreclaim_flag;
 	struct task_struct *task;
 	int i;
 
@@ -505,6 +507,8 @@ static void recover_worker(struct kthread_work *work)
 			msm_gem_vm_unusable(submit->vm);
 	}
 
+	noreclaim_flag = memalloc_noreclaim_save();
+
 	get_comm_cmdline(submit, &comm, &cmd);
 
 	if (comm && cmd) {
@@ -523,6 +527,8 @@ static void recover_worker(struct kthread_work *work)
 	pm_runtime_get_sync(&gpu->pdev->dev);
 	msm_gpu_crashstate_capture(gpu, submit, NULL, comm, cmd);
 
+	memalloc_noreclaim_restore(noreclaim_flag);
+
 	kfree(cmd);
 	kfree(comm);
 
@@ -587,6 +593,7 @@ void msm_gpu_fault_crashstate_capture(struct msm_gpu *gpu, struct msm_gpu_fault_
 	struct msm_gem_submit *submit;
 	struct msm_ringbuffer *cur_ring = gpu->funcs->active_ring(gpu);
 	char *comm = NULL, *cmd = NULL;
+	unsigned int noreclaim_flag;
 
 	mutex_lock(&gpu->lock);
 
@@ -594,6 +601,8 @@ void msm_gpu_fault_crashstate_capture(struct msm_gpu *gpu, struct msm_gpu_fault_
 	if (submit && submit->fault_dumped)
 		goto resume_smmu;
 
+	noreclaim_flag = memalloc_noreclaim_save();
+
 	if (submit) {
 		get_comm_cmdline(submit, &comm, &cmd);
 
@@ -609,6 +618,8 @@ void msm_gpu_fault_crashstate_capture(struct msm_gpu *gpu, struct msm_gpu_fault_
 	msm_gpu_crashstate_capture(gpu, submit, fault_info, comm, cmd);
 	pm_runtime_put_sync(&gpu->pdev->dev);
 
+	memalloc_noreclaim_restore(noreclaim_flag);
+
 	kfree(cmd);
 	kfree(comm);
 
-- 
2.53.0