[PATCH AUTOSEL 6.18-5.15] ACPI: FPDT: validate table and record lengths

[PATCH AUTOSEL 6.18-5.15] ACPI: FPDT: validate table and record lengths

[Sasha Levin]

From: Pengpeng Hou <pengpeng@iscas.ac.cn>

[ Upstream commit 458b40fcdd04a9a0334830de5a536d8425454e4b ]

FPDT records are supplied by firmware and are walked through
length fields stored in the table itself.

Check the main-table entry length before reading an entry, check
the mapped subtable length before remapping it, and check each
record length before saving a typed record pointer for sysfs.

This keeps malformed firmware records from being interpreted as
complete resume, suspend, or boot records when the current item
is shorter than the structure consumed by the driver.

Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260706094141.82438-1-pengpeng@iscas.ac.cn
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

I have enough verified history, diff, and review context to judge this
against the local 7.3-rc4 tree.

## Phase 1: Commit message forensics

**Step 1.1: Subject line**
Record: **[ACPI / FPDT] [validate] check firmware-supplied FPDT
table/record lengths before walking them or exposing typed records via
sysfs**

**Step 1.2: Tags**
Record:
- `Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>` (author)
- `Link:
  https://patch.msgid.link/20260706094141.82438-1-pengpeng@iscas.ac.cn`
- `Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>` (ACPI
  maintainer)
- No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-
  by:`, or `Cc: stable` (absence expected here)
- Ignore any pipeline `Signed-off-by: Sasha Levin` / `[Upstream commit
  ...]` markers

**Step 1.3: Body**
Record:
- **Bug:** FPDT entries/records are walked using length fields supplied
  by firmware. The driver previously trusted those lengths.
- **Symptom:** A truncated/malformed record can be treated as a full
  resume, suspend, or boot record. Sysfs then consumes a larger C struct
  than the firmware item actually occupies.
- **Root cause:** Missing bounds checks before mapping the subtable,
  before advancing the walker, and before storing typed pointers.
- **Versions:** none stated. Introduced with FPDT support, not by a
  later feature.

**Step 1.4: Hidden bug fix?**
Record: Not hidden. It is an explicit firmware bounds-check plus a
signature-mismatch unmap. That is a real OOB/leak fix, not style
cleanup.

## Phase 2: Diff analysis

**Step 2.1: Inventory**
Record:
- File: `drivers/acpi/acpi_fpdt.c` only (`+47 / -6`)
- Functions: `fpdt_process_subtable()`, `acpi_init_fpdt()`
- Scope: single-file surgical fix

**Step 2.2: Code flow**
Record (verified against parent `458b40fcdd04a^`):

1. **Signature mismatch:** mapped header was returned without unmap →
   now unmaps (fixes ioremap leak).
2. **Subtable remap:** `length` from firmware was passed to
   `acpi_os_map_memory()` with no lower bound → reject if `length <
   sizeof(*subtable_header)`.
3. **Record walk:** header was read and `offset +=
   record_header->length` before checking remaining space; only zero
   length was rejected (`a83c68a3bf7c4`) → require a full header,
   `length >= sizeof(header)`, and `length <= remaining`; zero is still
   rejected because `sizeof(*record_header)` is 4.
4. **Typed records:** `RECORD_S3_RESUME` / `SUSPEND` / `BOOT` stored
   pointers used by sysfs (`sizeof` 24 / 20 / 48) with no size check →
   reject if the firmware length is smaller than the struct.
5. **Main FPDT table:** walker did `offset += sizeof(*subtable)` with no
   leftover-bytes check → reject truncated/invalid entry lengths, then
   advance by `subtable->length` (spec length field).

**Step 2.3: Bug mechanism**
Record:
- **Category:** memory safety (OOB read) + resource leak
- **Mechanism:** firmware-controlled lengths were used as cursor and as
  justification to treat a short blob as a full
  `resume_performance_record` / `suspend_performance_record` /
  `boot_performance_record`. Sysfs `*_show` helpers then read fields
  past the real record. Truncated headers could also read past the
  mapped subtable.

**Step 2.4: Fix quality**
Record: Obviously correct, localized, no API/feature change. Regression
risk is low. The one behavioral change is walking the main table by
`subtable->length` instead of a fixed 16-byte stride. Spec pointer
records are 16 bytes (`struct fpdt_subtable_entry` /
`acpi_fpdt_boot_pointer`). Firmware with a garbage non-zero length in an
otherwise packed 16-byte table could now skip or fail FPDT init instead
of parsing later entries; that fails closed (no FPDT sysfs), not a
kernel crash. No follow-up on this file after `458b40fcdd04a`.

## Phase 3: Git history

**Step 3.1: Blame**
Record: Buggy walker comes from `d1eb86e59be09` (“ACPI: tables:
introduce support for FPDT table”, 2021-01-29), first in **v5.12-rc1**.
Zero-length hang was later fixed by `a83c68a3bf7c4` (2023), which did
**not** check truncated non-zero lengths or typed-struct size.

**Step 3.2: Fixes: tag**
Record: none. The incomplete predecessor is `a83c68a3bf7c4` (`Fixes:
d1eb86e59be0`, `Cc: stable`). That confirms the class (malformed FPDT
firmware) is real; this commit finishes the length checks.

**Step 3.3: File history**
Record (newest first):
- `458b40fcdd04a` this commit
- `8dcb4485e7672` expose FBPT/S3PT via sysfs (already in this tree;
  ancestor of the fix)
- `a83c68a3bf7c4` zero-length / invalid subtables
- `211391bf04b3c` invalid phys address
- `d1eb86e59be09` introduce driver

Standalone length-validation patch, not `N/M`.

**Step 3.4: Author**
Record: Pengpeng Hou; same period also `2c50ffdc73f3a` “ACPI: processor:
validate MADT IOAPIC entry bounds” (same firmware-table bounds pattern).
Not the ACPI maintainer; Rafael applied it.

**Step 3.5: Dependencies**
Record: No extra helpers. Needs the FPDT driver (`d1eb86e59be09`),
present here. `8dcb4485e7672` is already an ancestor (`git merge-base
--is-ancestor` succeeded). Can apply in this tree; it is already an
ancestor of HEAD.

## Phase 4: Mailing list / external

**Step 4.1:** `b4 dig -c 458b40fcdd04a` →
https://patch.msgid.link/20260706094141.82438-1-pengpeng@iscas.ac.cn
`b4 dig -a`: **v1 only**. Thread saved to mbox (2 messages).
Rafael: **“Applied as 7.3 material, thanks!”** No NAK, no requested
respin, no `Cc: stable` in review.

**Step 4.2:** `b4 dig -w` recipients: Pengpeng Hou, Rafael J. Wysocki,
Len Brown, linux-acpi, linux-kernel. Maintainer was on To/Cc and merged
it.

**Step 4.3:** No bugzilla/syzbot/Reported-by. No extra crash report
beyond the commit text. Related real hardware: `a83c68a3bf7c4` already
documented buggy FPDT BIOS tables (zero-length S3PT record, duplicated
FBPT signature).

**Step 4.4:** Not a multi-patch series.

**Step 4.5:** lore.kernel.org/stable search returned HTTP 403.
**UNVERIFIED:** whether stable@ discussed this hash.

## Phase 5: Semantic / reachability

**Step 5.1:** `fpdt_process_subtable`, `acpi_init_fpdt`.

**Step 5.2:** `acpi_init_fpdt` is `fs_initcall`; only caller of
`fpdt_process_subtable` is that init function. Boot path, not
interrupt/hot path.

**Step 5.3:** `acpi_get_table` / `acpi_os_map_memory` /
`acpi_os_unmap_memory` / `sysfs_create_group`. Records are later read by
sysfs `*_show` using `record_boot` / `record_suspend` / `record_resume`.

**Step 5.4:** Reachable when `CONFIG_ACPI_FPDT=y` and firmware publishes
FPDT. Userspace cannot craft the ACPI table on a locked-down platform;
VMs and broken BIOS can. Sysfs is the consumer of the typed pointers.

**Step 5.5:** Same pattern as the author’s MADT IOAPIC length checks.
Prior FPDT fix only handled length==0.

## Phase 6: This checkout

**Step 6.1:** `git describe HEAD` → **v7.3-rc4-27-gf0100363d8c37**.
`make kernelversion` → **7.3.0-rc4**.
`git merge-base --is-ancestor 458b40fcdd04a HEAD` → yes.
Current `drivers/acpi/acpi_fpdt.c` already contains the new checks
(lines 190–219, 223–226, 243–246, 262–265, 347–360, 374).
Buggy walker has existed in this lineage since v5.12.

**Step 6.2:** Backport difficulty **clean apply** here (already merged).
No later conflicting edits on this file.

**Step 6.3:** Related fix `a83c68a3bf7c4` is present (zero-length only).
It does not replace this patch.

## Phase 7: Subsystem

**Step 7.1:** ACPI FPDT driver under `drivers/acpi/`. **IMPORTANT**
(common x86_64/ARM64/LOONGARCH firmware table), not mm/core.
`CONFIG_ACPI_FPDT` is opt-in (`bool`, not `default y`); local `.config`
has it unset. Not staging.

**Step 7.2:** File is mature (2021–2026, few commits). This is hardening
of long-standing parse code, not a brand-new subsystem.

## Phase 8: Impact and risk

**Step 8.1:** Users who enable `CONFIG_ACPI_FPDT` on
x86_64/ARM64/LOONGARCH and whose firmware exposes FPDT. Not universal.

**Step 8.2:** Trigger is boot-time FPDT parse (`fs_initcall`) with a
malformed table. Unprivileged userspace cannot normally inject ACPI
tables; broken BIOS and untrusted VM firmware can. Real malformed FPDT
firmware is already documented.

**Step 8.3:** Failure mode:
- Read past mapped subtable → possible oops during boot
  (**HIGH/CRITICAL** if it faults)
- Short record accepted → sysfs reads adjacent firmware bytes (wrong
  data / info leak, **HIGH** memory-safety)
- Signature-mismatch ioremap leak at init (**LOW**, one-shot)

Severity: **HIGH** (firmware-controlled OOB on an enabled driver).

**Step 8.4:** Benefit high for FPDT-enabled systems with bad tables;
risk low (47 lines, fail closed, maintainer-acked, no revert).

## Phase 9: Synthesis

**For backporting**
- Firmware-supplied lengths used as walk cursor and as struct size:
  classic OOB.
- Completes a known FPDT firmware-bug class (`a83c68a3bf7c4` already
  proved bad BIOSes and was sent to stable).
- Also fixes a real `acpi_os_map_memory` leak on signature mismatch.
- Small, single-file, obviously correct; Rafael merged it.
- Driver and buggy code exist in this tree; no missing prerequisites.

**Against**
- No crash log / syzbot / `Fixes:` / explicit stable nomination.
- `CONFIG_ACPI_FPDT` is opt-in, not defconfig.
- Rafael labeled it “7.3 material,” not stable, but that is merge-window
  wording, not a NAK of the bug.
- Main-table walk-by-length could hide later entries if firmware lies
  about length; fail-closed.

**Unresolved**
- UNVERIFIED: stable@ thread (lore 403).
- UNVERIFIED: which distros set `CONFIG_ACPI_FPDT=y`.

**Stable rules**
1. Obviously correct and tested? **PASS** (v1 applied as-is by ACPI
   maintainer; in 7.3-rc4 with no follow-up revert).
2. Real user-affecting bug? **PASS** (OOB + leak on firmware tables;
   prior FPDT BIOS bugs in the wild).
3. Important (crash/security/corruption/deadlock)? **PASS** (OOB read
   from firmware lengths; possible oops or sysfs leak).
4. Small/contained? **PASS** (`+47/-6`, one file).
5. No new features/APIs? **PASS**.
6. Applies to this tree? **PASS**.

**Exception category:** none required (not a device-
ID/quirk/DT/build/doc exception). It is a straightforward memory-safety
fix.

This tree is **7.3.0-rc4**. The FPDT walker has been here since v5.12,
so the bug is in this lineage. The patch is small, correct, and prevents
firmware-controlled out-of-bounds reads (and an ioremap leak) in
`acpi_init_fpdt`. That meets stable criteria for this checkout.

### Verification
- [Phase 1] Parsed tags: author SOB, Rafael SOB, msgid Link; no
  Fixes/Reported-by/Cc stable
- [Phase 2] `git show 458b40fcdd04a`: +47/-6 in
  `drivers/acpi/acpi_fpdt.c`; parent walker lacked remaining/size
  checks; signature path leaked the map
- [Phase 2] Struct sizes: header 4, resume 24, suspend 20, boot 48,
  subtable entry 16
- [Phase 3] `git blame`: checks from `458b40fcdd04a`; original walker
  `d1eb86e59be09` (v5.12-rc1)
- [Phase 3] `git merge-base --is-ancestor 458b40fcdd04a HEAD` → 0
  (present)
- [Phase 3] `a83c68a3bf7c4` only handled zero length; `Cc: stable` on
  that older hang fix
- [Phase 3] `8dcb4485e7672` is ancestor; no later commits on this file
- [Phase 4] `b4 dig -c/-a/-w/-m`: v1 only; Rafael “Applied as 7.3
  material, thanks!”; lists linux-acpi + Rafael + Len Brown
- [Phase 4] lore.kernel.org WebFetch/curl → 403; stable@ discussion
  UNVERIFIED
- [Phase 5] `acpi_init_fpdt` is `fs_initcall`; only caller of
  `fpdt_process_subtable`
- [Phase 6] `git describe HEAD` = v7.3-rc4-27-gf0100363d8c37; current
  file already has the validation
- [Phase 7] `CONFIG_ACPI_FPDT` depends on X86_64||ARM64||LOONGARCH, not
  default y
- [Phase 8] Failure mode: firmware OOB on FPDT parse / sysfs typed reads
- UNVERIFIED: distro `CONFIG_ACPI_FPDT` defaults; stable@ mailing-list
  history

**YES**

 drivers/acpi/acpi_fpdt.c | 53 +++++++++++++++++++++++++++++++++++-----
 1 file changed, 47 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/acpi_fpdt.c b/drivers/acpi/acpi_fpdt.c
index 271092f2700a1..058d1ad47699a 100644
--- a/drivers/acpi/acpi_fpdt.c
+++ b/drivers/acpi/acpi_fpdt.c
@@ -165,7 +165,7 @@ static int fpdt_process_subtable(u64 address, u32 subtable_type)
 	struct fpdt_subtable_header *subtable_header;
 	struct fpdt_record_header *record_header;
 	char *signature = (subtable_type == SUBTABLE_FBPT ? "FBPT" : "S3PT");
-	u32 length, offset;
+	u32 length, offset, remaining;
 	int result;
 
 	if (!fpdt_address_valid(address)) {
@@ -179,10 +179,17 @@ static int fpdt_process_subtable(u64 address, u32 subtable_type)
 
 	if (strncmp((char *)&subtable_header->signature, signature, 4)) {
 		pr_info(FW_BUG "subtable signature and type mismatch!\n");
+		acpi_os_unmap_memory(subtable_header, sizeof(*subtable_header));
 		return -EINVAL;
 	}
 
 	length = subtable_header->length;
+	if (length < sizeof(*subtable_header)) {
+		pr_err(FW_BUG "Invalid FPDT subtable length %u.\n", length);
+		acpi_os_unmap_memory(subtable_header, sizeof(*subtable_header));
+		return -EINVAL;
+	}
+
 	acpi_os_unmap_memory(subtable_header, sizeof(*subtable_header));
 
 	subtable_header = acpi_os_map_memory(address, length);
@@ -191,17 +198,29 @@ static int fpdt_process_subtable(u64 address, u32 subtable_type)
 
 	offset = sizeof(*subtable_header);
 	while (offset < length) {
-		record_header = (void *)subtable_header + offset;
-		offset += record_header->length;
+		remaining = length - offset;
+		if (remaining < sizeof(*record_header)) {
+			pr_err(FW_BUG "Truncated FPDT record header.\n");
+			result = -EINVAL;
+			goto err;
+		}
 
-		if (!record_header->length) {
-			pr_err(FW_BUG "Zero-length record found in FPTD.\n");
+		record_header = (void *)subtable_header + offset;
+		if (record_header->length < sizeof(*record_header) ||
+		    record_header->length > remaining) {
+			pr_err(FW_BUG "Invalid FPDT record length %u.\n",
+			       record_header->length);
 			result = -EINVAL;
 			goto err;
 		}
+		offset += record_header->length;
 
 		switch (record_header->type) {
 		case RECORD_S3_RESUME:
+			if (record_header->length < sizeof(*record_resume)) {
+				result = -EINVAL;
+				goto err;
+			}
 			if (subtable_type != SUBTABLE_S3PT) {
 				pr_err(FW_BUG "Invalid record %d for subtable %s\n",
 				     record_header->type, signature);
@@ -218,6 +237,10 @@ static int fpdt_process_subtable(u64 address, u32 subtable_type)
 				goto err;
 			break;
 		case RECORD_S3_SUSPEND:
+			if (record_header->length < sizeof(*record_suspend)) {
+				result = -EINVAL;
+				goto err;
+			}
 			if (subtable_type != SUBTABLE_S3PT) {
 				pr_err(FW_BUG "Invalid %d for subtable %s\n",
 				     record_header->type, signature);
@@ -233,6 +256,10 @@ static int fpdt_process_subtable(u64 address, u32 subtable_type)
 				goto err;
 			break;
 		case RECORD_BOOT:
+			if (record_header->length < sizeof(*record_boot)) {
+				result = -EINVAL;
+				goto err;
+			}
 			if (subtable_type != SUBTABLE_FBPT) {
 				pr_err(FW_BUG "Invalid %d for subtable %s\n",
 				     record_header->type, signature);
@@ -289,7 +316,21 @@ static int __init acpi_init_fpdt(void)
 	}
 
 	while (offset < header->length) {
+		if (header->length - offset < sizeof(*subtable)) {
+			pr_err(FW_BUG "Truncated FPDT subtable entry.\n");
+			result = -EINVAL;
+			goto err_subtable;
+		}
+
 		subtable = (void *)header + offset;
+		if (subtable->length < sizeof(*subtable) ||
+		    subtable->length > header->length - offset) {
+			pr_err(FW_BUG "Invalid FPDT subtable entry length %u.\n",
+			       subtable->length);
+			result = -EINVAL;
+			goto err_subtable;
+		}
+
 		switch (subtable->type) {
 		case SUBTABLE_FBPT:
 		case SUBTABLE_S3PT:
@@ -302,7 +343,7 @@ static int __init acpi_init_fpdt(void)
 			/* Other types are reserved in ACPI 6.4 spec. */
 			break;
 		}
-		offset += sizeof(*subtable);
+		offset += subtable->length;
 	}
 	return 0;
 err_subtable:
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.12] ACPI: sysfs: Properly map BERT and CCEL data to their ACPI tables

[Sasha Levin]

From: Thomas Renninger <trenn@suse.de>

[ Upstream commit e45ee607ca6f9f97a2f97be356d844a912971a16 ]

In the case of multiple BERT ACPI tables, one gets:

sysfs: cannot create duplicate filename '/firmware/acpi/tables/data/BERT'

This is because both:

/firmware/acpi/tables/BERT1
/firmware/acpi/tables/BERT2

are attempted to be mapped to the same data table:

/firmware/acpi/tables/data/BERT

Address this problem by passing and using the same filename for data
tables.

Signed-off-by: Thomas Renninger <trenn@suse.de>
Reported-by: Michal Suchanek <msuchanek@suse.com>
Closes: https://bugzilla.suse.com/show_bug.cgi?id=1270211
[ rjw: Subject and changelog edits ]
Link: https://patch.msgid.link/20260717065129.72924-3-trenn@suse.de
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Local tree

This checkout is **mainline 7.3.0-rc4** (`v7.3-rc4-27-gf0100363d8c37`,
`VERSION=7 PATCHLEVEL=3 SUBLEVEL=0 EXTRAVERSION=-rc4`). The commit under
review is already an ancestor of `HEAD` as `e45ee607ca6f9`. The verdict
is whether this fix is suitable to backport, based on the code and
history in this tree.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: PARSE THE SUBJECT LINE**

Record: **[ACPI sysfs] [Properly map] BERT and CCEL data sysfs names to
the same instance filenames as the parent ACPI tables.** Subsystem
prefix `ACPI: sysfs:`. “Properly map” is a correctness/fix verb even
without “fix”.

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**

Record:
- **Fixes:** none (expected for this review pipeline)
- **Reported-by:** Michal Suchanek `<msuchanek@suse.com>` (real distro
  report)
- **Closes:** `https://bugzilla.suse.com/show_bug.cgi?id=1270211`
- **Link:**
  `https://patch.msgid.link/20260717065129.72924-3-trenn@suse.de` (patch
  2/2 of a series)
- **Cc: stable:** absent (expected; not a negative signal)
- **Signed-off-by:** Thomas Renninger `<trenn@suse.de>` (author); Rafael
  J. Wysocki `<rafael.j.wysocki@intel.com>` (ACPI maintainer)
- **[ rjw: Subject and changelog edits ]** — maintainer edited the
  changelog before applying
- No Tested-by, Reviewed-by, Acked-by, or syzbot tags

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**

Record:
- **Bug:** With more than one BERT table, sysfs tries to create
  `/firmware/acpi/tables/data/BERT` twice.
- **Symptom:** `sysfs: cannot create duplicate filename
  '/firmware/acpi/tables/data/BERT'`. Table files are `BERT1`/`BERT2`;
  data files were all named `BERT`.
- **Failure mode:** `sysfs_warn_dup()` prints that warning and calls
  `dump_stack()` at boot. The second BERT (or CCEL) error region is
  never exported.
- **Version info:** none in the message.
- **Root cause:** `acpi_bert_data_init` / `acpi_ccel_data_init` hard-
  coded the bin-attribute name to `"BERT"` / `"CCEL"` instead of using
  the instance filename already computed for the table.

Cover letter (from the lore mbox) shows real firmware with two BERT
tables:

```
ACPI: BERT ... (v01 AMD    AMD BERT ...)
ACPI: BERT ... (v01 AMI    AMI.BERT ...)
sysfs: cannot create duplicate filename
'/firmware/acpi/tables/data/BERT'
```

**Step 1.4: DETECT HIDDEN BUG FIXES**

Record: **Not hidden.** This is an explicit sysfs-name collision fix. It
is not cleanup, refactor, or a new feature.

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1: INVENTORY THE CHANGES**

Record:
- **File:** `drivers/acpi/sysfs.c` only — **+5 / −4** (9 lines).
- **Functions:** `acpi_bert_data_init`, `acpi_ccel_data_init`,
  `acpi_table_data_init`, `acpi_tables_sysfs_init`.
- **Struct:** `acpi_data_attr` gains `filename[]`.
- **Scope:** single-file surgical fix.

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**

Record:
- **Before:** `acpi_table_attr_init()` already builds `BERT` vs
  `BERT1`/`BERT2`. `acpi_table_data_init()` then created data files with
  a hard-coded `"BERT"` / `"CCEL"` name.
- **After:** `acpi_table_data_init(th, table_attr)` copies
  `table_attr->filename` into `data_attr->filename` and uses that as the
  sysfs name. Data nodes match table nodes (`BERT`, or `BERT1`/`BERT2`).
- **Path:** boot-time ACPI sysfs init only (`acpi_tables_sysfs_init`).
  Return value of `acpi_table_data_init` is still ignored (pre-
  existing).

**Step 2.3: IDENTIFY THE BUG MECHANISM**

Record: **[Logic / correctness]** Hard-coded sysfs names collide when
ACPI has multiple tables of the same signature. Fix: reuse the already-
instanced filename. Same pattern for BERT and CCEL.

**Step 2.4: ASSESS THE FIX QUALITY**

Record:
- **Quality:** obviously correct. `acpi_table_attr_init()` runs first
  and fills `table_attr->filename`; then `acpi_table_data_init()` copies
  it. `attr.name` points at the heap `data_attr->filename` buffer, which
  lives as long as the bin attribute (same lifetime as the old string-
  literal names).
- **Single-table ABI:** unchanged. Instance suffix is added only when a
  second table exists (`instance > 1` or `acpi_get_table(..., 2, ...)`
  succeeds), so a lone BERT still appears as
  `/firmware/acpi/tables/data/BERT`.
- **Regression risk:** very low. No locking, no public API, no new sysfs
  files in the common case.
- **Not introduced here:** if `sysfs_create_bin_file()` fails,
  `data_attr` is still leaked (return value ignored). This patch avoids
  the duplicate-name failure; it does not add that leak.

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: BLAME THE CHANGED LINES**

Record:
- BERT data sysfs: **`7dae6326ed764`** (“ACPI / sysfs: Extend ACPI sysfs
  to provide access to boot error region”), Tony Luck, **v4.14-rc1**.
  Hard-coded `"BERT"` is from that commit.
- CCEL: **`4f855dcead6c5`** (“ACPI: sysfs: Enable ACPI sysfs support for
  CCEL records”), **v6.4-rc1**. Copied the same hard-coded-name pattern.
- Table instance filenames: `acpi_table_attr.filename` since
  **`1c8fce27e275fd`** (v2.6.36-era sysfs) / **`3278675567dfb9`**
  (ACPI_NAMESEG_SIZE rename, 2019).
- Buggy pattern has been in tree for years, not last-month code.

**Step 3.2: FOLLOW THE FIXES: TAG**

Record: **No Fixes: tag.** Introducer is `7dae6326ed764` (BERT, v4.14)
and `4f855dcead6c5` (CCEL, v6.4). Both are ancestors of this HEAD (`git
merge-base --is-ancestor` exit 0).

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**

Record:
- Immediate parent: **`f45c999e67120`** — series patch 1/2, BERT
  `sizeof` check (`acpi_hest_generic_status` → `acpi_bert_region`).
  Independent; this patch does not need it.
- No later commits on `drivers/acpi/sysfs.c` after `e45ee607ca6f9` (no
  follow-up revert or fix).
- **Standalone** as a 2/2 series member: patch 1 is a separate size-
  check fix.

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**

Record: Thomas Renninger is a long-time ACPI contributor (SUSE). Same-
day sibling is only the BERT sizeof patch. Merged by ACPI maintainer
Rafael J. Wysocki.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**

Record: **None required for the naming fix.** It uses existing
`table_attr->filename`, `strscpy`, and `acpi_table_attr_init`.
`kzalloc_obj` in surrounding lines is later mainline allocation API and
is **not** introduced by this diff. On older trees the same hunks apply
around `kzalloc`. `strscpy` has been in the kernel since v4.3.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**

Record:
- **b4 dig:** series at
  `https://patch.msgid.link/20260717065129.72924-3-trenn@suse.de`
- Cover: `[PATCH 0/2] Fix sysfs duplicate filename if multiple BERT
  tables exist`
- This commit is **[PATCH 2/2]** (msgid `...72924-3...`). Subject on the
  list differed slightly from the applied subject (rjw edited it).
- **v2:** cover says previously sent to linux-pm; v2 stopped using
  `acpi_get_table` inside data init and instead passes `table_attr`.
  Applied version is that v2.
- **Reviewer:** Rafael: “Applied (with some modifications in
  subjects/changelogs) as 7.3 material, thanks!” No NAK.
- **Stable nomination in review:** none found.
- lore.kernel.org WebFetch returned **403**; thread recovered via `b4
  dig -m`.

**Step 4.2: CHECK WHO REVIEWED THE PATCH**

Record: **b4 dig -w** recipients: Thomas Renninger, `linux-
acpi@vger.kernel.org`, Saket Dumbre (Intel ACPI), Michal Suchanek
(reporter). ACPI maintainer applied it. No separate Reviewed-by.

**Step 4.3: SEARCH FOR THE BUG REPORT**

Record: SUSE bugzilla 1270211 WebFetch **403** (likely login-walled).
Cover letter includes the reporter’s dmesg: two BERT tables (AMD + AMI)
and the exact sysfs duplicate warning. That is enough to treat it as a
real distro hit, not theoretical.

**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**

Record: 2-patch series. Patch 1/2 (`f45c999e67120`) is an independent
BERT region-size check. This 2/2 patch does not depend on it.

**Step 4.5: CHECK STABLE MAILING LIST HISTORY**

Record: No stable@ discussion found (lore WebFetch 403; web search did
not turn up a stable thread). **UNVERIFIED** whether anyone later asked
for or rejected it on stable@.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: KEY FUNCTIONS**

Record: `acpi_bert_data_init`, `acpi_ccel_data_init`,
`acpi_table_data_init`, `acpi_tables_sysfs_init`. Struct field added on
`acpi_data_attr`.

**Step 5.2: TRACE CALLERS**

Record:
- `acpi_table_data_init` — only caller: `acpi_tables_sysfs_init`
- `acpi_tables_sysfs_init` — only caller: `acpi_sysfs_init`
  (`drivers/acpi/sysfs.c`)
- `acpi_sysfs_init` — called from `acpi_bus_init()` in
  `drivers/acpi/bus.c` during ACPI boot
- `acpi_sysfs_table_handler` (hot-added tables) does **not** call
  `acpi_table_data_init`; BERT/CCEL data nodes are boot-only. Confirmed
  with grep: only those two sites.

**Step 5.3: TRACE CALLEES**

Record: `kzalloc_obj` / `sysfs_attr_init` / `strscpy` /
`sysfs_create_bin_file` / `acpi_os_map_iomem` (read path). Init-time
sysfs creation, then userspace reads of BERT/CCEL error regions.

**Step 5.4: FOLLOW THE CALL CHAIN**

Record: ACPI boot → `acpi_bus_init` → `acpi_sysfs_init` →
`acpi_tables_sysfs_init` → per-table `acpi_table_data_init`. Triggered
on every ACPI boot that has BERT or CCEL. Userspace RAS tools read
`/sys/firmware/acpi/tables/data/`. Unprivileged users typically cannot
read these (mode `0400`). The **warning/dump_stack** happens in kernel
init regardless.

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**

Record: Only BERT and CCEL are in `acpi_data_objs[]`. Both had the same
hard-coded name. No other ACPI data table types in this file.

---

## PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE

**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**

Record: **Yes.** BERT data sysfs since v4.14 (`7dae6326ed764`,
ancestor). CCEL since v6.4 (`4f855dcead6c5`, ancestor). The fix is
already applied here as `e45ee607ca6f9`. The bug is old, not introduced
after 7.3 branched.

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**

Record: **Clean / minor context.** Hunks are localized. Older trees may
still use `kzalloc` instead of `kzalloc_obj` (adjacent lines only).
Pre-v6.4 trees have no CCEL function; BERT hunks still apply. `strscpy`
and `filename` on `acpi_table_attr` are present in long-term stables.

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**

Record: This is the fix. No earlier equivalent. No later follow-up on
this file.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: IDENTIFY THE SUBSYSTEM**

Record: **ACPI sysfs** (`drivers/acpi/sysfs.c`). **IMPORTANT** (not
mm/core, but ACPI boot sysfs on essentially all x86 and many ARM
servers). BERT is RAS/boot-error; CCEL is confidential-computing event
log.

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**

Record: Mature. BERT data mapping has been stable since 2017. Occasional
sysfs/BERT/CCEL fixes, not high churn.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: WHO IS AFFECTED**

Record: **Firmware-specific.** Systems with **two or more BERT** (or
CCEL) tables. Cover letter shows a real AMD + AMI dual-BERT OEM
firmware. Single-table systems are unaffected (same sysfs name as
before). CONFIG_ACPI.

**Step 8.2: TRIGGER CONDITIONS**

Record: **Every boot** on affected firmware. Not a race. Not
unprivileged-triggerable for the data read (0400), but the kernel
`dump_stack()` is automatic at init.

**Step 8.3: FAILURE MODE SEVERITY**

Record:
- `sysfs_warn_dup()` → `pr_warn` + **`dump_stack()`**
  (`fs/sysfs/dir.c`). Looks like a kernel bug in dmesg; `panic_on_warn`
  would panic (unverified whether any of these machines set that).
- Second BERT/CCEL error region is not in sysfs, so RAS tools can miss
  boot errors.
- Boot continues; `acpi_table_data_init` return is ignored.
- **Severity: MEDIUM** (boot warning + missing diagnostic RAS data). Not
  oops/corruption/deadlock, but a real distro-reported “oh, that’s not
  good” bug.

**Step 8.4: RISK-BENEFIT RATIO**

Record:
- **Benefit:** medium-high for dual-BERT firmware (every boot warning
  gone; both error regions exported). Zero change for the common single-
  table case.
- **Risk:** very low (5 insertions / 4 deletions, init-only naming).
- **Ratio:** favorable.

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: COMPILE THE EVIDENCE**

**For backporting:**
- Real bug on real hardware (AMD BERT + AMI BERT), SUSE bugzilla +
  dmesg.
- `dump_stack()` on every boot; second error region missing from sysfs.
- Tiny, obviously correct, ACPI-maintainer merged, v2 after review.
- Bug present since v4.14 (BERT) / v6.4 (CCEL).
- No new APIs; single-table sysfs ABI unchanged.
- Standalone; does not need series patch 1/2.
- Matches stable-kernel-rules: a real bug that bothers distro users, and
  an “oh, that’s not good” sysfs warning.

**Against:**
- Not a panic, UAF, deadlock, or data-corruption bug in normal configs.
- Only dual BERT/CCEL firmware hits it (uncommon, but not fictional).
- No `Cc: stable` (not a negative signal here).
- Rafael called it “7.3 material” without mentioning stable.

**Unresolved:**
- SUSE bugzilla body (403).
- Whether stable@ ever discussed this (403 / no hits).
- Whether affected machines use `panic_on_warn`.

**Step 9.2: STABLE RULES CHECKLIST**

1. Obviously correct and tested? **PASS** — naming logic is local and
   matches existing instance filenames; maintainer applied v2; reporter
   provided dmesg.
2. Fixes a real bug that affects users? **PASS** — distro report,
   dump_stack, missing BERT data node.
3. Important issue? **PASS** (medium) — boot `dump_stack` plus
   inaccessible RAS region; rules explicitly include “oh, that’s not
   good” and distro-reported issues.
4. Small and contained? **PASS** — 9 lines, one file.
5. No new features or APIs? **PASS** — corrects names of existing sysfs
   nodes.
6. Can apply to the local tree? **PASS** — already in this 7.3-rc4 tree;
   backport to older stables is clean or BERT-only on pre-CCEL trees.

**Step 9.3: EXCEPTION CATEGORIES**

Record: None (not a device ID, quirk, DT, build, or docs patch).
Qualifies as a normal small bugfix.

**Step 9.4: DECISION**

This is a small, correct fix for a user-visible boot warning and a real
RAS sysfs hole on multi-BERT firmware. The code has been wrong since
v4.14, the patch is surgical, and the common single-table ABI is
unchanged. That meets stable criteria.

---

## What the commit solves (for stable users)

On machines whose firmware publishes **two BERT tables** (seen with AMD
+ AMI), the kernel already creates `/sys/firmware/acpi/tables/BERT1` and
`BERT2`, but both data mappings used the name `BERT`.
`sysfs_create_bin_file()` fails, `sysfs_warn_dup()` dumps a stack at
every boot, and the second boot-error region is never exposed. The same
bug exists for multiple CCEL tables. The fix copies the table’s instance
filename onto the data node.

## Risk vs benefit

Benefit is removing a boot `dump_stack` and exporting all BERT/CCEL
regions on affected firmware. Risk is negligible: init-only string copy,
no locking, no ABI change when there is only one table.

## Concerns

Older stables without CCEL need the CCEL hunk dropped; BERT hunks still
apply. Adjacent `kzalloc_obj` is not part of this patch. Series patch
1/2 is optional, not a prerequisite.

---

## Verification

- **[Phase 1]** Parsed tags: Reported-by Michal Suchanek (SUSE), Closes
  bugzilla 1270211, Link patch 2/2, SOB author + Rafael; no
  Fixes/stable/syzbot.
- **[Phase 2]** `git show e45ee607ca6f9`: `drivers/acpi/sysfs.c` +5/−4;
  add `filename`, stop hard-coding `"BERT"`/`"CCEL"`, pass `table_attr`.
- **[Phase 2]** Read `acpi_table_attr_init` (instance suffix) and
  `acpi_tables_sysfs_init` (attr_init then data_init).
- **[Phase 2]** Read `sysfs_warn_dup` in `fs/sysfs/dir.c`: `pr_warn` +
  `dump_stack()`.
- **[Phase 3]** Blame: BERT data `7dae6326ed764` (v4.14-rc1), CCEL
  `4f855dcead6c5` (v6.4-rc1).
- **[Phase 3]** `git merge-base --is-ancestor 7dae6326ed764 HEAD` and
  `4f855dcead6c5 HEAD` and `e45ee607ca6f9 HEAD`: all 0 (present).
- **[Phase 3]** Sibling `f45c999e67120` is independent sizeof fix; no
  later sysfs.c commits after this one.
- **[Phase 4]** `b4 dig -c e45ee607ca6f9`: lore thread; v2 cover +
  dmesg; Rafael applied as 7.3 material; no NAK.
- **[Phase 4]** `b4 dig -w`: linux-acpi, Saket Dumbre, reporter on CC.
- **[Phase 4]** `b4 dig -m`: full mbox; WebFetch lore/bugzilla 403.
- **[Phase 5]** grep: `acpi_table_data_init` only from
  `acpi_tables_sysfs_init`; `acpi_sysfs_init` from `acpi_bus_init`.
- **[Phase 6]** `git describe HEAD` → `v7.3-rc4-27-gf0100363d8c37`;
  `make kernelversion` → 7.3.0-rc4; buggy BERT/CCEL code in this
  lineage.
- **[Phase 8]** Failure mode: boot dump_stack + missing second data
  node; severity MEDIUM.
- **UNVERIFIED:** full SUSE bugzilla text; stable@ archives;
  `panic_on_warn` on affected hosts.

The patch is obviously correct, fixes a real distro-reported boot
warning and missing RAS sysfs data, is nine lines in one file, and does
not add features.

**YES**

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

diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c
index e596224302f4c..d8d04437f63d6 100644
--- a/drivers/acpi/sysfs.c
+++ b/drivers/acpi/sysfs.c
@@ -316,6 +316,7 @@ struct acpi_table_attr {
 struct acpi_data_attr {
 	struct bin_attribute attr;
 	u64	addr;
+	char filename[ACPI_NAMESEG_SIZE+ACPI_INST_SIZE];
 };
 
 static ssize_t acpi_table_show(struct file *filp, struct kobject *kobj,
@@ -453,7 +454,6 @@ static int acpi_bert_data_init(void *th, struct acpi_data_attr *data_attr)
 	}
 	data_attr->addr = bert->address;
 	data_attr->attr.size = bert->region_length;
-	data_attr->attr.attr.name = "BERT";
 
 	return sysfs_create_bin_file(tables_data_kobj, &data_attr->attr);
 }
@@ -469,7 +469,6 @@ static int acpi_ccel_data_init(void *th, struct acpi_data_attr *data_attr)
 	}
 	data_attr->addr = ccel->log_area_start_address;
 	data_attr->attr.size = ccel->log_area_minimum_length;
-	data_attr->attr.attr.name = "CCEL";
 
 	return sysfs_create_bin_file(tables_data_kobj, &data_attr->attr);
 }
@@ -484,7 +483,7 @@ static struct acpi_data_obj {
 
 #define NUM_ACPI_DATA_OBJS ARRAY_SIZE(acpi_data_objs)
 
-static int acpi_table_data_init(struct acpi_table_header *th)
+static int acpi_table_data_init(struct acpi_table_header *th, struct acpi_table_attr *table_attr)
 {
 	struct acpi_data_attr *data_attr;
 	int i;
@@ -497,6 +496,8 @@ static int acpi_table_data_init(struct acpi_table_header *th)
 			sysfs_attr_init(&data_attr->attr.attr);
 			data_attr->attr.read = acpi_data_show;
 			data_attr->attr.attr.mode = 0400;
+			strscpy(data_attr->filename, table_attr->filename);
+			data_attr->attr.attr.name = data_attr->filename;
 			return acpi_data_objs[i].fn(th, data_attr);
 		}
 	}
@@ -543,7 +544,7 @@ static int acpi_tables_sysfs_init(void)
 			return ret;
 		}
 		list_add_tail(&table_attr->node, &acpi_table_attr_list);
-		acpi_table_data_init(table_header);
+		acpi_table_data_init(table_header, table_attr);
 	}
 
 	kobject_uevent(tables_kobj, KOBJ_ADD);
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] ACPI: button: Add DMI quirk for Razer Blade Pro 17 early 2020 lid switch

[Sasha Levin]

From: Robin Everaars <robineveraars@pm.me>

[ Upstream commit 415125669c2ddc773c579a60df108f75712dfa83 ]

The lid switch reports "close" but can miss the matching "open", leaving
_LID closed after resume. systemd-logind then suspends the system again
roughly every 35 seconds.

Reading the embedded controller's PSTA byte while _LID is stale shows that
bit 0x04 is set, which the DSDT treats as open. The DSDT returns the cached
LIDS byte from _LID. Its wake path aborts in RTEC on an unhandled
SystemCMOS region before copying PSTA to LIDS.

Initialize the lid state to open on resume, matching the existing quirk
for the Razer Blade Stealth 13 late 2019. With
button.lid_init_state=open, a physical close suspended once and resume
reported open without another suspend.

Signed-off-by: Robin Everaars <robineveraars@pm.me>
Link: https://patch.msgid.link/20260817141414.213075-1-robineveraars@pm.me
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

I have enough to decide: this is a DMI-scoped lid quirk, the buggy path
exists in 6.12, and the patch applies here.

===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================

Step 1.1: PARSE THE SUBJECT LINE
Record: [ACPI] [Add] [DMI quirk for Razer Blade Pro 17 early 2020 lid
switch]
Subsystem prefix: `ACPI: button:`. Action verb: **Add**. Claimed intent:
add a DMI match so this laptop initializes lid state as open, matching
an existing Razer quirk.

Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
Record:
- Signed-off-by: Robin Everaars <robineveraars@pm.me> (author)
- Link:
  https://patch.msgid.link/20260817141414.213075-1-robineveraars@pm.me
- Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (ACPI
  maintainer)
- No Fixes:, Reported-by:, Tested-by:, Reviewed-by:, Acked-by:, or Cc:
  stable (absence expected for this review)
- Ignore any pipeline "Upstream commit" / "Signed-off-by: Sasha Levin"
  markers

Notable: ACPI maintainer applied it. No syzbot/KASAN. Hardware-quirk
report from the machine owner.

Step 1.3: ANALYZE THE COMMIT BODY TEXT
Record:
- Bug: lid reports "close" but can miss the matching "open"; `_LID`
  stays closed after resume.
- Symptom: systemd-logind re-suspends roughly every 35 seconds (suspend
  loop).
- Root cause (firmware): EC PSTA bit 0x04 is set (DSDT treats that as
  open), but `_LID` returns cached LIDS. Wake path aborts in RTEC on an
  unhandled SystemCMOS region before copying PSTA to LIDS.
- Fix: DMI quirk `ACPI_BUTTON_LID_INIT_OPEN`, same as Razer Blade
  Stealth 13 late 2019.
- Test: with `button.lid_init_state=open`, a physical close suspended
  once; resume reported open; no second suspend.
- Version info: none in the message. Commit is in v7.3-rc1 (`git
  describe --contains` → `v7.3-rc1~39^2^3`).

Step 1.4: DETECT HIDDEN BUG FIXES
Record: Not a disguised cleanup. It is an explicit hardware quirk for a
firmware lid bug. The "Add" verb here is the standard DMI-quirk
exception, not a new feature.

===============================================================
PHASE 2: DIFF ANALYSIS - LINE BY LINE
===============================================================

Step 2.1: INVENTORY THE CHANGES
Record:
- File: `drivers/acpi/button.c` (+11 / -0)
- Function/data: `dmi_lid_quirks[]` only
- Scope: single-file surgical DMI table addition
- Commit: `415125669c2ddc773c579a60df108f75712dfa83`

Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
Record:
- Before: this DMI identity is unmatched;
  `acpi_button_register_driver()` sets `lid_init_state =
  ACPI_BUTTON_LID_INIT_METHOD` (evaluate `_LID`).
- After: match vendor `"Razer"` + product `"Blade Pro 17 (Early 2020) -
  RZ09-0329"` → `ACPI_BUTTON_LID_INIT_OPEN`.
- Affected path: lid init on first userspace open
  (`acpi_lid_input_open`) and on resume (`acpi_button_resume` →
  `acpi_lid_initialize_state` → `acpi_lid_notify_state(device, 1)`).
- Other machines: unchanged (`dmi_first_match` is exact).

Step 2.3: IDENTIFY THE BUG MECHANISM
Record: [Hardware workaround / DMI quirk]
Broken: firmware `_LID` stuck closed after resume; userspace treats that
as lid-closed and suspends again.
Fix: report lid open on init/resume for this DMI ID, same as existing
Razer/Medion/Samsung entries.

Step 2.4: ASSESS THE FIX QUALITY
Record: Obviously correct and minimal. Regression risk is confined to
this DMI string. If the lid is truly closed at resume from another
wakeup source, init-open can delay one close report until the next close
notify; that is the established tradeoff for this quirk class (Stealth
13 late 2019, Medion, Samsung). No API/locking/refcount changes.

===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================

Step 3.1: BLAME THE CHANGED LINES
Record: Insertion is between:
- `0528904926aab` (2020-01-02) Razer Blade Stealth 13 late 2019, same
  `ACPI_BUTTON_LID_INIT_OPEN` pattern
- `8fa73ee44daef` (2024-10-20) Samsung Galaxy Book2, same pattern, `Cc:
  All applicable <stable@vger.kernel.org>`
- Table exists since `d7cd08231a7fa` (2019-10-28)
The "bug" is firmware on a 2020 laptop; the kernel quirk table has been
in this driver for years.

Step 3.2: FOLLOW THE FIXES: TAG
Record: No Fixes: tag. Not applicable. Firmware defect, not a kernel
regression from a specific SHA.

Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
Record (this tree, last 20 on `drivers/acpi/button.c`): other DMI lid
quirks (Lenovo Yoga 9, Medion E2228T, Nextbook Ares 8A, Samsung Galaxy
Book2) plus unrelated notify/input_free_device changes. No prerequisite
refactor required for this table entry.
Standalone, not patch X/Y.

Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Record: `git log --author='Robin Everaars' -- drivers/acpi/` is empty in
this tree. Author is a hardware reporter, not the ACPI maintainer.
Weight comes from Rafael applying it and from matching an existing
quirk.

Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
Record: Depends only on `dmi_lid_quirks[]` and
`ACPI_BUTTON_LID_INIT_OPEN`, both present. Later mainline converted
`acpi_button_add` → `acpi_button_probe`; that is after 6.12 and not
required. A later mailing-list patch for Blade Stealth 13 Early 2020
(RZ09-0310) is a sibling quirk, not a dependency. Can apply standalone.

===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================

Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
Record:
- `b4 dig -c 415125669c2dd`:
  https://patch.msgid.link/20260817141414.213075-1-robineveraars@pm.me
- `b4 dig -a`: v1 msgid `20260817133259.195548-1-robineveraars@pm.me`,
  v2 same code; v1 was unapplicable because Proton OpenPGP/MIME inserted
  line breaks. No logic review changes.
- Rafael: "Applied as 7.3-rc material, thanks!" No NAK, no stable
  discussion in-thread.
- lore.kernel.org WebFetch returned 403; discussion recovered via b4,
  Patchew, and openwall.

Step 4.2: CHECK WHO REVIEWED THE PATCH
Record (`b4 dig -w`): To/Cc Rafael J. Wysocki, Len Brown, linux-acpi,
linux-kernel. Maintainer applied it. No extra Reviewed-by.

Step 4.3: SEARCH FOR THE BUG REPORT
Record: No bugzilla/syzbot Link. Evidence is the author's firmware
analysis (PSTA vs LIDS/RTEC) and the `lid_init_state=open` test. Same
class as the 2020 Stealth 13 quirk ("systemd continuously re-suspend the
laptop every 30s"). UserBenchmark/Geekbench and linux-hardware.org Razer
probes support the product-name form `Blade … - RZ09-xxxx` with vendor
`Razer`.

Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
Record: Standalone v2. Related later proposal: Ian Gallagher, Blade
Stealth 13 Early 2020 RZ09-0310, which cites this Pro 17 entry as
already in tree. Not required for this backport.

Step 4.5: CHECK STABLE MAILING LIST HISTORY
Record: WebSearch of lore.kernel.org/stable for this model found no
prior stable request or rejection. UNVERIFIED at the individual-message
level because lore WebFetch is 403.

===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================

Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF
Record: No function body changed. Data: `dmi_lid_quirks[]`. Consumers:
`acpi_button_register_driver()`, `acpi_lid_initialize_state()`.

Step 5.2: TRACE CALLERS
Record:
- `acpi_button_register_driver()`: module/driver init;
  `dmi_first_match(dmi_lid_quirks)` if `lid_init_state == -1`.
- `acpi_lid_initialize_state()`: from `acpi_button_resume()`
  (CONFIG_PM_SLEEP) and `acpi_lid_input_open()` (userspace opens
  `/dev/input` lid switch).
- Not IRQ/hot-path; boot and resume/open.

Step 5.3: TRACE CALLEES
Record: `ACPI_BUTTON_LID_INIT_OPEN` → `acpi_lid_notify_state(device, 1)`
reports SW_LID open. No alloc/new locks.

Step 5.4: FOLLOW THE CALL CHAIN
Record: Userspace-reachable: logind/systemd reads the lid input device
and acts on SW_LID. Trigger is close-lid suspend then resume with lid
open — normal laptop use. Unprivileged user can trigger by closing the
lid.

Step 5.5: SEARCH FOR SIMILAR PATTERNS
Record: Same `ACPI_BUTTON_LID_INIT_OPEN` DMI entries already in this
tree for Lenovo 82BG, Medion E2215T/E2228T, Razer Stealth 13 Late 2019,
Samsung 750XED. This is another instance of a known firmware class, not
a new mechanism.

===============================================================
PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE
===============================================================

Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?
Record:
- Tree: `pending-6.12`, `git describe HEAD` = `p-6.12-3-gc504cf0baa3d8`,
  `make kernelversion` = **6.12.111**
- `dmi_lid_quirks[]` present; Stealth 13 quirk present; **no**
  `RZ09-0329` / Blade Pro 17 entry
- `git merge-base --is-ancestor 415125669c2dd HEAD` → not an ancestor
  (not in this tree)
- Quirk infrastructure since 2019; bug is firmware on 2020 hardware,
  relevant to 6.12

Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
Record: `git show 415125669c2dd | git apply --check` succeeded (hunk at
line 130, offset -3). Difference vs mainline is later
`acpi_button_probe` conversion, not the DMI table. Expected: **clean
apply**.

Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE
Record: No RZ09-0329 match. No other 6.12 commit with this subject (`git
log --grep='Razer Blade Pro 17' -- drivers/acpi/button.c` empty).
Samsung/Stealth 13 quirks are related pattern, not a substitute for this
DMI ID.

===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================

Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
Record: [ACPI button / laptop lid] [IMPORTANT]
`CONFIG_ACPI_BUTTON` default y. Lid events drive suspend on essentially
all ACPI laptops. Not mm/core, but suspend-loop is user-visible
stability.

Step 7.2: ASSESS SUBSYSTEM ACTIVITY
Record: This 6.12 file is mature (quirks since 2019). Mainline later did
a large button.c rework (platform device, devres); that churn is **not**
in this tree. The DMI table is the stable part.

===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================

Step 8.1: DETERMINE WHO IS AFFECTED
Record: Driver-specific / DMI-specific: Razer Blade Pro 17 Early 2020
(RZ09-0329) only. ACPI button is default-y, so those laptops on 6.12 are
in scope.

Step 8.2: DETERMINE THE TRIGGER CONDITIONS
Record: Close lid → suspend → open lid/resume. Common laptop path.
Unprivileged user can trigger. Not a narrow error path.

Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
Record: [Suspend loop ~every 35s] [HIGH]
Not a panic, but the machine cannot stay awake after lid-wake. Matches
historical "systemd re-suspend every 30s" reports. Data-loss risk if
unsaved work is interrupted by repeated suspend.

Step 8.4: CALCULATE RISK-BENEFIT RATIO
Record:
- Benefit: HIGH for that model (fixes unusable suspend/resume)
- Risk: VERY LOW (11-line DMI entry, no other machines)
- Ratio: strongly favors backport

===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================

Step 9.1: COMPILE THE EVIDENCE

FOR:
- Real user-visible bug: lid stuck closed → logind suspend loop
- Hardware quirk exception (DMI table), explicitly allowed in stable
- Same mechanism as Stealth 13 late 2019 (in this tree since 2020) and
  Samsung Galaxy Book2 (`Cc: stable`)
- 11 lines, one file, no APIs
- Applies cleanly to 6.12.111
- ACPI maintainer applied as 7.3-rc
- Author tested `lid_init_state=open`
- DMI product string matches later Razer naming (`Blade … - RZ09-xxxx`)

AGAINST:
- Affects one laptop model, not all users
- No Fixes:/Cc: stable in the commit (expected; not a negative)
- Author tested the module param; DMI match correctness is inferred from
  the string they submitted (if wrong, quirk is a no-op, not a
  regression)

UNRESOLVED:
- lore.kernel.org HTTP 403; thread recovered via b4/Patchew/openwall
- No independent kernel bugzilla duplicate found
- Stable list not confirmed message-by-message (search found nothing)

Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. Obviously correct and tested? **PASS** — copy of existing quirk;
   author + maintainer
2. Fixes a real bug that affects users? **PASS** — suspend loop after
   resume
3. Important issue? **PASS** — HIGH: system re-suspends every ~35s
   (hang/unusable, not a panic)
4. Small and contained? **PASS** — +11 lines, one DMI entry
5. No new features or APIs? **PASS** — quirk table only
6. Can apply to the local tree? **PASS** — `git apply --check` clean;
   table present

Step 9.3: CHECK FOR EXCEPTION CATEGORIES
Record: **Hardware quirk/workaround** (DMI lid_init_state). Automatic
stable-qualifier.

Step 9.4: MAKE YOUR DECISION
This tree is 6.12.111. The quirk table and `ACPI_BUTTON_LID_INIT_OPEN`
exist; the RZ09-0329 entry does not. The patch is a small, model-scoped
workaround for a firmware lid bug that leaves the laptop in a suspend
loop. That is exactly the class of DMI quirk stable already carries for
this driver.

What it solves for 6.12 users: after closing the lid, resume can leave
`_LID` closed while the lid is open; systemd-logind then suspends again.
The quirk reports open on resume for this DMI ID only.

Risk vs benefit: benefit is restoring normal lid/suspend on this 2020
Razer; risk is a no-op on every other machine.

No dependencies, no backport rework, no new API.

Verification:
- [Phase 1] Parsed tags: author SOB, Rafael SOB, Link msgid
  `20260817141414.213075-1-robineveraars@pm.me`; no Fixes/Reported-
  by/Cc: stable
- [Phase 1] Body: `_LID` stale closed after resume; logind re-suspend
  ~35s; PSTA/LIDS/RTEC firmware explanation; tested
  `button.lid_init_state=open`
- [Phase 2] Diff: +11 lines in `dmi_lid_quirks[]` only;
  `ACPI_BUTTON_LID_INIT_OPEN` for Razer / `Blade Pro 17 (Early 2020) -
  RZ09-0329`
- [Phase 2] Local `acpi_lid_initialize_state()` OPEN case calls
  `acpi_lid_notify_state(device, 1)`; resume and `acpi_lid_input_open`
  both call it
- [Phase 3] Blame: Stealth 13 quirk `0528904926aab` (2020); Samsung
  `8fa73ee44daef` (2024, Cc: stable); table from `d7cd08231a7fa` (2019)
- [Phase 3] No Fixes: tag; standalone; no Robin Everaars history in this
  ACPI tree
- [Phase 4] `b4 dig -c 415125669c2dd`: v2 URL; `b4 dig -a`: v1→v2, PGP
  wrapping only; `b4 dig -w`: Rafael, Len Brown, linux-acpi
- [Phase 4] Patchew: Rafael "Applied as 7.3-rc material, thanks!"; no
  NAK
- [Phase 4] lore WebFetch 403; UNVERIFIED raw lore HTML
- [Phase 5] Callers: `acpi_button_register_driver` (init),
  `acpi_button_resume`, `acpi_lid_input_open`; userspace lid/logind path
- [Phase 5] Similar OPEN quirks already in this file for
  Lenovo/Medion/Razer/Samsung
- [Phase 6] `git describe HEAD` p-6.12-3-gc504cf0baa3d8; kernelversion
  6.12.111; `merge-base --is-ancestor 415125669c2dd HEAD` false
- [Phase 6] `git apply --check` succeeded at offset -3
- [Phase 6] Grep: no RZ09-0329 in this tree
- [Phase 7] MAINTAINERS ACPI: Rafael Wysocki; `CONFIG_ACPI_BUTTON`
  default y
- [Phase 8] Failure mode: suspend loop; severity HIGH; DMI-scoped; risk
  very low
- [Phase 3/4] Commit `415125669c2dd` is `v7.3-rc1~39^2^3` on
  origin/master
- UNVERIFIED: individual stable@ thread bodies (lore 403); exact
  dmidecode dump of the author's machine (string is consistent with
  other 2020+ Razer DMI names)

**YES**

 drivers/acpi/button.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
index 384caea90ce5f..4ddaee8955c30 100644
--- a/drivers/acpi/button.c
+++ b/drivers/acpi/button.c
@@ -132,6 +132,17 @@ static const struct dmi_system_id dmi_lid_quirks[] = {
 		},
 		.driver_data = (void *)(long)ACPI_BUTTON_LID_INIT_OPEN,
 	},
+	{
+		/*
+		 * Razer Blade Pro 17 early 2020, notification of the LID device
+		 * only happens on close, not on open and _LID keeps returning closed.
+		 */
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Razer"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "Blade Pro 17 (Early 2020) - RZ09-0329"),
+		},
+		.driver_data = (void *)(long)ACPI_BUTTON_LID_INIT_OPEN,
+	},
 	{
 		/*
 		 * Samsung galaxybook2 ,initial _LID device notification returns
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.12] ACPI: video: force native backlight on Acer Nitro AN515-46

[Sasha Levin]

From: Marcos Paulo Medeiros <maarcospm1996@gmail.com>

[ Upstream commit 525ba51157ac6e1772b5412eae26b20dd7ef8bda ]

The Acer Nitro AN515-46 is a hybrid graphics laptop whose internal
panel is driven by the AMD GPU (Radeon 680M); the discrete NVIDIA GPU
only drives external outputs. The firmware nevertheless advertises the
NVIDIA WMI EC backlight GUID, so the backlight type resolves to
nvidia_wmi_ec. The nvidia-wmi-ec-backlight driver however fails to
probe ("EC backlight control failed: AE_NOT_FOUND") and, since the
backlight type is still nvidia_wmi_ec, amdgpu skips registering its
own backlight device. The result is no backlight device at all,
leaving the brightness keys and the desktop brightness slider
non-functional.

Booting with acpi_backlight=native makes amdgpu register its backlight
interface and brightness control works. Add a DMI quirk to use the
native backlight on this model by default.

Signed-off-by: Marcos Paulo Medeiros <maarcospm1996@gmail.com>
Link: https://patch.msgid.link/20260727132151.12792-1-maarcospm1996@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

This is a DMI hardware quirk for a real backlight failure on the Acer
Nitro AN515-46. The buggy detection path, amdgpu skip, and Rembrandt GPU
support are all present in this 6.12.111 tree, and the 8-line table
entry matches the existing quirk pattern.

===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================

Step 1.1: PARSE THE SUBJECT LINE
Record: [ACPI: video] [force] [DMI quirk to use native backlight on Acer
Nitro AN515-46]

Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
Record:
- Signed-off-by: Marcos Paulo Medeiros (author)
- Link: https://patch.msgid.link/20260727132151.12792-1-
  maarcospm1996@gmail.com
- Signed-off-by: Rafael J. Wysocki (ACPI maintainer; applied the patch)
- No Fixes:, Reported-by, Tested-by, Reviewed-by, Acked-by, or Cc:
  stable (absence of the last two is expected for this review)
- Ignored: any pipeline-added Sasha Levin SOB / Upstream commit markers

Step 1.3: ANALYZE THE COMMIT BODY TEXT
Record:
- Bug: hybrid AMD+NVIDIA laptop; internal panel is AMD Radeon 680M;
  firmware still advertises the NVIDIA WMI EC backlight GUID.
- Detection then returns `nvidia_wmi_ec`. `nvidia-wmi-ec-backlight`
  probe fails with "EC backlight control failed: AE_NOT_FOUND". Because
  the type stays `nvidia_wmi_ec`, amdgpu does not register a native
  backlight device.
- Symptom: no backlight device; brightness keys and the desktop slider
  do nothing.
- Workaround: `acpi_backlight=native` lets amdgpu register and
  brightness works.
- Root cause: firmware advertises NVIDIA EC backlight that does not
  actually work; autodetection prefers it over native AMD backlight.

Step 1.4: DETECT HIDDEN BUG FIXES
Record: Not disguised. This is an explicit hardware-quirk bugfix: force
native backlight so the working GPU interface is used.

===============================================================
PHASE 2: DIFF ANALYSIS - LINE BY LINE
===============================================================

Step 2.1: INVENTORY THE CHANGES
Record:
- File: `drivers/acpi/video_detect.c` (+8 / −0)
- Function: static table `video_detect_dmi_table[]` (not a code-path
  change)
- Scope: single-file surgical DMI entry; callback is existing
  `video_detect_force_native`

Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
Record:
- Before: this product is not in the table, so autodetection can select
  `nvidia_wmi_ec`.
- After: DMI match on vendor "Acer" / product "Nitro AN515-46" sets
  `acpi_backlight_dmi = acpi_backlight_native`.
- Path: init-time DMI check in `__acpi_video_get_backlight_type()`,
  which already prefers DMI over nvidia_wmi_ec autodetection.

Step 2.3: IDENTIFY THE BUG MECHANISM
Record:
- Category: hardware workaround (DMI quirk)
- Mechanism: firmware reports NVIDIA EC backlight;
  `nvidia_wmi_ec_supported()` is true; type becomes
  `acpi_backlight_nvidia_wmi_ec`; GPU drivers then skip native
  registration via `acpi_video_backlight_use_native()`; the WMI EC
  driver fails probe; result is zero backlight devices.
- Fix: DMI override to native, which is checked before the nvidia_wmi_ec
  special case.

Step 2.4: ASSESS THE FIX QUALITY
Record:
- Obviously correct: same pattern as Dell G15 5515, Vostro 15 3535,
  Lenovo 82K8 already in this file.
- Minimal: 8 lines, one model, existing callback.
- Regression risk: very low; only that DMI product string is affected.
  Native is the workaround the author already confirmed.

===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================

Step 3.1: BLAME THE CHANGED LINES
Record: Insertion is after the HP OMEN 16-n0xxx native quirk
(`5b8d6a94f2e2c` in this tree). Surrounding native-force entries have
been in this file for many releases. `video_detect_force_native()` is
long-standing (lines 129–133).

Step 3.2: FOLLOW THE FIXES: TAG
Record: No Fixes: tag. Bug is firmware/autodetect interaction, not a
single introducing commit. Related infrastructure:
- `fe7aebb40d42b` "ACPI: video: Add Nvidia WMI EC brightness control
  detection" — in this tree (`git merge-base --is-ancestor` exit 0);
  first in v6.1-rc1.
- `da11ef832972e` "drm/amdgpu: Don't register backlight when another
  backlight should be used" — in this tree; first in v6.1-rc1.

Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
Record: Recent `video_detect.c` commits on this branch are the same
class of DMI quirks (HP OMEN 16, Lenovo 82K8, Dell OptiPlex AIOs). No
missing refactor prerequisite. Standalone DMI addition, not a series.

Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Record: Marcos Paulo Medeiros has this one ACPI video commit on
origin/master. Applied by Rafael J. Wysocki (ACPI maintainer). Hans de
Goede (backlight-detect author) was CCed.

Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
Record: Needs `acpi_backlight_nvidia_wmi_ec`,
`video_detect_force_native`, and GPU
`acpi_video_backlight_use_native()`. All exist here. Applies standalone.

===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================

Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
Record:
- Lore/msgid: https://patch.msgid.link/20260727132151.12792-1-
  maarcospm1996@gmail.com
- `b4 dig -a`: v1 only; no later revision.
- Thread: submission + Rafael "Applied as 7.3 material, thanks!" — no
  NAK, no requested changes.

Step 4.2: CHECK WHO REVIEWED THE PATCH
Record (`b4 dig -w`): To Rafael J. Wysocki; Cc Len Brown, Hans de Goede,
linux-acpi. Maintainer applied it. No reviewer-flagged risk.

Step 4.3: SEARCH FOR THE BUG REPORT
Record: No syzbot/bugzilla link. Author describes a concrete device
failure and a working cmdline workaround. A later AN515-58 patch cites
the same nvidia_wmi_ec failure mode on a sibling model (not in this
commit).

Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
Record: Standalone 1/1. Same class as Dell G15 5515 ("nvidia-ec-wmi
present but should not use it") already in this file.

Step 4.5: CHECK STABLE MAILING LIST HISTORY
Record: lore.kernel.org/stable search returned 403. UNVERIFIED whether
stable@ discussed this specific SHA. Not used as a negative signal.

===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================

Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF
Record: Table-only change. Callback: `video_detect_force_native()`.
Consumers: `__acpi_video_get_backlight_type()`,
`acpi_video_backlight_use_native()`, `nvidia_wmi_ec_backlight_probe()`,
`amdgpu_dm_register_backlight_device()`.

Step 5.2: TRACE CALLERS
Record:
- `dmi_check_system(video_detect_dmi_table)` at `video_detect.c:1013`
  during first `__acpi_video_get_backlight_type()`.
- `acpi_video_backlight_use_native()` called from amdgpu_dm, amdgpu
  atombios encoders, i915, nouveau, radeon, gma500 — GPU backlight
  registration.
- `nvidia_wmi_ec_backlight_probe()` refuses to bind unless type is
  `acpi_backlight_nvidia_wmi_ec`.

Step 5.3: TRACE CALLEES
Record: `video_detect_force_native()` only assigns `acpi_backlight_dmi =
acpi_backlight_native`. No alloc/lock/I/O.

Step 5.4: FOLLOW THE CALL CHAIN
Record: Boot/GPU probe on this laptop → `nvidia_wmi_ec_supported()` true
(SOURCE=EC) → type nvidia_wmi_ec → amdgpu skips (`Skipping amdgpu DM
backlight registration`) → WMI probe calls LEVEL and hits `EC backlight
control failed: AE_NOT_FOUND` (exact string in `nvidia-wmi-ec-
backlight.c:52`) → no backlight device. Userspace brightness is broken.
Reachable on normal laptop use, not a fuzzer-only path.

Step 5.5: SEARCH FOR SIMILAR PATTERNS
Record: Same `video_detect_force_native` + NVIDIA EC mismatch already
used for Dell G15 5515, Vostro 15 3535, Lenovo 82K8 in this file.
Systematic firmware issue, not a one-off pattern.

===============================================================
PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE
===============================================================

Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?
Record: Yes, this is pending-6.12 / 6.12.111 (`git describe HEAD` =
p-6.12-1-gf9fa14938873a).
- `acpi_backlight_nvidia_wmi_ec` in `include/acpi/video.h`
- `nvidia_wmi_ec_supported()` / return nvidia_wmi_ec in
  `video_detect.c:1044-1045`
- `nvidia-wmi-ec-backlight.c` present
- amdgpu skip at `amdgpu_dm.c:4843`
- Rembrandt/680M: `CHIP_YELLOW_CARP` PCI IDs `0x164D` and `0x1681` in
  `amdgpu_drv.c`
- No existing "Nitro AN515-46" entry

Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
Record: Clean apply. Upstream hunk sits after HP OMEN 16-n0xxx and
before the "x86 android tablets" comment; that exact sequence is at
lines 912–922 here.

Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE
Record: Related nvidia_wmi_ec native quirks exist (Dell G15, Lenovo
82K8). This model is not covered. `git log --grep=AN515 --
drivers/acpi/video_detect.c` is empty.

===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================

Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
Record: ACPI video backlight detection (`drivers/acpi/video_detect.c`).
IMPORTANT: laptop brightness on hybrid AMD/NVIDIA systems. Not core
mm/scheduler, but a common user-visible path.

Step 7.2: ASSESS SUBSYSTEM ACTIVITY
Record: Actively maintained; many DMI quirks already landed on this 6.12
branch. Mature table plus ongoing per-model entries.

===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================

Step 8.1: DETERMINE WHO IS AFFECTED
Record: Driver/platform-specific: Acer Nitro AN515-46 only (DMI
vendor+product). No effect on other machines.

Step 8.2: DETERMINE THE TRIGGER CONDITIONS
Record: Every boot on that model with default autodetection. No race.
Unprivileged users hit it via brightness keys/slider; they cannot fix it
without `acpi_backlight=native`.

Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
Record: No backlight device; brightness control dead. Not a panic/UAF.
Severity MEDIUM–HIGH for that hardware (panel brightness unusable).
Matches the hardware-quirk exception.

Step 8.4: CALCULATE RISK-BENEFIT RATIO
Record:
- Benefit: high for this 2022 Rembrandt+NVIDIA laptop — restores
  brightness without a cmdline workaround.
- Risk: very low — 8-line DMI entry, existing callback, DMI-gated.
- Ratio: strongly favorable.

===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================

Step 9.1: COMPILE THE EVIDENCE
FOR:
- Real user-visible bug: no backlight on a shipping hybrid laptop.
- Mechanism exists in 6.12 (nvidia_wmi_ec detect + amdgpu skip + WMI
  probe failure).
- GPU (Radeon 680M / Yellow Carp) is supported here.
- 8-line DMI quirk using an existing helper; same pattern as quirks
  already on this branch.
- Applies cleanly.
- ACPI maintainer applied v1 with no objections; Hans de Goede CCed.
- Hardware quirk is an explicit stable exception.

AGAINST:
- No Fixes:/Cc: stable (expected; not a negative).
- One reporter (the author).
- Does not fix a crash/UAF; only brightness on one model.

UNRESOLVED:
- Could not read lore.kernel.org/stable (403). Does not change the
  technical case.

Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. Obviously correct and tested? PASS — existing callback; author
   confirmed `acpi_backlight=native`; maintainer applied.
2. Fixes a real bug that affects users? PASS — brightness keys/slider
   dead on this model.
3. Important issue? PASS — hardware quirk restoring essential display
   brightness (stable exception).
4. Small and contained? PASS — +8 lines, one DMI entry.
5. No new features or APIs? PASS.
6. Can apply to the local tree? PASS — matching context in this 6.12
   tree.

Step 9.3: CHECK FOR EXCEPTION CATEGORIES
Record: Hardware quirk/workaround (DMI native-backlight override for
broken NVIDIA WMI EC advertisement). Qualifies.

Step 9.4: MAKE YOUR DECISION
Backport to this 6.12.111 tree. The bug, the skip path, and the GPU
support are all here; the fix is the standard low-risk DMI quirk.

Verification:
- [Phase 1] Parsed tags: author SOB, Rafael SOB, msgid.link; no
  Fixes:/Reported-by/Cc: stable
- [Phase 1] Body: nvidia_wmi_ec selected, WMI probe AE_NOT_FOUND, amdgpu
  skips, no backlight device
- [Phase 2] Diff: +8 lines in `video_detect_dmi_table[]`,
  `video_detect_force_native` for Acer / Nitro AN515-46
- [Phase 2] Precedence verified: DMI return at
  `video_detect.c:1037-1038` is before nvidia_wmi_ec at 1044-1045
- [Phase 3] `git merge-base --is-ancestor 525ba51157ac6 HEAD` → not in
  this tree (candidate)
- [Phase 3] `fe7aebb40d42b` (nvidia_wmi_ec detect) is ancestor of HEAD;
  contained in v6.1-rc1
- [Phase 3] `da11ef832972e` (amdgpu skip native) is ancestor of HEAD;
  contained in v6.1-rc1
- [Phase 3] Similar quirks already here: HP OMEN 16, Lenovo 82K8, Dell
  G15 5515
- [Phase 4] `b4 dig -c 525ba51157ac6`: https://patch.msgid.link/20260727
  132151.12792-1-maarcospm1996@gmail.com
- [Phase 4] `b4 dig -a`: v1 only
- [Phase 4] `b4 dig -w`: Rafael, Len Brown, Hans de Goede, linux-acpi
- [Phase 4] mbox: Rafael "Applied as 7.3 material, thanks!" — no NAK
- [Phase 4] UNVERIFIED: stable@ lore search (HTTP 403)
- [Phase 5] amdgpu skip: `amdgpu_dm.c:4843` `if
  (!acpi_video_backlight_use_native())`
- [Phase 5] WMI error string matches commit: `nvidia-wmi-ec-
  backlight.c:52` "EC backlight control failed: %s"
- [Phase 5] Callers of `acpi_video_backlight_use_native()`: amdgpu,
  i915, nouveau, radeon, gma500
- [Phase 6] `git describe HEAD` / `make kernelversion`: pending-6.12,
  6.12.111
- [Phase 6] Enum includes `acpi_backlight_nvidia_wmi_ec`; `nvidia-wmi-
  ec-backlight.c` exists
- [Phase 6] Rembrandt 680M IDs present: `0x1681` `CHIP_YELLOW_CARP` in
  `amdgpu_drv.c`
- [Phase 6] No "Nitro AN515-46" in this tree; HP OMEN + android-tablet
  context matches the hunk
- [Phase 8] Failure mode: no backlight device on this DMI model, not a
  kernel oops
- Note: an earlier probe of this workspace showed pending-5.10; the
  checkout used for the verdict is pending-6.12 / 6.12.111 as required

The patch is a small DMI quirk, the failure is real on this 6.12 tree,
and regression risk is limited to one product string.

**YES**

 drivers/acpi/video_detect.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 2a562cb425081..2b48b02f8a953 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -917,6 +917,14 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
 		DMI_MATCH(DMI_PRODUCT_NAME, "OMEN by HP Gaming Laptop 16-n0xxx"),
 		},
 	},
+	{
+	 .callback = video_detect_force_native,
+	 /* Acer Nitro AN515-46 */
+	 .matches = {
+		DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+		DMI_MATCH(DMI_PRODUCT_NAME, "Nitro AN515-46"),
+		},
+	},
 
 	/*
 	 * x86 android tablets which directly control the backlight through
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] i2c: acpi: Force ELAN1300 touchpads to 100 kHz

[Sasha Levin]

From: Abhijeeth Babu <babu.jeeth@gmail.com>

[ Upstream commit 9e9762e578db7556bea644bb5a8a2435f63544d1 ]

The ELAN1300 touchpad with HID ID 04F3:3104 on the ASUS VivoBook
X513UA_KM513UA exhibits severe pointer jumps and erratic movement when
the I2C bus operates at 400 kHz.

The system DSDT describes the touchpad using an I2cSerialBusV2 resource
with a speed of 0x00061A80, corresponding to 400 kHz, on the
AMDI0010:03 controller.

At this speed, libinput repeatedly reports:

kernel bug: Touch jump detected and discarded

Add ELAN1300 to i2c_acpi_force_100khz_device_ids so that it operates at
100 kHz.

Before the change, nine touch-jump events were recorded, with additional
messages suppressed by libinput's rate limiter. With the bus forced to
100 kHz, no touch-jump events have been observed and the touchpad operates
normally.

The affected system uses BIOS X513UA.319 dated 2023-05-09.

Signed-off-by: Abhijeeth Babu <babu.jeeth@gmail.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20260617192611.125513-1-babu.jeeth@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: PARSE THE SUBJECT LINE**

Record: `[i2c: acpi]` `[Force]` Force ELAN1300 touchpads to 100 kHz
instead of the DSDT-advertised 400 kHz.

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**

Record:
- `Fixes:` none (expected)
- `Reported-by:` none
- `Tested-by:` none (author reports before/after on the affected
  machine)
- `Reviewed-by:` none
- `Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>`
  (ACPI/I2C ACPI expert)
- `Signed-off-by: Abhijeeth Babu` (author)
- `Signed-off-by: Andi Shyti` (I2C host-driver maintainer; merged to
  `i2c/i2c-for-7.3`)
- `Link: https://lore.kernel.org/r/20260617192611.125513-1-
  babu.jeeth@gmail.com`
- `Cc: stable@vger.kernel.org` none (expected)
- Ignored: `[Upstream commit 9e9762e578db7556bea644bb5a8a2435f63544d1]`
  and `Signed-off-by: Sasha Levin` (pipeline markers)

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**

Record:
- Bug: ELAN1300 (`HID 04F3:3104`) on ASUS VivoBook X513UA_KM513UA
  jumps/erratically tracks when the I2C bus runs at 400 kHz.
- DSDT `I2cSerialBusV2` speed `0x00061A80` = 400000 Hz on `AMDI0010:03`.
- Symptom: libinput `kernel bug: Touch jump detected and discarded`
  (nine events before rate limiting).
- Root cause: bus too fast for this touchpad under Linux (same class of
  issue as existing ELAN06FA/DLL0945 100 kHz quirks; comment notes
  Windows works at 400 kHz, so this is a Linux HCNT/LCNT/timing
  interaction, not a DSDT typo).
- Author tested: jumps gone at 100 kHz. BIOS X513UA.319 (2023-05-09).

**Step 1.4: DETECT HIDDEN BUG FIXES**

Record: Not hidden. Explicit hardware quirk. Same pattern as the
existing `i2c_acpi_force_100khz_device_ids` entries.

---

## PHASE 2: DIFF ANALYSIS - LINE BY LINE

**Step 2.1: INVENTORY THE CHANGES**

Record:
- File: `drivers/i2c/i2c-core-acpi.c` (+1 / −0)
- Function: none; one ACPI ID added to
  `i2c_acpi_force_100khz_device_ids[]`
- Scope: single-file, one-line surgical quirk

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**

Record: Before, `i2c_acpi_lookup_speed()` left ELAN1300 at DSDT 400 kHz.
After, `acpi_match_device_ids()` matches `"ELAN1300"` and sets
`lookup->force_speed = I2C_MAX_STANDARD_MODE_FREQ` (100000).
`i2c_acpi_find_bus_speed()` then returns that forced speed and logs
`FW_BUG` if it differs from the ACPI-advertised speed.

**Step 2.3: IDENTIFY THE BUG MECHANISM**

Record: Category **(h) hardware workaround**. Same mechanism as
DLL0945/ELAN06FA: ACPI HID match forces the adapter to 100 kHz because
400 kHz produces unusable HID reports.

**Step 2.4: ASSESS THE FIX QUALITY**

Record: Obviously correct; one table entry; no API/locking/refcount
change. Regression risk is limited to other machines whose ACPI HID is
also `ELAN1300`: they would be forced to 100 kHz. Standard-mode I2C is
universally supported; previous quirks used the same HID-wide match.
Bus-wide force could slow sibling devices on `AMDI0010:03`; that is the
established tradeoff of this table.

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: BLAME THE CHANGED LINES**

Record: Table introduced by `bfd74cd1fbc02` (“i2c: Force ELAN06FA
touchpad I2C bus freq to 100KHz”, 2025-01-13). DLL0945 added by
`0b7c9528facdb` (2025-08-03). Both are in `v6.18` / `v6.18.53`. The 400
kHz force infrastructure is `7574c0db2e68c` (2019), also in this tree.

**Step 3.2: FOLLOW THE FIXES: TAG**

Record: No `Fixes:` tag. Not applicable. The “bug” is
hardware+DSDT+Linux timing, present whenever this laptop runs a kernel
that honors the 400 kHz DSDT resource.

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**

Record: Recent related commits on this file: ELAN06FA (`bfd74cd1fbc02`),
DLL0945 (`0b7c9528facdb`). Standalone; not patch X/Y. `ELAN0678` appears
in the mainline hunk context but is **not** in this 6.18 tree (`git log
--grep=ELAN0678 -- drivers/i2c/` empty; no matches in the tree). That ID
is not a prerequisite.

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**

Record: Only this I2C commit from Abhijeeth Babu. Acked by Mika
Westerberg; merged by Andi Shyti (`MAINTAINERS`: I2C host-driver
maintainer).

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**

Record: Depends on `i2c_acpi_force_100khz_device_ids` +
`i2c_acpi_lookup_speed()` force path. Both exist at `v6.18.53`.
Standalone one-line add. Applies to `v6.18.53` (`git apply --check` on
that file: rc 0).

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**

Record:
- `b4 dig -c 9e9762e578db7556bea644bb5a8a2435f63544d1` →
  https://patch.msgid.link/20260617192611.125513-1-babu.jeeth@gmail.com
- Thread: https://lore-kernel.gnuweeb.org/linux-
  acpi/ajSIc9fcALRaYhRq@zenone.zhora.eu/T/ (3 messages)
- `b4 dig -a`: v1 only; no later revisions
- No NAK. Mika Acked-by. Andi: “merged to i2c/i2c-for-7.3.” No reviewer
  `Cc: stable` request (absence is not a negative).

**Step 4.2: CHECK WHO REVIEWED THE PATCH**

Record (`b4 dig -w`): To Mika Westerberg, Andi Shyti; Cc linux-i2c,
linux-acpi, linux-kernel. Right maintainers on the original submission.

**Step 4.3: SEARCH FOR THE BUG REPORT**

Record: No syzbot/bugzilla. Author is the reporter: before (nine
libinput touch-jumps) / after (none). Real hardware, BIOS dated 2023.

**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**

Record: Standalone v1. Same table already holds ELAN06FA and DLL0945.

**Step 4.5: CHECK STABLE MAILING LIST HISTORY**

Record: gnuweeb `stable/?q=ELAN1300` hits are unrelated old stable
reviews (no this patch). No recorded reason to exclude it.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: IDENTIFY KEY FUNCTIONS**

Record: Table `i2c_acpi_force_100khz_device_ids`; consumers
`i2c_acpi_lookup_speed()`, `i2c_acpi_find_bus_speed()`. semcode MCP not
available; used grep.

**Step 5.2: TRACE CALLERS**

Record: `i2c_acpi_find_bus_speed()` callers include:
- `drivers/i2c/busses/i2c-designware-common.c`
  (`i2c_dw_acpi_round_bus_speed`) — **this is the path for AMDI0010**
- `i2c-amd-mp2-plat.c`, `i2c-synquacer.c`, `i2c-ls2x.c`,
  `i2c-viai2c-zhaoxin.c`, `i2c-usbio.c`, `drivers/crypto/atmel-i2c.c`

`AMDI0010` is in `dw_i2c_acpi_match[]` in `i2c-designware-platdrv.c`
(line 359). Probe-time bus frequency, not a hot path.

**Step 5.3: TRACE CALLEES**

Record: `acpi_walk_namespace` → `i2c_acpi_lookup_speed` →
`acpi_match_device_ids`. Then DesignWare `i2c_dw_adjust_bus_speed()`
takes `min`/`max` with ACPI speed. Forced 100 kHz is applied at adapter
setup.

**Step 5.4: FOLLOW THE CALL CHAIN**

Record: Laptop boot → DesignWare AMDI0010 probe → ACPI speed lookup →
ELAN1300 match → 100 kHz. Userspace HID/libinput then sees stable
reports. Reachable on any ACPI x86 laptop with this HID; not a rare
config.

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**

Record: Same table already has `{ "DLL0945", 0 }` and `{ "ELAN06FA", 0
}`. This is the third instance of the same quirk.

---

## PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE

**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**

Record: Local tree is **6.18.53** (`make kernelversion`; `git describe
HEAD` → `v6.18.53-5049-g0f0bdc2b0dffb`). At **`v6.18.53`** the table is:

```
{ "DLL0945", 0 },
{ "ELAN06FA", 0 },
{}
```

No `ELAN1300`. Matching/force path is present. Hardware (BIOS 2023)
predates 6.18. Bug exists here.

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**

Record: Clean apply to `v6.18.53` (`git apply --check` rc 0). Mainline
context mentions `ELAN0678`, which is not in 6.18; the one-line add
still matches `DLL0945`/`ELAN06FA`. Difficulty: clean / trivial.

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**

Record: ELAN06FA and DLL0945 are in `v6.18`. No other ELAN1300
workaround in hid/i2c (`rg ELAN1300` only this table). No alternate fix.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**

Record: I2C ACPI core (`drivers/i2c/i2c-core-acpi.c`). **IMPORTANT** for
ACPI laptops: input device usability. Not mm/fs/net core, but a shared
I2C path used by many x86 systems.

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**

Record: Mature. Speed-force tables have existed since 2019 (400 kHz) and
2025 (100 kHz). Low churn; ID additions are the normal maintenance
pattern.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: DETERMINE WHO IS AFFECTED**

Record: Driver/hardware-specific: ACPI HID `ELAN1300` (reported: ASUS
VivoBook X513UA_KM513UA, I2C-HID `04F3:3104`, DesignWare `AMDI0010`).
Only those machines change behavior.

**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**

Record: Every boot / every pointer motion at 400 kHz. Not a race.
Unprivileged user just uses the touchpad. Common on the affected laptop.

**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**

Record: Unusable touchpad (severe jumps; libinput discards motion). Not
a panic/UAF. **MEDIUM–HIGH** for affected users (primary pointing device
broken). Fits the documented **hardware quirk** exception.

**Step 8.4: CALCULATE RISK-BENEFIT RATIO**

Record:
- Benefit: high for ELAN1300 laptops on 6.18.y (touchpad works).
- Risk: very low (1 line, existing table, 100 kHz is safer than 400 kHz
  for I2C slaves).
- Ratio: strongly favors backport.

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: COMPILE THE EVIDENCE**

FOR:
- Real user-visible hardware bug (tested before/after).
- Classic I2C ACPI speed quirk; table and matcher already in 6.18.53.
- One line; no new API.
- Acked by Mika Westerberg; merged by Andi Shyti; no NAK.
- Same class as ELAN06FA/DLL0945 already in this tree.

AGAINST:
- Not a crash/security/corruption issue.
- Affects a specific HID, not all machines.
- No `Fixes:`/`Cc: stable` (expected; not a negative).
- HID-wide match could slow other ELAN1300 boards to 100 kHz (accepted
  pattern; low risk).

UNRESOLVED:
- lore.kernel.org WebFetch returned 403; discussion recovered via
  b4/gnuweeb/lkml.
- How many other products share ACPI HID `ELAN1300` is unverified.

**Step 9.2: APPLY THE STABLE RULES CHECKLIST**

1. Obviously correct and tested? **PASS** — one ID; author measured
   jumps gone.
2. Fixes a real bug that affects users? **PASS** — unusable touchpad on
   a shipping ASUS laptop.
3. Important issue? **PASS** as hardware quirk (broken input), not a
   kernel oops.
4. Small and contained? **PASS** — +1 line, one file.
5. No new features or APIs? **PASS** — existing quirk table.
6. Can apply to the local tree? **PASS** — table exists; applies cleanly
   to 6.18.53.

**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**

Record: **Hardware quirk/workaround** (and ACPI device-ID addition to an
existing table). Explicitly allowed for stable.

**Step 9.4: DECISION**

This 6.18.53 tree already has the 100 kHz force table and honors DSDT
400 kHz for unmatched HIDs, so ELAN1300 laptops still misbehave here.
The fix is a one-line ID add, the same mechanism already used for
ELAN06FA and DLL0945, and it applies cleanly.

What it solves for stable users: ASUS VivoBook X513UA (and any other
`ELAN1300`) touchpads stop jumping when the DesignWare `AMDI0010` bus is
left at 400 kHz.

Risk vs benefit: negligible code risk, restores a primary input device.

---

## Verification

- [Phase 1] Parsed tags: Acked-by Mika Westerberg; SOB Andi Shyti; Link
  lore msgid `20260617192611.125513-1-babu.jeeth@gmail.com`; no
  Fixes/Reported-by/Cc-stable. Ignored Upstream/Sasha markers.
- [Phase 1] Body: DSDT 0x00061A80 = 400 kHz; libinput touch jumps; BIOS
  X513UA.319 2023-05-09.
- [Phase 2] Diff: +1 `{ "ELAN1300", 0 }` in
  `i2c_acpi_force_100khz_device_ids`; `i2c_acpi_lookup_speed` sets
  `I2C_MAX_STANDARD_MODE_FREQ` (100000 in `include/linux/i2c.h`).
- [Phase 3] `git blame`: table from `bfd74cd1fbc02` (ELAN06FA, 2025-01);
  DLL0945 `0b7c9528facdb`. Both ancestors of `v6.18.53`.
- [Phase 3] `git merge-base --is-ancestor`: ELAN06FA and DLL0945 in
  v6.18.53; ELAN1300 **not** in v6.18.53 tag.
- [Phase 3] No ELAN0678 in this tree; not a dependency.
- [Phase 4] `b4 dig -c 9e9762e578db7556bea644bb5a8a2435f63544d1`: v1
  only; Mika ack; Andi merged to i2c-for-7.3; no NAK.
- [Phase 4] `b4 dig -w`: To Mika/Andi; Cc linux-i2c/linux-acpi.
- [Phase 4] Thread read via gnuweeb/lkml (lore.kernel.org fetch 403).
- [Phase 4] Stable list search for ELAN1300: no discussion of this
  patch.
- [Phase 5] Callers of `i2c_acpi_find_bus_speed`: DesignWare (AMDI0010),
  plus several other ACPI I2C hosts. `AMDI0010` in `i2c-designware-
  platdrv.c`.
- [Phase 5] semcode: namespace not present; used `rg`.
- [Phase 6] `make kernelversion` / `git describe HEAD`: 6.18.53 /
  `v6.18.53-5049-g0f0bdc2b0dffb`.
- [Phase 6] `git show v6.18.53:drivers/i2c/i2c-core-acpi.c`: table has
  DLL0945+ELAN06FA only.
- [Phase 6] `git apply --check` of the hunk onto v6.18.53 file: success
  (rc 0).
- [Phase 7] `MAINTAINERS`: Andi Shyti = I2C SUBSYSTEM HOST DRIVERS.
- [Phase 8] Failure mode: broken touchpad tracking, not oops. Severity
  MEDIUM–HIGH for affected laptops; quirk exception applies.
- UNVERIFIED: exact number of other SKUs using ACPI HID ELAN1300.

**YES**

 drivers/i2c/i2c-core-acpi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c
index ed90858a27b7b..98ebbc973f212 100644
--- a/drivers/i2c/i2c-core-acpi.c
+++ b/drivers/i2c/i2c-core-acpi.c
@@ -372,6 +372,7 @@ static const struct acpi_device_id i2c_acpi_force_100khz_device_ids[] = {
 	 */
 	{ "DLL0945", 0 },
 	{ "ELAN06FA", 0 },
+	{ "ELAN1300", 0 },
 	{}
 };
 
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.12] ACPI: battery: Sanitise model_number by dropping unprintable characters

[Sasha Levin]

From: Kate Hsuan <hpa@redhat.com>

[ Upstream commit 6587dd87595cfae6bf1304cd0cd1df2274424e42 ]

The battery Embedded Controller (EC) may return the model name with
trailing unprintable or non-ASCII characters. For example, on some
systems:

$ cat /sys/class/power_supply/BAT0/model_name
LNV-5B10W51864��

If a non-ASCII or an unprintable character is found, it will be
replaced with '\0' to ensure the model_number is a valid string.

If left intact, the malformed string prevents udev rules and hwdb
working correctly.

Link: https://gitlab.freedesktop.org/upower/upower/-/work_items/345
Signed-off-by: Kate Hsuan <hpa@redhat.com>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
[ rjw: Subject tweak ]
Link: https://patch.msgid.link/20260710125122.1621877-1-hpa@redhat.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: ACPI battery model_number sanitization

Local tree: **v7.3-rc4** (`7.3.0-rc4`, HEAD `f0100363d8c37`). Commit
under review: `6587dd87595cfae6bf1304cd0cd1df2274424e42`.

This is a mainline 7.3-rc checkout. The verdict is whether this fix has
the technical merit to be backported from this tree into stable, given
that the ACPI battery driver and the unsanitized `model_number` path
exist here.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: PARSE THE SUBJECT LINE**

Record: **[ACPI battery] [Sanitise] [drop unprintable/non-ASCII bytes
from `model_number` so sysfs `model_name` is a usable C string]**

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**

Record:
- **Fixes:** none (expected for this review)
- **Reported-by:** none
- **Tested-by:** none
- **Reviewed-by:** Mark Pearson `<mpearson-lenovo@squebb.ca>` (Lenovo)
- **Acked-by:** none
- **Link:**
  https://gitlab.freedesktop.org/upower/upower/-/work_items/345 (UPower
  work item)
- **Link:**
  https://patch.msgid.link/20260710125122.1621877-1-hpa@redhat.com (v2
  submission)
- **Cc: stable:** none (expected; not a negative)
- **Signed-off-by:** Kate Hsuan `<hpa@redhat.com>` (author, Red Hat);
  Rafael J. Wysocki `<rafael.j.wysocki@intel.com>` (ACPI maintainer)
- **Other:** `[ rjw: Subject tweak ]`

Notable: Lenovo Reviewed-by plus a Red Hat author. No syzbot/KASAN.

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**

Record:
- **Bug:** Battery EC/`_BIF`/`_BIX` returns a model string with trailing
  unprintable or non-ASCII bytes. Example: `LNV-5B10W51864` plus
  replacement characters in sysfs.
- **Symptom:** `/sys/class/power_supply/BAT0/model_name` is not a clean
  ASCII string; **udev rules and hwdb cannot match** it.
- **Failure mode:** Userspace battery identification fails (UPower, hwdb
  quirks, udev `ATTR{model_name}` rules). Not a kernel oops.
- **Version info:** none in the message. Driver and field are old (see
  Phase 3).
- **Root cause (author):** firmware/EC returns garbage; kernel copies it
  into `model_number` unchanged.

**Step 1.4: DETECT HIDDEN BUG FIXES**

Record: **Not a disguised cleanup.** The subject/body describe a
firmware-string sanitization so userspace matching works. It is a
**hardware quirk / firmware workaround**, not a crash fix.

---

## PHASE 2: DIFF ANALYSIS - LINE BY LINE

**Step 2.1: INVENTORY THE CHANGES**

Record:
- **File:** `drivers/acpi/battery.c` only — **+14 / −0**
- **Functions:** new `acpi_battery_clean_unprintable_chars()`; call
  added at the end of `extract_battery_info()`
- **Also:** `#include <linux/ctype.h>`
- **Scope:** single-file surgical change

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**

Record:
- **Before:** `extract_package()` `strscpy()`s ACPI string/buffer into
  `battery->model_number`. That value is exported as
  `POWER_SUPPLY_PROP_MODEL_NAME` (`val->strval =
  battery->model_number`). Trailing non-ASCII/unprintable bytes stay in
  the sysfs string.
- **After:** On successful extract (`!result`), walk `model_number` and
  replace the first non-ASCII or non-printable byte with `'\0'`
  (truncate). `isprint('\0')` is false, so an existing terminator also
  stops the loop.
- **Path:** initialization/update when `_BIF`/`_BIX` is parsed
  (`acpi_battery_get_info()` → `extract_battery_info()`), not a hot I/O
  path.

**Step 2.3: IDENTIFY THE BUG MECHANISM**

Record:
- **Category:** **hardware workaround / firmware string sanitization**
  (logic/correctness of exported sysfs string)
- **Mechanism:** EC returns trailing garbage; kernel treated it as a C
  string and exported it. Truncating at the first bad byte makes
  `model_name` matchable by udev/hwdb.
- **Not:** UAF, leak, race, NULL deref, overflow, deadlock.

**Step 2.4: ASSESS THE FIX QUALITY**

Record:
- **Quality:** Small and easy to verify. Loop is bounded by
  `ARRAY_SIZE(battery->model_number)` (64). Stops at NUL or first bad
  byte. Matches the “trailing garbage” report.
- **Regression risk:** Low. Sysfs `model_name` changes from a garbage-
  suffixed string to the printable prefix — that is the intended ABI
  cleanup. Unlikely udev rules match the unprintable suffix. Theoretical
  risk: a legitimate non-ASCII model name would be truncated; ACPI
  `_BIF`/`_BIX` model strings in practice are ASCII (Lenovo example
  `LNV-5B10W51864`). Only `model_number` is cleaned, not
  `serial_number`/`oem_info` — incomplete vs a full sanitizer, but
  matches the reported bug.
- **v1 vs v2:** v1 stripped unprintables in the middle and kept the
  rest; v2 truncates. v2 is what landed; Lenovo reviewed it as good.

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: BLAME THE CHANGED LINES**

Record:
- New helper is entirely this commit (`6587dd87595cfa`).
- `extract_battery_info()` exists since **Dave Lambley, 2016**
  (`2d09af4a88d99a`).
- `model_number[]` and copy-from-ACPI go back to the old ACPI battery
  driver (**~2007–2009**; `c67fcd670b55e` added `_BIX` in 2009).
  Unsanitized export has been present for many LTS generations.
- String copy uses `strscpy` from Armin Wolf, 2023 (`a1a32ded2887fd`) —
  that only changed copy safety, not sanitization.

**Step 3.2: FOLLOW THE FIXES: TAG**

Record: **No Fixes: tag.** Nothing to follow. Bug is long-standing
firmware/EC behavior, not a recent regression from a specific commit.

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**

Record: Recent `drivers/acpi/battery.c` commits after this one (mutex
split, notification merge, charging-status check) are **independent**.
No prerequisite series. Standalone.

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**

Record: Kate Hsuan (Red Hat) has this one ACPI battery commit plus other
hardware-enablement work (Lenovo cameras, power-supply LEDs). Not the
ACPI maintainer. ACPI maintainer (Rafael) applied it. Lenovo’s Mark
Pearson reviewed it.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**

Record: Uses `isascii`/`isprint` from `linux/ctype.h` (long-standing).
`extract_battery_info()` and `model_number[MAX_STRING_LENGTH]` exist in
this tree and in old kernels. **Standalone; no extra commits required.**

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**

Record:
- **b4 dig:**
  https://patch.msgid.link/20260710125122.1621877-1-hpa@redhat.com
- **Revisions:** v1 `20260708070732.578046-1-hpa@redhat.com`
  (2026-07-08); **v2** (committed) 2026-07-10. v1 compacted by dropping
  unprintables; v2 truncates at first bad byte.
- **Review:** Mark Pearson: “this impacts a few of our platforms”;
  “Implementation looks good to me.” **Reviewed-by** given.
- **Maintainer:** Rafael: **“Applied as 7.3 material, thanks!”** No NAK.
  No `Cc: stable` request in the v2 thread (mbox).
- lore.kernel.org HTTP **403**; thread recovered via **b4 mbox** and
  openwall.

**Step 4.2: CHECK WHO REVIEWED THE PATCH**

Record (b4 -w): Kate Hsuan, Mark Pearson (Lenovo), Rafael J. Wysocki,
Len Brown, linux-acpi@, linux-kernel@. Right maintainers were on Cc.
Rafael applied it.

**Step 4.3: SEARCH FOR THE BUG REPORT**

Record: UPower work item
https://gitlab.freedesktop.org/upower/upower/-/work_items/345 — **GitLab
returned 403; body UNVERIFIED**. Commit + Lenovo review still establish
real udev/hwdb/UPower impact on some Lenovo platforms.

**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**

Record: Standalone (not N/M). No follow-up in this tree extending
sanitization to serial/oem.

**Step 4.5: CHECK STABLE MAILING LIST HISTORY**

Record: lore.kernel.org/stable search **403**. **UNVERIFIED** whether
stable@ discussed this. No evidence in the ACPI thread of a stable
nomination or a rejection.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

semcode MCP was **not available**. Used `rg` and file reads.

**Step 5.1: IDENTIFY KEY FUNCTIONS**

Record: `acpi_battery_clean_unprintable_chars()` (new);
`extract_battery_info()` (caller added).

**Step 5.2: TRACE CALLERS**

Record:
- `extract_battery_info()` ← `acpi_battery_get_info()`
- `acpi_battery_get_info()` ← `acpi_battery_update()` (probe/update when
  `!update_time`), `acpi_battery_refresh()`, `battery_notify()` post-
  suspend path
- `model_number` read in `acpi_battery_get_property()` for
  `POWER_SUPPLY_PROP_MODEL_NAME` → sysfs `model_name`

Calling context: ACPI battery probe/update/resume, process context with
`property_lock`. Not IRQ. Userspace reads sysfs (udev, UPower, desktop
power applets).

**Step 5.3: TRACE CALLEES**

Record: `isascii()`, `isprint()` only. No alloc, no locks, no I/O.

**Step 5.4: FOLLOW THE CALL CHAIN**

Record: Firmware `_BIF`/`_BIX` → extract → sysfs `model_name` →
udev/hwdb/UPower. **Reachable on any ACPI-battery laptop at boot.**
Trigger is broken EC data on affected Lenovo (and similar) machines.

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**

Record: Same `!isascii || !isprint` pattern in ath10k/11k/12k SMBIOS
BDF, ipw2100/2200, sound/ump. Kernel already sanitizes firmware strings
this way. This patch does **not** sanitize
`serial_number`/`type`/`oem_info` in the same driver.

---

## PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE

**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**

Record: **Yes.** `drivers/acpi/battery.c` has
`model_number[MAX_STRING_LENGTH]` (64), `extract_package()` `strscpy`
into it, and sysfs export via `POWER_SUPPLY_PROP_MODEL_NAME`. The bug is
unsanitized firmware text; that behavior is ancient. Approximate
introduction: ACPI battery driver **2.6 era (~2007)**. This 7.3 tree
already contains the fix (`git merge-base --is-ancestor 6587dd87595cfa
HEAD` → yes). Evaluation is still whether the **fix itself** belongs on
stable, not whether it is already applied here.

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**

Record: **Clean/minor.** The hunk is a new helper + 4-line call +
include. `extract_battery_info()` surrounding quirk code
(`ACPI_BATTERY_QUIRK_*`) has been stable for years. Later 7.3-only
changes (`property_lock`, kfifo notify) sit **elsewhere** and are not
required. `for (unsigned int i = 0; ...)` is valid in current kernel C;
very old compilers on ancient LTS could need `unsigned int i;` moved out
— not an issue for this 7.3-based evaluation.

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**

Record: This is the only `model_number` sanitization in `battery.c`. No
earlier equivalent fix.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**

Record: **ACPI battery driver** (`drivers/acpi/battery.c`).
**IMPORTANT** for ACPI laptops (power sysfs, udev, UPower), not core
mm/VFS. Not staging.

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**

Record: Moderately active (locking, notify coalescing, charge-status).
Mature driver; this is a firmware quirk, not a new subsystem.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: DETERMINE WHO IS AFFECTED**

Record: **Driver/hardware-specific.** ACPI battery users whose EC
returns garbage in the model string. Confirmed: **some Lenovo
platforms** (Mark Pearson). Red Hat authored it, so it showed up on a
distro kernel. Not universal.

**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**

Record: Every boot on affected hardware (sysfs populated from
`_BIF`/`_BIX`). Unprivileged users can **read** `model_name`; they
cannot trigger a kernel crash. udev runs as root and fails to match.
Common on those machines, rare globally.

**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**

Record: **Failure mode:** udev/hwdb/UPower cannot match `model_name` →
battery quirks, identification, and distro rules do not apply.
**Severity: MEDIUM** (functional userspace integration, not
oops/corruption/deadlock). Official stable rules explicitly include
**hardware quirks**.

**Step 8.4: CALCULATE RISK-BENEFIT RATIO**

Record:
- **Benefit:** High for affected Lenovo/ACPI laptops on stable/LTS: hwdb
  and udev start working. Matches the hardware-quirk exception.
- **Risk:** Very low — 14 lines, no locking/alloc, truncates a firmware
  string already copied with `strscpy`.
- **Ratio:** Benefit outweighs risk for stable.

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: COMPILE THE EVIDENCE**

**FOR backporting:**
- Real firmware bug on shipping Lenovo platforms (Lenovo Reviewed-by; “a
  few of our platforms”).
- Documented UPower/udev/hwdb breakage.
- Official stable rules: *“hardware quirk”* is an accepted class
  (`Documentation/process/stable-kernel-rules.rst`).
- 14 lines, single file, obviously correct, no new API.
- ACPI maintainer applied it; Lenovo reviewed it; Red Hat authored it.
- Driver and unsanitized `model_number` exist far back; no missing
  prerequisites.
- Same sanitization pattern as other firmware-string handling in-tree.

**AGAINST:**
- Not a crash, UAF, deadlock, or CVE.
- Changes userspace-visible `model_name` (intentional).
- Rafael labeled it “7.3 material,” not an explicit stable nomination.
- Userspace *could* strip the bytes (kernel is still the right place, as
  with other firmware sanitizers).
- Only `model_number` is cleaned.

**UNRESOLVED:**
- UPower work item body (GitLab 403).
- v1 review text beyond the v1/v2 diff (lore 403).
- Whether stable@ already discussed it (lore 403).

**Step 9.2: APPLY THE STABLE RULES CHECKLIST**

1. Obviously correct and tested? **PASS** — bounded truncate; Lenovo
   review; maintainer applied.
2. Fixes a real bug that affects users? **PASS** — udev/hwdb/UPower fail
   on real Lenovo batteries.
3. Important issue? **PASS** as **hardware quirk** (explicitly listed in
   stable-kernel-rules.rst). Severity MEDIUM, not oops-level.
4. Small and contained? **PASS** — +14 lines, one file.
5. No new features or APIs? **PASS** — sanitizes an existing sysfs
   string.
6. Can apply to the local tree? **PASS** — driver and
   `extract_battery_info()` are present; hunk is self-contained.

**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**

Record: **Hardware quirk / firmware workaround** (sanitize broken EC
model string). Analogous to USB/PCI/codec quirks: small, device-
specific, makes existing userspace matching work.

**Step 9.4: MAKE YOUR DECISION**

This is a small, reviewed firmware sanitization that fixes a real
udev/hwdb failure on Lenovo ACPI batteries. It is not a kernel crash,
but stable rules treat hardware quirks as in-scope, and the risk is very
low. It should be backported.

---

## What the commit solves and why it matters to stable users

On some systems the battery EC returns a model name with trailing non-
ASCII/unprintable bytes. That string is exported as
`/sys/class/power_supply/BAT0/model_name`. udev rules and hwdb match on
that attribute; garbage bytes prevent matches, so UPower and distro
battery quirks do not apply. Stable/LTS laptop users (enterprise,
Fedora, Ubuntu) stay on these kernels for years; they need the same
identification to work.

## Stable rules, risk vs benefit, concerns

Meets the written rules: obviously correct, real user-visible bug,
hardware quirk, 14 lines, no new API. Benefit is restored udev/hwdb
matching on affected machines; risk is a one-time sysfs string cleanup
with no locking or allocation. No extra commits are required. Later 7.3
battery locking/notify work is unrelated.

---

Verification:
- [Phase 1] Parsed tags: Reviewed-by Mark Pearson (Lenovo); SOB Kate
  Hsuan (Red Hat) and Rafael J. Wysocki; Link to UPower work item 345
  and patch.msgid v2; no Fixes:/Reported-by/Cc:stable
- [Phase 1] Body: example `LNV-5B10W51864` plus unprintable suffix;
  udev/hwdb matching failure
- [Phase 2] Diff: +14 `drivers/acpi/battery.c`; new
  `acpi_battery_clean_unprintable_chars()`; call in
  `extract_battery_info()` when `!result`; `#include <linux/ctype.h>`
- [Phase 2] Confirmed `isprint`/`isascii` in `include/linux/ctype.h`;
  `isprint('\0')` is false so loop stops at NUL
- [Phase 2] `MAX_STRING_LENGTH` is 64;
  `ARRAY_SIZE(battery->model_number)` matches
- [Phase 3] Blame: helper is 6587dd87595cfa; `extract_battery_info` from
  2d09af4a88d99a (2016); `strscpy` from a1a32ded2887fd (2023);
  model_number field long-standing
- [Phase 3] No Fixes: tag; git log on `drivers/acpi/battery.c` shows no
  prerequisite series
- [Phase 3] `git merge-base --is-ancestor 6587dd87595cfa HEAD` succeeded
  (commit is in this tree)
- [Phase 4] `b4 dig -c 6587dd87595cfa`: v2 at
  patch.msgid.link/20260710125122.1621877-1-hpa@redhat.com
- [Phase 4] `b4 dig -a`: v1 2026-07-08 (strip-in-place), v2 2026-07-10
  (truncate) — committed version is v2
- [Phase 4] `b4 dig -w`: Rafael, Len Brown, linux-acpi, Mark Pearson on
  the original To/Cc
- [Phase 4] b4 mbox: Pearson “impacts a few of our platforms”; Rafael
  “Applied as 7.3 material”; no NAK, no Cc:stable in thread
- [Phase 4] lore.kernel.org and GitLab 403 — UPower issue body and
  stable@ history UNVERIFIED
- [Phase 5] Callers: `acpi_battery_get_info` from `acpi_battery_update`,
  `acpi_battery_refresh`, `battery_notify`; property
  `POWER_SUPPLY_PROP_MODEL_NAME` → sysfs
- [Phase 5] Similar isascii/isprint sanitization in ath1x k SMBIOS and
  ipw2x00
- [Phase 6] `git describe HEAD`: v7.3-rc4-27-gf0100363d8c37; `make
  kernelversion`: 7.3.0-rc4
- [Phase 6] Parent of fix still copies `model_number` via `strscpy` with
  no sanitization
- [Phase 7] Subsystem ACPI battery; official rules quote: hardware quirk
  is in-scope
- [Phase 8] Failure mode: udev/hwdb mismatch, severity MEDIUM; not
  oops/UAF
- UNVERIFIED: UPower work item 345 details; v1 mailing-list review
  comments; any prior stable@ discussion

The patch is a 14-line firmware quirk that restores battery `model_name`
matching for real Lenovo hardware, with negligible regression risk.

**YES**

 drivers/acpi/battery.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 296c2981b1a73..0b922aceb28d1 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -10,6 +10,7 @@
 
 #define pr_fmt(fmt) "ACPI: battery: " fmt
 
+#include <linux/ctype.h>
 #include <linux/delay.h>
 #include <linux/dmi.h>
 #include <linux/jiffies.h>
@@ -486,6 +487,15 @@ static int acpi_battery_get_status(struct acpi_battery *battery)
 	return 0;
 }
 
+static void acpi_battery_clean_unprintable_chars(char *str, size_t length)
+{
+	for (unsigned int i = 0; i < length; i++) {
+		if (!isascii(str[i]) || !isprint(str[i])) {
+			str[i] = '\0';
+			break;
+		}
+	}
+}
 
 static int extract_battery_info(const int use_bix,
 			 struct acpi_battery *battery,
@@ -527,6 +537,10 @@ static int extract_battery_info(const int use_bix,
 	    battery->capacity_now > battery->full_charge_capacity)
 		battery->capacity_now = battery->full_charge_capacity;
 
+	if (!result)
+		acpi_battery_clean_unprintable_chars(battery->model_number,
+					ARRAY_SIZE(battery->model_number));
+
 	return result;
 }
 
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] ACPI: APEI: Handle repeated SEA error storms

[Sasha Levin]

From: Junhao He <hejunhao3@h-partners.com>

[ Upstream commit e61487226b7df39e5f4683b036ee6aa7a5039d7b ]

When hardware memory corruption occurs and a user process accesses the
corrupted page, the CPU triggers a Synchronous External Abort (SEA).
The kernel invokes do_sea() to handle the exception, which calls
memory_failure() to handle the faulty page.

Scenario 1: Memory Error Interrupt First, then SEA
The page is already poisoned by the memory error interrupt path. The
subsequent SEA handler sends a SIGBUS to the task, which accesses the
poisoned page. This flow is correct.

Scenario 2: SEA first, then memory error interrupt (problematic scenario)
If a user task directly accesses corrupted memory through a PFNMAP-style
mapping (e.g., devmem), the page may still be in the free-buddy state when
SEA is handled. In this case, memory_failure() will poison the page without
invoking kill_accessing_process(), and then takes the free-buddy recovery
path.

After the CPU returns to the task context, the task re-enters the SEA
handler due to the same access. However, ghes_estatus_cached() suppresses
all subsequent entries during the 10-second window, preventing
ghes_do_proc() from being called. This suppression blocks the
MF_ACTION_REQUIRED-based SIGBUS delivery, causing the kernel to fail to
kill the task immediately. Consequently, the process keeps re-entering
the SEA handler, leading to an SEA storm. Later, the memory error
interrupt path also cannot kill the task, leaving the system stuck in
this repeated loop.

The following error logs are explained using the devmem process:
  NOTICE:  SEA Handle
  [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9
  [Hardware Error]: event severity: recoverable
  [Hardware Error]:   section_type: ARM processor error
  [Hardware Error]:    physical fault address: 0x0000001000093c00
  [T54990] Memory failure: 0x1000093: recovery action for free buddy page: Recovered
  [ T9955] EDAC MC0: 1 UE Multi-bit ECC on unknown memory
           (page:0x1000093 offset:0xc00 grain:1 - APEI location: ...)
  NOTICE:  SEA Handle
  NOTICE:  SEA Handle
  ...
  ...        ---> SEA storm
  ...
  NOTICE:  SEA Handle
  [ T9955] Memory failure: 0x1000093: already hardware poisoned
  ghes_print_estatus: 1 callbacks suppressed
  [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9
  [Hardware Error]: event severity: recoverable
  [Hardware Error]:   section_type: ARM processor error
  [Hardware Error]:    physical fault address: 0x0000001000093c00
  [T54990] Memory failure: 0x1000093: already hardware poisoned
  [T54990] 0x1000093: Sending SIGBUS to devmem:54990 due to hardware memory corruption

To resolve this, return an error when encountering the same SEA again.
The subsequent SEA handler invocation uses arm64_notify_die() to send a
SIGBUS signal to the task, which terminates the process and prevents it
from re-entering the handler loop.

Signed-off-by: Junhao He <hejunhao3@h-partners.com>
Reviewed-by: Wupeng Ma <mawupeng1@huawei.com>
Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com>
Reviewed-by: Tony Luck <tony.luck@intel.com>
Link: https://patch.msgid.link/20260527082707.2013499-1-hejunhao3@h-partners.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The local tree is **pending-6.18** (kernel **6.18.53**). The buggy GHES
cache-hit path is present here, the patch applies cleanly, and this is a
real ARM64 SEA-storm hang, so it should be backported.

===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================

Step 1.1: PARSE THE SUBJECT LINE
Record: [ACPI: APEI] [Handle] [Stop repeated SEA aborts from looping
when GHES cache suppresses a duplicate error]

Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
Record:
- Reviewed-by: Wupeng Ma <mawupeng1@huawei.com>
- Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com> (ACPI APEI
  reviewer in MAINTAINERS)
- Reviewed-by: Tony Luck <tony.luck@intel.com> (ACPI APEI reviewer /
  RAS)
- Link: https://patch.msgid.link/20260527082707.2013499-1-hejunhao3@h-
  partners.com
- Signed-off-by: Junhao He <hejunhao3@h-partners.com>
- Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (ACPI
  maintainer)
- No Fixes: tag (expected)
- No Cc: stable (expected)
- No Reported-by / Tested-by / syzbot
- Ignore pipeline SOBs such as Sasha Levin

Step 1.3: ANALYZE THE COMMIT BODY TEXT
Record:
- Bug: On ARM64 firmware-first SEA, if a userspace PFNMAP access
  (devmem) hits corrupted memory while the page is still a free buddy,
  `memory_failure()` poisons it as recovered and does not kill the task.
  The task retries the same access. `ghes_estatus_cached()` then drops
  duplicates for 10s (`GHES_ESTATUS_IN_CACHE_MAX_NSEC`), so
  `ghes_do_proc()` never runs again and SIGBUS is not delivered. The CPU
  loops in SEA. Firmware logs show a ~10s storm, then SIGBUS only after
  the cache expires.
- Symptom: exception storm / system stuck; related APEI commits note
  firmware threshold reboot or hard lockup from the same class of loop.
- Version info: none in the message. Logs are from a real ARM platform
  (APEI GHES source 9, EDAC MC0).
- Root cause: cache-hit path in `ghes_in_nmi_queue_one_entry()` returns
  success (`rc == 0`), so `apei_claim_sea()` claims the abort and
  `do_sea()` returns without `arm64_notify_die()`.

Step 1.4: DETECT HIDDEN BUG FIXES
Record: Not disguised. This is an explicit hang/storm fix, not cleanup.

===============================================================
PHASE 2: DIFF ANALYSIS - LINE BY LINE
===============================================================

Step 2.1: INVENTORY THE CHANGES
Record:
- File: `drivers/acpi/apei/ghes.c` only (+9 / -1)
- Function: `ghes_in_nmi_queue_one_entry()`
- Scope: single-file surgical fix

Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
Record:
- Before: cached estatus → `goto no_work` with `rc` still 0 → callers
  treat it as “successfully handled.”
- After: cached + `is_hest_sync_notify(ghes)` (HEST notify type SEA) →
  `rc = -ECANCELED` → `ghes_notify_sea()` / `apei_claim_sea()` fail →
  `do_sea()` falls through to `arm64_notify_die()` and SIGBUS.
- Path affected: duplicate synchronous SEA only. NMI/SDEI cache hits
  stay `rc = 0`.

Step 2.3: IDENTIFY THE BUG MECHANISM
Record:
- Category: logic / correctness in RAS exception handling (hang /
  exception storm).
- Mechanism: success-on-cache-hit hid an incomplete recovery (free-buddy
  poison without kill). Returning an error unclaims the SEA so the arch
  handler can kill the task.

Verified supporting code in this tree:
- `action_result(MF_RECOVERED)` returns 0 (`mm/memory-failure.c`).
- `memory_failure_cb()` returns without SIGBUS if `!ret`.
- Free-buddy path never calls `kill_accessing_process()`.
- `79a5ae3c4c5eb` only `force_sig(SIGBUS)` when `sync && !queued`; the
  first SEA *does* queue work, so that fallback does not fire.

Step 2.4: ASSESS THE FIX QUALITY
Record:
- Obviously correct for the single-source SEA case that matches the
  logs.
- Minimal; no API/data-structure change.
- Regression risk is low: gated by `is_hest_sync_notify()` so x86 NMI /
  SDEI behavior is unchanged.
- Known limitation (discussed on-list, accepted by Tony Luck): if
  several GHES SEA sources are on the list and one still returns 0,
  `-ECANCELED` is discarded. Author: a true multi-source storm is a
  different failure. Not a reason to withhold the single-source fix.
- KVM: `kvm_handle_guest_sea()` currently claims a duplicate SEA
  (`apei_claim_sea() == 0`). After this, it injects SError into the
  guest instead of leaving the host looping. That is an improvement, not
  a new API.

===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================

Step 3.1: BLAME THE CHANGED LINES
Record:
- Cache skip introduced in `d9f608dc156487` (“ACPI / APEI: Only use
  queued estatus entry during in_nmi_queue_one_entry()”, 2019-01-29).
  Present in this tree.
- `is_hest_sync_notify()` from `a70297d221325` (2023-12-18). Present.

Step 3.2: FOLLOW THE FIXES: TAG
Record: No Fixes: tag. Not applicable. The bug is interaction among the
2019 cache, long-standing free-buddy recovery, and SEA claim returning
success.

Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
Record: Related commits already in this tree:
- `a70297d221325` — MF_ACTION_REQUIRED on sync events
- `79a5ae3c4c5eb` — SIGBUS if sync error is not queued
- `c1f1fda141373` — run `memory_failure()` in task work for sync SEA
This patch is a remaining hole after those two 2025 SIGBUS fixes: queued
free-buddy recovery still does not kill, then cache blocks the retry.

Standalone. Not “patch X/Y”.

Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Record: Junhao He has HiSilicon PMU commits here, not APEI. Reviewers
are the APEI/RAS people. Weight is from review, not authorship.

Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
Record: Needs `is_hest_sync_notify()` and the existing
`ghes_in_nmi_queue_one_entry()` cache check. Both are in this tree. Can
apply standalone.

===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================

Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
Record:
- v1 msgid: `20251030071321.2763224-1-hejunhao3@h-partners.com`
  (2025-10-30), 12 messages. Returned `-EAGAIN` on every cache hit,
  including NMI/SDEI.
- v2 msgid: `20260527082707.2013499-1-hejunhao3@h-partners.com`
  (2026-05-27), 10 messages. This is the applied version: only SEA via
  `is_hest_sync_notify()`.
- Applied version is v2 (latest).
- No NAKs. Rafael required an APEI-reviewer ACK; Tony Luck then
  Reviewed-by. Rafael: “Applied as 7.3 material.”
- No reviewer Cc: stable.

Step 4.2: CHECK WHO REVIEWED THE PATCH
Record: Recipients/reviewers included ACPI APEI maintainers/reviewers
(Rafael, Tony Luck, Shuai Xue). Shuai asked for an x86 look because the
helper is shared; v2’s SEA-only gate was the answer. Tony Luck R-b after
that explanation.

Step 4.3: SEARCH FOR THE BUG REPORT
Record: No bugzilla/syzbot. Author included production-style firmware +
kernel logs (`devmem` task, free buddy Recovered, then 10s of “SEA
Handle”, then SIGBUS). Real hardware reproduction, not theoretical.

Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
Record: Single patch. v2 changelog: (1) commit message per Shuai Xue,
(2) SEA-only so other NMI-type GHES handlers are not affected.

Step 4.5: CHECK STABLE MAILING LIST HISTORY
Record: lore.kernel.org HTTP was 403/Anubis. Thread retrieved with `b4
mbox`. No stable@ discussion found in those threads. UNVERIFIED: other
independent stable-list threads beyond these two.

===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================

Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF
Record: `ghes_in_nmi_queue_one_entry()`; uses `ghes_estatus_cached()`,
`is_hest_sync_notify()`.

Step 5.2: TRACE CALLERS
Record:
- `ghes_in_nmi_spool_from_list()` ← `ghes_notify_sea()` (SEA) and NMI
  list
- `__ghes_sdei_callback()` (SDEI)
- `ghes_notify_sea()` ← `apei_claim_sea()` ← `do_sea()` (user_mode only)
  and `kvm_handle_guest_sea()`
NMI/SDEI: `is_hest_sync_notify()` is false, so no behavior change.

Step 5.3: TRACE CALLEES
Record: Cache lookup, `gen_pool_free` on `no_work`, no new locks/allocs
on the new path.

Step 5.4: FOLLOW THE CALL CHAIN
Record: Userspace load/store to poisoned PFNMAP memory → SEA → `do_sea`
→ `apei_claim_sea` → GHES. Reachable from userspace (`/dev/mem` in the
logs). Unprivileged trigger depends on who can map that physical page
(typically privileged), but once it fires the host loops. Firmware-first
ARM64 servers are the population.

Step 5.5: SEARCH FOR SIMILAR PATTERNS
Record: `ghes_proc()` still calls `ghes_do_proc()` even when cached (IRQ
path). Only the NMI-queue path skips processing on cache hit. That is
unique to this helper; no sibling copy of the same bug.

===============================================================
PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE
===============================================================

Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?
Record: Yes. `drivers/acpi/apei/ghes.c:1373-1375` is still:

```
if (ghes_estatus_cached(estatus))
    goto no_work;
```

`is_hest_sync_notify()` exists. `CONFIG_ACPI_APEI_SEA` is default y on
ARM64. Bug class present since the 2019 queue path; this 6.18 tree also
has the 2025 task-work SIGBUS series that still misses free-buddy.

Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
Record: Exact hunk matches this file. Expected apply: clean.

Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE
Record: `c1f1fda141373` and `79a5ae3c4c5eb` are in HEAD; they do not
cover this cache-hit + free-buddy case. This commit is not in HEAD (`git
log --grep` on the file found nothing).

===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================

Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
Record: ACPI APEI / GHES RAS. IMPORTANT for ARM64 firmware-first
platforms (servers, Huawei/Kunpeng-class). Not core-mm, but memory-error
handling on those machines.

Step 7.2: ASSESS SUBSYSTEM ACTIVITY
Record: Actively maintained (CXL CPER, ARM CPER bounds, task-work SEA).
Mature SEA queue dates to 2019.

===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================

Step 8.1: DETERMINE WHO IS AFFECTED
Record: ARM64 + ACPI APEI GHES SEA + memory failure. Driver/platform-
specific, not universal. Typical of enterprise ARM RAS.

Step 8.2: DETERMINE THE TRIGGER CONDITIONS
Record: Hardware UE/poison + userspace access via PFNMAP while page is
free buddy, SEA before (or instead of useful) async kill. Not every
boot. When it hits, it repeats until the 10s cache expires or firmware
reboots. Unprivileged users generally cannot open `/dev/mem`; still a
host-stability bug for RAS/error-injection and any PFNMAP consumer.

Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
Record: Exception storm / stuck task; related APEI text: firmware
threshold reboot or hard lockup. Severity: CRITICAL/HIGH. Logs prove the
10s storm (`1419.78` → `1429.81`).

Step 8.4: CALCULATE RISK-BENEFIT RATIO
Record:
- Benefit: high for ARM64 RAS — stops a documented SEA storm and
  delivers SIGBUS immediately.
- Risk: low — ~9 lines, SEA-only, no new ABI, clean apply.
- Ratio: benefit ≫ risk.

===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================

Step 9.1: COMPILE THE EVIDENCE
FOR:
- Real hang/storm with hardware logs
- Small, obviously correct, SEA-gated
- Applies cleanly to this 6.18 tree; helper already present
- Prior APEI SIGBUS fixes in this tree leave this hole
- Reviewed by APEI reviewers (Luck, Xue) and applied by Rafael

AGAINST:
- Trigger is RAS/PFNMAP, not every machine
- No Fixes:/Cc: stable (not a negative per rules)
- Incomplete if multiple concurrent distinct SEA sources all stay cached
  (accepted on-list)

UNRESOLVED:
- Could not HTTP-fetch lore (403); used `b4 mbox` instead
- UNVERIFIED: later mainline follow-ups after this commit
- UNVERIFIED: independent stable@ threads besides v1/v2

Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. Obviously correct and tested? PASS — v2 after review; logs; R-b from
   Luck/Xue/Ma
2. Fixes a real bug that affects users? PASS — documented SEA storm on
   devmem/PFNMAP
3. Important issue? PASS — hang / exception storm / possible firmware
   reboot
4. Small and contained? PASS — one function, ~9 lines
5. No new features or APIs? PASS
6. Can apply to the local tree? PASS — hunk present, helper present, not
   already applied

Step 9.3: CHECK FOR EXCEPTION CATEGORIES
Record: None (not a device ID/quirk/DT/build/doc exception). Qualifies
as a normal important bugfix.

Step 9.4: MAKE YOUR DECISION
This should be backported to this 6.18 tree. It closes a remaining ARM64
GHES SEA loop after the task-work SIGBUS work already in 6.18, with
negligible regression risk.

Verification:
- [Phase 1] Parsed tags: 3 Reviewed-by (Ma, Xue, Luck), Link msgid,
  Rafael SOB; no Fixes/Cc:stable/syzbot
- [Phase 2] Diff: +9/-1 in `ghes_in_nmi_queue_one_entry()`; `-ECANCELED`
  only if cached && `is_hest_sync_notify()`
- [Phase 2] Confirmed `action_result(MF_RECOVERED)` returns 0;
  `memory_failure_cb` skips SIGBUS; free-buddy path skips
  `kill_accessing_process`
- [Phase 2] Confirmed `79a5ae3c4c5eb` force-kill is `sync && !queued`
  only, so first SEA that queues work is not covered
- [Phase 3] blame: cache skip `d9f608dc156487` (2019);
  `is_hest_sync_notify` `a70297d221325`; both ancestors of HEAD
- [Phase 3] `git merge-base --is-ancestor` : a70297, c1f1fda, 79a5ae3,
  d9f608dc all in this tree
- [Phase 3] `git log --grep='repeated SEA'` on `drivers/acpi/`: empty —
  commit not here
- [Phase 4] `b4 am`/`b4 mbox`: v1 12 msgs (2025-10-30), v2 10 msgs
  (2026-05-27); v2 is applied version
- [Phase 4] Tony Luck questioned SDEI vs SEA callers; author said SEA-
  only; Luck R-b; Rafael applied as 7.3 material
- [Phase 4] lore HTTP 403; discussion taken from b4 mboxes
- [Phase 5] callers: `ghes_in_nmi_spool_from_list`,
  `__ghes_sdei_callback`; user path `do_sea` → `apei_claim_sea`; KVM
  `kvm_handle_guest_sea`
- [Phase 6] `git describe HEAD` = p-6.18-1-g03b85e06ca9bf; `make
  kernelversion` = 6.18.53
- [Phase 6] exact old hunk still in `ghes.c:1373-1375`; new hunk absent
- [Phase 8] Failure mode: SEA storm ~10s (log timestamps 1419 → 1429),
  then SIGBUS; severity HIGH/CRITICAL
- UNVERIFIED: follow-up commits after this one in later mainline; other
  stable@ threads

**YES**

 drivers/acpi/apei/ghes.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 5b52455d86e02..1a77aba0475be 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -1371,8 +1371,16 @@ static int ghes_in_nmi_queue_one_entry(struct ghes *ghes,
 	ghes_clear_estatus(ghes, &tmp_header, buf_paddr, fixmap_idx);
 
 	/* This error has been reported before, don't process it again. */
-	if (ghes_estatus_cached(estatus))
+	if (ghes_estatus_cached(estatus)) {
+		/*
+		 * Return failure on duplicate SEA entries so that the
+		 * subsequent SEA handler invocation sends a SIGBUS signal to
+		 * the task to prevent it from re-entering the handler loop.
+		 */
+		if (is_hest_sync_notify(ghes))
+			rc = -ECANCELED;
 		goto no_work;
+	}
 
 	llist_add(&estatus_node->llnode, &ghes_estatus_llist);
 
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.1] ACPI: scan: Defer device power initialization

[Sasha Levin]

From: Peixin Xie <peixin.xie@linux.spacemit.com>

[ Upstream commit dc948f8b384a516ac5c471eb9382959f838e02f4 ]

acpi_bus_get_power_flags() initializes the device power state while the
ACPI device object is being created, before checking whether the device
is ready for enumeration.

If enumeration is deferred, acpi_bus_attach() clears the initialized and
power_manageable flags. When the dependency is later satisfied,
acpi_bus_init_power() is called again and takes additional references to
the power resources used by the device. These references prevent the
resources from being turned off when the device enters D3.

This issue was reproduced on a SpacemiT K3 RISC-V Pico-ITX. The affected
device uses a power resource through _PR0 and has an automatically
derived dependency on its interrupt controller.

The initial power initialization acquires a power resource reference.
The device is then deferred, but that reference is not dropped. When
the dependency becomes available, power initialization acquires another
reference. Consequently, entering D3 only drops the reference count
from 2 to 1 and _OFF is not evaluated:

 [    0.314611] ACPI Debug:  "I2P2 _STA"
 [    0.318260] ACPI: \_SB_.I2P2: ACPI: PM: Power resource is on
 [    0.323998] ACPI: \_SB_.I2P2: New power resource
 [    0.382108] ACPI Debug:  "I2P2 _STA"
 [    0.478964] ACPI Debug:  "I2P2 _ON"
 [    0.482498] ACPI: \_SB_.I2P2: ACPI: PM: Power resource turned on
 [    0.488597] ACPI Debug:  "I2C2, PS0"
 [    0.863170] ACPI: \_SB_.I2P2: ACPI: PM: Power resource already on
 [    0.873686] ACPI Debug:  "I2C2, PS0"
 [    2.416055] ACPI Debug:  "I2C2, PS3"
 [    2.423397] ACPI: \_SB_.I2P2: ACPI: PM: Power resource still in use

To address this, remove the early acpi_bus_init_power() call and leave
regular ACPI device objects uninitialized until acpi_bus_attach() runs
after the device is ready for enumeration.

Power resource objects are initialized through acpi_add_power_resource()
and do not require the generic initialization in acpi_bus_attach(), so
mark them as initialized there.

After the change, device power state initialization is deferred until its
dependency is met. Since no reference is acquired before then, the power
resource left on by firmware is turned off as unused after the namespace
scan. Once the dependency is met, the resource is turned on once for the
device and is turned off normally when the device later enters D3:

 [    0.314628] ACPI Debug:  "I2P2 _STA"
 [    0.318277] ACPI: \_SB_.I2P2: ACPI: PM: Power resource is on
 [    0.324016] ACPI: \_SB_.I2P2: New power resource
 [    0.382118] ACPI Debug:  "I2P2 _STA"
 [    0.496116] ACPI: \_SB_.I2P2: ACPI: PM: Turning OFF
 [    0.501081] ACPI Debug:  "I2P2 _OFF"
 [    0.504705] ACPI: \_SB_.I2P2: ACPI: PM: Power resource turned off
 [    1.415899] ACPI Debug:  "I2P2 _ON"
 [    1.418866] ACPI: \_SB_.I2P2: ACPI: PM: Power resource turned on
 [    1.424947] ACPI Debug:  "I2C2, PS0"
 [    2.647655] ACPI Debug:  "I2C2, PS3"
 [    2.654856] ACPI Debug:  "I2P2 _OFF"
 [    2.654866] ACPI: \_SB_.I2P2: ACPI: PM: Power resource turned off

This also avoids powering up devices before their dependencies are
available.

Signed-off-by: Peixin Xie <peixin.xie@linux.spacemit.com>
[ rjw: Changelog edits ]
Link: https://patch.msgid.link/20260820-acpi-power-resource-ref-fix-v2-1-29818173ea13@linux.spacemit.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The local tree is 6.12.111. The buggy ACPI power-init path is present
here, so the rest of this is whether the leak is backport-worthy for
this checkout.

===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================

**Step 1.1: PARSE THE SUBJECT LINE**
Record: `[ACPI: scan:] [Defer] [device power initialization]`
Subsystem ACPI scan/PM. “Defer” is a timing change that the body
presents as a leak fix, not a feature.

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
Record:
- Signed-off-by: Peixin Xie \<peixin.xie@linux.spacemit.com\> (author)
- `[ rjw: Changelog edits ]` — ACPI maintainer edited the changelog
- Link: https://patch.msgid.link/20260820-acpi-power-resource-ref-
  fix-v2-1-29818173ea13@linux.spacemit.com
- Signed-off-by: Rafael J. Wysocki \<rafael.j.wysocki@intel.com\>
  (ACPI/PM maintainer)
- No Fixes:, Reported-by:, Tested-by:, Reviewed-by:, Acked-by:, or Cc:
  stable (absence is expected)
- Ignore any pipeline “Upstream commit” / Sasha Levin SOB if present

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
Record:
- Bug: `acpi_bus_get_power_flags()` calls `acpi_bus_init_power()` while
  the ACPI device is created, before readiness for enumeration. If
  attach defers the device, it clears `initialized` and
  `power_manageable` without dropping power-resource refs. Later re-init
  takes a second ref. D3 then drops 2→1 and `_OFF` is never evaluated.
- Symptom: power resource “still in use”; device stays powered in D3.
  Reproduced on SpacemiT K3 RISC-V Pico-ITX (I2C with `_PR0`, auto-dep
  on interrupt controller). Logs show `_ON` twice, then `_PS3` without
  `_OFF`.
- Root cause: leaked power-resource `ref_count` across deferred
  enumeration.
- Fix: drop the early `acpi_bus_init_power()`; leave `initialized` false
  until `acpi_bus_attach()` after the device is ready; mark power-
  resource objects `initialized` in `acpi_add_power_resource()`. Side
  effect: firmware-on unused resources can be turned off after namespace
  scan, then turned on once when the dependency is met.

**Step 1.4: DETECT HIDDEN BUG FIXES**
Record: This is an explicit bug fix (unbalanced power-resource refs),
not a disguised cleanup. The subject says “Defer” because that is the
mechanism.

===============================================================
PHASE 2: DIFF ANALYSIS - LINE BY LINE
===============================================================

**Step 2.1: INVENTORY THE CHANGES**
Record:
- `drivers/acpi/power.c`: +1 (`device->flags.initialized = true` in
  `acpi_add_power_resource()`)
- `drivers/acpi/scan.c`: −4 (remove `acpi_bus_init_power()` from
  `acpi_bus_get_power_flags()`; remove `initialized = true` from
  `acpi_init_device_object()`)
- Functions: `acpi_add_power_resource`, `acpi_bus_get_power_flags`,
  `acpi_init_device_object`
- Scope: single-subsystem, surgical (~5 lines)

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
Record:
- Hunk 1 (`power.c`): power-resource objects skip generic attach init;
  they must still be marked initialized so later `acpi_bus_attach()`
  does not treat them as uninitialized ACPI devices.
- Hunk 2 (`acpi_bus_get_power_flags`): still discovers `_PRx`/`_PSx` and
  fills state lists, but no longer takes refs / evaluates `_ON` at
  object-creation time.
- Hunk 3 (`acpi_init_device_object`): `initialized` stays false
  (kzalloc-zeroed) until attach. Existing attach path already does:
  - not ready → leave uninitialized, clear `power_manageable`
  - ready && `!initialized` → `acpi_bus_init_power()` once, then set
    `initialized`

Before: init at create (ref=1) → defer (flags cleared, ref still 1) →
later init (ref=2) → D3 (ref=1, no `_OFF`).
After: no early ref → defer → later init (ref=1) → D3 (ref=0, `_OFF`).

**Step 2.3: IDENTIFY THE BUG MECHANISM**
Record: Reference-counting / resource leak (ACPI power-resource
`ref_count`, not kmalloc). `acpi_power_on_unlocked()` does
`ref_count++`; `acpi_power_off_unlocked()` only calls `_OFF` when count
hits 0. Extra init leaves a sticky ref so D3 never turns the resource
off. Category: logic/correctness + PM refcount.

**Step 2.4: ASSESS THE FIX QUALITY**
Record: Obviously correct relative to the attach-time init path that has
existed since 2015 (`1b1f3e1699a988`). Minimal. Regression risk is the
global move of first `acpi_bus_init_power()` from add to attach for
every ACPI device, plus unused resources of deferred devices being
turned off after scan (existing DMI quirks already cover platforms that
cannot tolerate that). For devices ready immediately, attach still runs
in the same `acpi_bus_scan()` before driver probe, so common x86/ACPI
paths stay equivalent. Power-resource `initialized=true` is required so
walk-of-children attach does not mis-init those objects. Early devices
that skip `acpi_bus_attach()` (fixed power/sleep button, ECDT EC)
typically have no `_PR0`/`_PS0`; `acpi_device_enumerated()` was already
false because `visited` is unset — verified no change there.

===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================

**Step 3.1: BLAME THE CHANGED LINES**
Record:
- Early `acpi_bus_init_power()` in `acpi_bus_get_power_flags`:
  `1b1f3e1699a988` (2015-01-05, “ACPI / PM: Fix PM initialization for
  devices that are not present”) — in this tree.
- `initialized = true` in `acpi_init_device_object`: `202317a573b20d`
  (2013-11-22) — in this tree.
- Attach-time re-init: same 2015 commit.
- The leak becomes reachable when enumeration is deferred *and* the
  device is still present (`acpi_dev_ready_for_enumeration()` can fail
  on `honor_deps && dep_unmet` while `acpi_device_is_present()` is
  true). Honor-deps: `9d9bcae47fd5a` (2021, INT3472). RISC-V PLIC/APLIC
  on the honor list: `15f210f43e95f` (2024-08-27) — ancestor of v6.12
  and of HEAD.

**Step 3.2: FOLLOW THE FIXES: TAG**
Record: No Fixes: tag. The interaction is old init (2013–2015) plus
deferred enumeration (2021, much wider on RISC-V ACPI in 6.12).

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**
Record: Recent `scan.c` work is honor-list and dep-scan
(`15f210f43e95f`, `b38c61f1f394d`, `0dae3d96ca011`). Recent `power.c`
work includes unused-resource DMI quirks (`d08fb559b4557`,
`9b04d99788cf4`). This patch is standalone, not “2/N”. v1 was a
different approach (forced D3cold on defer); v2 replaced it.

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**
Record: No prior Peixin Xie ACPI commits in this tree. The design is
Rafael’s (v1 review), and he applied v2.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**
Record: Uses existing `acpi_bus_attach()` uninitialized path.
`acpi_init_device_object()` callers in this tree are only
`acpi_add_single_object()` and `acpi_add_power_resource()`. No missing
helpers. Standalone; applies to this tree.

===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**
Record:
- v2 lore msgid: `20260820-acpi-power-resource-ref-
  fix-v2-1-29818173ea13@linux.spacemit.com`
- v1: `20260811-acpi-power-resource-ref-
  fix-v1-1-828f1c383831@linux.spacemit.com`
- v1: drop refs by `acpi_power_transition(..., D3_COLD)` on the not-
  ready path. Rafael: pointless to power up then immediately down; drop
  early `acpi_bus_init_power()` and init once when ready.
- Author tested that on SpacemiT K3; runtime suspend/resume balanced.
- Rafael then asked to clear `initialized` in
  `acpi_init_device_object()` and set it in `acpi_add_power_resource()`
  (exactly v2).
- v2 reply from Rafael: “Applied as 7.3-rc material, thanks!” No NAK. No
  reviewer Cc: stable.
- Base-commit on the patch: `d58772d8520c7ef247c4b95c9bd76d3a25da9ff5`
  (mainline-era, not this branch).

**Step 4.2: CHECK WHO REVIEWED THE PATCH**
Record: To/Cc: Rafael J. Wysocki, Len Brown, Yixun Lan, linux-acpi,
linux-kernel, linux-riscv, spacemit. Maintainer designed and applied it.
No extra Reviewed-by.

**Step 4.3: SEARCH FOR THE BUG REPORT**
Record: No syzbot/bugzilla. Hardware report from the author with
before/after ACPI Debug traces (I2C2/I2P2 in v2; USBD.PDPR in v1). Real-
world, not theoretical.

**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**
Record: Single-patch series, v1→v2 only. No extra patches required for
the leak itself.

**Step 4.5: CHECK STABLE MAILING LIST HISTORY**
Record: No stable@ discussion found for this msgid. Not a reason to
reject.

===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================

**Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF**
Record: `acpi_bus_get_power_flags`, `acpi_init_device_object`,
`acpi_add_power_resource`. Callers of the removed init:
`acpi_bus_init_power` still from `acpi_bus_attach` and
`acpi_device_update_power`.

**Step 5.2: TRACE CALLERS**
Record:
- `acpi_bus_get_power_flags()` ← `acpi_add_single_object()` during
  namespace scan.
- `acpi_init_device_object()` ← `acpi_add_single_object()`,
  `acpi_add_power_resource()`.
- `acpi_bus_attach()` ← `acpi_bus_scan()` (pass 1),
  `acpi_scan_clear_dep_fn()` (deferred), hotplug attach.
- `acpi_scan_add_dep()` sets `honor_dep` when the supplier HID is in
  `acpi_honor_dep_ids` (PLIC `RSCV0001`, APLIC `RSCV0002`, INT3472,
  IVSC, PNP0C0F, ACPI0016, …). RISC-V `arch_acpi_add_auto_dep()` adds
  GSI/PLIC deps for devices with interrupts.

**Step 5.3: TRACE CALLEES**
Record: `acpi_bus_init_power()` → `acpi_device_get_power()` →
`acpi_power_on_resources()` → `acpi_power_on_list()` →
`acpi_power_on_unlocked()` (`ref_count++`, maybe `_ON`). End of
`acpi_scan_init()` calls `acpi_turn_off_unused_power_resources()` only
for `ref_count==0`.

**Step 5.4: FOLLOW THE CALL CHAIN**
Record: Boot ACPI scan, no userspace needed. On RISC-V ACPI, any GSI
consumer depending on PLIC/APLIC is deferred; if it also has `_PR0`, the
leak fires (I2C and USB in the reports). On x86, INT3472/IVSC camera
`_DEP` devices with power resources are the same class. Reachable on
real hardware in this tree.

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**
Record: Same extra-ref pattern is unique to “init, then clear flags
without dropping refs.” Wakeup-resource refcount has had its own stable-
worthy fixes historically; this patch does not touch that.

===============================================================
PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE
===============================================================

**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**
Record: Yes.
- Tree: `pending-6.12`, `git describe` `p-6.12-3-gc504cf0baa3d8`, `make
  kernelversion` **6.12.111**
- `drivers/acpi/scan.c:1160-1161` still calls `acpi_bus_init_power()`
  from `acpi_bus_get_power_flags()`
- `scan.c:1844` still sets `initialized = true` at object creation
- `scan.c:2298-2315` still clears flags on defer and re-inits if
  `!initialized`
- `power.c` `acpi_add_power_resource()` does **not** set `initialized`
- Subject not in `git log` on these files — not already applied
- RISC-V honor list + `arch_acpi_add_auto_dep()` are in this tree
  (`15f210f43e95f` is ancestor of v6.12)

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**
Record: Clean apply. The three contexts match. Mainline `kzalloc_obj` vs
this tree’s `kzalloc` is outside the hunk. Extra `strcpy` of name/class
in this tree is also outside the hunk.

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**
Record: No alternate fix. Unused-resource DMI quirks are unrelated (they
skip turning unused resources off).

===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================

**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**
Record: ACPI scan + ACPI PM (`drivers/acpi/scan.c`,
`drivers/acpi/power.c`). IMPORTANT: not mm/scheduler, but ACPI device PM
on every ACPI platform. Broken D3/runtime-PM for deferred devices.

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**
Record: Mature core with ongoing honor-dep/RISC-V work in 6.11–6.12.
This is a bug in that shipped 6.12 behavior, not a new 7.3-only
subsystem.

===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================

**Step 8.1: DETERMINE WHO IS AFFECTED**
Record: Config/platform-specific, but not a toy driver. Trigger: ACPI
device with `_PR0`/`_PS0` power resources **and** deferred enumeration
(`honor_deps && dep_unmet`). Populations: RISC-V ACPI (PLIC/APLIC auto-
dep — 6.12 feature); Intel camera `_DEP` (INT3472/IVSC); PCI link / CXL
host-bridge honor list. Unaffected: devices enumerated immediately
(typical x86).

**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**
Record: Every boot on matching firmware. Not a race. Not unprivileged-
syscall. Common on RISC-V ACPI boards with powered I2C/USB; less common
on generic x86.

**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**
Record: Power-resource ref leak → `_OFF` skipped → rails stay on in D3;
runtime suspend does not actually power the device. Not
oops/corruption/CVE. Severity **HIGH** for PM correctness and
battery/embedded power; **MEDIUM** as a generic “will this brick 6.12
laptops?” risk. Author’s logs match the code (`still in use` is the
`ref_count != 0` debug in `acpi_power_off_unlocked()`).

**Step 8.4: CALCULATE RISK-BENEFIT RATIO**
Record:
- Benefit: HIGH for RISC-V ACPI 6.12 users and any honor-dep + `_PR0`
  device; restores D3/`_OFF` and avoids powering devices before deps
  exist.
- Risk: LOW. Five lines, maintainer-designed, uses the existing attach
  init path. Common (non-deferred) devices only shift init from add to
  attach in the same scan, before probe.
- Ratio: benefit > risk for this tree because 6.12 shipped RISC-V auto-
  deps that make the leak easy to hit.

===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================

**Step 9.1: COMPILE THE EVIDENCE**

FOR:
- Real, reproduced leak; D3 does not turn resources off
- Buggy code and RISC-V honor-dep trigger are in 6.12.111
- Small, obviously correct, standalone
- ACPI maintainer specified v2 and applied it
- Tested with before/after traces
- Applies cleanly here

AGAINST:
- Not crash/security/filesystem corruption
- Changes first power-init timing for all ACPI devices
- Unused resources of deferred devices may `_OFF` after scan (intended;
  DMI quirks exist for broken firmware)
- No Cc: stable (not a negative per rules)
- Relatively new mainline (7.3-rc, ~Aug 2026)

UNRESOLVED:
- Mainline SHA not in this checkout (cannot `merge-base` the upstream
  commit). Not needed: the diff matches local code.
- No evidence of a revert in the month after apply (lore v2 thread is
  apply-only).

**Step 9.2: APPLY THE STABLE RULES CHECKLIST**
1. Obviously correct and tested? **PASS** — maintainer-designed;
   hardware logs.
2. Real bug that affects users? **PASS** — SpacemiT K3; any RISC-V ACPI
   `_PR0` + PLIC dep.
3. Important issue? **PASS** — sticky power resources break runtime
   D3/`_OFF`; serious PM bug, not a crash. Matches “etc.” for production
   PM.
4. Small and contained? **PASS** — 5 lines, two ACPI files.
5. No new features or APIs? **PASS**
6. Can apply to the local tree? **PASS** — contexts match; bug exists
   here.

**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**
Record: None (not a device ID/quirk/DT/build/docs add). Qualifies as a
normal bugfix.

**Step 9.4: MAKE YOUR DECISION**
This tree added RISC-V interrupt-controller honor deps. Combined with
early `acpi_bus_init_power()`, deferred present devices leak power-
resource refs and cannot leave D0 electrically. The fix is the attach-
time init path this tree already has, plus marking power-resource
objects initialized. That is appropriate for 6.12.y.

Verification:
- [Phase 1] Parsed tags: author SOB, Rafael SOB + changelog edits, lore
  Link; no Fixes/Cc:stable/syzbot
- [Phase 2] Diff: −4/+1; remove early init; delay `initialized`; set it
  in `acpi_add_power_resource()`
- [Phase 2] Confirmed `acpi_power_on_unlocked`/`acpi_power_off_unlocked`
  refcount vs “still in use” log
- [Phase 3] `git describe HEAD` / `make kernelversion`: p-6.12-3 /
  6.12.111
- [Phase 3] blame: early init `1b1f3e1699a988` (2015); `initialized`
  `202317a573b20d` (2013)
- [Phase 3] `git merge-base --is-ancestor 15f210f43e95f HEAD` and
  `v6.12`: YES (RISC-V honor list)
- [Phase 3] `git merge-base --is-ancestor 9d9bcae47fd5a HEAD`: YES
  (INT3472 honor)
- [Phase 3] `git log --grep="Defer device power initialization" --
  drivers/acpi/`: empty (not applied)
- [Phase 4] `b4 mbox` v2: Rafael “Applied as 7.3-rc material”
- [Phase 4] `b4 mbox` v1: Rafael requested this approach; author
  confirmed K3
- [Phase 5] callers: `acpi_add_single_object` → get_power_flags; attach
  re-init; RISC-V `arch_acpi_add_auto_dep` → `acpi_scan_add_dep` with
  PLIC/APLIC honor_dep
- [Phase 6] local `scan.c:1160` and `1844` still buggy; `power.c` lacks
  `initialized = true`
- [Phase 6] three hunks match this tree (clean apply)
- [Phase 8] failure: D3 does not `_OFF`; severity HIGH for PM, not oops
- UNVERIFIED: exact mainline SHA in torvalds.git (git.kernel.org HTML
  blocked); does not affect the local-tree decision

**YES**

 drivers/acpi/power.c | 1 +
 drivers/acpi/scan.c  | 4 ----
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
index 6d16740e1d70a..0d9c3fcf895ff 100644
--- a/drivers/acpi/power.c
+++ b/drivers/acpi/power.c
@@ -959,6 +959,7 @@ struct acpi_device *acpi_add_power_resource(acpi_handle handle)
 	strscpy(acpi_device_class(device), ACPI_POWER_CLASS);
 	device->power.state = ACPI_STATE_UNKNOWN;
 	device->flags.match_driver = true;
+	device->flags.initialized = true;
 
 	/* Evaluate the object to get the system level and resource order. */
 	status = acpi_evaluate_object(handle, NULL, NULL, &buffer);
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 7f9dd2704f638..e049fcfee2a84 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1144,9 +1144,6 @@ static void acpi_bus_get_power_flags(struct acpi_device *device)
 		if (!list_empty(&device->power.states[ACPI_STATE_D3_HOT].resources))
 			device->power.states[ACPI_STATE_D3_COLD].flags.valid = 1;
 	}
-
-	if (acpi_bus_init_power(device))
-		device->flags.power_manageable = 0;
 }
 
 static void acpi_bus_get_flags(struct acpi_device *device)
@@ -1826,7 +1823,6 @@ void acpi_init_device_object(struct acpi_device *device, acpi_handle handle,
 	acpi_init_properties(device);
 	acpi_bus_get_flags(device);
 	device->flags.match_driver = false;
-	device->flags.initialized = true;
 	device->flags.enumeration_by_parent =
 		acpi_device_enumeration_by_parent(device);
 	acpi_device_clear_enumerated(device);
-- 
2.53.0