[PATCH AUTOSEL 6.18] net: ibm: emac: fix unchecked platform_get_irq return value
From: Sasha Levin
Date: Mon Aug 31 2026 - 14:56:30 EST
From: Rosen Penev <rosenp@xxxxxxxxx>
[ Upstream commit 1681cb1bde051c3b9ebbd337c0bfdd3e74167b2f ]
platform_get_irq() returns a negative errno on failure.
Commit a598f66d9169 replaced irq_of_parse_and_map() (which returns 0
on failure) with platform_get_irq() but dropped the error check.
Without it, a negative IRQ number is passed to devm_request_irq(),
which fails with -EINVAL instead of propagating the real error
from platform_get_irq().
Add the missing error check and goto err_gone.
Signed-off-by: Rosen Penev <rosenp@xxxxxxxxx>
Reviewed-by: Jacob Keller <jacob.e.keller@xxxxxxxxx>
Link: https://patch.msgid.link/20260601040201.103481-1-rosenp@xxxxxxxxx
Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx>
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
---
LLM Generated explanations, may be completely bogus:
## Phase 1: Commit Message Forensics
### Step 1.1: Subject Line
**Record:** `[net: ibm: emac]` `[fix]` — restore missing error checking
on `platform_get_irq()` return value in `emac_probe()`.
### Step 1.2: Tags
**Record:**
- **Fixes:** — not present (expected for manual review)
- **Reported-by:** — none
- **Tested-by:** — none
- **Reviewed-by:** Jacob Keller \<jacob.e.keller@xxxxxxxxx\>
- **Acked-by:** — none
- **Link:**
https://patch.msgid.link/20260601040201.103481-1-rosenp@xxxxxxxxx
- **Cc: stable:** — none (expected)
- **Signed-off-by:** Rosen Penev (author), Jakub Kicinski (net
maintainer); ignore pipeline-added SOBs
Notable: reviewed by a netdev reviewer; no syzbot/user reports.
### Step 1.3: Body Analysis
**Record:**
- **Bug:** Commit `a598f66d9169` switched from `irq_of_parse_and_map()`
(returns 0 on failure, with an explicit check) to `platform_get_irq()`
(returns negative errno on failure) but removed the error check.
- **Symptom:** A negative IRQ number is passed to `devm_request_irq()`,
which returns `-EINVAL` instead of the real errno from
`platform_get_irq()`.
- **Root cause:** API semantics mismatch during refactor — old API used
0 for failure; new API uses negative errnos and requires an explicit
check.
- **Version info:** Bug introduced by `a598f66d9169` ("net: ibm: emac:
use platform_get_irq"), present since v6.18 in this tree.
### Step 1.4: Hidden Bug Fix Detection
**Record:** Yes — despite the straightforward message, this is a
functional probe-path bug, not cosmetic cleanup. Mishandling
`-EPROBE_DEFER` can prevent deferred reprobing (verified against
`platform_get_irq()` / `platform_get_irq_optional()` in
`drivers/base/platform.c`).
---
## Phase 2: Diff Analysis
### Step 2.1: Inventory
**Record:**
- **File:** `drivers/net/ethernet/ibm/emac/core.c` (+5 lines)
- **Function:** `emac_probe()`
- **Scope:** Single-file, surgical fix in driver probe error path
### Step 2.2: Code Flow Change
**Record:**
- **Before:** `dev->emac_irq = platform_get_irq(...)` → immediately
`devm_request_irq(..., dev->emac_irq, ...)`
- **After:** If `dev->emac_irq < 0`, set `err = dev->emac_irq` and `goto
err_gone`; otherwise proceed to `devm_request_irq()`
- **Path affected:** IRQ setup during platform device probe,
specifically the failure path
### Step 2.3: Bug Mechanism
**Record:** **Category:** Error-path / API misuse / probe-deferral bug
- `platform_get_irq()` can return `-EPROBE_DEFER`, `-ENXIO`, etc.
- `request_irq()` path does `irq_to_desc(irq)`; invalid/negative IRQ →
`-EINVAL`
- Without the check, `-EPROBE_DEFER` becomes `-EINVAL`, breaking
deferred probe
- Even for permanent failures, wrong errno is returned and a misleading
second error is logged
### Step 2.4: Fix Quality
**Record:** Obviously correct; matches the documented
`platform_get_irq()` usage pattern in `drivers/base/platform.c`. Minimal
change, no API changes, very low regression risk.
---
## Phase 3: Git History Investigation
### Step 3.1: Blame
**Record:** Line 3045 (`platform_get_irq`) introduced by `a598f66d91693`
(Oct 2024). Prior code used `irq_of_parse_and_map()` with an explicit
`if (!dev->emac_irq)` check since 2007-era code.
### Step 3.2: Fixes: Tag
**Record:** N/A — no `Fixes:` tag. Manually identified introducing
commit `a598f66d9169`, confirmed present in this tree (`git merge-base
--is-ancestor` → YES).
### Step 3.3: Related File History
**Record:** Recent related commits in this tree:
- `a103cdb0681e7` — NULL deref fix (moved ioremap before `request_irq`;
already backported)
- `c09c2e236eef6` — UAF fix during device removal (already in tree)
- `a598f66d9169` — introduced the bug
- On net-next: `8084fc9292c2b` fixes the same class of bug in `mal.c`
(not in 6.18.y)
Standalone fix; not part of a multi-patch series.
### Step 3.4: Author Context
**Record:** Rosen Penev is an active contributor to IBM EMAC cleanup.
Multiple recent emac commits in this tree. Jacob Keller reviewed.
### Step 3.5: Dependencies
**Record:** No dependencies. Applies after `a103cdb0681e7` reordering
(`git apply --check` passes cleanly on current HEAD).
---
## Phase 4: Mailing List and External Research
### Step 4.1: Original Discussion
**Record:** `b4 dig -c 1681cb1bde051` found v1 only:
- https://patch.msgid.link/20260601040201.103481-1-rosenp@xxxxxxxxx
- No stable nomination found in thread
- No NAKs found
### Step 4.2: Reviewers
**Record:** `b4 dig -w` — CC'd netdev maintainers (Kicinski, Abeni,
Miller, etc.) and IBM EMAC reviewers (Horman, Nelson, Lunn).
### Step 4.3: Bug Reports
**Record:** No external bug report or syzbot link. Bug identified via
code review during driver cleanup.
### Step 4.4: Related Patches
**Record:** Companion fix `8084fc9292c2b` for `mal.c` same issue;
separate commit, not a prerequisite.
### Step 4.5: Stable List
**Record:** lore.kernel.org/stable search blocked by bot protection;
could not verify stable-list discussion.
---
## Phase 5: Code Semantic Analysis
### Step 5.1: Key Functions
**Record:** `emac_probe()` — only function modified.
### Step 5.2: Callers
**Record:** `emac_probe()` is the `platform_driver.probe` callback,
invoked during device enumeration/boot on platforms with
`CONFIG_IBM_EMAC`.
### Step 5.3: Callees
**Record:** `platform_get_irq()` → may call `of_irq_get()` → can return
`-EPROBE_DEFER`; `devm_request_irq()` → `request_irq()` → rejects
invalid IRQ numbers.
### Step 5.4: Reachability
**Record:** Triggered during EMAC device probe on PowerPC/embedded
systems with IBM EMAC in device tree. Boot-time path for affected
hardware.
### Step 5.5: Similar Patterns
**Record:** Same unchecked-`platform_get_irq` pattern exists in `mal.c`
(lines 635–645) in this tree; fixed upstream separately in
`8084fc9292c2b`.
---
## Phase 6: Cross-Reference Against Local Tree
### Step 6.1: Buggy Code Present?
**Record:** **YES.** Tree is `stable/linux-6.18.y` at **v6.18.44**.
Buggy code at line 3045 of `core.c` — no check after
`platform_get_irq()`. Introducing commit `a598f66d9169` is in tree since
v6.18. Fix commit `1681cb1bde051` is **NOT** in tree.
### Step 6.2: Backport Complications
**Record:** **Clean apply.** `git show 1681cb1bde051 | git apply
--check` succeeds on current HEAD despite intervening `a103cdb0681e7`
ioremap reorder.
### Step 6.3: Related Fixes Already Present?
**Record:** `a103cdb0681e7` (NULL deref / probe ordering) and
`c09c2e236eef6` (UAF) are in tree. This specific `platform_get_irq`
check is not.
---
## Phase 7: Subsystem Context
### Step 7.1: Subsystem Criticality
**Record:** `drivers/net/ethernet/ibm/emac` — **PERIPHERAL** (legacy IBM
PowerPC embedded Ethernet). Important for affected hardware, not
universal.
### Step 7.2: Activity
**Record:** Actively maintained in 2024–2026 with multiple devm/cleanup
commits and recent stable backports (`a103cdb0681e7`, `c09c2e236eef6`).
---
## Phase 8: Impact and Risk Assessment
### Step 8.1: Who Is Affected
**Record:** Users of `CONFIG_IBM_EMAC` on PowerPC/embedded platforms
with IBM EMAC in device tree.
### Step 8.2: Trigger Conditions
**Record:** When `platform_get_irq()` fails — missing/misconfigured IRQ
in DT, or IRQ not yet available (`-EPROBE_DEFER`). Uncommon on correctly
configured systems; realistic during boot ordering on deferred-probe
paths.
### Step 8.3: Failure Mode Severity
**Record:**
- **Without fix on `-EPROBE_DEFER`:** Probe returns `-EINVAL` instead of
deferring → driver may fail permanently → **no network on affected
hardware** (HIGH functional impact)
- **Without fix on `-ENXIO`:** Probe still fails, but wrong errno and
misleading log (MEDIUM)
- No crash, corruption, or security impact identified
### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** Restores correct probe deferral and errno propagation;
fixes regression from `a598f66d9169` already in 6.18.y
- **Risk:** Very low — 5-line error-path addition matching kernel API
documentation
- **Ratio:** Favorable for backport
---
## Phase 9: Final Synthesis
### Step 9.1: Evidence Summary
**FOR:**
- Real regression from `a598f66d9169` (in this tree)
- `-EPROBE_DEFER` → `-EINVAL` conversion breaks deferred probe
- Matches documented `platform_get_irq()` usage pattern
- Small, surgical, applies cleanly
- Reviewed-by on netdev
- Related emac probe fixes already backported to 6.18.y
**AGAINST:**
- Legacy driver, small user base
- On permanent IRQ failure, probe fails either way
- No user reports or syzbot findings
- Not crash/corruption class
**UNRESOLVED:**
- No stable-list discussion verified (lore blocked)
- No confirmed user report of deferral failure in the field
### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — matches API docs; reviewed;
trivial logic
2. Fixes a real bug? **PASS** — regression; broken `-EPROBE_DEFER`
handling
3. Important issue? **PASS** — probe deferral failure can prevent driver
binding/network on affected hardware
4. Small and contained? **PASS** — 5 lines, one file
5. No new features/APIs? **PASS**
6. Can apply to local tree? **PASS** — clean apply verified
### Step 9.3: Exception Categories
**Record:** None (not device ID, quirk, DT, build, or docs fix).
### Step 9.4: Decision Rationale
This is a regression fix for code already in linux-6.18.y. The missing
check can convert `-EPROBE_DEFER` into `-EINVAL`, causing permanent
probe failure instead of deferred retry — a real functional bug on the
boot/probe path. The fix is minimal, matches kernel API requirements,
applies cleanly, and carries negligible risk. While the driver serves a
niche platform, stable has already accepted other emac probe fixes for
this tree.
---
## Verification
- [Phase 1] Parsed subject, tags, body from provided commit message and
`git show 1681cb1bde051`
- [Phase 2] Diff analysis: +5 lines in `emac_probe()` after
`platform_get_irq()`
- [Phase 3] `git describe HEAD` → v6.18.44; `make kernelversion` →
6.18.44
- [Phase 3] `git blame -L 3040,3055` → `platform_get_irq` from
`a598f66d9169`
- [Phase 3] `git show a598f66d9169` → removed `irq_of_parse_and_map`
error check
- [Phase 3] `git merge-base --is-ancestor a598f66d9169 HEAD` → YES
- [Phase 3] `git merge-base --is-ancestor 1681cb1bde051 HEAD` → NO (fix
not in tree)
- [Phase 3] `git log --oneline -20 --
drivers/net/ethernet/ibm/emac/core.c` → related history
- [Phase 4] `b4 dig -c 1681cb1bde051` → lore URL found, v1 only
- [Phase 4] `b4 dig -c 1681cb1bde051 -w` → netdev maintainers CC'd
- [Phase 4] `b4 dig -c 1681cb1bde051 -m /tmp/emac_irq_thread.mbox` →
thread saved, Reviewed-by Keller
- [Phase 4] lore stable search → blocked by bot protection (UNVERIFIED
for stable-list discussion)
- [Phase 5] Read `platform_get_irq()` / `platform_get_irq_optional()` in
`drivers/base/platform.c` → can return `-EPROBE_DEFER`; docs require
`if (irq < 0) return irq`
- [Phase 5] Read `request_threaded_irq()` in `kernel/irq/manage.c` →
`irq_to_desc(irq)` returns NULL for invalid IRQ → `-EINVAL`
- [Phase 5] Grep `emac_probe` callers → platform driver probe callback
- [Phase 6] Read current `core.c` lines 3038–3058 → buggy code confirmed
present
- [Phase 6] `git show 1681cb1bde051 | git apply --check` → applies
cleanly
- [Phase 6] `git show a103cdb0681e7` → different fix (ioremap ordering),
already in tree
- [Phase 8] `git tag --contains a598f66d9169` → present since v6.18
- [Phase 8] Grep `platform_get_irq` in emac → also unchecked in `mal.c`
(separate upstream fix `8084fc9292c2b`, not in tree)
**YES**The branch search finished successfully. On `net-next/master` it
found:
- **`1681cb1bde051`** — `net: ibm: emac: fix unchecked platform_get_irq
return value` (the commit under review)
- **`8084fc9292c2b`** — the companion fix for the same issue in `mal.c`
Neither is in the local **linux-6.18.y** tree at v6.18.44; the buggy
unchecked `platform_get_irq()` call is still present in `core.c`. The
analysis conclusion stands: **YES** for backport.
drivers/net/ethernet/ibm/emac/core.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/ibm/emac/core.c b/drivers/net/ethernet/ibm/emac/core.c
index f48568140480e..074cc6d1050eb 100644
--- a/drivers/net/ethernet/ibm/emac/core.c
+++ b/drivers/net/ethernet/ibm/emac/core.c
@@ -3044,6 +3044,11 @@ static int emac_probe(struct platform_device *ofdev)
/* Setup error IRQ handler */
dev->emac_irq = platform_get_irq(ofdev, 0);
+ if (dev->emac_irq < 0) {
+ err = dev->emac_irq;
+ goto err_gone;
+ }
+
err = devm_request_irq(&ofdev->dev, dev->emac_irq, emac_irq, 0, "EMAC",
dev);
if (err) {
--
2.53.0