[PATCH AUTOSEL 6.18-6.6] mfd: tps65219: Make poweroff handler conditional on system-power-controller

[PATCH AUTOSEL 6.18-6.6] mfd: tps65219: Make poweroff handler conditional on system-power-controller

[Sasha Levin]

From: Akashdeep Kaur <a-kaur@ti.com>

[ Upstream commit 104cd764a031bfe2ffe253adce9581384a78c16e ]

Currently, the TPS65219 driver unconditionally registers a poweroff
handler. This causes issues on systems where a different component
(such as TF-A firmware) should handle system poweroff instead.

Make the poweroff handler registration conditional based on the
"system-power-controller" device tree property. This follows the
standard kernel pattern where only the designated power controller
registers for system poweroff operations.

On systems where the property is absent, the PMIC will not register
a poweroff handler, allowing other poweroff mechanisms to function.

Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
Link: https://patch.msgid.link/20260401112257.1248437-3-a-kaur@ti.com
Signed-off-by: Lee Jones <lee@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: `[mfd: tps65219]` `[Make]` — Make poweroff handler registration
conditional on the `system-power-controller` device-tree property.

**Step 1.2 — Tags**

Record:
- `Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>` (author)
- `Link:
  https://patch.msgid.link/20260401112257.1248437-3-a-kaur@ti.com`
  (patch submission; message-id suffix `-3` indicates patch 3 of a
  series)
- `Signed-off-by: Lee Jones <lee@kernel.org>` (MFD maintainer)
- No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Cc:
  stable@vger.kernel.org`

**Step 1.3 — Body analysis**

Record:
- **Bug:** TPS65219 driver unconditionally registers a system poweroff
  handler even when another component (e.g. TF-A) should handle
  shutdown.
- **Symptom:** Wrong poweroff path is taken; TF-A/PSCI shutdown is
  preempted or conflicted by PMIC I2C soft-shutdown.
- **Root cause:** Driver ignores the existing `system-power-controller`
  DT property documented in the binding.
- **Fix:** Only call `devm_register_power_off_handler()` when
  `of_device_is_system_power_controller()` is true.

**Step 1.4 — Hidden bug fix?**

Record: Yes. Despite “Make … conditional” wording, this is a real
platform correctness bug: the driver registers a shutdown handler on
boards where it should not, breaking the intended poweroff mechanism.

---

## Phase 2: Diff Analysis

**Step 2.1 — Inventory**

Record:
- **File:** `drivers/mfd/tps65219.c` (+4/-4 net, ~10 lines touched)
- **Function:** `tps65219_probe()`
- **Scope:** Single-file, surgical driver fix

**Step 2.2 — Code flow change**

Record:
- **Before:** `devm_register_power_off_handler()` always runs during
  probe.
- **After:** Registration is wrapped in `if
  (of_device_is_system_power_controller(tps->dev->of_node))`.
- **Error handling:** Switches to `dev_err_probe()` (consistent with
  nearby tps6594 code).
- **Path affected:** Probe success path on all boards with a
  TPS65214/15/19 PMIC.

**Step 2.3 — Bug mechanism**

Record:
- **Category:** Logic / correctness fix (wrong shutdown handler
  registration).
- **Mechanism:** PMIC registers into the sys-off handler chain
  unconditionally. On K3 platforms where TF-A/PSCI owns shutdown, the
  PMIC handler sends an I2C OFF request via `tps65219_soft_shutdown()`,
  conflicting with the firmware path. The DT binding already defines
  `system-power-controller` as the gate for this behavior; the driver
  simply did not honor it.

**Step 2.4 — Fix quality**

Record:
- Fix is obviously correct and matches established PMIC driver patterns
  (`tps6594-core.c`, `rn5t618.c`, `max77620.c`, `tps6586x.c`).
- Minimal diff, no API changes.
- **Regression risk:** Low for boards that already have `system-power-
  controller` in DT (no behavior change). One in-tree board
  (`k3-am62-lp-sk.dts`) lacks the property and currently relies on
  unconditional registration; it may need a companion DT patch adding
  `system-power-controller` if PMIC shutdown is still required there.
  Other AM62 tps65219 boards already have the property.

---

## Phase 3: Git History Investigation

**Step 3.1 — Blame**

Record:
- Unconditional `devm_register_power_off_handler()` introduced by commit
  `3df4c63675203` (“mfd: tps65219: Add support for soft shutdown via
  sys-off API”, 2023-06-15).
- That code is present unchanged in the local tree at lines 544–550.

**Step 3.2 — Fixes: tag**

Record: Not applicable (no `Fixes:` tag). Bug introduced by
`3df4c63675203`, which is in this tree.

**Step 3.3 — Related file history**

Record:
- Driver added in `74c17a0a49a6a` (first appeared in v6.10).
- Poweroff support added 2023-06-15.
- DT binding `system-power-controller` documented since `4d2aed6ee306c`
  (2022-08-23), before poweroff handler was added.
- Fix commit is not yet merged into this checkout (buggy code still
  present).
- Patch is 3/N of a series per message-id; standalone driver change is
  self-contained.

**Step 3.4 — Author context**

Record: Akashdeep Kaur is a TI contributor with K3 device-tree work. Lee
Jones is the MFD maintainer who committed the original poweroff support.

**Step 3.5 — Dependencies**

Record:
- `of_device_is_system_power_controller()` exists in
  `include/linux/of.h` (available via `#include <linux/i2c.h>` already
  in the file).
- No structural prerequisites; patch applies standalone to
  `tps65219_probe()`.

---

## Phase 4: Mailing List and External Research

**Step 4.1 — Original discussion**

Record: `b4 dig -c` could not match the fix commit (not merged in this
tree). Direct lore fetch returned 403 Forbidden. Link points to patch 3
of an April 2026 TI submission series.

**Step 4.2 — Reviewers**

Record: UNVERIFIED — could not retrieve thread via lore or b4.

**Step 4.3 — Bug report**

Record: No external bug report linked. Issue described in commit message
(TF-A conflict).

**Step 4.4 — Series context**

Record: Message-id suffix `-3` suggests a multi-patch series; possible
companion DT updates exist but were not analyzed (not in provided diff).

**Step 4.5 — Stable list**

Record: UNVERIFIED — stable list search not accessible.

---

## Phase 5: Code Semantic Analysis

**Step 5.1 — Key functions**

Record: `tps65219_probe()`, `tps65219_power_off_handler()`,
`tps65219_soft_shutdown()`.

**Step 5.2 — Callers**

Record: `tps65219_probe()` called from I2C core during device
enumeration on boards with `compatible = "ti,tps65214"`,
`"ti,tps65215"`, or `"ti,tps65219"`. Ten in-tree TI K3 DTS files use
tps65219.

**Step 5.3 — Callees**

Record: `devm_register_power_off_handler()` → sys-off notifier chain;
handler calls `tps65219_soft_shutdown()` which writes PMIC registers
over I2C.

**Step 5.4 — Reachability**

Record: Triggered on every `poweroff`/`halt`/`shutdown` on systems where
the handler is registered. User-visible via standard shutdown syscalls.

**Step 5.5 — Similar patterns**

Record: Identical conditional pattern in `tps6594-core.c:788-792`,
`rn5t618.c:217-222`, `max77620.c:576-580`, `tps6586x.c:585-599`.

---

## Phase 6: Cross-Reference Against Local Tree (v6.18.44)

**Step 6.1 — Buggy code present?**

Record: **Yes.** Local tree is `v6.18.44` (`git describe HEAD` =
`v6.18.44-1-g2736c32da98b9`). Unconditional registration at
`drivers/mfd/tps65219.c:544-550`. Bug present since v6.10 (driver
introduction) for poweroff path since mid-2023.

**Step 6.2 — Backport difficulty**

Record: Clean apply expected — small hunk in `tps65219_probe()`, no
conflicts visible. `of_device_is_system_power_controller` and DT binding
property both exist in this tree.

**Step 6.3 — Related fixes already present?**

Record: No equivalent conditional registration found in current
`tps65219.c`.

---

## Phase 7: Subsystem Context

**Step 7.1 — Subsystem**

Record: `drivers/mfd/` — MFD/PMIC driver. **Criticality: IMPORTANT**
(affects system shutdown on embedded TI K3 platforms, not universal but
operationally critical on affected hardware).

**Step 7.2 — Activity**

Record: Active development — TPS65214/15 support added recently; driver
actively maintained by TI and MFD maintainers.

---

## Phase 8: Impact and Risk Assessment

**Step 8.1 — Who is affected**

Record: Users of TI K3 SoCs (AM62 family and derivatives) with
TPS65214/15/19 PMIC, especially boards where TF-A handles shutdown but
the PMIC is present for regulators.

**Step 8.2 — Trigger conditions**

Record: Any system shutdown (`halt`, `poweroff`, `shutdown`). Common
user/admin operation. Not security-sensitive but operationally
important.

**Step 8.3 — Failure mode severity**

Record: Improper or failed system shutdown when PMIC handler conflicts
with TF-A/PSCI path. **Severity: MEDIUM-HIGH** — system may hang instead
of powering off, or take wrong shutdown path. Not a kernel oops, but a
real operational failure on production embedded systems.

**Step 8.4 — Risk vs benefit**

Record:
- **Benefit:** HIGH for affected TI K3 platforms — restores correct
  shutdown delegation per DT contract.
- **Risk:** LOW — 10-line change following established pattern; 9 of 10
  in-tree tps65219 boards already declare `system-power-controller`.
- **Ratio:** Benefit clearly outweighs risk.

---

## Phase 9: Final Synthesis

**Evidence FOR backport:**
- Fixes real shutdown correctness bug on TF-A-managed platforms
- Aligns driver with DT binding documented since 2022
- Matches established kernel PMIC pattern (tps6594, rn5t618, etc.)
- Small, surgical, maintainer-reviewed
- Buggy code confirmed present in v6.18.44 tree
- Affects commonly deployed TI K3 embedded hardware

**Evidence AGAINST:**
- `k3-am62-lp-sk.dts` lacks `system-power-controller`; may need
  companion DT patch (not in this commit)
- Mailing list review details unverified
- Not a crash/corruption bug — shutdown path correctness

**Stable rules checklist:**
1. Obviously correct and tested? **PASS** — standard pattern, maintainer
   SOB; runtime testing claimed in original poweroff commit for related
   hardware
2. Fixes real bug affecting users? **PASS** — wrong shutdown handler on
   TF-A platforms
3. Important issue? **PASS** — shutdown failure/hang, MEDIUM-HIGH
   severity
4. Small and contained? **PASS** — single file, ~10 lines
5. No new features/APIs? **PASS** — implements existing DT contract
6. Can apply to local tree? **PASS** — code and prerequisites present

**Exception category:** Hardware/platform quirk/workaround alignment
(DT-driven behavior gate).

---

## Verification

- [Phase 1] Parsed commit message and tags from user-provided diff
- [Phase 2] Analyzed diff: conditional
  `of_device_is_system_power_controller()` wrap in `tps65219_probe()`
- [Phase 3] `git describe HEAD`: v6.18.44-1-g2736c32da98b9
- [Phase 3] `git blame -L 544,550 drivers/mfd/tps65219.c`: lines from
  `3df4c63675203` (2023-06-08)
- [Phase 3] `git show 3df4c63675203`: introduced unconditional poweroff
  handler
- [Phase 3] `git log --oneline -20 -- drivers/mfd/tps65219.c`: confirmed
  driver history
- [Phase 3] `git tag --contains 74c17a0a49a6a`: driver first in v6.10
- [Phase 4] `b4 dig -c 3df4c63675203`: found original poweroff patch
  lore link
- [Phase 4] `b4 dig -c <fix_commit>`: no match (fix not merged)
- [Phase 4] lore fetch: 403 Forbidden — review thread UNVERIFIED
- [Phase 5] Read `tps65219_power_off_handler()` and
  `tps65219_soft_shutdown()` at lines 29-40
- [Phase 5] Read `kernel/reboot.c:557-565`:
  `devm_register_power_off_handler` API
- [Phase 5] Compared with `tps6594-core.c:788-792`, `rn5t618.c:217-222`,
  `max77620.c:576-580`
- [Phase 6] Grep confirmed buggy unconditional registration at
  `tps65219.c:544-550`
- [Phase 6] Grep `system-power-controller` in 10 tps65219 DTS files: 9
  have property, `k3-am62-lp-sk.dts` does not
- [Phase 6] Read
  `Documentation/devicetree/bindings/regulator/ti,tps65219.yaml:34-37`:
  property documented
- [Phase 6] Read `include/linux/of.h:1706-1708`:
  `of_device_is_system_power_controller()` implementation
- [Phase 6] Verified `#include <linux/i2c.h>` pulls in `<linux/of.h>` —
  no new include needed
- [Phase 7] K3 AM62 has PSCI (`k3-am62.dtsi:30-31`)
- [Phase 8] UNVERIFIED: exact failure symptoms on specific TF-A platform
  (no bug report accessible)

This commit corrects a driver-DT contract violation that causes improper
system shutdown on TI K3 platforms where TF-A should handle poweroff.
The fix is small, follows an established PMIC pattern already used in
this tree, and the buggy code is present in v6.18.44.

**YES**

 drivers/mfd/tps65219.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/mfd/tps65219.c b/drivers/mfd/tps65219.c
index 7275dcdb7c44f..e52fbf1481fef 100644
--- a/drivers/mfd/tps65219.c
+++ b/drivers/mfd/tps65219.c
@@ -541,13 +541,15 @@ static int tps65219_probe(struct i2c_client *client)
 		return ret;
 	}
 
-	ret = devm_register_power_off_handler(tps->dev,
-					      tps65219_power_off_handler,
-					      tps);
-	if (ret) {
-		dev_err(tps->dev, "failed to register power-off handler: %d\n", ret);
-		return ret;
+	if (of_device_is_system_power_controller(tps->dev->of_node)) {
+		ret = devm_register_power_off_handler(tps->dev,
+						      tps65219_power_off_handler,
+						      tps);
+		if (ret)
+			return dev_err_probe(tps->dev, ret,
+					     "Failed to register power-off handler\n");
 	}
+
 	return 0;
 }
 
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] ASoC: ti: omap3pandora: update board check to use DT compatible

[Sasha Levin]

From: Ethan Nelson-Moore <enelsonmoore@gmail.com>

[ Upstream commit 45efb8fbdae303539e7fb5562e147583d4ed63ad ]

The omap3pandora driver contains a check for the ARM machine ID via the
machine_is_omap3_pandora() macro. The board concerned now supports
only FDT booting, which does not use machine IDs, and therefore the
code should be updated to check the DT compatible property instead. The
legacy board file for this machine was removed in commit 7fcf7e061edd
("ARM: OMAP2+: Remove legacy booting support for Pandora").
The presence of this machine ID check prevents the removal of machine
IDs no longer used by the kernel from arch/arm/tools/mach-types,
because the machine_is_*() macros are generated from mach-types. To
resolve this issue, use of_machine_is_compatible() instead.

Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.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:** `[ASoC: ti: omap3pandora]` `[update]` — Update OMAP3 Pandora
board detection to use device-tree compatible strings instead of ARM
machine ID.

### Step 1.2: Tags
**Record:**
- **Signed-off-by:** Ethan Nelson-Moore `<enelsonmoore@gmail.com>`
  (author)
- **Acked-by:** Jarkko Nikula `<jarkko.nikula@bitmer.com>`
- **Signed-off-by:** Mark Brown `<broonie@kernel.org>` (ASoC maintainer)
- **No** Fixes:, Reported-by:, Tested-by:, Link:, or Cc:
  stable@vger.kernel.org in the committed message (v1 had Cc: stable; v3
  removed it per review)
- Notable: maintainer ack and ASoC maintainer sign-off

### Step 1.3: Body analysis
**Record:**
- **Bug:** `machine_is_omap3_pandora()` relies on legacy ARM machine
  IDs; Pandora boots only via FDT since legacy board support was removed
  in `7fcf7e061edd` (2015).
- **Symptom:** The ASoC module’s `module_init()` returns `-ENODEV`, so
  the Pandora audio card never registers on DT-booted systems.
- **Secondary motivation:** The `machine_is_*()` reference blocks
  cleanup of unused `mach-types` entries.
- **Root cause:** Board detection uses `MACH_TYPE_OMAP3_PANDORA` while
  DT boot matches generic `OMAP3_DT` / `OMAP36XX_DT` machine descriptors
  and sets `__machine_arch_type` accordingly (see
  `arch/arm/kernel/devtree.c:235`).

### Step 1.4: Hidden bug fix?
**Record:** Yes. Although framed partly as mach-types maintenance, this
is a functional board-detection bug: DT-booted Pandora boards do not
match `machine_is_omap3_pandora()`, so audio never initializes. v2
changelog softened v1’s “always fails” wording, but on normal DT boot
`__machine_arch_type` is set from the matched DT machine descriptor, not
`MACH_TYPE_OMAP3_PANDORA`.

---

## Phase 2: Diff Analysis

### Step 2.1: Inventory
**Record:**
- **File:** `sound/soc/ti/omap3pandora.c` (+3 / -2 net, ~5 logical lines
  changed)
- **Functions:** `omap3pandora_soc_init()` only
- **Scope:** Single-file surgical fix

### Step 2.2: Code flow change
**Record:**
- **Hunk 1 (includes):** Adds `<linux/of.h>`, removes `<asm/mach-
  types.h>` — switches from machine-ID API to OF API.
- **Hunk 2 (`omap3pandora_soc_init`):**
  - **Before:** `if (!machine_is_omap3_pandora()) return -ENODEV;`
  - **After:** `if
    (!of_machine_is_compatible("openpandora,omap3-pandora-600mhz") &&
    !of_machine_is_compatible("openpandora,omap3-pandora-1ghz")) return
    -ENODEV;`
  - **Path affected:** `module_init()` gate for the entire Pandora audio
    driver.

### Step 2.3: Bug mechanism
**Record:** **Logic / correctness fix (board detection).** On DT boot,
Pandora DTs use compatibles `openpandora,omap3-pandora-{600mhz,1ghz}`
plus generic `ti,omap3430`/`ti,omap3630`. Kernel matches generic
OMAP3/OMAP36xx DT machine descriptors; `__machine_arch_type` is not
`MACH_TYPE_OMAP3_PANDORA` (1761). The old check always fails on DT boot,
blocking driver registration.

### Step 2.4: Fix quality
**Record:** Obviously correct. Matches DT files in-tree and the pattern
used by sibling OMAP board drivers (`rx51.c`, `n810.c`). Minimal change,
no API changes, very low regression risk. Only Pandora DT compatibles
pass the new check.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame
**Record:** Current `machine_is_omap3_pandora()` gate is long-standing
driver code. Legacy Pandora board file removed in `7fcf7e061edd`
(2015-07-16). DT support added in `771048f59d068`, `b715da74deaf`,
`9ccd0106c9db` (2015-03-16). Mismatch between DT-only boot and machine-
ID check has existed since ~2015.

### Step 3.2: Fixes: tag
**Record:** N/A — no Fixes: tag in committed version (removed in v2
after review).

### Step 3.3: Related file history
**Record:** No related omap3pandora fixes in recent history. A larger
rewrite series (“Rewrite sound card driver as a platform driver with
DT”, Nikolaus Schaller, 2026) exists on mailing lists but is not in this
tree and would be unsuitable for stable anyway.

### Step 3.4: Author context
**Record:** Ethan Nelson-Moore appears to be a board-specific
contributor. Patch acked by Jarkko Nikula and signed off by Mark Brown
(ASoC maintainer).

### Step 3.5: Dependencies
**Record:** Standalone. Requires only existing DT compatibles and
`of_machine_is_compatible()`, both present in this tree. No series
prerequisites.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original discussion
**Record:** Patch went through v1 → v2 → v3 (May 2026). v2 changelog:
removed Fixes: tags and corrected claim that machine IDs “always fail” —
noted they can work if bootloader passes ID. v3 is the committed form.
Lore fetch blocked by bot protection; details corroborated via
Ratatoskr/search results.

### Step 4.2: Reviewers
**Record:** Acked-by Jarkko Nikula; Signed-off-by Mark Brown.
Appropriate ASoC maintainers involved.

### Step 4.3: Bug reports
**Record:** No syzbot, bugzilla, or user crash reports. Functional
hardware-enablement issue, not a sanitizer finding.

### Step 4.4: Related patches
**Record:** v1 included Cc: stable; final v3 does not. Larger DT
platform-driver rewrite is a separate future effort.

### Step 4.5: Stable list history
**Record:** Not investigated on lore stable list (fetch blocked). No
evidence of prior stable rejection.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key functions
**Record:** `omap3pandora_soc_init()` (modified gate only).

### Step 5.2: Callers
**Record:** Called via `module_init()` when `snd-soc-omap3pandora.ko` is
loaded (`CONFIG_SND_SOC_OMAP3_PANDORA=m` in `omap2plus_defconfig`). Runs
in process context during module load, after DT is populated — safe for
`of_machine_is_compatible()`.

### Step 5.3: Callees
**Record:** `of_machine_is_compatible()`, then existing
`platform_device_alloc/add`, GPIO/regulator setup unchanged.

### Step 5.4: Reachability
**Record:** Triggered when distro/user loads the omap3pandora audio
module on OpenPandora hardware booted from DT (the only supported method
since 2015). Direct user-visible impact: audio card registration.

### Step 5.5: Similar patterns
**Record:** `sound/soc/ti/rx51.c:364` uses `machine_is_nokia_rx51() ||
of_machine_is_compatible("nokia,omap3-n900")`.
`sound/soc/ti/n810.c:289-291` uses only DT compatibles. omap3pandora was
the outlier still using machine ID only.

---

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

### Step 6.1: Buggy code present?
**Record:** **Yes.** `sound/soc/ti/omap3pandora.c:226` still has
`machine_is_omap3_pandora()`. DT files with correct compatibles exist at
`arch/arm/boot/dts/ti/omap/omap3-pandora-{600mhz,1ghz}.dts`. Legacy
board file is gone (`7fcf7e061edd` present). `mach-types` still lists
`omap3_pandora` at line 325.

### Step 6.2: Backport complications
**Record:** **Clean apply** — verified with `git apply --check` against
current tree. No conflicts expected.

### Step 6.3: Related fixes already present?
**Record:** No equivalent DT-compatible check already applied in this
tree.

---

## Phase 7: Subsystem and Maintainer Context

### Step 7.1: Subsystem
**Record:** **ASoC / OMAP3 Pandora audio driver** — PERIPHERAL (niche
embedded hardware: OpenPandora handheld).

### Step 7.2: Activity
**Record:** Mature, low-churn driver. OMAP DT infrastructure stable.
Recent activity is this board-detection fix and a proposed larger DT
rewrite.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who is affected
**Record:** OpenPandora users with `CONFIG_SND_SOC_OMAP3_PANDORA`
enabled (present in `omap2plus_defconfig`). Small but real user
population.

### Step 8.2: Trigger conditions
**Record:** DT boot (standard for Pandora since 2015) + omap3pandora
module load. Common for intended users, not a race or obscure corner
case.

### Step 8.3: Failure mode severity
**Record:** Audio driver silently fails init (`-ENODEV`); no kernel
crash, corruption, or security issue. **Severity: MEDIUM** — broken
hardware functionality (“oh, that's not good” per stable rules), not
CRITICAL.

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** Restores Pandora audio on the only supported boot path;
  enables mach-types cleanup; follows established OMAP DT-detection
  pattern.
- **Risk:** Very low — 5-line change, board-specific compatibles only.
- **Ratio:** Moderate-to-good benefit for affected users, minimal risk.

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence summary

**FOR backport:**
- Real functional bug: DT-booted Pandora never passes board check
- Small, surgical, maintainer-reviewed fix
- Applies cleanly to 6.18.43
- Matches in-tree DT compatibles
- Precedent in sibling OMAP ASoC drivers
- Qualifies as hardware quirk / board-detection fix under stable
  exceptions

**AGAINST backport:**
- Niche hardware, small user base
- Bug present since ~2015 without crash/security impact
- No user bug reports or syzbot findings
- Final commit omits Cc: stable (not decisive per review rules)
- Strict “important issue” bar (crash/corruption/deadlock) not met

**Unresolved:** No direct user bug report verified; lore thread not
fully readable due to bot protection.

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** — logic verified against DT
   files and `devtree.c` behavior; maintainer acked.
2. Fixes a real bug affecting users? **PASS** — Pandora audio module
   cannot initialize on DT boot.
3. Important issue? **PASS (borderline)** — hardware functionality
   broken for affected users; hardware-quirk category, not
   crash/security.
4. Small and contained? **PASS** — ~5 lines, one file.
5. No new features or APIs? **PASS** — detection mechanism change only.
6. Can apply to local tree? **PASS** — verified clean apply.

### Step 9.3: Exception category
**Record:** Hardware quirk / board-detection workaround — analogous to
DT updates enabling already-supported hardware.

### Step 9.4: Decision rationale

For **this 6.18.43 tree**, the buggy code exists, DT is the only Pandora
boot path, and the fix is minimal and correct. Without it,
`CONFIG_SND_SOC_OMAP3_PANDORA` is effectively dead on real hardware.
While the user base is small and severity is functional rather than
catastrophic, stable rules explicitly accept fixes for “hardware quirk”
issues and “real bug[s] that bother people.” This fits that pattern and
mirrors accepted OMAP board-detection fixes (`rx51`, `n810`).

---

## Verification

- [Phase 1] Parsed commit message and tags from user-provided content;
  noted v1→v3 evolution via web search.
- [Phase 2] Read full `sound/soc/ti/omap3pandora.c`; confirmed diff
  scope and `module_init` gate.
- [Phase 3] `git describe HEAD`: v6.18.43-1-gc7f0dac02d232 / kernel
  6.18.43.
- [Phase 3] `git show 7fcf7e061edd`: legacy Pandora board file removed
  2015-07-16; present in tree.
- [Phase 3] `git show b715da74deaf`, `9ccd0106c9db`, `771048f59d068`: DT
  files added 2015-03-16; present in tree.
- [Phase 3] `git blame` on lines 222-230: long-standing
  `machine_is_omap3_pandora()` check.
- [Phase 4] Web search: found v1/v2/v3 thread; v2 changelog correction
  about machine IDs; lore direct fetch blocked.
- [Phase 4] `b4 dig`: no result for attempted lookups.
- [Phase 5] Grep `of_machine_is_compatible` in `sound/soc/ti/rx51.c`,
  `n810.c`: confirmed precedent.
- [Phase 5] Read `arch/arm/kernel/devtree.c:234-235`: DT boot sets
  `__machine_arch_type = mdesc->nr`.
- [Phase 5] Read `arch/arm/mach-omap2/board-generic.c:130-161`: Pandora
  matches generic OMAP3/OMAP36xx DT descriptors, not OMAP3_PANDORA.
- [Phase 5] Grep `arch/arm/tools/mach-types`: `omap3_pandora` = 1761.
- [Phase 6] Grep `sound/soc/ti/omap3pandora.c`: buggy
  `machine_is_omap3_pandora()` at line 226.
- [Phase 6] Grep DT files: compatibles
  `openpandora,omap3-pandora-600mhz` and
  `openpandora,omap3-pandora-1ghz` present.
- [Phase 6] `git apply --check`: patch applies cleanly to current tree.
- [Phase 6] Grep `CONFIG_SND_SOC_OMAP3_PANDORA`: enabled as module in
  `omap2plus_defconfig`.
- [Phase 7] Read `Documentation/process/stable-kernel-rules.rst`:
  hardware quirk criterion applies.
- [Phase 8] Traced failure mode: `module_init` returns `-ENODEV` → no
  audio card registered.

**YES**

 sound/soc/ti/omap3pandora.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/sound/soc/ti/omap3pandora.c b/sound/soc/ti/omap3pandora.c
index 808fb6765c05f..2ddd14e8f6b6c 100644
--- a/sound/soc/ti/omap3pandora.c
+++ b/sound/soc/ti/omap3pandora.c
@@ -11,12 +11,12 @@
 #include <linux/delay.h>
 #include <linux/regulator/consumer.h>
 #include <linux/module.h>
+#include <linux/of.h>
 
 #include <sound/core.h>
 #include <sound/pcm.h>
 #include <sound/soc.h>
 
-#include <asm/mach-types.h>
 #include <linux/platform_data/asoc-ti-mcbsp.h>
 
 #include "omap-mcbsp.h"
@@ -223,7 +223,8 @@ static int __init omap3pandora_soc_init(void)
 {
 	int ret;
 
-	if (!machine_is_omap3_pandora())
+	if (!of_machine_is_compatible("openpandora,omap3-pandora-600mhz") &&
+		!of_machine_is_compatible("openpandora,omap3-pandora-1ghz"))
 		return -ENODEV;
 
 	pr_info("OMAP3 Pandora SoC init\n");
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] net: cpsw_new: unregister devlink on port registration failure

[Sasha Levin]

From: Guangshuo Li <lgs201920130244@gmail.com>

[ Upstream commit b64f763b607426ac97e44b114f0b8844ac3b86dd ]

cpsw_probe() registers devlink before registering the CPSW ports.

If cpsw_register_ports() fails, the error path only unregisters the
notifiers and then releases the lower level resources. It does not undo
the successful cpsw_register_devlink() call, leaving the devlink instance
and its parameters registered after probe has failed.

Add a devlink cleanup label for the path where devlink registration has
already succeeded, and use it when port registration fails.

Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Link: https://patch.msgid.link/20260604043115.1409134-1-lgs201920130244@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `net: cpsw_new: unregister devlink on port
registration failure`

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

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject line
**Record:** `[net: cpsw_new]` `[unregister]` — On
`cpsw_register_ports()` failure after successful devlink registration,
unregister the devlink instance instead of leaking it.

### Step 1.2: Tags
**Record:**
- **Reviewed-by:** Aleksandr Loktionov \<aleksandr.loktionov@intel.com\>
- **Reviewed-by:** Alexander Sverdlin \<alexander.sverdlin@siemens.com\>
  (reviewed prior stable-nominated error-path fixes in this driver)
- **Signed-off-by:** Guangshuo Li \<lgs201920130244@gmail.com\>
- **Link:** https://patch.msgid.link/20260604043115.1409134-1-
  lgs201920130244@gmail.com
- **Signed-off-by:** Jakub Kicinski \<kuba@kernel.org\>
- No Fixes:, Reported-by:, Tested-by:, Cc: stable@vger.kernel.org, or
  syzbot references
- v2 notes: subject updated for net-next; Fixes tag dropped

### Step 1.3: Body analysis
**Record:**
- **Bug:** `cpsw_probe()` registers devlink before ports. If
  `cpsw_register_ports()` fails, the error path unregisters notifiers
  but not devlink.
- **Symptom:** Orphaned devlink instance and registered devlink
  parameters after a failed probe.
- **Root cause:** Missing `cpsw_unregister_devlink()` on the port-
  registration failure path.
- **Version info:** None in the message; bug dates to devlink
  introduction in 2019.

### Step 1.4: Hidden bug fix?
**Record:** Yes. Described as cleanup, but it fixes a real resource-
management bug: devlink allocated with `devlink_alloc()` (not devm) is
never freed on this error path, and `dl_priv->cpsw` can dangle once devm
frees `cpsw`.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
**Record:**
- **File:** `drivers/net/ethernet/ti/cpsw_new.c` (+3 / -1)
- **Function:** `cpsw_probe()`
- **Scope:** Single-file surgical fix in one error path

### Step 2.2: Code flow change
**Record:**
- **Hunk 1 (line 2051):** `cpsw_register_ports()` failure: `goto
  clean_unregister_notifiers` → `goto clean_unregister_devlink`
- **Hunk 2 (lines 2063–2064):** New label `clean_unregister_devlink:`
  calling `cpsw_unregister_devlink(cpsw)` before the existing notifier
  cleanup chain

**Before:** Port registration failure skipped devlink teardown.
**After:** Port registration failure runs the same devlink cleanup as
`cpsw_remove()`.

### Step 2.3: Bug mechanism
**Record:** **Category:** Error-path resource leak (and potential UAF).
**Mechanism:** `cpsw_register_devlink()` calls `devlink_alloc()`,
`devlink_params_register()`, and `devlink_register()`. On port failure,
only notifiers were torn down. `cpsw` (devm) is freed on probe failure
while devlink (non-devm) remains registered with `dl_priv->cpsw`
pointing at freed memory.

### Step 2.4: Fix quality
**Record:** Obviously correct — mirrors `cpsw_remove()`. Minimal, no API
changes. Very low regression risk; only affects the
`cpsw_register_ports()` failure path.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
**Record:** Buggy `goto clean_unregister_notifiers` after
`cpsw_register_ports()` introduced in `ed3525eda4c49` (2019-11-20,
"introduce cpsw switchdev based driver part 1 - dual-emac"). Present in
this tree.

### Step 3.2: Fixes: tag
**Record:** N/A — no Fixes: tag (dropped in v2).

### Step 3.3: Related file history
**Record:** Recent related stable-nominated error-path fixes already in
this tree:
- `299b825716b82` — unnecessary netdev unregistration in `cpsw_probe()`
  error path (Cc: stable)
- `29739ec197ed6` — unregister of netdev not yet registered (Cc: stable)

Both fix `cpsw_probe()` error handling from the same original commit
(`Fixes: ed3525eda4c49`). This patch is a third, complementary error-
path fix.

### Step 3.4: Author context
**Record:** Guangshuo Li has no prior commits in `cpsw_new.c` in this
tree. Reviewer Alexander Sverdlin reviewed the Kevin Hao stable fixes
and this patch.

### Step 3.5: Dependencies
**Record:** Standalone. No series dependencies. Applies cleanly to this
tree (verified with `git apply --check`).

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Original discussion
**Record:** `b4 am 20260604043115.1409134-1-lgs201920130244@gmail.com`
found v2 patch thread. Lore/patch.msgid.link blocked by bot protection;
content retrieved from local mbox. No replies in mbox; b4 reported 14
code-review trailers on lore (content not directly readable). No
explicit stable nomination in the patch.

### Step 4.2: Reviewers
**Record:** Reviewed-by from Aleksandr Loktionov (Intel) and Alexander
Sverdlin (Siemens, prior reviewer of stable-nominated cpsw error-path
fixes).

### Step 4.3: Bug reports
**Record:** None. No syzbot, bugzilla, or user reports.

### Step 4.4: Related patches
**Record:** Part of ongoing `cpsw_probe()` error-path hardening
alongside Kevin Hao's v1 series (Feb 2026). Those fixes are already in
6.18.44; this one is not yet.

### Step 4.5: Stable list history
**Record:** Could not search lore stable list (bot protection).
Precedent: related fixes in the same function were explicitly `Cc:
stable@vger.kernel.org`.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key functions
**Record:** `cpsw_probe()`, `cpsw_register_devlink()`,
`cpsw_unregister_devlink()`, `cpsw_register_ports()`

### Step 5.2: Callers
**Record:** `cpsw_probe()` is the `platform_driver.probe` callback for
`cpsw_new` (TI CPSW on AM335x, AM4372, DRA7, etc.). Called during
platform device enumeration / module load.

### Step 5.3: Callees
**Record:** On failure path, fix adds `devlink_unregister()`,
`devlink_params_unregister()`, `devlink_free()` via
`cpsw_unregister_devlink()`.

### Step 5.4: Reachability
**Record:** Triggered when `register_netdev()` fails inside
`cpsw_register_ports()` during probe — uncommon but reachable on
boot/module load (ENOMEM, registration failure, etc.). Not userspace-
triggerable directly, but affects device bring-up.

### Step 5.5: Similar patterns
**Record:** `am65-cpsw-nuss.c` has its own devlink registration with
proper cleanup in remove; this fix addresses the parallel gap in
`cpsw_new.c` only.

---

## PHASE 6: CROSS-REFERENCING AGAINST LOCAL TREE

### Step 6.1: Buggy code present?
**Record:** **Yes.** In `cpsw_new.c` at lines 2049–2051:

```2049:2051:drivers/net/ethernet/ti/cpsw_new.c
        ret = cpsw_register_ports(cpsw);
        if (ret)
                goto clean_unregister_notifiers;
```

`clean_unregister_devlink` does not exist; devlink is not unregistered
on this path.

### Step 6.2: Backport complications
**Record:** Clean apply expected — `git apply --check` passed with no
conflicts.

### Step 6.3: Related fixes already present?
**Record:** Kevin Hao's netdev error-path fixes (`299b825716b82`,
`29739ec197ed6`) are in tree. This devlink cleanup fix is **not** yet
applied.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem criticality
**Record:** **drivers/net/ethernet/ti** — IMPORTANT for embedded TI
platforms (AM33xx, AM4372, DRA7). `CONFIG_TI_CPSW_SWITCHDEV` / module
`cpsw_new`.

### Step 7.2: Subsystem activity
**Record:** Active — multiple 2026 commits including error-path fixes
for this same probe function.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who is affected
**Record:** Users of TI CPSW (`cpsw_new`) on OMAP/AM33xx/AM4372/DRA7
platforms with `CONFIG_TI_CPSW_SWITCHDEV` enabled.

### Step 8.2: Trigger conditions
**Record:** `cpsw_register_ports()` → `register_netdev()` fails during
probe. Uncommon (boot/module-load error path). Not a normal runtime
path.

### Step 8.3: Failure mode severity
**Record:**
- **Primary:** Devlink memory leak; orphaned devlink registration and
  sysfs entries after failed probe
- **Secondary:** `dl_priv->cpsw` may point at devm-freed `cpsw` —
  potential UAF if devlink is accessed after failed probe
- **Severity:** **MEDIUM** — error-path only, rare trigger, but real
  resource bug with UAF potential; not a hot-path crash

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** MEDIUM — completes error-path cleanup already being fixed
  in this driver for stable
- **Risk:** VERY LOW — 3-line change, mirrors existing remove path
- **Ratio:** Favorable for backport

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence

**FOR backport:**
- Real bug present since 2019 in this tree
- Missing devlink cleanup on probe error path
- Non-devm devlink allocation leaked; dangling pointer to devm-freed
  `cpsw`
- Trivial, obviously correct fix; applies cleanly
- Reviewed by driver maintainers
- Same `cpsw_probe()` error path already received stable-nominated fixes
  in 6.18.44
- Matches stable pattern for probe error-path resource leaks

**AGAINST backport:**
- Only triggers on rare `register_netdev()` failure during probe
- No user reports, syzbot, or CVE
- Not a normal-operation crash
- No explicit Cc: stable on this patch

**Unresolved:** Full lore review thread content (bot-blocked); exact
severity if devlink sysfs is accessed post-failed-probe is inferred from
code, not reproduced.

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** — mirrors `cpsw_remove()`;
   reviewed by two maintainers
2. Fixes a real bug? **PASS** — devlink leak on probe failure
3. Important issue? **PASS (MEDIUM)** — resource leak with UAF potential
   on error path; not critical hot-path crash
4. Small and contained? **PASS** — 3 lines, one file
5. No new features/APIs? **PASS**
6. Can apply to local tree? **PASS** — bug present; patch applies
   cleanly

### Step 9.3: Exception categories
**Record:** N/A — standard error-path bug fix, not device
ID/quirk/build/doc exception.

### Step 9.4: Decision rationale

For **6.18.44**, the buggy code exists and has since devlink support
landed in 2019. The fix is minimal, correct, and consistent with stable-
nominated error-path fixes already merged for the same `cpsw_probe()`
function. While the trigger is uncommon, leaving devlink registered
after probe failure leaks resources and leaves a dangling `cpsw` pointer
inside devlink private data. This is appropriate stable material for
this tree.

---

## Verification

- **[Phase 1]** Parsed commit message and tags from user query and mbox
  file
- **[Phase 1]** v2 changelog: Fixes tag dropped; subject updated for
  net-next
- **[Phase 2]** Diff: +3/-1 in `cpsw_probe()`; adds
  `clean_unregister_devlink` label
- **[Phase 2]** Read `cpsw_register_devlink()` /
  `cpsw_unregister_devlink()` — non-devm `devlink_alloc()` with
  `dl_priv->cpsw = cpsw`
- **[Phase 3]** `git describe HEAD`: v6.18.44
- **[Phase 3]** `git blame -L 2045,2051`: buggy path from
  `ed3525eda4c49` (2019-11-20)
- **[Phase 3]** `git log --oneline -20 -- cpsw_new.c`: related stable
  fixes `299b825716b82`, `29739ec197ed6` present
- **[Phase 3]** `git log -S cpsw_register_devlink`: introduced in
  `ed3525eda4c49`
- **[Phase 3]** `git apply --check`: patch applies cleanly
- **[Phase 4]** `b4 am 20260604043115...`: found v2 patch; Reviewed-by
  tags confirmed
- **[Phase 4]** Lore/patch.msgid.link fetch: blocked by Anubis bot
  protection
- **[Phase 5]** Read `cpsw_register_ports()` — fails on
  `register_netdev()` error
- **[Phase 5]** `cpsw_remove()` calls `cpsw_unregister_devlink()` — fix
  matches remove path
- **[Phase 6]** Confirmed buggy `goto clean_unregister_notifiers` at
  lines 2049–2051 in current tree
- **[Phase 6]** `grep clean_unregister_devlink`: not present — fix not
  yet applied
- **[Phase 7]** Kconfig: `TI_CPSW_SWITCHDEV` selects `NET_DEVLINK`,
  module `cpsw_new`
- **[Phase 8]** UAF potential inferred from non-devm devlink + devm
  `cpsw` — not runtime-tested

**YES**

 drivers/net/ethernet/ti/cpsw_new.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/ti/cpsw_new.c b/drivers/net/ethernet/ti/cpsw_new.c
index c6cf7a0375e08..34c0e651e2da3 100644
--- a/drivers/net/ethernet/ti/cpsw_new.c
+++ b/drivers/net/ethernet/ti/cpsw_new.c
@@ -2048,7 +2048,7 @@ static int cpsw_probe(struct platform_device *pdev)
 
 	ret = cpsw_register_ports(cpsw);
 	if (ret)
-		goto clean_unregister_notifiers;
+		goto clean_unregister_devlink;
 
 	dev_notice(dev, "initialized (regs %pa, pool size %d) hw_ver:%08X %d.%d (%d)\n",
 		   &ss_res->start, descs_pool_size,
@@ -2060,6 +2060,8 @@ static int cpsw_probe(struct platform_device *pdev)
 
 	return 0;
 
+clean_unregister_devlink:
+	cpsw_unregister_devlink(cpsw);
 clean_unregister_notifiers:
 	cpsw_unregister_notifiers(cpsw);
 clean_cpts:
-- 
2.53.0