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

[Sasha Levin <sashal@kernel.org>]

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