[PATCH AUTOSEL 6.18] i2c: qup: Propagate clock enable failures

[PATCH AUTOSEL 6.18] i2c: qup: Propagate clock enable failures

[Sasha Levin]

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

[ Upstream commit a477626332800942f463d76aa48db0c47f1dfd18 ]

The QUP I2C driver treats the core and iface clocks as required
resources, but qup_i2c_enable_clocks() ignores clk_prepare_enable()
failures.  Probe can then continue to register the I2C adapter, and
runtime/system resume can return success, even when a required clock
transition failed.

Make the helper return an error, unwind a partially enabled clock, and
propagate failures from probe and resume paths.

Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20260624055237.29977-1-pengpeng@iscas.ac.cn
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The local checkout is **v7.3-rc4**. The driver and the ignored-clock-
enable bug exist in this lineage (since v3.15); the fix is a small,
self-contained error-path change that belongs in this tree.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: PARSE THE SUBJECT LINE**

Record: **[i2c: qup]** **[Propagate]** — make `clk_prepare_enable()`
failures visible instead of swallowing them.

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

Record:
- **Fixes:** none (expected)
- **Reported-by:** none
- **Tested-by:** none
- **Reviewed-by:** Konrad Dybcio (Qualcomm / linux-arm-msm)
- **Acked-by:** none
- **Link:**
  https://lore.kernel.org/r/20260624055237.29977-1-pengpeng@iscas.ac.cn
- **Cc: stable:** none (expected)
- **Signed-off-by:** Pengpeng Hou (author); Andi Shyti (I2C maintainer)
- No syzbot / kernel test robot tags

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

Record:
- **Bug:** `qup_i2c_enable_clocks()` treats core and iface clocks as
  required, but ignores `clk_prepare_enable()` return values.
- **Symptoms:** probe still registers the I2C adapter; runtime/system
  resume still return success after a required clock failed.
- **Version info:** none in the message. Git shows the ignore-return
  pattern since the driver was added.
- **Root cause:** void helper with unchecked clock enables; callers
  cannot fail.

**Step 1.4: DETECT HIDDEN BUG FIXES**

Record: Not disguised. It is an explicit error-path fix: check returns,
unwind a half-enabled clock, propagate from probe and resume.

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1: INVENTORY THE CHANGES**

Record:
- **File:** `drivers/i2c/busses/i2c-qup.c` — **+24 / −7** (31 lines)
- **Functions:** `qup_i2c_enable_clocks`, `qup_i2c_probe`,
  `qup_i2c_pm_resume_runtime`, `qup_i2c_resume`
- **Scope:** single-file surgical fix

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

Record:
1. **Helper:** void, two unchecked `clk_prepare_enable()` → `int`, abort
   on first failure, disable core clk if iface enable fails.
2. **Probe (DT path only):** ignore enable → `ret = …; if (ret) goto
   fail_dma`. ACPI path still skips this helper.
3. **Runtime resume:** always `return 0` → return the helper’s error.
4. **System resume:** always `pm_request_autosuspend()` after resume →
   skip autosuspend request if clocks failed.

**Step 2.3: IDENTIFY THE BUG MECHANISM**

Record: **Error-path / ignored-return + resource leak.**
- Broken: required clocks can fail; driver still MMIO-resets the QUP
  (`writel` to `QUP_SW_RESET` immediately after enable in probe) and
  later runs I2C with clocks off; iface-fail leaves core clk enabled.
- Fix: fail probe/resume, unwind partial enable.

**Step 2.4: ASSESS THE FIX QUALITY**

Record: Obviously correct and matches other I2C host drivers. `goto
fail_dma` is the right label: `fail:` would call
`qup_i2c_disable_clocks()` and MMIO/unprepare clocks that were never (or
no longer) enabled. Regression risk is low: a real clock failure now
fails probe/resume instead of continuing on dead hardware.

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: BLAME THE CHANGED LINES**

Record: Ignored enables introduced in **`10c5a8425968`** (“i2c: qup: New
bus driver…”, Bjorn Andersson, 2014). First contained in **v3.15-rc1**.
`git log -L :qup_i2c_enable_clocks:` shows only that commit and this
fix.

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

Record: No `Fixes:` tag. Original driver commit is an ancestor of HEAD.

**Step 3.3: CHECK FILE HISTORY**

Record: Recent related work is unrelated (`pm_runtime_mark_last_busy`,
timeout loop, interconnect vote). Older related fix **`3cf357dfb40b`**
already routed some probe errors to `fail` so clocks get released — this
patch fills the missing enable-check. Standalone, not `X/Y`.

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

Record: Pengpeng Hou has only this commit under `drivers/i2c/`. Reviewer
is a Qualcomm platform maintainer; committer is the I2C maintainer.

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

Record: No new APIs or structs. Applies standalone on this tree. No
follow-ups on `i2c-qup.c` after `a477626332800`.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

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

Record:
- **b4 dig:**
  https://patch.msgid.link/20260624055237.29977-1-pengpeng@iscas.ac.cn
- **Revisions:** v1 only (no v2/v3)
- **Review:** Konrad Dybcio `Reviewed-by` the same day; Andi Shyti
  merged to `i2c/i2c` (~2026-07-28). No NAK, no stable nomination in-
  thread.
- lore.kernel.org fetch returned 403; thread confirmed via gnuweeb,
  patchew, and openwall mirrors.

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

Record (`b4 dig -w`): To Andi Shyti; Cc linux-arm-msm, linux-i2c, linux-
kernel. Konrad was not in the original To/Cc but reviewed from linux-
arm-msm.

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

Record: No bugzilla/syzbot/user report. Issue is from code review of
ignored returns.

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

Record: Single standalone patch, not a series.

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

Record: No discussion of this subject on stable@ found
(lore.kernel.org/stable 403; web search did not hit this patch).

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: KEY FUNCTIONS**

Record: `qup_i2c_enable_clocks`, `qup_i2c_probe`,
`qup_i2c_pm_resume_runtime`, `qup_i2c_resume`. (semcode MCP not
available.)

**Step 5.2: TRACE CALLERS**

Record: Only three call sites in this file:
- `qup_i2c_probe` (DT/clk path, boot / module load)
- `qup_i2c_pm_resume_runtime` (runtime PM; also used as `RUNTIME_PM_OPS`
  resume)
- `qup_i2c_resume` → that runtime helper (system sleep)

Not interrupt context. Reachable on every QUP I2C device probe and every
resume.

**Step 5.3: TRACE CALLEES**

Record: `clk_prepare_enable` / `clk_disable_unprepare` only. Probe then
`clk_get_rate` and `writel(QUP_SW_RESET)`.

**Step 5.4: FOLLOW THE CALL CHAIN**

Record: Platform probe / PM resume. Userspace does not call this
directly, but every Qualcomm QUP I2C bus (touch, sensors, PMICs, cameras
on many phones and boards) goes through it. Unclocked MMIO after a
failed enable is a hang path.

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**

Record: Most I2C hosts already check `clk_prepare_enable`
(`i2c-designware-common.c`, `i2c-exynos5.c`, `i2c-img-scb.c`, etc.). A
few still ignore it (`i2c-mv64xxx.c`, `i2c-hix5hd2.c`). This brings QUP
in line with the common pattern.

---

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

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

Record: **Yes.** Tree is **v7.3-rc4** (`7.3.0-rc4`, `f0100363d8c37`).
Introducer `10c5a8425968` and fix `a477626332800` are both ancestors of
HEAD. Pre-fix helper in the parent of the fix is still the 2014 void
ignore-return version. Driver: `drivers/i2c/busses/i2c-qup.c`.

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**

Record: Clean apply on this tree (same file, same functions). No extra
prerequisites.

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

Record: No alternate fix for ignored enable. `3cf357dfb40b` only fixes a
later probe unwind, not enable checking. No post-fix regressions on this
file.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: SUBSYSTEM AND CRITICALITY**

Record: **I2C host driver** (`drivers/i2c/busses/i2c-qup.c`),
`CONFIG_I2C_QUP` (`ARCH_QCOM || COMPILE_TEST`). **IMPORTANT** for
Qualcomm platforms (common on phones, boards, IoT); not core mm/VFS.

**Step 7.2: SUBSYSTEM ACTIVITY**

Record: Mature driver (2014), still getting occasional correctness
fixes. Not a new subsystem.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: WHO IS AFFECTED**

Record: Qualcomm SoC users with QUP I2C (`qcom,i2c-qup-v1.1.1` /
`v2.1.1` / `v2.2.1`). Driver- and config-specific, but a large device
population.

**Step 8.2: TRIGGER CONDITIONS**

Record: `clk_prepare_enable()` failure on core or iface (probe, runtime
resume, or system resume). Unprivileged users cannot poke the helper,
but resume is a normal path. Failures are uncommon on healthy clocks;
they do happen with power-domain / RPM / -ENOMEM issues. No public
reproducer.

**Step 8.3: FAILURE MODE SEVERITY**

Record: Continuing after a failed enable then `writel`/`readl` on the
QUP can hang the interconnect; resume success with clocks off breaks
later transfers; iface-fail leaks a prepared core clk. **HIGH** when it
triggers (hang / stuck I2C), **MEDIUM** overall because triggers are
rare. Not a demonstrated CVE.

**Step 8.4: RISK-BENEFIT RATIO**

Record:
- **Benefit:** avoid unclocked MMIO and false-success resume on QUP I2C.
- **Risk:** very low (~24 insertions, error paths only, standard clk
  unwind).
- **Ratio:** favorable.

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: EVIDENCE**

**For:**
- Real ignored-error bug on required clocks.
- Probe immediately MMIO-resets the block; clocks-off access can hang.
- Resume used to report success with clocks still off.
- Partial enable leaked the core clock.
- 24 insertions in one file; obviously correct; no new API.
- Reviewed by Konrad Dybcio, merged by Andi Shyti.
- Bug present since v3.15; no extra dependencies.
- Matches the usual I2C host-driver pattern.

**Against:**
- No user/syzbot report in ~12 years.
- Clock enable rarely fails on working hardware.
- No in-thread `Cc: stable`.

**Unresolved:** Direct lore.kernel.org/stable search 403; no evidence
this was rejected for stable.

**Step 9.2: STABLE RULES CHECKLIST**

1. Obviously correct and tested? **PASS** — standard clk check/unwind;
   maintainer review/merge. No extra Tested-by.
2. Fixes a real bug that affects users? **PASS** — ignored required-
   clock failure on probe/resume.
3. Important issue? **PASS** — hang / dead I2C / clock leak on that
   path, not a style cleanup.
4. Small and contained? **PASS** — +24/−7, one file.
5. No new features or APIs? **PASS**.
6. Can apply to the local tree? **PASS** — driver and call sites match.

**Step 9.3: EXCEPTION CATEGORIES**

Record: None (not a device ID, quirk, DT, build, or doc fix). Qualifies
as a normal error-path bugfix.

**Step 9.4: DECISION**

This is a small, correct fix for ignored required-clock errors. On this
v7.3-rc4 tree the buggy helper and the QUP probe/resume paths are
present; the change prevents probe/resume from continuing into unclocked
MMIO. That is enough for stable, even without a field report.

---

### What it solves for this tree

`qup_i2c_enable_clocks()` used to ignore `clk_prepare_enable()`. Probe
still registered the adapter and then `writel`’d `QUP_SW_RESET`; resume
returned 0. If enable actually failed, that is unclocked MMIO (possible
SoC hang) plus a clock leak when only the iface clock failed. The patch
fails those paths and unwinds.

### Stable rules / risk

Meets the rules: real bug, small, no features, applies here. Benefit is
avoiding hangs and false-success PM on Qualcomm QUP I2C; risk is low.

### Concerns

No `Fixes:` / user report (not a reason to reject). `fail_dma` on enable
failure is correct. No follow-up fix found.

---

### Verification

- **[Phase 1]** Tags: Reviewed-by Konrad Dybcio; SOB Andi Shyti; Link
  lore msgid `20260624055237.29977-1`; no Fixes/Reported-by/Cc:stable.
- **[Phase 2]** Diff: +24/−7 in `i2c-qup.c`; helper becomes `int`;
  probe/resume propagate; partial unwind on iface fail.
- **[Phase 2]** Pre-fix parent: void helper, probe
  `qup_i2c_enable_clocks(qup)` then `writel(QUP_SW_RESET)`; resume
  always 0.
- **[Phase 2]** Post-fix probe uses `goto fail_dma` (not `fail`), so
  `qup_i2c_disable_clocks()` is not run on a failed enable.
- **[Phase 3]** `git log -L :qup_i2c_enable_clocks:` → `10c5a8425968`
  (v3.15-rc1) then `a477626332800`.
- **[Phase 3]** `git merge-base --is-ancestor` both SHAs vs HEAD: both
  in this tree.
- **[Phase 3]** Author: only this I2C commit; no later commits on this
  file after the fix.
- **[Phase 4]** `b4 dig -c a477626332800`: matched msgid; `-a`: v1 only;
  `-w`: Andi + linux-i2c/arm-msm.
- **[Phase 4]** Review: Konrad Reviewed-by; Andi “merged to i2c/i2c”; no
  NAK.
- **[Phase 4]** lore.kernel.org 403; gnuweeb/patchew/openwall used
  instead. Stable-list search: no hits for this subject.
- **[Phase 5]** Callers: probe, runtime resume, system resume only.
  Other I2C hosts already check `clk_prepare_enable`.
- **[Phase 6]** `git describe HEAD` → `v7.3-rc4-27-gf0100363d8c37`;
  `make kernelversion` → `7.3.0-rc4`. Buggy code existed; driver
  present.
- **[Phase 7]** `CONFIG_I2C_QUP` depends on `ARCH_QCOM`; I2C maintainer
  Andi Shyti.
- **[Phase 8]** Failure mode: unclocked MMIO / false resume success;
  severity HIGH if triggered, uncommon trigger.
- **UNVERIFIED:** Could not fetch lore.kernel.org HTML directly (403).
  Thread content verified via b4 + mirrors.

**YES**

 drivers/i2c/busses/i2c-qup.c | 31 ++++++++++++++++++++++++-------
 1 file changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index a0e076fc5f363..ee7915ee2ba2f 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -1657,10 +1657,21 @@ static const struct i2c_adapter_quirks qup_i2c_quirks_v2 = {
 	.flags = I2C_AQ_NO_ZERO_LEN,
 };
 
-static void qup_i2c_enable_clocks(struct qup_i2c_dev *qup)
+static int qup_i2c_enable_clocks(struct qup_i2c_dev *qup)
 {
-	clk_prepare_enable(qup->clk);
-	clk_prepare_enable(qup->pclk);
+	int ret;
+
+	ret = clk_prepare_enable(qup->clk);
+	if (ret)
+		return ret;
+
+	ret = clk_prepare_enable(qup->pclk);
+	if (ret) {
+		clk_disable_unprepare(qup->clk);
+		return ret;
+	}
+
+	return 0;
 }
 
 static void qup_i2c_disable_clocks(struct qup_i2c_dev *qup)
@@ -1823,7 +1834,9 @@ static int qup_i2c_probe(struct platform_device *pdev)
 			ret = PTR_ERR(qup->pclk);
 			goto fail_dma;
 		}
-		qup_i2c_enable_clocks(qup);
+		ret = qup_i2c_enable_clocks(qup);
+		if (ret)
+			goto fail_dma;
 		src_clk_freq = clk_get_rate(qup->clk);
 	}
 	qup->src_clk_freq = src_clk_freq;
@@ -1975,8 +1988,7 @@ static int qup_i2c_pm_resume_runtime(struct device *device)
 	struct qup_i2c_dev *qup = dev_get_drvdata(device);
 
 	dev_dbg(device, "pm_runtime: resuming...\n");
-	qup_i2c_enable_clocks(qup);
-	return 0;
+	return qup_i2c_enable_clocks(qup);
 }
 
 static int qup_i2c_suspend(struct device *device)
@@ -1988,7 +2000,12 @@ static int qup_i2c_suspend(struct device *device)
 
 static int qup_i2c_resume(struct device *device)
 {
-	qup_i2c_pm_resume_runtime(device);
+	int ret;
+
+	ret = qup_i2c_pm_resume_runtime(device);
+	if (ret)
+		return ret;
+
 	pm_request_autosuspend(device);
 	return 0;
 }
-- 
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] i2c: imx-lpi2c: properly unwind resources on probe failure

[Sasha Levin]

From: Carlos Song <carlos.song@nxp.com>

[ Upstream commit cbd043b00ee3f542c115c8809c4d9a67465c07d5 ]

When probe fails at devm_clk_rate_exclusive_get() or clk_get_rate(),
which occur before runtime PM is initialized, the clocks enabled by
clk_bulk_prepare_enable() are never disabled.

When probe fails after runtime PM is initialized, the previous error
path called pm_runtime_put_sync(), which triggers the runtime suspend
callback. However, due to different clock management strategies on
different SoCs[1] (to avoid deadlocks between the global prepare_lock
and runtime PM), the callback may only disable clocks without
unpreparing them, causing an incomplete unwind.

Introduce a new error label 'clk_disable' to explicitly invoke
clk_bulk_disable_unprepare(). Replace pm_runtime_put_sync() with the
sequence of pm_runtime_disable(), pm_runtime_set_suspended() and
pm_runtime_put_noidle() to bypass the runtime suspend callback during
error recovery. During the LPI2C driver probe phase, clock APIs are
used exclusively to manage clocks. Once probing succeeds, clock
management is handed over to the runtime PM core.

[1] https://lore.kernel.org/all/20251125084718.2156168-1-carlos.song@nxp.com/

Signed-off-by: Carlos Song <carlos.song@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20260716071957.2670263-2-carlos.song@oss.nxp.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The local tree is **6.12.111** (`pending-6.12`). The buggy probe unwind
is present here; the later SoC-specific clock strategy is not. The leak
is real and the fix is a small error-path change.

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

Step 1.1: PARSE THE SUBJECT LINE
Record: **[i2c: imx-lpi2c]** **[properly unwind]** probe resources are
not released when `lpi2c_imx_probe()` fails. “Properly unwind” is fix
language (missing cleanup), not a feature.

Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
Record:
- **Fixes:** none (expected for this review queue)
- **Reported-by / Tested-by / Acked-by / Cc: stable:** none
- **Reviewed-by:** Frank Li &lt;Frank.Li@nxp.com&gt;
- **Signed-off-by:** Carlos Song &lt;carlos.song@nxp.com&gt; (author);
  Andi Shyti &lt;andi.shyti@kernel.org&gt; (I2C maintainer, merger)
- **Link:** https://lore.kernel.org/r/20260716071957.2670263-2-
  carlos.song@oss.nxp.com
- **Inline [1]:** https://lore.kernel.org/all/20251125084718.2156168-1-
  carlos.song@nxp.com/ (later SoC clock/IRQ RPM split)
- Ignore any pipeline SOBs / “Upstream commit” markers

Step 1.3: ANALYZE THE COMMIT BODY TEXT
Record:
- **Bug:** After `clk_bulk_prepare_enable()`, two classes of probe
  failure leak clocks.
  1. Failures **before** RPM init (`devm_clk_rate_exclusive_get()`,
     `clk_get_rate()`): early `return` leaves clocks prepared **and**
     enabled.
  2. Failures **after** RPM init: `pm_runtime_put_sync()` runs
     `lpi2c_runtime_suspend()`, which on this tree only
     `clk_bulk_disable()`s (no unprepare), so the prepare count is left
     elevated.
- **Symptom:** Unbalanced clock prepare/enable. On `-EPROBE_DEFER` the
  prepare count grows on every retry.
- **Root cause:** Probe uses clock APIs; after success, RPM owns
  enable/disable. Error paths mixed the two and did not fully unwind.
- **Version info in message:** none for 6.12. `[1]` is the later
  i.MX8QXP/8QM RPM split (`949f647eff76a`, **not** in this tree).

Step 1.4: DETECT HIDDEN BUG FIXES
Record: Not hidden. Explicit resource-leak / incomplete error-path
unwind. Not style cleanup.

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

Step 2.1: INVENTORY THE CHANGES
Record:
- **File:** `drivers/i2c/busses/i2c-imx-lpi2c.c` (+14 / −7)
- **Function:** `lpi2c_imx_probe()` only
- **Scope:** single-file, error-path only

Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
Record:
- **Hunk 1 (pre-RPM errors):** `return dev_err_probe(...)` after
  exclusive-get / `clk_get_rate()` failure → `goto clk_disable` so
  `clk_bulk_disable_unprepare()` runs.
- **Hunk 2 (post-RPM errors):** `rpm_disable` no longer
  `pm_runtime_put_sync()`. It now `pm_runtime_disable()`,
  `pm_runtime_set_suspended()`, `pm_runtime_put_noidle()`, then falls
  through to `clk_disable` for `clk_bulk_disable_unprepare()`.
- **Success path:** unchanged (`pm_runtime_put_autosuspend()` still
  hands clocks to RPM).

Step 2.3: IDENTIFY THE BUG MECHANISM
Record: **Error-path resource leak (clock prepare/enable).**
- Missing `clk_bulk_disable_unprepare()` on early probe failure.
- RPM suspend used as unwind, but in **this** tree
  `lpi2c_runtime_suspend()` is only `clk_bulk_disable()` (since
  `fa39065833dbd`), so prepare is never reversed.
- `clk_disable` is an added put/unprepare, not a double-free: RPM
  suspend is skipped, then clocks are disabled and unprepared once.

Step 2.4: ASSESS THE FIX QUALITY
Record: Surgical and correct for this tree. Same pattern as other probe-
fail RPM unwinds. Success path untouched. Regression risk is low; the
only real risk is pairing `put_sync` with `disable_unprepare` (double-
disable). This patch removes `put_sync` and does one explicit unwind.

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

Step 3.1: BLAME THE CHANGED LINES
Record (this checkout):
- Early leak: `4268254a39484` (“Avoid calling clk_get_rate during
  transfer”, 2024-05-06) — **in v6.12**.
- RPM enable/disable-only callbacks: `fa39065833dbd` (2023) — **in
  v6.12**.
- `rpm_disable` + `put_sync`: `4f4388a55019d` / upstream `b1852c5de2f2a`
  (“Fix clock count when probe defers”) — **already in this 6.12 tree**.
  That only fixed the **enable** count; prepare still leaks.
- `-EPROBE_DEFER` from recovery pinctrl: `188542964e782` — **in this
  tree**.

Step 3.2: FOLLOW THE FIXES: TAG
Record: No `Fixes:` tag. Bug-introducing history above is in this tree.
`cbd043b00ee3f` is **not** an ancestor of HEAD.

Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
Record: Latest local change is `4f4388a55019d` (the incomplete enable-
count fix). This commit is the missing prepare-count half of that
unwind. Standalone for 6.12; does not need DMA, `hwdata`, or
`need_prepare_unprepare_clk`.

Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Record: Carlos Song is an NXP LPI2C contributor (GPIO recovery in this
tree). Frank Li reviewed. Andi Shyti merged. Series v6 patch 2
(`a4c419356a333`, controller reset) is independent and not required.

Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
Record: Message cites later SoC clock strategies (`949f647eff76a`,
2026-01-19) — **not in 6.12**. The **code** of this fix does not use
`hwdata` / `need_prepare_unprepare_clk`. Needed APIs
(`clk_bulk_disable_unprepare`, `pm_runtime_put_noidle`,
`pm_runtime_set_suspended`) exist in 6.12. **Can be backported
standalone** with context tweaks.

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

Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
Record:
- SHA: `cbd043b00ee3f542c115c8809c4d9a67465c07d5`
- `b4 dig -c`: https://patch.msgid.link/20260716071957.2670263-2-
  carlos.song@oss.nxp.com
- Series: **v6 1/2** “fix probe error handling and reset controller”
  (v4/v5/v6 of the same subject)
- Andi Shyti: merged to `i2c/i2c-2` (2026-07-28). No NAK.
- Cover letter: v3 replaced `put_sync` with disable + set_suspended +
  put_noidle specifically to avoid the suspend callback during error
  recovery.

Step 4.2: CHECK WHO REVIEWED THE PATCH
Record (`b4 dig -w`): linux-i2c, imx@lists, linux-arm-kernel; Andi
Shyti; Dong Aisheng (LPI2C maintainer in MAINTAINERS); Frank Li
(Reviewed-by); Pengutronix i.MX folks. Right audience.

Step 4.3: SEARCH FOR THE BUG REPORT
Record: No syzbot/bugzilla. Bug is from code review / NXP analysis, not
a crash report. Still a concrete leak with a documented `-EPROBE_DEFER`
path.

Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
Record: Patch 2/2 (reset in probe) is a separate hang-on-boot issue; not
a dependency. Earlier `b1852c5`/`4f4388a55019d` is the related
incomplete stable fix already here.

Step 4.5: CHECK STABLE MAILING LIST HISTORY
Record: lore.kernel.org/stable returned HTTP 403. No stable nomination
on the patch itself. Related defer clock-count fix **was** `Cc: stable #
v4.16+` and is already in this tree.

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

Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF
Record: `lpi2c_imx_probe()` only. Unwind interacts with
`lpi2c_runtime_suspend()` (not edited).

Step 5.2: TRACE CALLERS
Record: `.probe = lpi2c_imx_probe` on the platform driver. Called from
driver core on DT devices (`fsl,imx7ulp-lpi2c`) and on deferred retry.
Not a syscall hot path.

Step 5.3: TRACE CALLEES
Record: `clk_bulk_prepare_enable` / `clk_bulk_disable_unprepare`,
`devm_clk_rate_exclusive_get`, `clk_get_rate`, RPM helpers,
`lpi2c_imx_init_recovery_info()` (`devm_pinctrl_get` → `-EPROBE_DEFER`),
`i2c_add_adapter()`.

Step 5.4: FOLLOW THE CALL CHAIN
Record: Reachable at boot and on probe defer.
`lpi2c_imx_init_recovery_info()` is a real `-EPROBE_DEFER` source when
pinctrl is not ready. Unprivileged userspace does not need to trigger
it.

Step 5.5: SEARCH FOR SIMILAR PATTERNS
Record: Other I2C drivers use `clk_disable:` /
`clk_bulk_disable_unprepare` on probe fail (`i2c-qcom-geni.c`,
`i2c-qcom-cci.c`). This driver was the odd one out after RPM callbacks
stopped unpreparing.

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

Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?
Record: **Yes.** `lpi2c_imx_probe()` in `drivers/i2c/busses/i2c-imx-
lpi2c.c` still does:

```609:625:drivers/i2c/busses/i2c-imx-lpi2c.c
        ret = clk_bulk_prepare_enable(lpi2c_imx->num_clks,
lpi2c_imx->clks);
        if (ret)
                return ret;
        ...
        if (ret)
                return dev_err_probe(...);  /* exclusive_get: leak */
        ...
        if (!lpi2c_imx->rate_per)
                return dev_err_probe(...);  /* rate 0: leak */
```

```654:657:drivers/i2c/busses/i2c-imx-lpi2c.c
rpm_disable:
        pm_runtime_dont_use_autosuspend(&pdev->dev);
        pm_runtime_put_sync(&pdev->dev);
        pm_runtime_disable(&pdev->dev);
```

```672:679:drivers/i2c/busses/i2c-imx-lpi2c.c
static int __maybe_unused lpi2c_runtime_suspend(struct device *dev)
{
        ...
        clk_bulk_disable(lpi2c_imx->num_clks, lpi2c_imx->clks);
```

No `hwdata` / `need_prepare_unprepare_clk` here, so **every** SoC only
disables in RPM. The prepare leak on `rpm_disable` is unconditional.

Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
Record: **`git apply --check` fails** because context includes
`hwdata->need_prepare_unprepare_clk` and later DMA probe code. Logical
change maps 1:1 onto this probe (same exclusive-get returns, same
`rpm_disable` + `put_sync`). Difficulty: **minor context backport**, not
a rewrite.

Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE
Record: `4f4388a55019d` is here and only switched `pm_runtime_put()` to
`put_sync()`. It does **not** unprepare. No other unwind of this leak in
this tree.

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

Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
Record: I2C bus driver for i.MX LPI2C (`CONFIG_I2C_IMX_LPI2C`,
`ARCH_MXC`). **IMPORTANT** for i.MX boards (PMIC, audio, sensors on that
bus), not core MM/VFS. Maintainer: Dong Aisheng; I2C maintainer merged
it.

Step 7.2: ASSESS SUBSYSTEM ACTIVITY
Record: Mature driver (since ~2016). This tree’s recent churn is small
fixes, not a rewrite. The big SoC RPM split landed after 6.12.

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

Step 8.1: DETERMINE WHO IS AFFECTED
Record: **Driver-specific / platform-specific** — i.MX systems using
LPI2C. Common on i.MX7ULP / i.MX8 class boards, not all Linux users.

Step 8.2: DETERMINE THE TRIGGER CONDITIONS
Record:
- Exclusive-get / zero clock rate: uncommon hard errors.
- **`-EPROBE_DEFER` from pinctrl in recovery init:** normal boot race;
  retries leak another prepare each time.
- `i2c_add_adapter()` failure: less common.
- Not a userspace-triggered security path.

Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
Record: Clock prepare leak (and enable leak on the pre-RPM returns).
Repeated defer can unbalance the clock tree, keep parents prepared, and
block low power. Not an oops/corruption/CVE. **Severity: MEDIUM**,
higher if defer retries pile up.

Step 8.4: CALCULATE RISK-BENEFIT RATIO
Record:
- **Benefit:** Completes the unwind that `4f4388a55019d` only half-
  fixed; stops prepare-count growth on defer. Medium benefit for i.MX
  LPI2C users.
- **Risk:** ~20-line error-path change; success path unchanged. Low risk
  if backported without keeping `put_sync`.
- **Ratio:** Favorable.

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

Step 9.1: COMPILE THE EVIDENCE

**FOR backporting:**
- Real clock leak on probe failure, including a documented
  `-EPROBE_DEFER` path.
- Buggy code is in this 6.12 tree (exclusive-get + disable-only RPM +
  `put_sync` unwind).
- This tree already took the enable-count half (`4f4388a55019d`); this
  is the remaining prepare-count fix.
- Small, probe-error only; reviewed and merged by the I2C maintainer.
- No new API/feature; no `hwdata` dependency in the changed lines.

**AGAINST:**
- Does not apply with `git apply` as-is (later DMA/`hwdata` context).
- Not a crash/security/corruption bug.
- No `Cc: stable` / syzbot / user crash report.
- Message talks about later per-SoC clock strategies that 6.12 does not
  have (the leak is still real here, and simpler).

**UNRESOLVED:**
- Stable list search was blocked (HTTP 403). Unverified whether anyone
  already NAK’d this for stable.

Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. Obviously correct and tested? **PASS** — explicit unwind; merged
   after v4–v6 review.
2. Fixes a real bug that affects users? **PASS** — clock leak on probe
   fail/defer.
3. Important issue? **PASS** at medium — not panic-level, but resource
   leak on a normal defer path; sister fix already went to stable.
4. Small and contained? **PASS** — one function, error labels only.
5. No new features or APIs? **PASS**.
6. Can apply to the local tree? **PASS with backport** — code is here;
   context needs a small edit. Not “code missing / bug introduced after
   branch.”

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

Step 9.4: MAKE YOUR DECISION
Backport to **this** 6.12 tree. The later SoC RPM split is not required.
Drop `hwdata`/DMA context and apply the same `goto clk_disable` + RPM-
bypass + `clk_bulk_disable_unprepare()` sequence to `lpi2c_imx_probe()`.

Verification:
- [Phase 1] Tags: Reviewed-by Frank Li; SOB Andi Shyti; Link to v6 1/2;
  no Fixes/Cc:stable/syzbot
- [Phase 2] Diff: +14/−7 in `lpi2c_imx_probe()`; two early returns →
  `clk_disable`; `put_sync` → disable/set_suspended/put_noidle +
  `clk_bulk_disable_unprepare`
- [Phase 3] Blame: leak from `4268254a39484` (in v6.12); RPM disable-
  only from `fa39065833dbd` (in v6.12); incomplete enable fix
  `4f4388a55019d` already in HEAD
- [Phase 3] `git merge-base --is-ancestor cbd043b00ee3f HEAD` → not in
  this tree
- [Phase 3] `949f647eff76a` (`need_prepare_unprepare_clk`) → **not** in
  this tree
- [Phase 4] `b4 dig -c cbd043b00ee3f`: lore v6 1/2; Andi merged to
  i2c-2; no NAK
- [Phase 4] Cover: v3 introduced the RPM-bypass unwind; patch 2/2 is
  independent
- [Phase 4] UNVERIFIED: stable@ lore (403)
- [Phase 5] Probe is platform `.probe`; `-EPROBE_DEFER` from
  `devm_pinctrl_get` in recovery init
- [Phase 6] `git describe` / Makefile: 6.12.111; buggy returns and
  `rpm_disable` present; `git apply --check` fails on `hwdata` context
- [Phase 8] Failure mode: clock prepare leak, worse on deferred probe;
  severity MEDIUM; risk low

The leak exists on this 6.12 branch, the fix is small and correct, and
it finishes an unwind this tree already started.

**YES**

 drivers/i2c/busses/i2c-imx-lpi2c.c | 21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index 24c70ea371bb9..7c560a4f68319 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -1500,14 +1500,18 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
 	 * each transfer
 	 */
 	ret = devm_clk_rate_exclusive_get(&pdev->dev, lpi2c_imx->clks[0].clk);
-	if (ret)
-		return dev_err_probe(&pdev->dev, ret,
-				     "can't lock I2C peripheral clock rate\n");
+	if (ret) {
+		ret = dev_err_probe(&pdev->dev, ret,
+				    "can't lock I2C peripheral clock rate\n");
+		goto clk_disable;
+	}
 
 	lpi2c_imx->rate_per = clk_get_rate(lpi2c_imx->clks[0].clk);
-	if (!lpi2c_imx->rate_per)
-		return dev_err_probe(&pdev->dev, -EINVAL,
-				     "can't get I2C peripheral clock rate\n");
+	if (!lpi2c_imx->rate_per) {
+		ret = dev_err_probe(&pdev->dev, -EINVAL,
+				    "can't get I2C peripheral clock rate\n");
+		goto clk_disable;
+	}
 
 	pm_runtime_set_autosuspend_delay(&pdev->dev, I2C_PM_TIMEOUT);
 	pm_runtime_use_autosuspend(&pdev->dev);
@@ -1545,8 +1549,11 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
 
 rpm_disable:
 	pm_runtime_dont_use_autosuspend(&pdev->dev);
-	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
+	pm_runtime_set_suspended(&pdev->dev);
+	pm_runtime_put_noidle(&pdev->dev);
+clk_disable:
+	clk_bulk_disable_unprepare(lpi2c_imx->num_clks, lpi2c_imx->clks);
 
 	return ret;
 }
-- 
2.53.0

[PATCH AUTOSEL 6.18] i2c: amd-asf: Validate firmware-reported length

[Sasha Levin]

From: Paritosh Potukuchi <paritoshpotukuchi@gmail.com>

[ Upstream commit b2f4816a378dc840b605a1235b80e57c5f85b46c ]

The firmware may sometimes return a length greater than the
allocated buffer size, which can lead to out-of-bounds access
and a kernel panic.

Currently, the driver does not validate the length read from
firmware.

Add a check to ensure the firmware-reported length stays within
the bounds of the data buffer.

Signed-off-by: Paritosh Potukuchi <paritosh.potukuchi@amd.com>
Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20260612101815.4124804-1-paritosh.potukuchi@amd.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit message forensics

**Step 1.1 — Subject line**
Record: **[i2c/amd-asf] [Validate] firmware-reported length used as a
copy bound**

**Step 1.2 — Tags** (pipeline markers ignored: `[Upstream commit ...]`,
`Signed-off-by: Sasha Levin`)
Record:
- Signed-off-by: Paritosh Potukuchi &lt;paritosh.potukuchi@amd.com&gt;
  (author)
- Acked-by: Shyam Sundar S K &lt;Shyam-sundar.S-k@amd.com&gt; (original
  driver author)
- Signed-off-by: Andi Shyti &lt;andi.shyti@kernel.org&gt; (I2C
  maintainer)
- Link: https://lore.kernel.org/r/20260612101815.4124804-1-
  paritosh.potukuchi@amd.com
- No Fixes:, Reported-by, Tested-by, Reviewed-by, or Cc: stable (absence
  expected)

**Step 1.3 — Body**
Record: Firmware can return a length larger than the allocated buffer;
that produces **out-of-bounds access and a kernel panic**. The driver
never checked the length read from firmware. The fix is a bounds check
against the data buffer. No stack trace, reproducer, or version range is
given.

**Step 1.4 — Hidden bug fix?**
Record: **No.** This is an explicit OOB/panic fix, not cleanup disguised
as a fix.

---

## Phase 2: Diff analysis

**Step 2.1 — Inventory**
Record: One file, `drivers/i2c/busses/i2c-amd-asf-plat.c`, **+4 / −0**.
Function: `amd_asf_process_target()`. Surgical single-function change.

**Step 2.2 — Code flow**
Before (verified in `v6.18.53`):

```92:94:drivers/i2c/busses/i2c-amd-asf-plat.c
                len = inb_p(ASFDATARWPTR);
                for (idx = 0; idx < len; idx++)
                        data[idx] = inb_p(ASFINDEX);
```

`data` is `u8 data[ASF_BLOCK_MAX_BYTES]` (72). `len` is `u8`, so
firmware can return 0–255. The loop writes past the stack buffer when
`len > 72`. A later loop in the same function also indexes `data[idx]`
with the same `len`.

After: if `len > ASF_BLOCK_MAX_BYTES`, return before the copy.

**Step 2.3 — Bug mechanism**
Record: **(d) Memory safety — buffer overflow / OOB.** Firmware-supplied
I/O length used as loop bound with no clamp. Same pattern already exists
on the host write path (`amd_asf_access()`: `if (len == 0 || len >
ASF_BLOCK_MAX_BYTES)`).

**Step 2.4 — Fix quality**
Record: Minimal and obviously correct for stopping the overflow.
Comparison is `>` against a 72-byte array (index 0..71), so `len == 72`
is valid. Regression risk is low on the success path. On the error path
the early `return` skips bank-status clear and `ASFSETDATARDPTR` reset;
that can leave hardware stuck after a firmware bug, but that path
already panicked. No API, locking, or data-structure change.

---

## Phase 3: Git history

**Step 3.1 — Blame**
Record: Buggy loop introduced in `9b25419ad3971` (“i2c: amd-asf: Add
routine to handle the ASF slave process”, 2024-09-23). First in
**v6.13-rc1**. Present in this 6.18.y tree.

**Step 3.2 — Fixes: tag**
Record: None. Introducer is `9b25419ad3971`, confirmed ancestor of
`v6.18.53`.

**Step 3.3 — File history**
Record: Related commits already in `v6.18.53`:
- `a5089cd23b10c` — initialize `len` (Fixes: 9b25419ad397)
- `b719afaa1e5d8` — set `cmd` on error
No extra prerequisite is required for this bounds check. Standalone.

**Step 3.4 — Author**
Record: First I2C commit from Paritosh Potukuchi. Acked by original AMD
ASF author Shyam Sundar S K. Applied by I2C maintainer Andi Shyti.

**Step 3.5 — Dependencies**
Record: Uses existing `ASF_BLOCK_MAX_BYTES` and the existing loop. `git
diff v6.18.53 d88d3b2633b03^ -- drivers/i2c/busses/i2c-amd-asf-plat.c`
is empty; `git apply --check` against the 6.18.53 file succeeded.
**Applies standalone and cleanly.**

---

## Phase 4: Mailing list / external research

**Step 4.1 — Original discussion**
Record: `b4 dig -c b2f4816a378dc840b605a1235b80e57c5f85b46c` matched
https://patch.msgid.link/20260612093502.3805287-1-
paritosh.potukuchi@amd.com
Thread saved to mbox (lore HTTP 403 via WebFetch/curl).

Revisions:
- v1 (2026-06-12 09:35): same check, broken indentation
- v2 (2026-06-12 10:18): indentation fixed (subject still `[PATCH]`, not
  `[PATCH v2]`)
- Applied version adds a blank line before the `if` (Andi added it on
  apply)

Andi asked how often this happens and whether it should be considered a
fix. Shyam acked without quantifying frequency and without NAK. Andi
merged to `i2c/i2c-for-7.2`. No reviewer asked for `Cc: stable`. No NAK.

**Step 4.2 — Recipients (`b4 dig -w`)**
Record: Author, shyam-sundar.s-k@amd.com, andi.shyti@kernel.org,
linux-i2c, linux-kernel. Right maintainers were on the patch.

**Step 4.3 — Bug report**
Record: No syzbot/bugzilla link. Report is the patch itself from AMD,
describing firmware returning too-large length and a panic.

**Step 4.4 — Series**
Record: Standalone single patch, not part of a multi-patch series.

**Step 4.5 — Stable list**
Record: lore.kernel.org/stable returned 403. Mbox has no “stable”
mention. **UNVERIFIED** whether stable@ discussed it separately.

---

## Phase 5: Code semantic analysis

**Step 5.1 — Functions**
Record: `amd_asf_process_target()` only.

**Step 5.2 — Callers**
Record: Not called directly. Registered as delayed-work callback in
`amd_asf_probe()` via `devm_delayed_work_autocancel(...,
amd_asf_process_target)`. Scheduled from `amd_asf_irq_handler()` when
ASF target IRQ bit 6 is set (`schedule_delayed_work(&dev->work_buf,
HZ)`). Workqueue context, not IRQ context.

**Step 5.3 — Callees**
Record: `inb_p`/`outb_p` (port I/O), then (after this hunk)
`i2c_slave_event()`. No alloc/lock in the changed path.

**Step 5.4 — Reachability**
Record: Reached when AMD ASF slave/target interrupt fires
(`CONFIG_I2C_AMD_ASF`, ACPI `AMDI001A`). Trigger is firmware/BMC ASF
traffic, not a generic unprivileged syscall. Still a host kernel stack
overflow if firmware reports `len > 72`.

**Step 5.5 — Similar patterns**
Record: Host path already bounds-checks in `amd_asf_access()` (`len == 0
|| len > ASF_BLOCK_MAX_BYTES`) and `amd_asf_xfer()` (`msgs->len >
ASF_BLOCK_MAX_BYTES - 3`). Slave/target path was the missing check.

---

## Phase 6: Local tree (`v6.18.53` / 6.18.y)

**Step 6.1 — Does the buggy code exist?**
Record: **Yes.** `git merge-base --is-ancestor d88d3b2633b03 v6.18.53`
failed (fix not in 6.18.53). `git show
v6.18.53:drivers/i2c/busses/i2c-amd-asf-plat.c` has the unbounded loop.
Driver added in v6.13; bug since then.

**Step 6.2 — Backport difficulty**
Record: **Clean apply.** Parent of the candidate matches 6.18.53 file
content; `git apply --check` succeeded.

**Step 6.3 — Related fixes already here?**
Record: Uninit-`len` and error-`cmd` fixes are in 6.18.53. **No existing
bounds check** on this firmware length.

---

## Phase 7: Subsystem context

**Step 7.1**
Record: **drivers/i2c** (AMD ASF bus driver). Criticality:
**PERIPHERAL** (AMD ASF/DASH, depends on `I2C_PIIX4`), but a host panic
still matters for those systems.

**Step 7.2**
Record: Small, mature-enough driver (landed v6.13, a few follow-up fixes
through 6.15). Not staging.

---

## Phase 8: Impact and risk

**Step 8.1 — Who is affected**
Record: **Driver-specific / config-specific:** `CONFIG_I2C_AMD_ASF` on
AMD systems with ASF (`AMDI001A`).

**Step 8.2 — Trigger**
Record: ASF target interrupt + firmware length &gt; 72. Frequency not
quantified on-list (Andi asked; Shyam only acked). Not a normal syscall
path; firmware/BMC-driven. Unprivileged userspace generally cannot set
that I/O length directly.

**Step 8.3 — Failure mode**
Record: Stack buffer overflow (up to 183 bytes past a 72-byte stack
array), then OOB read in the second loop. Commit states **kernel
panic**. Severity: **CRITICAL** (crash; stack smash).

**Step 8.4 — Risk vs benefit**
Record: Benefit **high** for ASF users (panic/OOB). Risk **very low** (4
lines, success path unchanged, same check already used on the write
path). Early-return skips HW cleanup only on the already-broken firmware
path.

---

## Phase 9: Synthesis

**For backporting**
- Real stack OOB from unvalidated firmware length → panic
- Tiny, obviously correct, matches existing driver checks
- Driver and buggy loop are in this 6.18.53 tree (since v6.13)
- Applies cleanly; no missing helpers
- Acked by original driver author; applied by I2C maintainer

**Against**
- AMD-only driver, not a core path
- Frequency of bad firmware length never quantified
- Early return does not reset ASF bank/pointer (error-path
  incompleteness, not a happy-path regression)
- No Fixes:/Cc: stable (not a negative per rules)

**Unresolved**
- Stable mailing list search (lore 403)
- Exact field reproduction rate (unverified beyond AMD’s “may
  sometimes”)

**Stable rules**
1. Obviously correct and tested? **PASS** — 4-line bound check;
   maintainer applied after ack
2. Real bug affecting users? **PASS** — OOB/panic on ASF target RX
3. Important (crash/security/corruption/deadlock)? **PASS** — stack
   overflow → panic
4. Small and contained? **PASS** — +4 lines, one function
5. No new features/APIs? **PASS**
6. Can apply to this tree? **PASS** — clean against 6.18.53

Exception category: none needed; this is a normal crash/OOB fix.

This 6.18.y tree has the unbounded copy and not the fix. Backporting
prevents a kernel panic on AMD ASF hardware when firmware reports a
length above 72.

---

## What the commit solves, and why it matters here

`amd_asf_process_target()` copies firmware bytes into a 72-byte stack
buffer using a length read from `ASFDATARWPTR` with no cap. `len` is
`u8`, so a value 73–255 overruns the stack and can panic. This 6.18.53
tree still has that loop. The patch adds the same bound already used on
the write path. Cost is four lines; the normal path is unchanged.

---

## Verification

- **[Phase 1]** Parsed message/tags from `git show d88d3b2633b03`; no
  Fixes/Reported-by/Cc: stable; Acked-by Shyam; SOB Andi Shyti
- **[Phase 2]** Diff is +4 in `amd_asf_process_target`;
  `data[ASF_BLOCK_MAX_BYTES]` (72); `len` is `u8`; write path already
  checks `len > ASF_BLOCK_MAX_BYTES` at line 176
- **[Phase 3]** `git blame` on v6.18.53: loop from `9b25419ad3971`; `git
  describe --contains` → v6.13-rc1; `git merge-base --is-ancestor
  9b25419ad3971 v6.18.53` true
- **[Phase 3]** `git merge-base --is-ancestor d88d3b2633b03 v6.18.53`
  false (fix not in 6.18.53)
- **[Phase 3]** `a5089cd23b10c` and `b719afaa1e5d8` are ancestors of
  v6.18.53
- **[Phase 3]** `git diff v6.18.53 d88d3b2633b03^ --
  drivers/i2c/busses/i2c-amd-asf-plat.c` empty
- **[Phase 4]** `b4 dig -c b2f4816a378dc840b605a1235b80e57c5f85b46c` /
  `-a` / `-w` / `-m`; thread: v1 indent bug, v2 indent fix, Andi process
  nits + “how often?”, Shyam Ack, merged i2c-for-7.2; no NAK
- **[Phase 4]** lore WebFetch/curl 403; discussion taken from saved mbox
- **[Phase 4]** git.kernel.org commit
  `b2f4816a378dc840b605a1235b80e57c5f85b46c` exists; no Fixes/Cc: stable
  in that commit
- **[Phase 5]** `git grep amd_asf_process_target`: only definition +
  `devm_delayed_work_autocancel`; scheduled from `amd_asf_irq_handler`
- **[Phase 6]** `git describe HEAD` → `v6.18.53-5049-g0f0bdc2b0dffb`;
  `make kernelversion` → 6.18.53; buggy loop present in `v6.18.53:` file
- **[Phase 6]** `git apply --check` of this patch onto the v6.18.53
  file: rc 0
- **[Phase 7]** `CONFIG_I2C_AMD_ASF` in v6.18.53 Kconfig, depends on
  `I2C_PIIX4`, ACPI id `AMDI001A`
- **[Phase 8]** Failure mode: stack OOB → panic (from commit + code);
  trigger is firmware length, not a generic syscall
- **UNVERIFIED:** stable@ list discussion (lore 403); how often firmware
  returns len &gt; 72 (not answered on-list)

**YES**

 drivers/i2c/busses/i2c-amd-asf-plat.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/i2c/busses/i2c-amd-asf-plat.c b/drivers/i2c/busses/i2c-amd-asf-plat.c
index ca45f0f233210..f5b73c8340495 100644
--- a/drivers/i2c/busses/i2c-amd-asf-plat.c
+++ b/drivers/i2c/busses/i2c-amd-asf-plat.c
@@ -90,6 +90,10 @@ static void amd_asf_process_target(struct work_struct *work)
 		outb_p(reg, ASFDATABNKSEL);
 		cmd = inb_p(ASFINDEX);
 		len = inb_p(ASFDATARWPTR);
+
+		if (len > ASF_BLOCK_MAX_BYTES)
+			return;
+
 		for (idx = 0; idx < len; idx++)
 			data[idx] = inb_p(ASFINDEX);
 
-- 
2.53.0