public inbox for linux-arm-msm@vger.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Jens Glathe <jens.glathe@oldschoolsolutions.biz>,
	Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
	"Colin K. Williams" <colin@li-nk.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Sasha Levin <sashal@kernel.org>,
	konradybcio@kernel.org, linux-arm-msm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 7.0-6.18] firmware: qcom: scm: allow QSEECOM on ASUS Vivobook X1P42100 variant
Date: Mon, 20 Apr 2026 09:19:54 -0400	[thread overview]
Message-ID: <20260420132314.1023554-200-sashal@kernel.org> (raw)
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>

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


  parent reply	other threads:[~2026-04-20 13:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260420132314.1023554-1-sashal@kernel.org>
2026-04-20 13:16 ` [PATCH AUTOSEL 7.0-5.15] remoteproc: qcom: Fix minidump out-of-bounds access on subsystems array Sasha Levin
2026-04-20 13:17 ` [PATCH AUTOSEL 6.18] arm64: dts: qcom: monaco: Reserve full Gunyah metadata region Sasha Levin
2026-04-20 13:17 ` [PATCH AUTOSEL 7.0-6.18] firmware: qcom: scm: Allow QSEECOM on Lenovo IdeaCentre Mini X Sasha Levin
2026-04-20 13:17 ` [PATCH AUTOSEL 7.0-5.10] ASoC: codecs: wcd-clsh: Always update buck/flyback on transitions on transitions Sasha Levin
2026-04-20 13:18 ` [PATCH AUTOSEL 7.0-6.1] drm/msm/dpu: fix vblank IRQ registration before atomic_mode_set Sasha Levin
2026-04-20 13:18 ` [PATCH AUTOSEL 7.0-6.18] firmware: qcom: scm: Allow QSEECOM on ECS LIVA QC710 Sasha Levin
2026-04-20 13:19 ` [PATCH AUTOSEL 6.18] arm64: dts: qcom: hamoa/x1: fix idle exit latency Sasha Levin
2026-04-20 13:19 ` Sasha Levin [this message]
2026-04-20 13:20 ` [PATCH AUTOSEL 6.18] arm64: dts: qcom: qcm6490-idp: Fix WCD9370 reset GPIO polarity Sasha Levin
2026-04-20 13:21 ` [PATCH AUTOSEL 6.18] soc: qcom: pd-mapper: Fix element length in servreg_loc_pfr_req_ei Sasha Levin
2026-04-20 13:21 ` [PATCH AUTOSEL 6.18] arm64: dts: qcom: monaco: Fix UART10 pinconf Sasha Levin
2026-04-20 13:21 ` [PATCH AUTOSEL 7.0-6.18] drm: gpu: msm: forbid mem reclaim from reset Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260420132314.1023554-200-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=andersson@kernel.org \
    --cc=colin@li-nk.org \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=jens.glathe@oldschoolsolutions.biz \
    --cc=konradybcio@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox