[PATCH AUTOSEL 6.18] ARM: tegra: tf600t: Invert accelerometer calibration matrix

[PATCH AUTOSEL 6.18] ARM: tegra: tf600t: Invert accelerometer calibration matrix

[Sasha Levin]

From: Svyatoslav Ryhel <clamor95@gmail.com>

[ Upstream commit 774bc2764647cfd6b65727cfa978d809f11df392 ]

IMU calibration matrix used in the device tree is inverted when testing on
the device which results in wrong screen orientation. Invert it to match
the matrix dumped from the device.

Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: ARM: tegra: tf600t: Invert accelerometer
calibration matrix

**Local tree:** Linux **6.18.44** (`git describe HEAD` → `v6.18.44`,
Makefile `VERSION=6 PATCHLEVEL=18 SUBLEVEL=44`)

**Commit under review:** `774bc2764647c` (mainline; **not** present in
this 6.18.y checkout)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
**Record:** `[ARM: tegra: tf600t]` `[Invert]` `[accelerometer
calibration matrix in device tree]`

Subsystem: ARM Tegra device tree for ASUS TF600T. Action: correct an
inverted IMU `mount-matrix`.

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
**Record:**
| Tag | Value |
|-----|-------|
| Tested-by | Andreas Westman Dorcsak \<hedmoo@yahoo.com\> |
| Signed-off-by | Svyatoslav Ryhel \<clamor95@gmail.com\> (author) |
| Signed-off-by | Thierry Reding \<treding@nvidia.com\> (Tegra
maintainer) |
| Fixes: | absent (expected) |
| Reported-by: | absent |
| Cc: stable@vger.kernel.org | absent (expected, not a negative signal)
|
| Link: | absent |

Notable: hardware-tested on the actual device; maintainer sign-off from
Thierry Reding.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
**Record:**
- **Bug:** IMU `mount-matrix` in `tegra30-asus-tf600t.dts` is inverted
  relative to values read from the physical device.
- **Symptom:** Wrong screen orientation (auto-rotation does not match
  physical tablet orientation).
- **Root cause:** Incorrect device-tree sensor orientation matrix for
  the MPU6050 IMU node.
- **Version info:** None stated; fix targets board support introduced in
  `8ae70af2477b7`.

### Step 1.4: DETECT HIDDEN BUG FIXES
**Record:** Not disguised as cleanup. This is an explicit device-tree
hardware-description correction. It is a functional bug fix (wrong
sensor axis mapping), not a refactor or style change.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: INVENTORY THE CHANGES
**Record:**
- **File:** `arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts` (+3 / −3
  lines)
- **Node:** `imu@69` (compatible `"invensense,mpu6050"`)
- **Functions:** N/A (device tree only)
- **Scope:** Single-file, surgical, device-specific DT fix

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**Record:**
| Hunk | Before | After |
|------|--------|-------|
| IMU `mount-matrix` | `[[0,-1,0],[-1,0,0],[0,0,-1]]` |
`[[0,1,0],[1,0,0],[0,0,1]]` |

The magnetometer child node (`ak8975`) `mount-matrix` is **unchanged**
(still the old values). Only the MPU6050 accelerometer/gyro orientation
is corrected. The IIO driver reads this matrix at probe via
`iio_read_mount_matrix()` and exposes corrected axis data to
userspace/kernel consumers that drive display rotation.

### Step 2.3: IDENTIFY THE BUG MECHANISM
**Record:**
- **Category:** Hardware description / DT correctness fix (incorrect
  `mount-matrix`)
- **Mechanism:** Inverted axis transformation causes accelerometer
  readings to be mapped to the wrong physical axes; consumers
  interpreting gravity vector for screen rotation get incorrect
  orientation.

### Step 2.4: ASSESS THE FIX QUALITY
**Record:**
- Fix is minimal and obviously correct for the stated hardware
  measurement.
- Zero impact on any other board (property change is inside TF600T DTS
  only).
- Regression risk: **very low** — affects only TF600T IMU node.
- Matrix values are a sign flip on all three diagonal elements,
  consistent with a 180°/axis-inversion correction.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
**Record:**
- Buggy `mount-matrix` introduced in `8ae70af2477b7` by Svyatoslav Ryhel
  (2025-06-17, committed 2025-07-09).
- Subject: "ARM: tegra: Add device-tree for ASUS VivoTab RT TF600T"
- Present in this 6.18.y tree at lines 1043–1045 (verified via `git
  blame` and file read).

### Step 3.2: FOLLOW THE FIXES: TAG
**Record:** No `Fixes:` tag present. N/A.

### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
**Record:**
- **6.18.y history** for this file: only `8ae70af2477b7` (initial TF600T
  DTS).
- **master history** additionally has panel/backlight/connector commits
  not in 6.18.y:
  - `2ecff0cda80b9` Configure panel
  - `d9c890d753034` Drop backlight regulator
  - `774bc2764647c` Invert accelerometer calibration matrix (this
    commit)
- This specific fix is **standalone** (patch 9/9 of a series on lore,
  but functionally independent — only touches IMU matrix).

### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
**Record:** Svyatoslav Ryhel is an active Tegra DTS contributor (TF600T,
SL101, Transformer, etc.). Thierry Reding (maintainer) committed both
the original DTS and this fix.

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
**Record:** No code dependencies. The MPU6050 driver and TF600T DTS
already exist in 6.18.y. Fix applies cleanly (`git apply --check`
passed). **Standalone: yes.**

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
**Record:**
- `b4 dig -c 774bc2764647c` found: [PATCH v1 9/9] ARM: tegra: tf600t:
  Invert accelerometer calibration matrix
- URL:
  https://patch.msgid.link/20260511074859.24930-10-clamor95@gmail.com
- Also matched earlier v1 series from 2026-04-06 (same patch 9/9).
- WebFetch of lore URL blocked by Anubis bot protection — could not read
  thread replies.
- **UNVERIFIED:** Whether reviewers explicitly nominated `Cc: stable` in
  thread replies.

### Step 4.2: CHECK WHO REVIEWED THE PATCH
**Record:** (`b4 dig -w`) CC'd: Rob Herring, Krzysztof Kozlowski, Conor
Dooley (DT maintainers), Thierry Reding, Jonathan Hunter, devicetree@,
linux-tegra@, linux-kernel@. Appropriate subsystem coverage.

### Step 4.3: SEARCH FOR THE BUG REPORT
**Record:** No external bug report links. Testing evidence is `Tested-
by:` on actual TF600T hardware.

### Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
**Record:** Part of a 9-patch TF600T series on lore; other patches
address panel/backlight/connector. This matrix fix does not depend on
them.

### Step 4.5: CHECK STABLE MAILING LIST HISTORY
**Record:** **UNVERIFIED** — did not search lore stable list (no
indication of prior stable discussion found via b4).

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF
**Record:** Device-tree property only. Runtime handling is in IIO
drivers (`iio_read_mount_matrix()` used by ST magnetometer, BMC150,
etc.; MPU6050 uses same binding per
`Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml`).

### Step 5.2: TRACE CALLERS
**Record:** `mount-matrix` is read at IMU driver probe. Accelerometer
data feeds userspace (e.g., `iio-sensor-proxy`, compositors) and kernel
display-rotation logic. Affects normal runtime sensor path on TF600T
when `CONFIG_INV_MPU6050_IIO` (or equivalent) is enabled.

### Step 5.3: TRACE CALLEES
**Record:** IIO core reads DT `mount-matrix` property and applies
transformation to raw sensor readings before exposing channels.

### Step 5.4: FOLLOW THE CALL CHAIN
**Record:** Boot → DT probe of `imu@69` → MPU6050 driver reads `mount-
matrix` → accelerometer channel data transformed → userspace/kernel
reads orientation → display rotation. **Reachable during normal tablet
use** (not an obscure error path).

### Step 5.5: SEARCH FOR SIMILAR PATTERNS
**Record:** Other boards in-tree use `mount-matrix` for orientation
(e.g., PinePhone, various ST sensors). Incorrect matrices are a known
class of DT bugs; magnetometer on the same TF600T node still has the old
matrix (intentionally left unchanged per this commit).

---

## PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE (6.18.y)

### Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?
**Record:** **Yes.** Current 6.18.44 tree has the buggy matrix at lines
1043–1045. `git merge-base --is-ancestor 8ae70af2477b7 HEAD` → TF600T
DTS is in tree. `git merge-base --is-ancestor 774bc2764647c HEAD` →
**fix is NOT in tree.**

### Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
**Record:** **Clean apply expected.** `git apply --check` on formatted
patch succeeded. Line numbers differ slightly from mainline diff (1074
vs 1091) due to fewer upstream commits in stable file, but merge is
trivial.

### Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE
**Record:** No alternate fix for this issue found in 6.18.y history.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
**Record:** **Subsystem:** ARM device tree / Tegra platform / IIO sensor
orientation. **Criticality:** PERIPHERAL — affects only ASUS VivoTab RT
TF600T (Tegra30 tablet, niche but real hardware).

### Step 7.2: ASSESS SUBSYSTEM ACTIVITY
**Record:** TF600T support is new (added 6.17 cycle, present in 6.18.y).
Active development on mainline with follow-up TF600T patches not yet in
stable.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: DETERMINE WHO IS AFFECTED
**Record:** **Platform-specific** — users running Linux on ASUS TF600T
with kernel 6.18.y. No impact on any other hardware.

### Step 8.2: DETERMINE THE TRIGGER CONDITIONS
**Record:** Trigger is **every boot / every sensor read** on TF600T when
display auto-rotation is used. Common for tablet use. Not security-
relevant; unprivileged users cannot trigger kernel crashes via this bug.

### Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
**Record:**
- **Failure mode:** Incorrect screen orientation / auto-rotation.
- **Severity:** **LOW to MEDIUM** — functional/interactivity issue, not
  crash, corruption, deadlock, or security. Annoying and breaks expected
  tablet behavior, but system remains stable.

### Step 8.4: CALCULATE RISK-BENEFIT RATIO
**Record:**
- **Benefit:** Corrects broken auto-rotation for TF600T users on 6.18.y;
  completes board support already shipped in stable.
- **Risk:** Minimal — 3-line DT change scoped to one device node on one
  board.
- **Ratio:** High benefit-to-risk for TF600T users; near-zero risk for
  everyone else.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**FOR backporting:**
- Real, hardware-verified bug (wrong screen orientation)
- Buggy code is present in 6.18.y (board support was merged with
  incorrect matrix)
- Trivial, device-specific DT fix; applies cleanly
- Tegra maintainer signed off; Tested-by on hardware
- Matches stable exception: DT fix for incorrect hardware description
- Per `stable-kernel-rules.rst`: fixes "a real bug that bothers people"
  on supported hardware

**AGAINST backporting:**
- Low severity (orientation wrong, not crash/corruption/security)
- Extremely niche hardware (2012-era Windows RT tablet)
- No syzbot/fuzzer report, no widespread user reports
- Other TF600T improvements remain mainline-only (panel, backlight) —
  stable already ships partial board support

**UNRESOLVED:**
- Whether lore reviewers explicitly requested `Cc: stable` (WebFetch
  blocked)
- Whether any distribution kernel maintainer has reported this to stable

### Step 9.2: APPLY THE STABLE RULES CHECKLIST

| Criterion | Result |
|-----------|--------|
| 1. Obviously correct and tested? | **PASS** — Tested-by on device;
maintainer ack; values match hardware dump |
| 2. Fixes a real bug affecting users? | **PASS** — wrong screen
orientation on TF600T |
| 3. Important issue? | **PASS (borderline)** — interactivity/functional
bug on supported hardware, not crash-level; qualifies as hardware-
description correction per stable DT guidance |
| 4. Small and contained? | **PASS** — 3 lines, 1 file |
| 5. No new features or APIs? | **PASS** — DT property value correction
only |
| 6. Can apply to local tree? | **PASS** — verified clean apply |

### Step 9.3: CHECK FOR EXCEPTION CATEGORIES
**Record:** **Device tree update for existing hardware** — corrects
incorrect `mount-matrix` for a board whose DTS is already in 6.18.y.

### Step 9.4: DECISION RATIONALE

This 6.18.y tree already ships TF600T device-tree support
(`8ae70af2477b7`) with an incorrect accelerometer orientation matrix.
Users of this specific tablet on 6.18.x get broken auto-rotation. The
fix is as low-risk as stable backports get: three lines in a board-
specific DTS, hardware-tested, maintainer-approved, and applies cleanly.
While severity is low compared to crashes or security issues, stable
rules explicitly accept DT hardware-description fixes and "real bugs
that bother people" on supported platforms. Shipping board support
without this correction leaves a known, verified functional defect in
the stable tree.

---

## Verification

- **[Phase 1]** Parsed commit message and tags from `git show
  774bc2764647c`
- **[Phase 2]** Diff analysis: 3 lines changed in `imu@69` `mount-
  matrix`; magnetometer matrix unchanged
- **[Phase 3]** `git blame`: buggy lines from `8ae70af2477b7`
  (2025-07-09)
- **[Phase 3]** `git log stable/linux-6.18.y -- tegra30-asus-
  tf600t.dts`: only intro commit in stable
- **[Phase 3]** `git log master -- tegra30-asus-tf600t.dts`: fix + 3
  other TF600T commits not in stable
- **[Phase 3]** `git merge-base --is-ancestor`: DTS in 6.18.y, fix NOT
  in 6.18.y
- **[Phase 4]** `b4 dig -c 774bc2764647c`: found lore URL
- **[Phase 4]** `b4 dig -w`: DT and Tegra maintainers CC'd
- **[Phase 4]** `b4 dig -a`: v1 series, patch 9/9
- **[Phase 4]** WebFetch lore URL: blocked (Anubis) — stable nomination
  in thread UNVERIFIED
- **[Phase 5]** Read current DTS at lines 1043–1064; confirmed buggy IMU
  matrix present
- **[Phase 5]** Grep: `mount-matrix` binding documented in
  `invensense,mpu6050.yaml`
- **[Phase 6]** `git describe HEAD`: v6.18.44
- **[Phase 6]** `git apply --check` on formatted patch: clean apply
- **[Phase 6]** Read file: confirmed buggy code exists at lines
  1043–1045
- **[Phase 7]** Read `Documentation/process/stable-kernel-rules.rst`:
  DT/hardware-description fixes qualify
- **[Phase 8]** Assessed severity: functional orientation bug, LOW-
  MEDIUM, platform-specific

**YES**

 arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts b/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
index 5d9e23a438204..856b1bb8b6f37 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
+++ b/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
@@ -1040,9 +1040,9 @@ imu@69 {
 			vdd-supply   = <&vdd_3v3_sys>;
 			vddio-supply = <&vdd_1v8_vio>;
 
-			mount-matrix =	 "0", "-1",  "0",
-					"-1",  "0",  "0",
-					 "0",  "0", "-1";
+			mount-matrix =	 "0",  "1",  "0",
+					 "1",  "0",  "0",
+					 "0",  "0",  "1";
 
 			/* External I2C interface */
 			i2c-gate {
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.12] soc/tegra: fuse: Register nvmem lookups at probe

[Sasha Levin]

From: Kartik Rajput <kkartik@nvidia.com>

[ Upstream commit 8a3571618c2e3f339b5b6fee5841143face58a2b ]

Register nvmem lookups in tegra_fuse_probe(), after the nvmem device has
been registered, since they can only be used after the nvmem device is
registered.

Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The background check on `stable/linux-6.18.y` finished and matches the
earlier analysis:

- **Prerequisites present:** `71661c1c8c34d` (lookup helper),
  `972167c690801` (ACPI fuse support), `4a4193d9c6dde` (ACPI SoC
  cleanup)
- **Fix not present:** no “Register nvmem lookups at probe” commit in
  6.18.y

**Verdict for this tree (v6.18.44): YES** — small init-order fix for
ACPI Tegra fuse lookups; applies cleanly and corrects code already in
6.18.y.

 drivers/soc/tegra/fuse/fuse-tegra.c | 14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/soc/tegra/fuse/fuse-tegra.c b/drivers/soc/tegra/fuse/fuse-tegra.c
index 74d2fedea71ca..972a63993e1db 100644
--- a/drivers/soc/tegra/fuse/fuse-tegra.c
+++ b/drivers/soc/tegra/fuse/fuse-tegra.c
@@ -182,10 +182,6 @@ static int tegra_fuse_probe(struct platform_device *pdev)
 		}
 
 		fuse->soc->init(fuse);
-
-		err = tegra_fuse_add_lookups(fuse);
-		if (err)
-			return dev_err_probe(&pdev->dev, err, "failed to add FUSE lookups\n");
 	}
 
 	fuse->clk = devm_clk_get_optional(&pdev->dev, "fuse");
@@ -231,6 +227,10 @@ static int tegra_fuse_probe(struct platform_device *pdev)
 		return err;
 	}
 
+	err = tegra_fuse_add_lookups(fuse);
+	if (err)
+		return dev_err_probe(&pdev->dev, err, "failed to add FUSE lookups\n");
+
 	fuse->rst = devm_reset_control_get_optional(&pdev->dev, "fuse");
 	if (IS_ERR(fuse->rst))
 		return dev_err_probe(&pdev->dev, PTR_ERR(fuse->rst), "failed to get FUSE reset\n");
@@ -473,7 +473,7 @@ static int __init tegra_init_fuse(void)
 	const struct of_device_id *match;
 	struct device_node *np;
 	struct resource regs;
-	int err;
+	int err = 0;
 
 	tegra_init_apbmisc();
 
@@ -566,10 +566,6 @@ static int __init tegra_init_fuse(void)
 
 	tegra_fuse_print_sku_info(&tegra_sku_info);
 
-	err = tegra_fuse_add_lookups(fuse);
-	if (err)
-		pr_err("failed to add FUSE lookups\n");
-
 	return err;
 }
 early_initcall(tegra_init_fuse);
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] thermal/drivers/tegra/soctherma: Switch to devm cooling device registration

[Sasha Levin]

From: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>

[ Upstream commit ee126267bc04bfb03816ae9d71ca24c5bf99e739 ]

Use devm_thermal_of_cooling_device_register() to simplify resource
management and avoid manual cleanup in error paths.

As a side effect this change has the benefit of solving an existing
issue. Before, the function tegra_soctherm_remove() only called
debugfs_remove_recursive() and never called thermal_cooling_device_unregister()
for any of the cooling devices registered here.

After the driver removal, the thermal framework's cdev list would
still hold references to thermal_cooling_device objects whose devdata
pointer (ts) pointed to memory already freed by the platform device's
devm cleanup.

With this change, the cooling device is unregistered when the driver
is removed, thus fixing the issue above.

Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Link: https://patch.msgid.link/20260424160019.41710-2-daniel.lezcano@oss.qualcomm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: tegra/soctherm devm cooling device
registration

**Local tree:** `v6.18.44` (Linux 6.18.44)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject line
**Record:** `[thermal/drivers/tegra/soctherma]` `[Switch]` — move
throttle cooling-device registration to the devm thermal API.

### Step 1.2: Tags
**Record:**
- **Signed-off-by:** Daniel Lezcano `<daniel.lezcano@oss.qualcomm.com>`,
  Daniel Lezcano `<daniel.lezcano@kernel.org>`
- **Reviewed-by:** Lukasz Luba `<lukasz.luba@arm.com>`
- **Link:** https://patch.msgid.link/20260424160019.41710-2-
  daniel.lezcano@oss.qualcomm.com
- **Absent (expected):** Fixes:, Reported-by:, Tested-by:, Cc:
  stable@vger.kernel.org
- **Notable:** Part of a 2-patch series; no syzbot/fuzzer report.

### Step 1.3: Body analysis
**Record:**
- **Bug:** `tegra_soctherm_remove()` never calls
  `thermal_cooling_device_unregister()` for throttle cooling devices
  registered in `soctherm_init_hw_throt_cdev()`.
- **Symptom:** After driver removal, the thermal core still holds
  `thermal_cooling_device` entries whose `devdata` points at `struct
  tegra_soctherm *ts`, but `ts` is freed by devm when the platform
  device is torn down → use-after-free.
- **Root cause:** Non-devm `thermal_of_cooling_device_register()` with
  no matching unregister in `.remove`.
- **Fix approach:** `devm_thermal_of_cooling_device_register(dev, ...)`
  so unregister happens automatically on device release.

### Step 1.4: Hidden bug fix?
**Record:** Yes. The commit is framed as resource-management cleanup,
but it explicitly fixes a real UAF on driver removal.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
**Record:**
- **Files:** `drivers/thermal/tegra/soctherm.c` only (+3 / −3 lines)
- **Function modified:** `soctherm_init_hw_throt_cdev()`
- **Scope:** Single-file, surgical change

### Step 2.2: Code flow change
**Record:**
- **Before:** `thermal_of_cooling_device_register(np_stcc, name, ts,
  &throt_cooling_ops)` — lifetime not tied to `pdev->dev`; survives past
  `.remove`.
- **After:** `devm_thermal_of_cooling_device_register(dev, np_stcc,
  name, ts, &throt_cooling_ops)` — cooling device unregistered when
  `dev` is released.
- **Path affected:** Probe-time throttle cooling-device registration;
  cleanup on driver remove/unbind.

### Step 2.3: Bug mechanism
**Record:** **Category:** Use-after-free / missing resource cleanup on
driver removal.

Mechanism verified in tree:
1. `tegra` is allocated with `devm_kzalloc(&pdev->dev, ...)` (line
   2101).
2. Cooling devices store `ts` as `devdata` (line 1704).
3. `throt_get_cdev_cur_state()` dereferences `cdev->devdata` as `ts` and
   reads `ts->regs` (lines 1512–1515).
4. `tegra_soctherm_remove()` only removes debugfs and disables clocks —
   no cooling-device unregister (lines 2228–2235).
5. After remove, thermal framework callbacks can touch freed `ts`
   memory.

### Step 2.4: Fix quality
**Record:** Obviously correct; matches the pattern already used in the
same probe path for thermal zones (`devm_thermal_of_zone_register` at
line 2197). Minimal regression risk; no new APIs.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
**Record:** `git blame` on the registration lines attributes them to
`7e22de67e545d` (“drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON()”),
which is clearly unrelated — this tree’s git history for `soctherm.c`
appears squashed/corrupted. **Cannot reliably determine the introducing
commit or kernel version from history in this checkout.**

### Step 3.2: Fixes: tag
**Record:** N/A — no Fixes: tag in the commit message.

### Step 3.3: Related file history
**Record:** `git log --oneline -- drivers/thermal/tegra/soctherm.c`
returns only the unrelated amdgpu commit. History is not usable here.
The buggy pattern is present in the current file content.

### Step 3.4: Author context
**Record:** Daniel Lezcano is a thermal maintainer. No other tegra
thermal commits visible in this tree’s truncated history.

### Step 3.5: Dependencies
**Record:** Patch is **2/2** in a series with patch 1/2 (clock disable
via `devm_add_action_or_reset`). **Patch 2/2 is standalone** — it only
changes the cooling-device registration call and does not depend on
patch 1. `devm_thermal_of_cooling_device_register()` already exists in
this tree’s `thermal_core.c` (lines 1217–1240).

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Original discussion
**Record:**
- **URL:** https://patch.msgid.link/20260424160019.41710-2-
  daniel.lezcano@oss.qualcomm.com
- **Series:** 2 patches (clock devm cleanup + this cooling-device devm
  fix)
- **b4:** Reports patch applies clean to current tree
- **Review:** `Reviewed-by: Lukasz Luba` on patch 1/2; no separate
  replies found for patch 2/2 in thread grep
- **Stable nomination:** None found in thread or stable@ search

### Step 4.2: Reviewers
**Record:** CC’d: Rafael Wysocki, Daniel Lezcano, Thierry Reding,
Jonathan Hunter; lists: linux-pm, linux-tegra.

### Step 4.3: Bug report
**Record:** No external bug report, syzbot, or crash log — bug
identified by code inspection during cleanup.

### Step 4.4: Series context
**Record:** Patch 1/2 is independent (clock error-path cleanup). Not
required for this fix to work.

### Step 4.5: Stable list
**Record:** No prior stable@ discussion found for this issue.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key functions
**Record:** `soctherm_init_hw_throt_cdev()`,
`throt_get_cdev_cur_state()`, `tegra_soctherm_remove()`,
`tegra_soctherm_probe()`.

### Step 5.2: Callers
**Record:**
- `soctherm_init_hw_throt_cdev()` called from `tegra_soctherm_probe()`
  (line 2180)
- Driver registered via `module_platform_driver(tegra_soctherm_driver)`
  (line 2288) — `.remove` runs on unbind/module unload
- Thermal zone trip handling also references `ts->throt_cfgs[i].cdev`
  (lines 617–628)

### Step 5.3: Callees
**Record:** Registration goes through
`devm_thermal_of_cooling_device_register()` →
`__thermal_cooling_device_register()` with devm release via
`thermal_cooling_device_release()`.

### Step 5.4: Reachability
**Record:**
- Requires `CONFIG_TEGRA_SOCTHERM` (tristate, `ARCH_TEGRA ||
  COMPILE_TEST`)
- Requires DT `throttle-cfgs` child nodes with non-OC throttle entries
  (`stc->id < THROTTLE_OC1`)
- Trigger: platform driver remove/unbind after successful probe with
  throttle cooling devices registered
- Post-remove thermal activity (zone polling, trip handling, sysfs) can
  invoke cooling-device ops → UAF

### Step 5.5: Similar patterns
**Record:** Same file already uses devm for zones
(`devm_thermal_of_zone_register`), `tegra` struct, clocks, and other
probe allocations. Cooling-device registration was the outlier.

---

## PHASE 6: CROSS-REFERENCE AGAINST LOCAL TREE (v6.18.44)

### Step 6.1: Buggy code present?
**Record:** **Yes.** Lines 1703–1705 still use
`thermal_of_cooling_device_register()`; `tegra_soctherm_remove()` has no
unregister. The fix is not yet in this tree.

### Step 6.2: Backport complications
**Record:** **Clean apply.** Verified with `git apply --check` — 3
insertions, 3 deletions, no conflicts.
`devm_thermal_of_cooling_device_register()` is declared in
`include/linux/thermal.h` and implemented in
`drivers/thermal/thermal_core.c`.

### Step 6.3: Related fixes already present?
**Record:** No. `grep thermal_cooling_device_unregister
drivers/thermal/tegra/` returns nothing. Bug remains unfixed.

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem and criticality
**Record:** `drivers/thermal/tegra/` — Tegra platform thermal driver.
**PERIPHERAL** (Tegra/embedded only), but thermally safety-relevant on
affected hardware.

### Step 7.2: Activity
**Record:** File history unavailable in this checkout; driver is mature
and actively maintained upstream (April 2026 patch series).

---

## PHASE 8: IMPACT AND RISK

### Step 8.1: Who is affected
**Record:** Systems with `CONFIG_TEGRA_SOCTHERM` built-in or as a
module, DT `throttle-cfgs` present, and throttle cooling devices
registered (LIGHT/HEAVY, not OC-only configs).

### Step 8.2: Trigger conditions
**Record:** Driver removal/unbind/module unload — not every boot, but a
real kernel code path. Any subsequent thermal-framework access to the
stale cooling device can trigger the bug.

### Step 8.3: Failure mode severity
**Record:** **Use-after-free** via `ts->regs` in
`throt_get_cdev_cur_state()` → kernel oops/panic, unpredictable
behavior. **Severity: HIGH.**

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** HIGH for affected Tegra systems — prevents UAF on
  teardown
- **Risk:** VERY LOW — 3-line change, established devm API, no
  structural changes
- **Ratio:** Strongly favors backport

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence summary

**FOR backport:**
- Real UAF on driver removal, clearly described and verified in code
- Dangling `devdata` (`ts`) dereferenced in `throt_get_cdev_cur_state()`
- Small, surgical, obviously correct devm fix
- `devm_thermal_of_cooling_device_register()` exists in v6.18.44
- Patch applies cleanly
- Reviewed in series by Arm thermal reviewer; thermal maintainer
  authored

**AGAINST backport:**
- Tegra-specific, not universal
- Driver removal is less common than steady-state operation (often
  built-in)
- No fuzzer report or user crash log
- Git history in this checkout cannot confirm how long the bug has
  existed

**Unresolved:** Exact commit that introduced the bug (history unusable
in this tree).

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** — standard devm pattern;
   series reviewed
2. Fixes a real user-affecting bug? **PASS** — UAF on driver teardown
3. Important issue? **PASS** — UAF / potential crash
4. Small and contained? **PASS** — 3 lines, one function
5. No new features/APIs? **PASS** — uses existing devm API
6. Can apply to local tree? **PASS** — verified clean apply; API present

### Step 9.3: Exception categories
**Record:** None (not a quirk/DT-ID/docs fix) — standard bug fix.

### Step 9.4: Decision rationale
For **Linux 6.18.44**, the buggy non-devm cooling-device registration
exists, `tegra_soctherm_remove()` does not unregister those devices, and
thermal callbacks dereference the freed `ts` pointer. The fix is
minimal, self-contained, uses infrastructure already in this tree, and
applies cleanly. This meets stable criteria for a real, important UAF
fix.

---

## Verification

- **[Phase 1]** Parsed subject, tags, and body from provided commit
  message
- **[Phase 1]** Confirmed no Fixes:/Reported-by:/Cc: stable tags
- **[Phase 2]** Read `soctherm.c` lines 1502–1534, 1655–1719, 2101,
  2180, 2228–2235
- **[Phase 2]** Confirmed `throt_get_cdev_cur_state()` dereferences
  `cdev->devdata` as `ts`
- **[Phase 2]** Confirmed `tegra_soctherm_remove()` has no
  `thermal_cooling_device_unregister()`
- **[Phase 3]** `git describe HEAD` → `v6.18.44`
- **[Phase 3]** `git blame -L 1700,1710` → history unreliable (unrelated
  amdgpu commit)
- **[Phase 3]** `git log --oneline -- drivers/thermal/tegra/soctherm.c`
  → single unrelated commit
- **[Phase 3]** Verified `devm_thermal_of_cooling_device_register` in
  `thermal_core.c:1217-1240` and `thermal.h:259`
- **[Phase 4]** `b4 am 20260424160019.41710-2-...` → 2-patch series,
  applies clean
- **[Phase 4]** curl lore mbox → patch 2/2 content and series metadata;
  Reviewed-by on patch 1/2 only
- **[Phase 4]** curl stable@ search → no prior discussion found
- **[Phase 5]** Traced call chain: `probe` →
  `soctherm_init_hw_throt_cdev` → thermal callbacks on stale cdev
- **[Phase 5]** `grep thermal_cooling_device_unregister
  drivers/thermal/tegra/` → no matches
- **[Phase 6]** Confirmed buggy `thermal_of_cooling_device_register()`
  at lines 1703–1705
- **[Phase 6]** `git apply --check` on provided diff → clean apply
  (3+/3-)
- **[Phase 6]** Read `Kconfig` → `CONFIG_TEGRA_SOCTHERM` tristate,
  `ARCH_TEGRA || COMPILE_TEST`
- **[Phase 8]** Failure mode: UAF via `ts->regs` → severity HIGH
- **UNVERIFIED:** Exact kernel version/commit that introduced the non-
  devm registration (git history in this checkout is not trustworthy)

**YES**

 drivers/thermal/tegra/soctherm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/tegra/soctherm.c b/drivers/thermal/tegra/soctherm.c
index 5d26b52beaba7..9d3eb3be2db02 100644
--- a/drivers/thermal/tegra/soctherm.c
+++ b/drivers/thermal/tegra/soctherm.c
@@ -1700,9 +1700,9 @@ static void soctherm_init_hw_throt_cdev(struct platform_device *pdev)
 			stc->init = true;
 		} else {
 
-			tcd = thermal_of_cooling_device_register(np_stcc,
-							 (char *)name, ts,
-							 &throt_cooling_ops);
+			tcd = devm_thermal_of_cooling_device_register(dev, np_stcc,
+								      (char *)name, ts,
+								      &throt_cooling_ops);
 			if (IS_ERR_OR_NULL(tcd)) {
 				dev_err(dev,
 					"throttle-cfg: %s: failed to register cooling device\n",
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.15] host1x: bus: Fix missing ops null check in error teardown

[Sasha Levin]

From: shayderrr <darknessshayder@gmail.com>

[ Upstream commit 71d25f668bc5c0f36ea843462e12307dea45aaa3 ]

In host1x_device_init(), the error teardown paths do not check
client->ops before dereferencing it, unlike the forward init paths
which correctly guard with 'client->ops &&'. This can result in a
NULL pointer dereference if client->ops is NULL.

Fix by adding the missing client->ops check in both the teardown
and teardown_late labels.

Signed-off-by: shayderrr <darknessshayder@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260517170456.84927-1-darknessshayder@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: Subject Line
**Record:** `[host1x: bus]` `[Fix]` — Add missing `client->ops` NULL
checks in `host1x_device_init()` error teardown paths.

### Step 1.2: Tags
**Record:**
- **Signed-off-by:** shayderrr \<darknessshayder@gmail.com\> (author)
- **Signed-off-by:** Thierry Reding \<treding@nvidia.com\> (host1x/Tegra
  maintainer)
- **Link:** https://patch.msgid.link/20260517170456.84927-1-
  darknessshayder@gmail.com
- No Fixes:, Reported-by:, Tested-by:, Reviewed-by:, Acked-by:, or Cc:
  stable tags
- Notable: maintainer sign-off is a strong quality signal; no
  syzbot/user bug report

### Step 1.3: Body Analysis
**Record:**
- **Bug:** `host1x_device_init()` teardown (`teardown`, `teardown_late`)
  dereferences `client->ops` without a NULL guard; forward init paths
  already use `client->ops &&`.
- **Symptom:** NULL pointer dereference during error recovery when
  initialization fails.
- **Root cause:** Oversight when teardown was added (2017) and when
  `teardown_late` was added (2021); `host1x_device_exit()` and other
  paths in the same file already guard correctly.

### Step 1.4: Hidden Bug Fix?
**Record:** No — this is an explicit NULL-deref fix on an error path,
not disguised cleanup.

---

## Phase 2: Diff Analysis

### Step 2.1: Inventory
**Record:**
- **File:** `drivers/gpu/host1x/bus.c` (+2 / -2 lines)
- **Function:** `host1x_device_init()`
- **Scope:** Single-file, surgical (2-line change)

### Step 2.2: Code Flow Change
**Record:**
- **Hunk 1 (`teardown`):** `if (client->ops->exit)` → `if (client->ops
  && client->ops->exit)`
- **Hunk 2 (`teardown_late`):** `if (client->ops->late_exit)` → `if
  (client->ops && client->ops->late_exit)`
- **Before:** Error teardown could dereference NULL `client->ops`.
- **After:** Clients without `ops` are skipped, matching forward init
  and `host1x_device_exit()`.

### Step 2.3: Bug Mechanism
**Record:** **Category:** NULL pointer dereference (memory safety).
**Mechanism:** On `early_init`/`init` failure, reverse iteration calls
`client->ops->exit` / `client->ops->late_exit` even when `client->ops`
is NULL — a client skipped in the forward path can still be visited in
teardown.

### Step 2.4: Fix Quality
**Record:** Obviously correct; mirrors existing patterns at lines
196–207, 257–271, and 815–836 in the same file. Minimal regression risk.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame
**Record:**
- `teardown` without NULL check: introduced in `8f7da1578e90b` (Thierry
  Reding, 2017-11-08) — "gpu: host1x: Cleanup on initialization failure"
- `teardown_late` without NULL check: introduced in `933deb8c7b8e3f`
  (Thierry Reding, 2021-03-26) — "gpu: host1x: Add early init and late
  exit callbacks"
- Forward paths have had `client->ops &&` since original
  `host1x_device_init()` (2013)

### Step 3.2: Fixes: Tag
**Record:** N/A — no Fixes: tag.

### Step 3.3: Related File History
**Record:** Recent host1x stable-style fixes in this tree include UAF
(`5f4de3c717d34`), reference leak (`c4d6442ac3ed0`), and syncpt race
(`79197c6007f2a`). Standalone fix; not part of a series.

### Step 3.4: Author Context
**Record:** shayderrr is a contributor; Thierry Reding (maintainer)
signed off. Author is not the subsystem maintainer but patch was
accepted by one.

### Step 3.5: Dependencies
**Record:** No prerequisites. Applies to code present since 2017/2021.
Self-contained.

---

## Phase 4: Mailing List and External Research

### Step 4.1–4.5
**Record:**
- `b4 dig` by commit hash and subject: no match (commit not in this
  checkout)
- Lore/patch.msgid.link: blocked by Anubis bot protection — could not
  read thread
- **UNVERIFIED:** Reviewer feedback, stable nominations, series
  revisions

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Functions
**Record:** `host1x_device_init()` — only function modified.

### Step 5.2: Callers
**Record:** `host1x_device_init()` is called from:
- `drivers/gpu/drm/tegra/drm.c` (Tegra DRM probe)
- `drivers/crypto/tegra/tegra-se-main.c` (Tegra SE)
- `drivers/staging/media/tegra-video/video.c` (staging Tegra video)

All are device-probe initialization paths on Tegra (or COMPILE_TEST).

### Step 5.3: Callees
**Record:** `client->ops->exit`, `client->ops->late_exit`,
`mutex_lock/unlock`, list iteration macros.

### Step 5.4: Reachability
**Record:**
1. Tegra clients register via `host1x_client_register()` /
   `__host1x_client_register()`.
2. `host1x_device_init()` runs when the composite host1x device driver
   probes.
3. If any client's `init`/`early_init` fails, teardown runs.
4. Forward path skips clients with `client->ops == NULL`; teardown does
   not — inconsistent and unsafe.
5. In-tree drivers set `ops` before register, but the API explicitly
   allows NULL `ops` (forward guards prove intent). A client with NULL
   `ops` on `device->clients` plus a later init failure triggers the
   bug.

**Userspace trigger:** Indirect — probe failure during boot/driver load
on Tegra systems with `CONFIG_TEGRA_HOST1X` and dependent drivers.

### Step 5.5: Similar Patterns
**Record:** Same `client->ops &&` pattern used in
`host1x_device_exit()`, `host1x_client_suspend()`, and
`host1x_client_resume()` in the same file. Teardown paths are the
outlier.

---

## Phase 6: Cross-Reference Against Local Tree

### Step 6.1: Buggy Code Present?
**Record:** **Yes.** Local tree is **v6.18.44** (Makefile: 6.18.44).
Buggy code at lines 224 and 232 in `drivers/gpu/host1x/bus.c` — fix not
yet applied.

### Step 6.2: Backport Complications
**Record:** **Clean apply expected** — two identical one-line changes.
No conflicting recent churn in this function.

### Step 6.3: Related Fixes Already Present?
**Record:** No existing fix for this issue in this tree.

---

## Phase 7: Subsystem and Maintainer Context

### Step 7.1: Subsystem
**Record:** `drivers/gpu/host1x/` — Tegra display/multimedia bus
infrastructure. **Criticality:** IMPORTANT for Tegra/embedded;
PERIPHERAL globally (requires `CONFIG_TEGRA_HOST1X`, `ARCH_TEGRA` or
`COMPILE_TEST`).

### Step 7.2: Activity
**Record:** Actively maintained; multiple bugfix commits in recent
history on this subsystem.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who Is Affected
**Record:** Tegra platform users with host1x clients (DRM, crypto,
staging video). Not universal x86/ARM server impact.

### Step 8.2: Trigger Conditions
**Record:**
- `host1x_device_init()` called during probe
- A client `init`/`early_init` fails
- Teardown visits a client with `client->ops == NULL` (skipped during
  forward init)
- **Likelihood:** Low-to-medium on error paths; requires init failure
  plus NULL-ops client on the list

### Step 8.3: Failure Mode Severity
**Record:** Kernel oops (NULL dereference) during error recovery instead
of clean `-errno` return. **Severity: HIGH** for affected path (turns
recoverable probe failure into crash).

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** Prevents crash on init-failure teardown; makes error
  recovery robust
- **Risk:** Very low — 2-line change matching established pattern
- **Ratio:** Favorable for Tegra stable users

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence Summary

**FOR backport:**
- Real NULL-deref bug on error path
- Trivial, obviously correct 2-line fix
- Matches existing code in same function/file
- Maintainer (Thierry Reding) signed off
- Bug present since 2017/2021; affects this v6.18.44 tree
- Error-path crash is worse than the original init failure

**AGAINST backport:**
- Platform-specific (Tegra only)
- Requires init failure (uncommon)
- No user/syzbot report documented
- In-tree drivers appear to always set `ops` before register (trigger
  may be rare in practice)

**UNRESOLVED:**
- Mailing list review thread (Anubis blocked)
- No confirmed in-tree reproduction with current drivers

The unresolved items do not outweigh the clear correctness fix: forward
paths already treat NULL `ops` as valid; teardown must match.

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — mirrors existing guards;
   maintainer SOB; no logic change beyond NULL safety
2. Fixes a real bug? **PASS** — NULL deref on error teardown
3. Important issue? **PASS** — kernel oops on probe error recovery (HIGH
   for affected users)
4. Small and contained? **PASS** — 2 lines, 1 file
5. No new features/APIs? **PASS**
6. Can apply to local tree? **PASS** — buggy code confirmed in v6.18.44

### Step 9.3: Exception Categories
**Record:** None (standard bug fix).

### Step 9.4: Decision Rationale
This is a conservative, surgical fix for an inconsistent NULL check that
can kernel-oops during `host1x_device_init()` error recovery on Tegra
systems. The fix aligns teardown with forward init and
`host1x_device_exit()`, carries negligible regression risk, and the
buggy code is present in this v6.18.44 tree.

---

## Verification

- **[Phase 1]** Parsed commit message and tags from user query
- **[Phase 2]** Confirmed diff: 2 lines in `host1x_device_init()`
  teardown paths
- **[Phase 3]** `git describe HEAD`: v6.18.44; Makefile confirms 6.18.44
- **[Phase 3]** `git blame -L 222,236`: teardown from 2017
  (`8f7da1578e90b`), teardown_late from 2021 (`933deb8c7b8e3f`)
- **[Phase 3]** `git show 8f7da1578e90bf`: original teardown added
  without NULL check while forward path had one
- **[Phase 3]** `git log -p -S 'if (client->ops->exit)'`: confirmed 2017
  introduction of unguarded teardown
- **[Phase 3]** `git log --oneline -15 -- drivers/gpu/host1x/bus.c`:
  recent related fixes; no duplicate fix
- **[Phase 4]** `b4 dig`: no results (commit not in tree)
- **[Phase 4]** WebFetch lore/patch.msgid.link: blocked by Anubis —
  **UNVERIFIED** review discussion
- **[Phase 5]** `grep host1x_device_init`: callers in tegra drm, tegra-
  se, tegra-video
- **[Phase 5]** Read `host1x_device_init()`, `host1x_device_exit()`,
  suspend/resume: confirmed `client->ops &&` pattern elsewhere
- **[Phase 5]** Read tegra driver probes (dc.c, gr3d.c, sor.c, tegra-
  se): ops set before register
- **[Phase 6]** Read current `bus.c` lines 224, 232: buggy code present
  (no NULL check)
- **[Phase 6]** Kconfig: `CONFIG_TEGRA_HOST1X` depends on `ARCH_TEGRA ||
  COMPILE_TEST`
- **[Phase 8]** Failure mode: NULL deref → oops on init-failure teardown

**YES**The backport analysis is done.

**Commit:** `host1x: bus: Fix missing ops null check in error teardown`
**Tree:** v6.18.44 — the bug is still present (unguarded `client->ops`
derefs at lines 224 and 232 in `drivers/gpu/host1x/bus.c`).

**Summary:** On Tegra, if `host1x_device_init()` fails partway through,
the teardown paths can NULL-deref `client->ops` while forward init and
`host1x_device_exit()` already guard against that. The fix is two lines,
matches existing patterns, and is signed off by host1x maintainer
Thierry Reding.

**Verdict: YES** — backport to this tree.

A background `git log --grep` search timed out; it wasn’t needed for the
decision since the buggy code and history were already confirmed
directly.

 drivers/gpu/host1x/bus.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index 3313ead8bfcc2..06aa7fcd367e1 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -221,7 +221,7 @@ int host1x_device_init(struct host1x_device *device)
 
 teardown:
 	list_for_each_entry_continue_reverse(client, &device->clients, list)
-		if (client->ops->exit)
+		if (client->ops && client->ops->exit)
 			client->ops->exit(client);
 
 	/* reset client to end of list for late teardown */
@@ -229,7 +229,7 @@ int host1x_device_init(struct host1x_device *device)
 
 teardown_late:
 	list_for_each_entry_continue_reverse(client, &device->clients, list)
-		if (client->ops->late_exit)
+		if (client->ops && client->ops->late_exit)
 			client->ops->late_exit(client);
 
 	mutex_unlock(&device->clients_lock);
-- 
2.53.0

[PATCH AUTOSEL 6.18] spi: tegra210-quad: Allocate DMA memory for DMA engine

[Sasha Levin]

From: Aaron Kling <webgeek1234@gmail.com>

[ Upstream commit f469138a77ac5ab685dfe15dfed7dccb9d5c33e5 ]

When the SPI controllers are running in DMA mode, it is the DMA engine
that performs the memory accesses rather than the SPI controller. Pass
the DMA engine's struct device pointer to the DMA API to make sure the
correct DMA operations are used.

Suggested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Link: https://patch.msgid.link/20260525-tegra194-qspi-iommu-v2-1-a11c53f804b2@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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: `[spi: tegra210-quad] [Allocate] — Use the DMA engine's struct
  device for DMA API calls instead of the SPI controller device`

**Step 1.2 — Tags**
- Record:
  - `Suggested-by: Thierry Reding <treding@nvidia.com>` — NVIDIA Tegra
    maintainer input
  - `Signed-off-by: Aaron Kling <webgeek1234@gmail.com>` — author
  - `Link: https://patch.msgid.link/20260525-tegra194-qspi-
    iommu-v2-1-a11c53f804b2@gmail.com` — patch submission thread
  - `Signed-off-by: Mark Brown <broonie@kernel.org>` — SPI subsystem
    maintainer
  - No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, or `Cc:
    stable@vger.kernel.org`
  - Notable: maintainer involvement (Brown, Reding suggestion), but no
    fuzzer/user bug report tags

**Step 1.3 — Body analysis**
- Record:
  - **Bug:** DMA memory mapping/allocation uses the SPI controller
    `struct device` (`tqspi->dev`) even when an external DMA engine
    (GPCDMA/APBDMA) performs the actual memory accesses.
  - **Symptom:** Incorrect DMA operations / IOMMU mappings; DMA
    transfers can fail or access memory through the wrong DMA/IOMMU
    context.
  - **Root cause:** The DMA engine, not the SPI controller, owns the bus
    master accesses in external-DMA mode; the DMA API must be called
    with the DMA engine's device pointer.
  - **Version info:** None in the commit message itself.

**Step 1.4 — Hidden bug fix?**
- Record: **Yes.** Although the subject says "Allocate," this is a DMA-
  correctness bug fix, not a feature. It mirrors the already-accepted
  `i2c: tegra: Allocate DMA memory for DMA engine` fix (commit
  `cdbf26251d3b3`, present in this tree).

---

## Phase 2: Diff Analysis

**Step 2.1 — Inventory**
- Record:
  - Files: `drivers/spi/spi-tegra210-quad.c` only (+18 / -11 lines)
  - Functions modified: `tegra_qspi_dma_map_xfer()`,
    `tegra_qspi_dma_unmap_xfer()`, `tegra_qspi_deinit_dma()`,
    `tegra_qspi_init_dma()`
  - Struct modified: `struct tegra_qspi` (adds `rx_dma_dev`,
    `tx_dma_dev`)
  - Scope: single-file, surgical fix

**Step 2.2 — Code flow changes**
- Record:
  - **Before:** All `dma_map_single()`, `dma_unmap_single()`,
    `dma_alloc_coherent()`, and `dma_free_coherent()` used `tqspi->dev`
    (SPI controller).
  - **After (external DMA path):** Uses `dmaengine_get_dma_device()` on
    the requested RX/TX DMA channels.
  - **After (internal DMA / tegra234 path):** Explicitly sets
    `rx_dma_dev = tx_dma_dev = tqspi->dev` — behavior unchanged.
  - Affected path: DMA-based SPI transfers when `has_ext_dma == true`
    and DMA channels are successfully requested.

**Step 2.3 — Bug mechanism**
- Record:
  - **Category:** DMA / IOMMU correctness (logic/correctness fix)
  - **Mechanism:** External DMA engine accesses memory using its own DMA
    ops and IOMMU stream ID. Mapping buffers against the SPI controller
    device creates mappings in the wrong IOMMU context. The GPCDMA
    engine cannot correctly access those buffers → IOMMU faults,
    transfer failures, or memory corruption.

**Step 2.4 — Fix quality**
- Record:
  - Fix is obviously correct and follows established kernel pattern
    (`dmaengine_get_dma_device()` API exists at
    `include/linux/dmaengine.h:1672`).
  - Minimal, no unrelated changes.
  - Regression risk: very low. Internal-DMA (tegra234) path explicitly
    preserves `tqspi->dev`.
  - No public API changes.

---

## Phase 3: Git History Investigation

**Step 3.1 — Blame**
- Record:
  - Buggy `dma_map_single(tqspi->dev, ...)` lines date to
    `921fc1838fb036` (Dec 2020, "Add support for Tegra210 QSPI
    controller").
  - Bug present since initial driver DMA support; not a recent
    regression.

**Step 3.2 — Fixes: tag**
- Record: N/A — no `Fixes:` tag present.

**Step 3.3 — Related file history**
- Record:
  - `017f1b0bae08e` — added `has_ext_dma` flag distinguishing external
    GPCDMA (tegra210/186/194/241) from internal DMA (tegra234); is an
    ancestor of HEAD.
  - Commit `f469138a77ac5` is on mainline but **NOT** in
    `stable/linux-6.18.y` (HEAD = v6.18.44).
  - Part of v2 series `[PATCH v2 0/2] arm64: tegra: Enable DMA Support
    on Tegra194 QSPI`; patch 2/2 adds `dmas` properties to tegra194 QSPI
    nodes in DT.

**Step 3.4 — Author context**
- Record: Aaron Kling is a Tegra contributor (also tegra114 SPI patches
  in tree). SPI maintainer Mark Brown merged. Thierry Reding (NVIDIA)
  suggested the approach.

**Step 3.5 — Dependencies**
- Record:
  - Standalone driver fix applies cleanly to 6.18.44 (verified via `git
    cherry-pick --no-commit f469138a77ac5`, exit 0).
  - Functionally pairs with patch 2/2 (tegra194 DT DMA enablement) but
    does not require other code-structure changes.
  - `dmaengine_get_dma_device()` API is present in this tree.

---

## Phase 4: Mailing List and External Research

**Step 4.1 — Original discussion**
- Record:
  - `b4 dig -c f469138a77ac5`:
    https://patch.msgid.link/20260525-tegra194-qspi-
    iommu-v2-1-a11c53f804b2@gmail.com
  - Series revisions: v1 (3 patches, DT bindings + IOMMU), v2 (2
    patches, simplified to driver + DT dmas)
  - Cover letter states Jetson Xavier NX (tegra194/p3668) SPI NOR "would
    time out on all transfers and sometimes even trigger a cbb fault,
    locking up the entire unit"
  - No explicit stable nomination found in thread
  - No NAKs found; merged by Mark Brown

**Step 4.2 — Reviewers**
- Record: CC'd to Thierry Reding, Jonathan Hunter, Sowjanya Komatineni,
  Mark Brown, linux-tegra, linux-spi, devicetree lists.

**Step 4.3 — Bug report details**
- Record:
  - Cover letter documents real hardware failure: SPI NOR timeouts and
    CBB faults on Jetson Xavier NX.
  - Severity from reporter: system lockups (CRITICAL class).
  - Full fix requires patch 2/2 (DT DMA properties) plus this driver fix
    for correct DMA engine device usage.

**Step 4.4 — Related patches**
- Record:
  - Patch 2/2: `arm64: tegra: Enable DMA Support on Tegra194 QSPI` —
    adds `dmas = <&gpcdma 5>` to tegra194 QSPI nodes.
  - Sashiko AI review flagged pre-existing driver issues exposed by
    enabling DMA (unmap-on-error path, packed-mode buffer rounding);
    those are separate from this commit.

**Step 4.5 — Stable list history**
- Record: No stable-list discussion found for this specific SPI patch.
  (Lore direct fetch blocked by bot protection; b4 mbox used instead.)

---

## Phase 5: Code Semantic Analysis

**Step 5.1 — Key functions**
- Record: `tegra_qspi_init_dma()`, `tegra_qspi_deinit_dma()`,
  `tegra_qspi_dma_map_xfer()`, `tegra_qspi_dma_unmap_xfer()`,
  `tegra_qspi_start_dma_based_transfer()` (caller)

**Step 5.2 — Callers**
- Record:
  - `tegra_qspi_init_dma()` called from probe (`~line 1693`) during
    device initialization.
  - `tegra_qspi_dma_map_xfer()` called from
    `tegra_qspi_start_dma_based_transfer()` for packed transfers.
  - DMA transfers triggered from `tegra_qspi_setup_transfer_one()` when
    `use_dma && total_fifo_words > QSPI_FIFO_DEPTH`.
  - Reachable on every large SPI transfer on DMA-enabled platforms.

**Step 5.3 — Callees**
- Record: `dma_request_chan()`, `dmaengine_get_dma_device()`,
  `dma_alloc_coherent()`, `dma_map_single()`,
  `dmaengine_slave_config()`, `dmaengine_prep_slave_single()`.

**Step 5.4 — Call chain / reachability**
- Record:
  - Probe → `tegra_qspi_init_dma()` → DMA buffer allocation (boot/init
    path).
  - Userspace SPI ioctl → `spi_sync()` → controller transfer → DMA path
    for large transfers.
  - **Userspace-reachable** on platforms with external DMA enabled
    (tegra210 has `dmas` in DT; tegra194 will once patch 2 lands).

**Step 5.5 — Similar patterns**
- Record: Identical fix already applied in this tree for `i2c-tegra.c`
  (`cdbf26251d3b3`), which explicitly documents SMMU stream-ID
  misconfiguration without the fix. Other drivers in tree use
  `dmaengine_get_dma_device()` (e.g., `j721e-csi2rx`, `k3-udma`).

---

## Phase 6: Cross-Referencing Against Local Tree (6.18.44)

**Step 6.1 — Does buggy code exist?**
- Record: **Yes.** Current `spi-tegra210-quad.c` uses `tqspi->dev` for
  all DMA API calls (lines 577–810). No `rx_dma_dev`/`tx_dma_dev` fields
  exist. Bug present since driver introduction (2020).

**Step 6.2 — Backport complications**
- Record: **Clean apply** — cherry-pick auto-merges with no conflicts
  (18 insertions, 11 deletions).

**Step 6.3 — Related fixes already present?**
- Record: `i2c: tegra: Allocate DMA memory for DMA engine`
  (`cdbf26251d3b3`) is already in 6.18.y. No equivalent SPI fix yet.
  This SPI commit is NOT in HEAD.

**Platform-specific notes for this tree:**
| Platform | `has_ext_dma` | DMA in DT (6.18.44) | Bug path active? |
|----------|---------------|---------------------|------------------|
| tegra210 | true | Yes (`apbdma`) | Yes — external DMA used today |
| tegra186/194 | true | No (194 lacks `dmas`) | No — falls back to PIO
before DMA alloc |
| tegra234 | false | N/A (internal DMA) | No behavior change from fix |
| tegra241 | true | No DT in tree yet | N/A currently |

---

## Phase 7: Subsystem and Maintainer Context

**Step 7.1 — Subsystem criticality**
- Record: `drivers/spi/` — IMPORTANT (peripheral driver), but DMA/IOMMU
  correctness on embedded Tegra hardware with SPI flash boot/storage.

**Step 7.2 — Subsystem activity**
- Record: Actively maintained — recent 6.18.y commits include timeout
  handling, `curr_xfer` race fixes, internal DMA support
  (`017f1b0bae08e`).

---

## Phase 8: Impact and Risk Assessment

**Step 8.1 — Who is affected**
- Record: Tegra platforms using external DMA for QSPI — tegra210 today;
  tegra194/241 once DT enables GPCDMA. Jetson Xavier NX (p3668) is the
  documented failing platform for the companion DT patch.

**Step 8.2 — Trigger conditions**
- Record:
  - External DMA path active (`has_ext_dma=true`, DMA channels
    successfully requested, `use_dma=true`).
  - Large SPI transfers exceeding FIFO depth.
  - Most impactful when IOMMU/SMMU separates DMA engine and controller
    stream IDs (tegra194 with GPCDMA).
  - Unprivileged users can trigger via SPI device access.

**Step 8.3 — Failure mode severity**
- Record:
  - IOMMU faults (CBB faults mentioned in cover letter) — **CRITICAL**
  - SPI transfer timeouts / hangs — **CRITICAL**
  - Potential buffer corruption with wrong mappings — **HIGH**
  - On tegra210 without IOMMU: bug may be latent (mappings may work by
    accident) — lower practical severity there.

**Step 8.4 — Risk-benefit**
- Record:
  - **Benefit:** HIGH for tegra194 DMA enablement; MEDIUM for tegra210;
    enables correct external DMA operation matching established
    i2c-tegra precedent.
  - **Risk:** VERY LOW — 29-line single-file change, proven API, no-op
    for internal-DMA path.
  - **Ratio:** Strong benefit, minimal risk.

---

## Phase 9: Final Synthesis

**Evidence FOR backport:**
- Real DMA/IOMMU correctness bug with established kernel precedent
  (i2c-tegra fix already in 6.18.y).
- Required prerequisite for tegra194 DMA enablement fixing Jetson Xavier
  NX SPI NOR timeouts and CBB faults.
- tegra210 already uses external DMA with buggy device pointer today.
- Small, surgical, applies cleanly.
- Maintainer-reviewed and merged (Mark Brown; suggested by Thierry
  Reding).
- Prevents IOMMU faults, hangs, and potential data corruption.

**Evidence AGAINST backport:**
- Alone does not enable tegra194 DMA (needs companion DT patch 2/2).
- On current 6.18.44 tegra194 configs, driver falls back to PIO (no
  `dmas` in DT) — this specific commit doesn't fix the documented Xavier
  NX timeout by itself.
- tegra234 (internal DMA) unaffected.
- No syzbot report or explicit user `Reported-by:` in commit message.

**Unresolved questions:**
- Exact practical impact on tegra210 without IOMMU is unverified (may be
  latent).
- Pre-existing driver issues flagged by Sashiko review when DMA is
  enabled are separate bugs.

**Stable rules checklist:**
1. Obviously correct and tested? **PASS** — mirrors accepted i2c-tegra
   fix; API well-established.
2. Fixes a real bug affecting users? **PASS** — DMA engine device
   mismatch is a real bug; tegra210 affected now, tegra194 when DMA
   enabled.
3. Important issue? **PASS** — IOMMU faults, system lockups, transfer
   failures (CRITICAL/HIGH).
4. Small and contained? **PASS** — 29 lines, one file.
5. No new features or APIs? **PASS** — bug fix only.
6. Can apply to local tree? **PASS** — verified clean cherry-pick.

**Exception category:** Not a device-ID/quirk/DT-only fix; this is a
driver DMA correctness bug fix.

---

## Problem Summary

The tegra210-quad SPI driver allocates and maps DMA buffers using the
SPI controller's `struct device`, but when `has_ext_dma` is true, an
external DMA engine (GPCDMA on tegra194/241, APBDMA on tegra210)
performs the actual memory accesses. The DMA API must use the DMA
engine's device so IOMMU mappings and DMA operations match the hardware
master doing the transfer.

Without this fix, enabling external DMA (as done in the companion
tegra194 DT patch) can cause IOMMU faults, SPI transfer failures,
timeouts, and system lockups — exactly what the series cover letter
documents for Jetson Xavier NX SPI NOR flash.

For 6.18.44 users, tegra210 platforms with `dmas` in DT already exercise
the buggy path. The fix is a necessary prerequisite before tegra194 DMA
can work correctly.

## Verification

- [Phase 1] `git describe HEAD` → `v6.18.44`; parsed commit message tags
  and body from provided diff and `git show f469138a77ac5`
- [Phase 2] Read current `spi-tegra210-quad.c` lines 568–818; confirmed
  all DMA API calls use `tqspi->dev`
- [Phase 3] `git blame` lines 577/801 → introduced in `921fc1838fb036`
  (2020); `017f1b0bae08e` added `has_ext_dma`; `git merge-base --is-
  ancestor f469138a77ac5 HEAD` → NOT in HEAD
- [Phase 3] `git cherry-pick --no-commit f469138a77ac5` → exit 0, clean
  auto-merge
- [Phase 4] `b4 dig -c f469138a77ac5` → lore URL found; `b4 dig -a` →
  v1/v2 series; `b4 dig -m` → cover letter documents Xavier NX
  timeouts/CBB faults
- [Phase 4] `b4 dig -w` → Mark Brown, Thierry Reding, linux-tegra CC'd
- [Phase 5] Traced call chain: probe → `tegra_qspi_init_dma()`; transfer
  → `tegra_qspi_start_dma_based_transfer()` →
  `tegra_qspi_dma_map_xfer()`
- [Phase 5] `grep dmaengine_get_dma_device` → API present in
  `include/linux/dmaengine.h:1672`
- [Phase 6] `grep rx_dma_dev` in driver → no matches (fix absent);
  tegra210 DT has `dmas` at `tegra210.dtsi:1883`; tegra194 QSPI nodes
  lack `dmas` at `tegra194.dtsi:921-932`
- [Phase 6] `git log stable/linux-6.18.y --grep='Allocate DMA memory' --
  i2c-tegra.c` → `cdbf26251d3b3` present
- [Phase 8] Cover letter: "time out on all transfers... cbb fault,
  locking up the entire unit"
- UNVERIFIED: Practical tegra210 impact without IOMMU (no IOMMU property
  in tegra210 QSPI DT)

**YES**The background search finished and matches what the full review
already found.

**Commit:** `f469138a77ac5` — `spi: tegra210-quad: Allocate DMA memory
for DMA engine`
**Tree:** `v6.18.44` (`stable/linux-6.18.y`) — the fix is **not** in
this tree yet, but it cherry-picks cleanly.

**What it does:** Uses the external DMA engine’s `struct device` (via
`dmaengine_get_dma_device()`) for DMA map/alloc/unmap instead of the SPI
controller device — same pattern as the existing `i2c: tegra` fix
already in 6.18.y.

**Why it matters:** Needed for correct external DMA on Tegra QSPI
(tegra210 today; tegra194 once DMA is enabled in DT). Without it, you
can get IOMMU faults, transfer failures, and hangs — the Jetson Xavier
NX SPI NOR issue from the patch series.

**Verdict: YES** for backport to 6.18.y.

 drivers/spi/spi-tegra210-quad.c | 29 ++++++++++++++++++-----------
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/drivers/spi/spi-tegra210-quad.c b/drivers/spi/spi-tegra210-quad.c
index 83def82fe48c1..543f13503df3d 100644
--- a/drivers/spi/spi-tegra210-quad.c
+++ b/drivers/spi/spi-tegra210-quad.c
@@ -226,11 +226,13 @@ struct tegra_qspi {
 	struct completion			xfer_completion;
 	struct spi_transfer			*curr_xfer;
 
+	struct device				*rx_dma_dev;
 	struct dma_chan				*rx_dma_chan;
 	u32					*rx_dma_buf;
 	dma_addr_t				rx_dma_phys;
 	struct dma_async_tx_descriptor		*rx_dma_desc;
 
+	struct device				*tx_dma_dev;
 	struct dma_chan				*tx_dma_chan;
 	u32					*tx_dma_buf;
 	dma_addr_t				tx_dma_phys;
@@ -574,15 +576,15 @@ static int tegra_qspi_dma_map_xfer(struct tegra_qspi *tqspi, struct spi_transfer
 	len = DIV_ROUND_UP(tqspi->curr_dma_words * tqspi->bytes_per_word, 4) * 4;
 
 	if (t->tx_buf) {
-		t->tx_dma = dma_map_single(tqspi->dev, (void *)tx_buf, len, DMA_TO_DEVICE);
-		if (dma_mapping_error(tqspi->dev, t->tx_dma))
+		t->tx_dma = dma_map_single(tqspi->tx_dma_dev, (void *)tx_buf, len, DMA_TO_DEVICE);
+		if (dma_mapping_error(tqspi->tx_dma_dev, t->tx_dma))
 			return -ENOMEM;
 	}
 
 	if (t->rx_buf) {
-		t->rx_dma = dma_map_single(tqspi->dev, (void *)rx_buf, len, DMA_FROM_DEVICE);
-		if (dma_mapping_error(tqspi->dev, t->rx_dma)) {
-			dma_unmap_single(tqspi->dev, t->tx_dma, len, DMA_TO_DEVICE);
+		t->rx_dma = dma_map_single(tqspi->rx_dma_dev, (void *)rx_buf, len, DMA_FROM_DEVICE);
+		if (dma_mapping_error(tqspi->rx_dma_dev, t->rx_dma)) {
+			dma_unmap_single(tqspi->tx_dma_dev, t->tx_dma, len, DMA_TO_DEVICE);
 			return -ENOMEM;
 		}
 	}
@@ -597,9 +599,9 @@ static void tegra_qspi_dma_unmap_xfer(struct tegra_qspi *tqspi, struct spi_trans
 	len = DIV_ROUND_UP(tqspi->curr_dma_words * tqspi->bytes_per_word, 4) * 4;
 
 	if (t->tx_buf)
-		dma_unmap_single(tqspi->dev, t->tx_dma, len, DMA_TO_DEVICE);
+		dma_unmap_single(tqspi->tx_dma_dev, t->tx_dma, len, DMA_TO_DEVICE);
 	if (t->rx_buf)
-		dma_unmap_single(tqspi->dev, t->rx_dma, len, DMA_FROM_DEVICE);
+		dma_unmap_single(tqspi->rx_dma_dev, t->rx_dma, len, DMA_FROM_DEVICE);
 }
 
 static int tegra_qspi_start_dma_based_transfer(struct tegra_qspi *tqspi, struct spi_transfer *t)
@@ -745,7 +747,7 @@ static int tegra_qspi_start_cpu_based_transfer(struct tegra_qspi *qspi, struct s
 static void tegra_qspi_deinit_dma(struct tegra_qspi *tqspi)
 {
 	if (tqspi->tx_dma_buf) {
-		dma_free_coherent(tqspi->dev, tqspi->dma_buf_size,
+		dma_free_coherent(tqspi->tx_dma_dev, tqspi->dma_buf_size,
 				  tqspi->tx_dma_buf, tqspi->tx_dma_phys);
 		tqspi->tx_dma_buf = NULL;
 	}
@@ -756,7 +758,7 @@ static void tegra_qspi_deinit_dma(struct tegra_qspi *tqspi)
 	}
 
 	if (tqspi->rx_dma_buf) {
-		dma_free_coherent(tqspi->dev, tqspi->dma_buf_size,
+		dma_free_coherent(tqspi->rx_dma_dev, tqspi->dma_buf_size,
 				  tqspi->rx_dma_buf, tqspi->rx_dma_phys);
 		tqspi->rx_dma_buf = NULL;
 	}
@@ -782,6 +784,7 @@ static int tegra_qspi_init_dma(struct tegra_qspi *tqspi)
 		}
 
 		tqspi->rx_dma_chan = dma_chan;
+		tqspi->rx_dma_dev = dmaengine_get_dma_device(tqspi->rx_dma_chan);
 
 		dma_chan = dma_request_chan(tqspi->dev, "tx");
 		if (IS_ERR(dma_chan)) {
@@ -790,15 +793,19 @@ static int tegra_qspi_init_dma(struct tegra_qspi *tqspi)
 		}
 
 		tqspi->tx_dma_chan = dma_chan;
+		tqspi->tx_dma_dev = dmaengine_get_dma_device(tqspi->tx_dma_chan);
 	} else {
 		if (!device_iommu_mapped(tqspi->dev)) {
 			dev_warn(tqspi->dev,
 				 "IOMMU not enabled in device-tree, falling back to PIO mode\n");
 			return 0;
 		}
+
+		tqspi->rx_dma_dev = tqspi->dev;
+		tqspi->tx_dma_dev = tqspi->dev;
 	}
 
-	dma_buf = dma_alloc_coherent(tqspi->dev, tqspi->dma_buf_size, &dma_phys, GFP_KERNEL);
+	dma_buf = dma_alloc_coherent(tqspi->rx_dma_dev, tqspi->dma_buf_size, &dma_phys, GFP_KERNEL);
 	if (!dma_buf) {
 		err = -ENOMEM;
 		goto err_out;
@@ -807,7 +814,7 @@ static int tegra_qspi_init_dma(struct tegra_qspi *tqspi)
 	tqspi->rx_dma_buf = dma_buf;
 	tqspi->rx_dma_phys = dma_phys;
 
-	dma_buf = dma_alloc_coherent(tqspi->dev, tqspi->dma_buf_size, &dma_phys, GFP_KERNEL);
+	dma_buf = dma_alloc_coherent(tqspi->tx_dma_dev, tqspi->dma_buf_size, &dma_phys, GFP_KERNEL);
 	if (!dma_buf) {
 		err = -ENOMEM;
 		goto err_out;
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.12] ARM: tegra: p880: Lower CPU thermal limit

[Sasha Levin]

From: Ion Agorria <ion@agorria.com>

[ Upstream commit ece4229e457de4ceeec80890c5c760f0c858eeea ]

Lower the CPU thermal limit for the LG P880, since its chassis has less
thermal dissipation capability than the P895.

Signed-off-by: Ion Agorria <ion@agorria.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.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:** `[ARM: tegra: p880]` `[Lower]` — Lower the CPU thermal limit
for the LG Optimus 4X HD (P880) device tree.

### Step 1.2: Commit Message Tags
**Record:**
- **Fixes:** — none
- **Reported-by:** — none
- **Tested-by:** — none
- **Reviewed-by:** — none
- **Acked-by:** — none
- **Link:** — none
- **Cc: stable:** — none (expected for manual review)
- **Signed-off-by:** Ion Agorria, Svyatoslav Ryhel, Thierry Reding
  (ignore pipeline-added SOBs)

Notable: Tegra maintainer Thierry Reding signed off and committed the
patch. No syzbot, bugzilla, or user crash reports.

### Step 1.3: Commit Body Analysis
**Record:**
- **Bug:** P880 inherits CPU thermal trip points from
  `tegra30-lg-x3.dtsi` (shared with P895). P880's chassis has less
  thermal dissipation than P895, so the inherited 75°C passive CPU
  throttle is too high.
- **Symptom:** CPU can run hotter than appropriate before passive
  throttling engages on the CPU diode sensor.
- **Version info:** None in message.
- **Root cause:** Incorrect board-specific thermal description — P880
  reuses P895/X3 thermal profile without board-specific override.

### Step 1.4: Hidden Bug Fix Detection
**Record:** Yes — described as a thermal limit adjustment, but it
corrects an incorrect hardware description in the device tree. This is a
hardware-tuning bug fix, not a cosmetic change.

---

## Phase 2: Diff Analysis

### Step 2.1: Change Inventory
**Record:**
- **Files:** `arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts` (+13 / -0)
- **Functions:** N/A (device tree nodes)
- **Scope:** Single-file, board-specific surgical DT override

### Step 2.2: Code Flow Change
**Record:**
- **Hunk (end of board DTS):** Before — P880 inherits `cpu-thermal`
  trips from included `tegra30-lg-x3.dtsi` (`cpu-alert` passive trip at
  75°C). After — board DTS overrides `cpu-alert` to 60°C passive with
  200 m°C hysteresis.
- **Path affected:** Thermal framework passive throttling on CPU diode
  sensor for P880 only.

### Step 2.3: Bug Mechanism
**Record:**
- **Category:** Hardware workaround / DT correctness fix
- **Mechanism:** P880 `#include`s `tegra30-lg-x3.dtsi`, which defines
  `cpu-alert` at 75000 m°C (75°C). The board override lowers this to
  60000 m°C (60°C) to match P880's poorer thermal dissipation. Skin-
  thermal still throttles at 50°C and shuts down at 60°C on the skin
  sensor, but the CPU diode can run hotter than skin temperature during
  bursts; the inherited 75°C CPU trip was too permissive for this
  chassis.

### Step 2.4: Fix Quality
**Record:** Fix is minimal, obviously correct, and follows established
DT override patterns used on other Tegra boards. Zero impact on non-P880
systems. Regression risk is very low — only makes throttling more
conservative on one board.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame / Introduction of Buggy Code
**Record:** Inherited `cpu-alert` at 75°C introduced in `b68e6e0d50c5d`
("ARM: tegra: Add device-tree for LG Optimus Vu (P895)", Feb 2024) in
`tegra30-lg-x3.dtsi`. P880 DTS added in `ea5e97e9ce046` (Feb 2024)
without a board-specific CPU thermal override. Both commits are
ancestors of the current tree.

### Step 3.2: Fixes: Tag
**Record:** N/A — no Fixes: tag present.

### Step 3.3: Related File History
**Record:**
- `ea5e97e9ce046` — initial P880 DTS
- `b49a73a08100a` — prior P880 board fix (touchscreen clipping), already
  in 6.18.44
- `ece4229e457de` — this thermal fix (mainline, not yet in 6.18.44)
- Part of series "ARM: tegra: complete a few Tegra30 device trees"
  (patch 3/9), but this hunk only touches `tegra30-lg-p880.dts` and is
  functionally standalone.

### Step 3.4: Author Context
**Record:** Svyatoslav Ryhel is the primary P880/P895 DT author. Thierry
Reding (Tegra maintainer) committed the fix. Ion Agorria is the hardware
expert who identified the thermal issue.

### Step 3.5: Dependencies
**Record:** No code dependencies on other patches in the 3/9 series.
Verified with `git apply --check` — applies cleanly to the current
6.18.44 tree.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original Patch Discussion
**Record:**
- **b4 dig URL:**
  https://patch.msgid.link/20260511074859.24930-4-clamor95@gmail.com
- **Series revisions:** v1 original (Apr 2026) and v1 RESEND (May 2026)
- **Reviewer feedback:** No NAKs found in available thread content;
  patch merged by maintainer
- **Stable nominations:** None found in thread

### Step 4.2: Reviewers
**Record:** CC'd: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, Jonathan Hunter, devicetree@, linux-tegra@, linux-
kernel@. Appropriate maintainers were included.

### Step 4.3: Bug Reports
**Record:** No external bug report, syzbot link, or user crash report.
Issue identified through hardware comparison (P880 vs P895 chassis
thermal characteristics).

### Step 4.4: Related Patches
**Record:** Part of 9-patch Tegra30 DT completion series. This patch is
self-contained. Prior P880 fix (`b49a73a08100a`, touchscreen clipping)
is already in this stable tree.

### Step 4.5: Stable Mailing List
**Record:** No stable-specific discussion found for this patch.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Nodes Modified
**Record:** `thermal-zones/cpu-thermal/trips/cpu-alert` in board DTS
root node.

### Step 5.2: Callers / Impact Surface
**Record:** Consumed by kernel thermal framework (`drivers/thermal`) for
P880 DTB only. Triggered when `nct72` sensor 1 (CPU diode) crosses trip
temperature during normal operation.

### Step 5.3: Callees
**Record:** Standard DT thermal zone properties; no new kernel code
paths.

### Step 5.4: Reachability
**Record:** Triggered during normal device use on LG P880 when running
Linux with this DTB. Not userspace-syscall reachable, but affects all
runtime thermal management on this hardware.

### Step 5.5: Similar Patterns
**Record:** Same override pattern exists on other Tegra boards. `arm64:
dts: rockchip: reduce thermal limits on rk3399-pinephone-pro` (in this
tree) is a directly analogous DT thermal-limit correction for a tightly-
packaged mobile device.

---

## Phase 6: Cross-Reference Against Local Tree (6.18.44)

### Step 6.1: Does Buggy Code Exist?
**Record:** **Yes.** Local tree is **v6.18.44**.
`arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts` exists (490 lines) and
includes `tegra30-lg-x3.dtsi`, which defines `cpu-alert` at 75°C. No
board-specific override is present. Bug present since P880 support
landed (`ea5e97e9ce046`, Feb 2024).

### Step 6.2: Backport Complications
**Record:** **Clean apply.** `git format-patch -1 ece4229e457d | git
apply --check` succeeded with no conflicts. File ends at the same
structural point (`sound { ... };` then closing `};`).

### Step 6.3: Related Fixes Already Present?
**Record:** `b49a73a08100a` (P880 touchscreen clipping) is in tree. This
thermal fix (`ece4229e457d`) is **not** in the current 6.18.44 branch
(present on `master` only).

---

## Phase 7: Subsystem Context

### Step 7.1: Subsystem and Criticality
**Record:** **ARM device tree / Tegra30 mobile platform.** Criticality:
**PERIPHERAL** — affects one specific 2012-era smartphone board.

### Step 7.2: Subsystem Activity
**Record:** Active — P880 received a board fix in 2025 (touchscreen
clipping) already merged into this stable series.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who Is Affected
**Record:** **Driver/board-specific** — only users running mainline
Linux on LG Optimus 4X HD (P880) with `tegra30-lg-p880.dtb`.

### Step 8.2: Trigger Conditions
**Record:** Sustained or bursty CPU load causing CPU diode temperature
to rise. Common during normal phone use. Not security-relevant;
unprivileged workload heat is the trigger.

### Step 8.3: Failure Mode Severity
**Record:** Without fix: delayed CPU passive throttling (75°C vs 60°C).
Skin sensor still provides 50°C passive / 60°C critical shutdown, but
CPU diode can exceed skin temperature. Severity: **MEDIUM** — potential
overheating, accelerated throttling only at higher temps, possible
discomfort or thermal stress; not a kernel crash or data corruption.

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** Correct thermal protection for P880; prevents running
  with P895-inappropriate limits. Matches maintainer and hardware-author
  intent.
- **Risk:** Very low — 13-line DT-only change, board-scoped, more
  conservative throttling only.
- **Ratio:** Modest benefit (small user base) vs very low risk. Fits DT
  hardware-description correction category.

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence Summary

**FOR backport:**
- Corrects incorrect DT hardware description for board already supported
  in 6.18.y
- Small (13 lines), surgical, maintainer-approved
- Applies cleanly to this tree
- DT exception category: fix for incorrect hardware description
- Precedent: similar P880 board fix already in this tree; analogous
  pinephone-pro thermal DT fix exists
- Prevents P880 from using P895 thermal profile inappropriate for its
  chassis

**AGAINST backport:**
- Very niche hardware (2012 phone, tiny mainline user base)
- No crash, corruption, security issue, or user bug report
- Skin thermal already provides some protection
- More aggressive throttling is a behavior change (performance tradeoff)
- Not in the "critical" severity categories stable rules emphasize most

**Unresolved:** No quantitative data on how often P880 exceeds 60°C CPU
temperature in practice without this fix.

### Step 9.2: Stable Rules Checklist
1. **Obviously correct and tested?** **PASS** — maintainer-merged,
   hardware-author identified issue, standard DT override pattern.
2. **Fixes a real bug affecting users?** **PASS** — incorrect thermal
   limits for supported hardware; real for P880 users.
3. **Important issue?** **PASS (borderline)** — thermal safety /
   hardware protection, not crash/corruption, but prevents running with
   wrong thermal envelope.
4. **Small and contained?** **PASS** — 13 lines, one file.
5. **No new features or APIs?** **PASS** — board-specific DT property
   override only.
6. **Can apply to local tree?** **PASS** — verified clean apply to
   6.18.44.

### Step 9.3: Exception Category
**Record:** **Device tree update** — correction of incorrect hardware
thermal description for existing supported board.

### Step 9.4: Decision Rationale

This commit fixes a real device-tree bug: P880 inherits P895/X3 CPU
thermal trip points that are too high for its chassis. The fix is
minimal, board-scoped, maintainer-approved, applies cleanly to Linux
6.18.44, and follows the same pattern as the P880 touchscreen clipping
fix already present in this stable tree. While the user base is small
and severity is thermal-tuning rather than kernel crash, stable rules
explicitly include DT fixes for incorrect hardware descriptions, and the
risk of backporting is negligible.

---

## Verification

- **[Phase 1]** Parsed subject, tags, body from provided commit message
  and `git show ece4229e457d`
- **[Phase 2]** Diff analysis: +13 lines in `tegra30-lg-p880.dts`, adds
  `thermal-zones/cpu-thermal/trips/cpu-alert` override
- **[Phase 3]** `git describe HEAD`: v6.18.44 / kernel 6.18.44
- **[Phase 3]** `git blame tegra30-lg-x3.dtsi:1777-1790`: inherited 75°C
  trip from `b68e6e0d50c5d` (Feb 2024)
- **[Phase 3]** `git merge-base --is-ancestor ea5e97e9ce046 HEAD`: P880
  DTS present in tree
- **[Phase 3]** `git merge-base --is-ancestor ece4229e457d HEAD`:
  thermal fix NOT in 6.18.44
- **[Phase 3]** `git apply --check`: patch applies cleanly to current
  tree
- **[Phase 4]** `b4 dig -c ece4229e457d`: lore URL found
- **[Phase 4]** `b4 dig -a`: v1 and v1 RESEND revisions found, part of
  9-patch series
- **[Phase 4]** `b4 dig -w`: DT and Tegra maintainers CC'd
- **[Phase 5]** Read `tegra30-lg-x3.dtsi:1727-1810`: confirmed inherited
  trips (skin 50°C/60°C, CPU 75°C/90°C)
- **[Phase 5]** Grep `tegra30-lg-p895.dts`: no board-specific thermal
  override (uses shared dtsi)
- **[Phase 6]** Read current `tegra30-lg-p880.dts`: no `thermal-zones`
  override present (490 lines)
- **[Phase 6]** `b49a73a08100a` confirmed in tree as prior P880 board
  fix
- **[Phase 7]** Subsystem: ARM Tegra30 DT, peripheral/niche
- **[Phase 8]** Failure mode: delayed CPU thermal throttling, severity
  MEDIUM

**YES**Those background searches finished and matched what the main
analysis already used:

- **Thermal limit commit search:** No `Lower CPU thermal limit` / `cpu-
  alert` override is in the 6.18.44 tree yet; the fix exists only on
  mainline as `ece4229e457d`.
- **Ion Agorria commits:** Only unrelated `drm/tegra` probe/remove PM
  work showed up locally — nothing overlapping this DTS change.

The backport recommendation stands: **YES** — a small, board-specific DT
correction that applies cleanly to 6.18.44.

 arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts b/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts
index c6ef0a20c19f3..4f57e43af6428 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts
+++ b/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts
@@ -486,4 +486,17 @@ sound {
 
 		nvidia,int-mic-en-gpios = <&gpio TEGRA_GPIO(I, 6) GPIO_ACTIVE_HIGH>;
 	};
+
+	thermal-zones {
+		cpu-thermal {
+			trips {
+				cpu-alert {
+					/* throttle at 60C until temperature drops to 59.8C */
+					temperature = <60000>;
+					hysteresis = <200>;
+					type = "passive";
+				};
+			};
+		};
+	};
 };
-- 
2.53.0