[PATCH AUTOSEL 7.0-5.15] leds: lgm-sso: Fix typo in macro for src offset

[PATCH AUTOSEL 7.0-5.15] leds: lgm-sso: Fix typo in macro for src offset

[Sasha Levin]

From: Lukas Kraft <rebootrequired42@gmail.com>

[ Upstream commit 0e2287999f0432b51a54c235db660789ca657f53 ]

Replace unused argument pinc with used argument pin.

Signed-off-by: Lukas Kraft <rebootrequired42@gmail.com>
Link: https://patch.msgid.link/20260312210958.48467-1-rebootrequired42@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have enough information to do a complete analysis. Let me write it
up.

## Commit Analysis

### PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject line parse**
Record: Subsystem: `leds/lgm-sso`; Action verb: "Fix"; Summary: Fix typo
in macro parameter name (`pinc` -> `pin`).

**Step 1.2: Tags**
Record:
- Signed-off-by: Lukas Kraft (author - first-time contributor based on
  git log)
- Link: https://patch.msgid.link/20260312210958.48467-1-
  rebootrequired42@gmail.com
- Signed-off-by: Lee Jones (subsystem maintainer, committer)
- No `Fixes:` tag (expected - that's why it needs review)
- No `Cc: stable@vger.kernel.org`
- No `Reported-by:`, `Tested-by:`, or `Reviewed-by:`

**Step 1.3: Commit body**
Record: Minimal message: "Replace unused argument pinc with used
argument pin." No explanation of user-visible impact, no reproduction
steps, no stack traces. Author appears to have noticed this through code
inspection.

**Step 1.4: Hidden bug fix detection**
Record: The subject explicitly says "Fix typo". The body describes it as
replacing "unused argument pinc with used argument pin" - this IS a real
bug fix (not hidden), but the commit undersells the impact. The typo
means the macro body references `pin` from the caller's scope instead of
the macro argument, producing incorrect register bit positions.

### PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
Record: 1 file (`drivers/leds/blink/leds-lgm-sso.c`), 1 line changed (1
deletion, 1 addition). Surgical, minimal scope.

**Step 2.2: Code flow change**
Record:
- Before: `#define GET_SRC_OFFSET(pinc)    (((pin) * 6) + 4)` —
  parameter `pinc` is unused; `pin` in body is resolved from the
  enclosing scope at macro expansion time.
- After: `#define GET_SRC_OFFSET(pin)    (((pin) * 6) + 4)` — parameter
  `pin` now matches the identifier in the body, so the macro argument is
  used.

**Step 2.3: Bug mechanism**
Record: Category (g) "Logic / correctness fix." The macro has a single
call site at line 226: `low = GET_SRC_OFFSET(off);` inside
`sso_led_freq_set(struct sso_led_priv *priv, u32 pin, int freq_idx)`.
The function has a local parameter named `pin`. With the buggy macro,
`(((pin) * 6) + 4)` captures the function's `pin` parameter instead of
the macro argument `off`. This produces completely different values:
- Buggy: for pin=25, computes 25*6+4 = 154
- Fixed: for off=1 (pin 25 in group 1), computes 1*6+4 = 10

The `low`/`high` values feed into `GENMASK(high, low)` and `freq_src <<
high` at lines 228-229, used by `regmap_update_bits()` to set clock-
source bits in the LED_BLINK_H8_0/1 register. With `low > 32` the
shift/GENMASK produce undefined/wrong values, so the clock source for
hardware LED blinking is written to wrong register bits (or not written
at all).

**Step 2.4: Fix quality**
Record: Trivial correctness fix. Zero regression risk - the old macro
parameter `pinc` was unused, so no caller relied on its name. The
callsite passes `off`, and the fix makes the macro correctly use that
argument.

### PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
Record: The buggy line was introduced in commit `c3987cd2bca34` ("leds:
lgm: Add LED controller driver for LGM SoC") by Amireddy Mallikarjuna
reddy, dated 2020-12-10, first appearing in **v5.12-rc1**. Bug has been
present for ~5 years in all stable trees.

**Step 3.2: Follow Fixes: tag**
Record: No `Fixes:` tag in commit, but blame identifies introducing
commit as `c3987cd2bca34ddfec69027acedb2fae5ffcf7a0` - present in v5.12
and every subsequent release including all active LTS trees.

**Step 3.3: File history**
Record: Recent changes are unrelated refactors (GPIO callback renames,
error-code propagation, clock-handling fixes). The macro has been
untouched since the initial driver commit.

**Step 3.4: Author context**
Record: Lukas Kraft is apparently a first-time contributor (no other
commits under this email in the repo). The committer/maintainer Lee
Jones applied it directly via b4 tooling (see the "Applied, thanks!"
reply in the mbox).

**Step 3.5: Dependencies**
Record: No dependencies. Standalone, single-line change.

### PHASE 4: MAILING LIST RESEARCH

**Step 4.1: Original submission**
Record: `b4 dig -c 0e2287999f04` resolved to https://lore.kernel.org/all
/20260312210958.48467-1-rebootrequired42@gmail.com/. Single revision
(v1). The maintainer (Lee Jones) replied with "Applied, thanks!"
directly via `b4-ty`. No review comments or feedback.

**Step 4.2: Reviewers**
Record: Thread shows submission to `lee@kernel.org` (Lee Jones, LED
maintainer) and `pavel@kernel.org` (Pavel Machek, LED maintainer), CC to
linux-leds and linux-kernel. Applied by Lee Jones.

**Step 4.3: Bug report**
Record: No `Reported-by:` or bug report linked. Author discovered via
code inspection.

**Step 4.4: Related patches**
Record: Standalone patch, not part of a series.

**Step 4.5: Stable mailing list**
Record: No prior stable discussion found.

### PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Key functions**
Record: `GET_SRC_OFFSET` macro; used only in `sso_led_freq_set()`.

**Step 5.2: Callers of affected code**
Record: `sso_led_freq_set()` is called from:
- `sso_led_blink_set()` (line 315) - the LED class `.blink_set`
  callback, invoked from userspace via
  `/sys/class/leds/*/delay_on|delay_off`
- `sso_led_hw_cfg()` (line 331) - called from `sso_create_led()` during
  probe, only if `desc->hw_blink` is set (DT property `intel,sso-hw-
  blink`)

**Step 5.3: Callees**
Record: The function calls `regmap_update_bits()` to set bits in the
LED_BLINK_H8_0/LED_BLINK_H8_1 hardware registers.

**Step 5.4: Call chain reachability**
Record: Reachable from userspace via sysfs if `intel,sso-hw-blink` DT
property is set. Also executed at probe time for every LED configured
with hw_blink. Triggers on pins 24-31 only (group 0 returns early at
line 205).

**Step 5.5: Similar patterns**
Record: The adjacent macro `GET_FREQ_OFFSET(pin, src)` is correct,
making the typo in `GET_SRC_OFFSET` clearly a one-off error. I confirmed
the bug with a small C test program: `GET_SRC_OFFSET(off=1)` returns 154
(buggy, using pin=25) vs. 10 (fixed). The fixed value is coherent with
`GET_FREQ_OFFSET`'s result of 8 - they sit next to each other in the
register bitmap.

### PHASE 6: CROSS-REFERENCING STABLE TREES

**Step 6.1: Does buggy code exist in stable?**
Record: Verified bug present in v5.15, v6.1, v6.6, v6.12 (all active LTS
trees) - the macro has identical buggy form. The file path
`drivers/leds/blink/leds-lgm-sso.c` has been stable since introduction.

**Step 6.2: Backport complications**
Record: File structure in the area of the patch is unchanged across
stable trees. The fix should apply cleanly to all active LTS trees
(5.15.y through 6.12.y) and current 6.17+/6.18+ trees.

**Step 6.3: Related fixes in stable**
Record: No related fix is already in stable for this issue.

### PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1: Subsystem criticality**
Record: `drivers/leds/blink/` - LED blink drivers. PERIPHERAL
criticality. Affects only systems using Intel Lightning Mountain (LGM)
SoC, a networking SoC used primarily in home routers and gateway
devices.

**Step 7.2: Subsystem activity**
Record: Low-to-moderate activity. Recent changes are treewide refactors
affecting this driver as a bystander (GPIO callback renames, platform
driver API changes).

### PHASE 8: IMPACT AND RISK

**Step 8.1: Affected population**
Record: DRIVER-SPECIFIC. Only systems with CONFIG_LEDS_LGM=y (or =m) AND
Intel LGM SoC AND `intel,sso-hw-blink` set for LEDs on pins 24-31. A
narrow but real user population (Intel LGM-based routers/gateways).

**Step 8.2: Trigger conditions**
Record: Triggered at LED probe (hw_cfg path) if hw_blink is enabled in
DT, or at runtime when userspace writes to
`/sys/class/leds/*/delay_on|delay_off` for an LED with hw_blink. No
privilege required for the sysfs path. Not a race - deterministic
behavior.

**Step 8.3: Failure mode severity**
Record: MEDIUM (low). Incorrect register bits are programmed for clock-
source selection of hardware LED blink, meaning LEDs may blink at the
wrong rate, wrong clock source, or fail to blink via the hardware path.
No crash, no data corruption, no security issue. Purely
functional/hardware-correctness issue.

**Step 8.4: Risk-benefit**
Record:
- BENEFIT: Low-to-medium. Fixes real hardware register miscalculation on
  LGM systems. Narrow user base but real correctness fix.
- RISK: Very low. 1-line macro parameter rename; the old parameter was
  unused; call site is single and clearly correct with the fix.
- Ratio: Benefit >> risk, but benefit is not high in absolute terms.

### PHASE 9: SYNTHESIS

**Step 9.1: Evidence**
- FOR: Clear, obvious bug fix; fixes a real register-computation error;
  trivial 1-line change; zero regression risk; applies cleanly to all
  stable trees; confirmed with a reproduction test; bug has existed
  since v5.12 in all LTS trees.
- AGAINST: No user reports; no Cc: stable; no Fixes: tag; narrow
  hardware (Intel LGM SoC); severity is "functional correctness" not
  crash/security/corruption; commit message undersells/doesn't explain
  the real user impact; single-line commit with no Reviewed-by.
- UNRESOLVED: None material.

**Step 9.2: Stable rules checklist**
1. Obviously correct? YES - trivial typo fix, verified by reproduction
2. Fixes real bug? YES - macro silently uses wrong value
3. Important issue (crash/security/corruption/deadlock)? NO - only
   incorrect LED hardware blink programming
4. Small and contained? YES - 1 line
5. No new features/APIs? YES
6. Applies cleanly? YES

**Step 9.3: Exception categories**
Record: Could qualify as a "build/correctness fix" for a specific
driver, similar to a hardware quirk fix. Not a pure exception category,
but a trivially correct bug fix.

**Step 9.4: Decision**
This is a genuine, trivially-correct bug fix for incorrect register-bit
computation affecting hardware LED blink on Intel LGM SoCs. The fix is 1
line with zero regression risk, applies cleanly to all stable trees, and
has been in a buggy state since v5.12. The user-visible impact is narrow
(LGM-based networking hardware with hw_blink) and the failure mode is
non-critical (wrong LED blink behavior, not
crashes/corruption/security). It doesn't meet the "important issue"
threshold strictly, but it is exactly the category of "small, obvious
bug fixes" that stable rules welcome.

## Verification

- [Phase 1] Parsed subject/tags: single `Signed-off-by: Lukas Kraft` +
  committer Lee Jones; no Reported-by/Tested-by/Fixes/Cc: stable.
  Confirmed by reading the commit header.
- [Phase 2] Diff analysis: confirmed single 1-line change to macro
  parameter name in `drivers/leds/blink/leds-lgm-sso.c` line 28.
- [Phase 2] Semantic analysis: compiled a small C test
  `/tmp/test_macro.c` demonstrating that the buggy macro produces 154
  (using the captured `pin=25`) while the fixed macro produces 10 (using
  argument `off=1`).
- [Phase 3] git blame -L 28,28: buggy macro introduced by
  `c3987cd2bca34` ("leds: lgm: Add LED controller driver for LGM SoC"),
  2020-12-10, first release v5.12-rc1.
- [Phase 3] git describe --contains c3987cd2bca34 → `v5.12-rc1~17^2~9` -
  confirmed v5.12 is the origin.
- [Phase 3] git log --author="rebootrequired42@gmail.com": no prior
  commits by this author - first-time contributor.
- [Phase 3] git log on file: no dependencies; standalone patch.
- [Phase 4] b4 dig -c 0e2287999f04: found original submission at https:/
  /lore.kernel.org/all/20260312210958.48467-1-
  rebootrequired42@gmail.com/
- [Phase 4] b4 dig -a: v1 only, no evolution.
- [Phase 4] Read /tmp/leds-lgm/thread.mbox: confirmed Lee Jones (LED
  subsystem maintainer) applied it directly via b4-ty without additional
  review comments; no reviewer objections or stable suggestions.
- [Phase 5] grep GET_SRC_OFFSET in the file: single caller at line 226
  inside `sso_led_freq_set`, which has `u32 pin` as function parameter
  (confirming the macro body references this parameter in the buggy
  form).
- [Phase 5] Traced call chain: `sso_led_freq_set` → called from
  `sso_led_blink_set` (sysfs blink_set callback) and `sso_led_hw_cfg`
  (probe-time setup when hw_blink is set).
- [Phase 6] git show v5.15:drivers/leds/blink/leds-lgm-sso.c | grep
  GET_SRC_OFFSET: confirmed bug present in v5.15 with identical form.
- [Phase 6] Same verification for v6.1, v6.6, v6.12 - all have the
  identical buggy macro and file location.
- [Phase 8] Failure mode: `GENMASK(h, l)` with l > BITS_PER_LONG is
  undefined; `val << high` with high > 31 on u32 is also undefined per C
  standard. Verified the computed low/high values are out of 32-bit
  register range for all LGM-valid pins (24-31) via my test program.
- UNVERIFIED: I did not build and boot on LGM hardware to confirm the
  LED blink misbehavior in practice; my assessment relies on code
  analysis of the register interactions.

## Summary

This is a real, trivially-correct 1-line bug fix for a 5-year-old macro
typo in the Intel LGM SoC LED driver. The macro parameter name (`pinc`)
didn't match the identifier in its body (`pin`), so the macro silently
captured the function's `pin` parameter instead of the argument passed.
This causes incorrect register-bit computation in `regmap_update_bits()`
during hardware LED blink setup, affecting LEDs on pins 24-31 of the
Intel Lightning Mountain SoC.

The fix is obviously correct, zero-risk, applies cleanly to all stable
trees (5.15.y, 6.1.y, 6.6.y, 6.12.y), and the bug exists in all of them.
The impact is narrow (specific SoC hardware) and severity is moderate
(incorrect hardware register programming, not
crashes/security/corruption), but the patch is exactly the small,
obviously correct fix that stable policy welcomes.

**YES**

 drivers/leds/blink/leds-lgm-sso.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/leds/blink/leds-lgm-sso.c b/drivers/leds/blink/leds-lgm-sso.c
index 8923d2df47049..99cfb8c1bb3f8 100644
--- a/drivers/leds/blink/leds-lgm-sso.c
+++ b/drivers/leds/blink/leds-lgm-sso.c
@@ -25,7 +25,7 @@
 #define LED_BLINK_H8_0			0x0
 #define LED_BLINK_H8_1			0x4
 #define GET_FREQ_OFFSET(pin, src)	(((pin) * 6) + ((src) * 2))
-#define GET_SRC_OFFSET(pinc)		(((pin) * 6) + 4)
+#define GET_SRC_OFFSET(pin) 		(((pin) * 6) + 4)
 
 #define DUTY_CYCLE(x)			(0x8 + ((x) * 4))
 #define SSO_CON0			0x2B0
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] leds: core: Implement fallback to software node name for LED names

[Sasha Levin]

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

[ Upstream commit 4f530c65487636dc1536b3fa1041f9a877a66a7f ]

If a software node defining an LED is missing explicit 'label', 'color',
or 'function' properties, led_compose_name() currently fails with
-EINVAL, because fallback to using node name in place of LED name/label
is only implemented for OF nodes.

Implement similar fallback for software nodes. Unlike OF nodes, which
use the short 'name' attribute of the device tree node to avoid
including the address block, use fwnode_get_name() directly since
swnodes do not include an address block and always have a valid name.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://patch.msgid.link/20260311-led-swnode-name-v1-1-798a49e041c6@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have enough information for a complete analysis.

# Analysis: leds: core: Implement fallback to software node name for LED
names

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject line
Record: `[leds: core]` `[Implement]` `[fallback to software node name
for LED names]`. The verb "Implement" suggests adding missing
functionality, but the commit body describes fixing an -EINVAL failure,
making this a bug fix in substance.

### Step 1.2: Tags
Record:
- Signed-off-by: Dmitry Torokhov (author)
- Signed-off-by: Lee Jones (LED subsystem maintainer)
- Link: `https://patch.msgid.link/20260311-led-swnode-
  name-v1-1-798a49e041c6@gmail.com`
- No `Fixes:` tag
- No `Cc: stable` tag
- No `Reported-by` / `Tested-by` / `Reviewed-by` tags

### Step 1.3: Body text
Record: Bug description: "If a software node defining an LED is missing
explicit 'label', 'color', or 'function' properties,
`led_compose_name()` currently fails with -EINVAL." Author explicitly
describes a failure mode. Root cause: OF-only fallback. Fix: use
`fwnode_get_name()` for software nodes.

### Step 1.4: Hidden bug fix
Record: The verb "Implement" reads like a feature addition, but the
commit body explicitly says the existing code "fails with -EINVAL" -
this is a bug fix disguised as a feature implementation. Pattern "Handle
X properly" / missing error-path fallback.

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
Record: 1 file changed (`drivers/leds/led-core.c`), 3 lines added, 0
removed. Single function modified: `led_compose_name()`. Scope: single-
file surgical fix.

### Step 2.2: Code flow change
Record: Before: if fwnode is software_node (not OF) and lacks
label/color/function properties → return -EINVAL. After: if
software_node, use `fwnode_get_name(fwnode)` as the LED classdev name
(same fallback pattern as OF nodes).

### Step 2.3: Bug mechanism
Record: Category (h) hardware-workaround-ish / (g) logic-correctness.
The `led_compose_name` fallback chain was incomplete: it handled OF-node
fallback (`to_of_node(fwnode)->name`) but didn't handle the
`is_software_node()` case, causing LED registration to fail for drivers
that describe LEDs via software nodes with only a `.name` field. Fix
adds the missing `else if (is_software_node(fwnode))` branch.

### Step 2.4: Quality
Record: Obviously correct - mirrors the OF pattern. Uses
`fwnode_get_name()` which for swnodes resolves to
`kobject_name(&swnode->kobj)` (always valid for registered swnodes). No
regression risk: only affects a path that previously returned -EINVAL.

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: git blame
Record: The `is_of_node(fwnode)` OF fallback was added by
`bb4e9af0348df` (Jun 2019, v5.4-rc1) - "leds: core: Add support for
composing LED class device names". The swnode gap has existed since 2019
but was latent until drivers began using swnodes for LEDs without a
"label" property.

### Step 3.2: Fixes: tag
Record: No Fixes: tag. Most relevant trigger commit: `4e0bcbd270e88`
("platform/x86: barco-p50-gpio: use software nodes for gpio-leds/keys")
merged in v6.18-rc1, which defined an LED swnode with only `.name =
"identify"` and no label/color/function properties. Verified via `git
describe --contains 4e0bcbd270e88` → `v6.18-rc1~82^2~2`.

### Step 3.3: Related recent changes
Record: `git log --oneline -- drivers/leds/led-core.c` shows last change
was `ee44a1def7ee4` in v6.16-rc1 ("leds: core: Bail out when composed
name can't fit the buffer"). No conflicting changes in stable range.

### Step 3.4: Author
Record: Dmitry Torokhov is a prolific input/driver maintainer; has
landed other swnode conversions recently (`4e0bcbd270e88` barco,
`b8754092dfed4` pcengines-apuv2). Strong familiarity with swnode
plumbing. Applied by Lee Jones (LED subsystem maintainer).

### Step 3.5: Dependencies
Record: `is_software_node()` and `fwnode_get_name()` have been stable
APIs in the fwnode infrastructure for years. No prerequisite patches.
Standalone fix.

## PHASE 4: MAILING LIST RESEARCH

### Step 4.1-4.2: Thread investigation
Record: Used `b4 mbox -o /tmp/b4-dig 20260311-led-swnode-
name-v1-1-798a49e041c6@gmail.com` to retrieve the thread (8 messages).
Patch is [PATCH 1/2] of "Fall back to using software node name as LED
name" series. Maintainer Lee Jones applied both patches: "Applied,
thanks! [1/2] commit: 4f530c65487636dc1536b3fa1041f9a877a66a7f [2/2]
commit: 91dc0c2a152373c4004df7e36de45190b82089ab". No NAKs. Initial
application failed due to conflict with patch 2/2 formatting changes -
author resent after rebase. No stable nomination in thread. Cover letter
motivation: "helpful when converting old boards using bespoke platform
data to software nodes/static device properties."

### Step 4.3-4.5: Bug report / stable discussion
Record: No `Reported-by:` tag, no linked syzbot/bugzilla. No explicit
stable discussion observed in the thread.

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Functions modified
Record: `led_compose_name()` only.

### Step 5.2: Callers
Record: `led_compose_name` is called by:
- `drivers/leds/led-class.c:498` (`led_classdev_register_ext`) - the
  main registration path used by dozens of LED drivers
- `drivers/pci/npem.c:498` - PCI NPEM LED registration

`led_classdev_register_ext` is called from ~70+ LED drivers via
`devm_led_classdev_register_ext`, including `drivers/leds/leds-
gpio.c:create_gpio_led` which is the specific path exercised by
barco-p50-gpio.

### Step 5.3: Callees
Record: `is_software_node()`, `fwnode_get_name()`, `snprintf()` - all
well-established.

### Step 5.4: Call chain / reachability
Record: Reachable from platform device probe paths. Specifically: `leds-
gpio` probe → `gpio_leds_create()` → `create_gpio_led()` (with
`template->name = NULL`) → `devm_led_classdev_register_ext()` →
`led_classdev_register_ext()` → `led_compose_name()`. Triggered on every
boot for affected hardware.

### Step 5.5: Similar patterns
Record: Verified `drivers/platform/x86/barco-p50-gpio.c` at v7.0 has
`identify_led_node` with `.name = "identify"` and `identify_led_props`
containing only `PROPERTY_ENTRY_GPIO` (no label/color/function). Other
swnode LED users (`meraki-mx100`, `pcengines-apuv2`, `x86-android-
tablets`) include `PROPERTY_ENTRY_STRING("label", ...)` so they work
without this fix.

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Code in stable trees
Record: The `led_compose_name()` function exists in all active stable
branches. Verified `git show v6.12:drivers/leds/led-core.c` and
`v6.6:drivers/leds/led-core.c` both have identical `else if
(is_of_node(fwnode)) { ... } else return -EINVAL;` pattern. The bug
(swnode fallback gap) exists in every version since v5.4. However, the
practical USER-VISIBLE bug (barco-p50-gpio LED not registering) only
appears starting in v6.18 (via `4e0bcbd270e88`). Before v6.18, barco
used `gpio_led_platform_data` with `.name = "identify"`, which bypasses
`led_compose_name` entirely (via the `if (template->name)` branch in
`create_gpio_led`).

### Step 6.2: Backport difficulty
Record: `git log --oneline v6.19..v7.0 -- drivers/leds/led-core.c` →
empty. File is stable. Clean apply expected for v6.18.y+ (where the
regression exists). For older stable trees (6.6, 6.12), the fix is a no-
op improvement (no driver there triggers the path) but still applies
cleanly.

### Step 6.3: Related fixes in stable
Record: None found. No other approach to the same bug observed.

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem
Record: `drivers/leds/` - LED class core. Criticality: IMPORTANT (common
driver infrastructure used by many hardware drivers). Failure mode here
is driver-specific rather than core-kernel.

### Step 7.2: Activity
Record: `drivers/leds/led-core.c` receives only a handful of changes per
release. Mature, stable code.

## PHASE 8: IMPACT AND RISK

### Step 8.1: Affected users
Record: Users of hardware whose drivers describe LEDs via software nodes
without `label`/`color`/`function` properties. Concretely: Barco P50
board (`barco-p50-gpio`) in v6.18+ - identify LED fails to register.
Platform-specific (niche hardware).

### Step 8.2: Trigger conditions
Record: Triggered every boot on affected hardware. No privilege needed -
happens automatically during probe.

### Step 8.3: Failure severity
Record: LED fails to register (returns -EINVAL during probe). Severity:
LOW-MEDIUM. No crash, no data loss, no security issue. Functional
regression: identify LED on Barco P50 doesn't appear in /sys/class/leds.
For most users this is a minor annoyance; for Barco P50 appliance users,
the identify-button LED feature is broken.

### Step 8.4: Risk-benefit
Record:
- Benefit: LOW-MEDIUM (fixes functional regression on specific hardware,
  v6.18+ only)
- Risk: VERY LOW (3-line mirror of existing OF logic, only affects a
  path that previously returned -EINVAL)
- Ratio: Favorable - very cheap fix for real regression

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence
FOR backporting:
- Commit body explicitly describes an -EINVAL failure (bug fix in
  substance)
- Fixes a functional regression in v6.18+ (barco-p50-gpio identify LED)
- Small (3 lines), surgical, single file
- Mirrors existing OF-node fallback logic (obviously correct)
- Applied by the LED subsystem maintainer after review on the list
- Very low regression risk - only affects paths that previously returned
  -EINVAL
- Trigger is deterministic (boot-time probe) so any affected users hit
  it every boot

AGAINST backporting:
- No `Fixes:` tag linking to `4e0bcbd270e88`
- No `Cc: stable` tag
- No `Reported-by:` (no cited user complaint)
- Commit message framed as "helpful" for future conversions rather than
  "fix"
- Affected hardware is niche (Barco P50 appliance)
- Non-critical failure (no crash/corruption/security)

### Step 9.2: Stable rules checklist
1. Obviously correct and tested: YES - trivial mirror of existing OF
   branch, accepted by LED maintainer.
2. Fixes real bug: YES - barco-p50-gpio LED registration fails in
   v6.18+.
3. Important issue: BORDERLINE - functional regression but not
   crash/security/corruption.
4. Small and contained: YES - 3 lines, one file, one function.
5. No new features/APIs: YES - no new interfaces; fills a missing
   fallback.
6. Applies cleanly to stable: YES - the file is stable across recent
   versions.

### Step 9.3: Exception category
Record: Partial match to "hardware enablement / driver fix for existing
hardware". The fix makes an in-tree driver (barco-p50-gpio, present
since v5.16, swnode-converted in v6.18) actually work.

### Step 9.4: Decision
The commit fixes a real, deterministic functional regression introduced
into v6.18 by commit `4e0bcbd270e88`. Although the failure is not a
crash or security issue, it is a clean-cut boot-time driver probe
failure that users will hit every boot on affected hardware. The fix is
minimal (3 lines), obviously correct (mirrors the existing OF-node
fallback), safe (cannot break previously-working configurations since it
only covers a path that previously returned -EINVAL), and was accepted
by the subsystem maintainer.

The absence of `Fixes:`/`Cc: stable` tags is exactly what AUTOSEL exists
to catch. Weight of evidence favors backport, particularly to v6.18.y
and v6.19.y where the regression actually manifests. For earlier trees
the fix is a safe no-op improvement that still applies cleanly.

## Verification
- [Phase 1] Parsed tags from commit message: no `Fixes:`, no `Cc:
  stable`, no `Reported-by:`; only `Signed-off-by:` from author (Dmitry
  Torokhov) and LED maintainer (Lee Jones); `Link:` to
  `patch.msgid.link` for `20260311-led-swnode-
  name-v1-1-798a49e041c6@gmail.com`.
- [Phase 2] Read `drivers/leds/led-core.c` (617 lines, current v7.0):
  confirmed `led_compose_name` structure - `is_of_node(fwnode)` branch
  (line 581) falls back to `to_of_node(fwnode)->name`, `else return
  -EINVAL` (line 585). Diff adds 3 lines of `else if
  (is_software_node(fwnode))` branch using `fwnode_get_name(fwnode)`.
- [Phase 3] `git blame drivers/leds/led-core.c -L 574,592`: `is_of_node`
  fallback dates to `bb4e9af0348dfe` (2019, Jacek Anaszewski) - "leds:
  core: Add support for composing LED class device names".
- [Phase 3] `git describe --contains 4e0bcbd270e88` →
  `v6.18-rc1~82^2~2`: confirms barco swnode conversion landed in v6.18.
- [Phase 3] `git show
  4e0bcbd270e88^:drivers/platform/x86/barco-p50-gpio.c`: confirmed
  pre-v6.18 barco used `gpio_led_platform_data` with `.name =
  "identify"`, bypassing `led_compose_name`.
- [Phase 3] `git show v6.6:drivers/platform/x86/barco-p50-gpio.c`: still
  uses `gpio_led_platform_data`, not swnodes - so regression does NOT
  exist in v6.6.y.
- [Phase 3] `git log --oneline -- drivers/leds/led-core.c`: last change
  `ee44a1def7ee4` in v6.16-rc1; no churn in v6.18..v7.0.
- [Phase 4] `b4 mbox -o /tmp/b4-dig 20260311-led-swnode-name-v1-1-...`:
  retrieved 8-message thread. Lee Jones replied "Applied, thanks!" and
  listed commit hash `4f530c65487636dc1536b3fa1041f9a877a66a7f` for
  patch 1/2. Initial application failed (conflict with patch 2/2
  formatting), author re-submitted.
- [Phase 4] Read thread: no `Cc: stable` suggestion, no NAKs, no
  Reported-by reference; author frames the change as "helpful when
  converting old boards."
- [Phase 5] Read `drivers/leds/leds-gpio.c`: confirmed
  `gpio_leds_create()` passes `struct gpio_led led = {}` (name == NULL)
  into `create_gpio_led`, forcing the fwnode path with `init_data =
  {.fwnode = fwnode}` - the exact path that hits `led_compose_name` and
  fails without this fix.
- [Phase 5] Read `drivers/platform/x86/barco-p50-gpio.c` lines 83-101
  (v7.0): confirmed `identify_led_node` has `.name = "identify"` with
  `identify_led_props` containing ONLY `PROPERTY_ENTRY_GPIO("gpios",
  ...)` - no `label`/`color`/`function`.
- [Phase 5] Examined other swnode LED users: `pcengines-apuv2`, `meraki-
  mx100`, `x86-android-tablets/other.c` all include
  `PROPERTY_ENTRY_STRING("label", ...)` → unaffected by the bug.
- [Phase 5] Read `drivers/base/swnode.c` line 423-427 and
  `drivers/base/property.c` line 654-658: `fwnode_get_name(swnode)`
  returns `kobject_name(&swnode->kobj)`, always valid for registered
  swnodes. Safe to use here.
- [Phase 6] `git show v6.12:drivers/leds/led-core.c` and
  `v6.6:drivers/leds/led-core.c`: confirmed identical `is_of_node`
  fallback structure with `else return -EINVAL` - fix applies cleanly.
- [Phase 6] `git diff v6.17:...led-core.c v7.0:...led-core.c`: no
  difference → file is stable in the 6.18-6.19-7.0 range where the
  regression exists.
- [Phase 8] Trigger reachability: boot-time probe path, deterministic
  every boot on affected hardware.
- UNVERIFIED: Could not verify the patch's upstream commit SHA
  `4f530c65487636dc1536b3fa1041f9a877a66a7f` in the local 7.0 tree (tree
  HEAD is `028ef9c96e961 Linux 7.0`, likely predates the leds-next merge
  for this commit). This matches the AUTOSEL candidate context.
- UNVERIFIED: Did not confirm by dynamic test that barco-p50-gpio
  actually fails without this fix; conclusion based on code inspection
  of `leds-gpio` + `led_compose_name` + the barco swnode definition.

The fix is a small, surgical 3-line fallback that mirrors well-
established OF-node handling. It addresses a real regression introduced
in v6.18 (Barco P50 identify LED fails to register) and cannot cause
regressions because it only covers a previously-failing path. Accepted
by the LED subsystem maintainer. This is the kind of low-risk driver-
enablement fix that AUTOSEL is designed to pick up for recent stable
trees.

**YES**

 drivers/leds/led-core.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index 59473f286b31f..8ce41b36c6455 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -581,6 +581,9 @@ int led_compose_name(struct device *dev, struct led_init_data *init_data,
 	} else if (is_of_node(fwnode)) {
 		n = snprintf(led_classdev_name, LED_MAX_NAME_SIZE, "%s",
 			     to_of_node(fwnode)->name);
+	} else if (is_software_node(fwnode)) {
+		n = snprintf(led_classdev_name, LED_MAX_NAME_SIZE, "%s",
+			     fwnode_get_name(fwnode));
 	} else
 		return -EINVAL;
 
-- 
2.53.0