[PATCH AUTOSEL 7.0-6.12] pinctrl: realtek: Fix return value and silence log for unsupported configs

[PATCH AUTOSEL 7.0-6.12] pinctrl: realtek: Fix return value and silence log for unsupported configs

[Sasha Levin]

From: Tzuyi Chang <tychang@realtek.com>

[ Upstream commit 6a6b238c66dc69cd784baf03b170c50f7e5f24d9 ]

Treating unsupported configurations as errors causes upper layers (like the
GPIO subsystem) to interpret optional features as hard failures, aborting
operations or printing unnecessary error logs.

For example, during gpiod_get(), the GPIO framework attempts to set
PIN_CONFIG_PERSIST_STATE. Since this driver does not support it, false
error reports are generated in dmesg.

Fix this by returning -ENOTSUPP and demoting the log level to dev_dbg.

Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Tzuyi Chang <tychang@realtek.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have enough information to provide a comprehensive analysis.

## Phase 1: Commit Message Forensics

**Step 1.1: Subject Line**
Record: [pinctrl: realtek] [Fix + silence] Fix return value and demote
log level for unsupported pinconf parameters.

**Step 1.2: Tags**
Record:
- Reviewed-by: Bartosz Golaszewski (GPIO subsystem maintainer)
- Signed-off-by: Tzuyi Chang (original author, the person who authored
  the driver in the first place)
- Signed-off-by: Yu-Chun Lin (series submitter)
- Signed-off-by: Linus Walleij (pinctrl subsystem maintainer)
- No Fixes: tag, no Cc: stable (expected)
- No Reported-by, no Link:

**Step 1.3: Commit Body Analysis**
Record: The commit explains a concrete failure mode: "Treating
unsupported configurations as errors causes upper layers (like the GPIO
subsystem) to interpret optional features as hard failures, aborting
operations..." With a specific example: during `gpiod_get()`, the GPIO
framework attempts to set `PIN_CONFIG_PERSIST_STATE`. Since the driver
returns `-EINVAL` (not `-ENOTSUPP`), `gpiod_get()` fails entirely. This
is a real functional bug, not cosmetic.

**Step 1.4: Hidden Bug Fix Detection**
Record: Marked as "silence log" which sounds cosmetic, but the `return
-EINVAL` -> `-ENOTSUPP` change is a real functional bug fix. The GPIO
layer's helper `gpio_set_config_with_argument_optional()` only swallows
`-ENOTSUPP`; `-EINVAL` propagates up and fails `gpiod_get()`.

## Phase 2: Diff Analysis

**Step 2.1: Inventory**
Record: 1 file, 2 lines changed (+2/-2), single function
`rtd_pconf_parse_conf()`, single-file surgical fix.

**Step 2.2: Code Flow Change**
Record: In the `default:` branch of the `switch ((u32)param)` in
`rtd_pconf_parse_conf`:
- BEFORE: `dev_err(...); return -EINVAL;`
- AFTER: `dev_dbg(...); return -ENOTSUPP;`

**Step 2.3: Bug Mechanism**
Record: Logic/correctness fix + return-code semantics fix. The pinctrl
API contract with gpiolib expects `-ENOTSUPP` for "feature not
implemented" so that optional config calls (like
`PIN_CONFIG_PERSIST_STATE` from `gpiod_set_transitory()`) are silently
ignored. Returning `-EINVAL` breaks this contract.

**Step 2.4: Fix Quality**
Record: Obviously correct. All the other branches in the same switch
already return `-ENOTSUPP` (see lines 297, 304, 317, 329, 415, 432, 449)
- the default path was the outlier. The companion function
`rtd_pin_config_get()` also already returns `-ENOTSUPP` in its default
(line 478). No regression risk - a change from a hard error to a soft
error for an inherently "unsupported" case.

## Phase 3: Git History Investigation

**Step 3.1: Blame**
Record: The buggy `return -EINVAL` was introduced in the original driver
commit `e99ce78030db2` ("pinctrl: realtek: Add common pinctrl driver for
Realtek DHC RTD SoCs"), which entered mainline in v6.7-rc1. Verified:
`git show e99ce78030db2` shows the buggy code was there from day one.

**Step 3.2: Fixes Tag**
Record: No Fixes tag present. Based on git blame, the effective "Fixes:"
would be `e99ce78030db2` ("pinctrl: realtek: Add common pinctrl driver
for Realtek DHC RTD SoCs"), which is in stable trees from v6.12 onwards.

**Step 3.3: File History**
Record: Between v6.12 and this fix, only 2 commits touch the file:
```
6a6b238c66dc6 pinctrl: realtek: Fix return value and silence log for
unsupported configs
a248904e30309 pinctrl: realtek: Cleanup license string
```
Standalone fix; no dependencies on other series patches.

**Step 3.4: Author**
Record: Tzuyi Chang is the original author of the Realtek pinctrl driver
(verified via `git log --author`). This is a fix from the subsystem
domain expert. Reviewed by Bartosz Golaszewski (GPIO subsystem
maintainer), and applied by Linus Walleij (pinctrl maintainer).

**Step 3.5: Dependencies**
Record: None. The default branch of a switch statement is self-
contained. Does not rely on any other patch in the v2 14-patch series.

## Phase 4: Mailing List Research

**Step 4.1: Lore Thread**
Record: b4 dig found: `https://lore.kernel.org/all/20260306075244.117039
9-3-eleanor.lin@realtek.com/`. Submitted as patch 2/14 of "pinctrl:
realtek: Core improvements and RTD1625 support".

**Step 4.2: Reviewers**
Record: b4 dig -w shows appropriate reviewers: Linus Walleij (pinctrl
maintainer), Bartosz Golaszewski (GPIO maintainer who added Reviewed-
by), linux-gpio ML. The RIGHT people reviewed this.

**Step 4.3: Series Revisions**
Record: b4 dig -a shows only v2 exists (no v3/v4 required). The v2
change was simply adding Bartosz's Reviewed-by; no behavior changes.

**Step 4.4: No stable tag in series**
Record: No `Cc: stable` was added in the patch or discussion. No
explicit stable nomination from reviewers - but this is expected for the
candidates being reviewed here.

**Step 4.5: Related prior art**
Record: Confirmed that a nearly-identical fix was already made for
`pinctrl-amd`: commit `87b549efcb0f7` ("pinctrl: amd: Don't show
`Invalid config param` errors"), which:
- Changed `dev_err` -> `dev_dbg` AND `-EINVAL` -> `-ENOTSUPP` for the
  same unsupported `PIN_CONFIG_PERSIST_STATE` scenario triggered by
  `gpiod_get()`
- Was explicitly marked with `Cc: stable@vger.kernel.org # 6.1`
- Was accepted to stable

This strongly validates that the pattern is considered stable material.

## Phase 5: Code Semantic Analysis

**Step 5.1: Functions**
Record: Single function: `rtd_pconf_parse_conf`.

**Step 5.2: Callers**
Record: Called from `rtd_pin_config_set`
(`drivers/pinctrl/realtek/pinctrl-rtd.c:493`). That is the
`.pin_config_set` callback used by the pinctrl framework. This is called
via pinctrl → gpiolib integration.

**Step 5.3/5.4: Call Chain (gpiod_get failure path)**
Record (verified in `drivers/gpio/gpiolib.c`):

```c
gpiod_get() ...
  -> gpiod_configure_flags()            // line 4897
    -> gpiod_set_transitory()           // line 4938 unconditional
      ->
gpio_set_config_with_argument_optional(PIN_CONFIG_PERSIST_STATE) // line
3228
        -> gpio_set_config_with_argument() -> pinctrl set_config
callback
         // Line 2721: "if (ret != -ENOTSUPP) return ret;"
         // -EINVAL propagates up as hard error
```

So every `gpiod_get()` on a Realtek RTD SoC was failing with -EINVAL.
This is reachable from `.probe()` of every device that requests a GPIO
via `gpiod_get()` - a very common operation.

**Step 5.5: Similar Patterns**
Record: Similar issue fixed in `pinctrl-amd` (87b549efcb0f7). Other
pinctrl drivers correctly use -ENOTSUPP. The helper
`gpio_set_config_with_argument_optional()` has existed since v5.11-rc1
(commit `baca3b15cd2a1`), so the `-ENOTSUPP` contract is long-standing.

## Phase 6: Cross-referencing and Stable Tree Analysis

**Step 6.1: Where does the buggy code exist?**
Record (verified via `git show v<TAG>:drivers/pinctrl/realtek/pinctrl-
rtd.c`):
- v6.6: driver does NOT exist (not affected)
- v6.12: buggy code present (affected)
- v6.13: buggy code present (affected)
- v6.15: buggy code present (affected)
- Active stable trees affected: 6.12.y and later LTS/stable branches

**Step 6.2: Backport Complexity**
Record: Only 2 commits touched this file between v6.12 and the fix, and
the other is a license string cleanup. The surrounding context in the
`default:` branch has not changed since driver introduction. Clean apply
expected.

**Step 6.3: Related fixes already in stable**
Record: None found for this specific issue in pinctrl-rtd.

## Phase 7: Subsystem Context

**Step 7.1: Subsystem/Criticality**
Record: Subsystem: pinctrl (specifically Realtek DHC RTD SoC pinctrl).
Hardware-specific, but on these platforms it affects ALL users since the
failure is in a very common GPIO path (`gpiod_get()`). Criticality:
IMPORTANT for Realtek RTD users.

**Step 7.2: Subsystem Activity**
Record: Actively developed; the fact that the bug wasn't previously
caught suggests limited runtime coverage, but once a consumer calls
`gpiod_get()` it breaks.

## Phase 8: Impact and Risk Assessment

**Step 8.1: Affected Users**
Record: Users of Realtek DHC (Digital Home Center) RTD SoCs, e.g.,
RTD1xxx family (TV/STB/embedded ARM64 systems). Driver-specific, but
universal across those platforms.

**Step 8.2: Trigger**
Record: Any caller of `gpiod_get()` / `gpiod_get_index()` / similar in a
driver that targets a Realtek RTD SoC. Common paths: every probe
function requesting a GPIO line. No privilege needed — triggered during
normal boot.

**Step 8.3: Failure Mode**
Record: `gpiod_get()` returns `-EINVAL` with log "setup of GPIO %s
failed: -22". Consumer driver probe fails. Depending on device: missing
hardware support (HDMI detect, reset pins, regulator enables) -
effectively device breakage on affected SoCs. Severity: HIGH.

**Step 8.4: Risk/Benefit**
Record:
- BENEFIT: Restores correct `gpiod_get()` operation on Realtek RTD SoCs;
  eliminates false error messages. HIGH benefit for that user
  population.
- RISK: Changing a log-level and an errno value. Only affects the
  error/unsupported path. All other callers of this pinctrl driver that
  use supported params are unaffected. VERY LOW risk.

## Phase 9: Final Synthesis

**Step 9.1: Evidence**

FOR backporting:
- Fixes a real functional bug: `gpiod_get()` fails entirely on Realtek
  RTD SoCs
- Small, surgical, obviously-correct change (2 lines)
- Fix aligns with how all other `-ENOTSUPP` returns in the same file
  work
- Reviewed by the GPIO subsystem maintainer (Bartosz Golaszewski)
- Applied by the pinctrl maintainer (Linus Walleij)
- An identical conceptual fix was already backported to stable for
  `pinctrl-amd` (commit `87b549efcb0f7` with `Cc: stable # 6.1`)
- Buggy code present since v6.7-rc1, exists in current LTS (6.12.y) and
  later
- No dependencies on the rest of the 14-patch series
- Clean apply expected

AGAINST backporting:
- No explicit Cc: stable or Fixes: tag (expected; that is why this is a
  candidate for review)
- No Reported-by or user bug link (but the commit message clearly
  describes the failure mechanism and the fix is obviously correct)

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested: YES (matches the GPIO contract; all
   sibling branches already use -ENOTSUPP)
2. Fixes a real bug affecting users: YES (gpiod_get() failure)
3. Important issue: YES (driver/GPIO broken = device probe failures)
4. Small and contained: YES (2 lines in one function)
5. No new features/APIs: YES (pure bug fix)
6. Can apply to stable: YES (clean apply expected on 6.12.y+)

**Step 9.3: Exception**
Not applicable (this is a straightforward bug fix, not a special
exception category).

**Step 9.4: Decision**
Strong YES.

## Verification

- [Phase 1] Parsed tags: Reviewed-by: Bartosz Golaszewski; Signed-off-
  by: author + Linus Walleij. No Fixes, no Cc:stable.
- [Phase 2] Diff: Verified 2-line change in `rtd_pconf_parse_conf`
  default branch, converting `dev_err + -EINVAL` to `dev_dbg +
  -ENOTSUPP`. Context shows all other error cases in same switch already
  return `-ENOTSUPP`.
- [Phase 3] `git blame`/`git show e99ce78030db2`: Verified buggy code
  was present from the driver's original commit.
- [Phase 3] `git describe --contains e99ce78030db2`: returns
  `v6.7-rc1~70^2~58` - driver added in v6.7-rc1.
- [Phase 3] `git log v6.12..6a6b238c66dc6 --
  drivers/pinctrl/realtek/pinctrl-rtd.c`: Only 2 commits between v6.12
  and the fix - clean backport.
- [Phase 4] `b4 dig -c 6a6b238c66dc6`: Found lore thread `https://lore.k
  ernel.org/all/20260306075244.1170399-3-eleanor.lin@realtek.com/`,
  matched by patch-id.
- [Phase 4] `b4 dig -a`: Only v2 exists; v2 changelog shows only "Add
  Bartosz's Reviewed-by tag" (no code change from v1).
- [Phase 4] `b4 dig -w`: Verified linusw@kernel.org,
  bartosz.golaszewski@oss.qualcomm.com, linux-gpio@vger.kernel.org on
  the thread.
- [Phase 4] `git show 87b549efcb0f7`: Confirmed `pinctrl-amd` got the
  same conceptual fix with `Cc: stable@vger.kernel.org # 6.1`.
- [Phase 5] Verified call chain in `drivers/gpio/gpiolib.c`: `gpiod_get`
  → `gpiod_configure_flags` (line 4771/4897) → `gpiod_set_transitory`
  (line 4938) → `gpio_set_config_with_argument_optional` (line 3228)
  which only swallows `-ENOTSUPP` (line 2721).
- [Phase 5] `git describe --contains baca3b15cd2a1`: helper added in
  v5.11-rc1; present in all LTS trees of interest.
- [Phase 6] Verified via `git show
  v6.12/v6.13/v6.15:drivers/pinctrl/realtek/pinctrl-rtd.c`: buggy code
  present in all; v6.6 does not contain driver.
- [Phase 8] Verified caller at `drivers/gpio/gpiolib.c:4771`: on error,
  `gpiod_put(desc)` + `dev_err(... setup of GPIO %s failed: %d)` - user-
  visible failure.
- UNVERIFIED: Could not retrieve dmesg logs from an actual Realtek RTD
  device (no hardware access), but the code path analysis is definitive.
- UNVERIFIED: Did not check every single 6.7.y-6.11.y tree individually
  - these are EOL so not relevant for current backport targets.

The fix is small, surgical, obviously correct, reviewed by the
appropriate maintainers, and an exact precedent (`pinctrl-amd`
87b549efcb0f7) was previously accepted to stable. It fixes a concrete
functional failure (`gpiod_get()` breakage on Realtek RTD SoCs) present
in active LTS 6.12.y and later.

**YES**

 drivers/pinctrl/realtek/pinctrl-rtd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/realtek/pinctrl-rtd.c b/drivers/pinctrl/realtek/pinctrl-rtd.c
index 2440604863327..8d7cdb18cf773 100644
--- a/drivers/pinctrl/realtek/pinctrl-rtd.c
+++ b/drivers/pinctrl/realtek/pinctrl-rtd.c
@@ -456,8 +456,8 @@ static int rtd_pconf_parse_conf(struct rtd_pinctrl *data,
 		break;
 
 	default:
-		dev_err(data->dev, "unsupported pinconf: %d\n", (u32)param);
-		return -EINVAL;
+		dev_dbg(data->dev, "unsupported pinconf: %d\n", (u32)param);
+		return -ENOTSUPP;
 	}
 
 	ret = regmap_update_bits(data->regmap_pinctrl, reg_off, mask, val);
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] gpio: tps65086: normalize return value of gpio_get

[Sasha Levin]

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

[ Upstream commit 9eb7ecfd20f868421e44701274896ba9e136daae ]

The GPIO get callback is expected to return 0 or 1 (or a negative error
code). Ensure that the value returned by tps65086_gpio_get() is normalized
to the [0, 1] range.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://patch.msgid.link/20260218190657.2974723-6-dmitry.torokhov@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed. Let me compile the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `gpio: tps65086`
- Action: "normalize" (ensure correctness of return value)
- Summary: Normalize the return value of `gpio_get` to comply with the
  GPIO API contract (must return 0, 1, or negative error).
Record: [gpio: tps65086] [normalize] [Ensure gpio_get returns 0/1 per
API contract]

**Step 1.2: Tags**
- `Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>` - author,
  well-known kernel developer (input subsystem maintainer)
- `Link: https://patch.msgid.link/20260218190657.2974723-6-
  dmitry.torokhov@gmail.com` - part 6 of a series
- `Signed-off-by: Bartosz Golaszewski
  <bartosz.golaszewski@oss.qualcomm.com>` - GPIO subsystem maintainer
- No Fixes: tag (expected for autosel candidates)
- No Cc: stable tag (expected)
Record: Author is a highly trusted kernel developer. Applied by GPIO
subsystem maintainer. Part of a series (patch 6 of N).

**Step 1.3: Commit Body**
The message explains the API contract: `.get()` callbacks must return 0,
1, or negative error. The driver was returning raw bit values
(potentially 16, 32, 64, 128) which violates this contract.
Record: Bug is API contract violation. Symptom depends on kernel version
- may cause warnings or errors.

**Step 1.4: Hidden Bug Fix Detection**
"Normalize return value" = ensuring correct API behavior. This IS a real
bug fix - the function violated its documented contract.
Record: Yes, this is a real bug fix disguised as normalization.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file: `drivers/gpio/gpio-tps65086.c`
- 1 line changed: `-` removed, `+` added
- Function modified: `tps65086_gpio_get()`
- Scope: Single-file, single-line surgical fix
Record: 1 file, 1 line changed in tps65086_gpio_get(). Minimal scope.

**Step 2.2: Code Flow Change**
- Before: `return val & BIT(4 + offset);` — returns the raw bit value
  (e.g., BIT(4)=16, BIT(5)=32, BIT(6)=64, BIT(7)=128)
- After: `return !!(val & BIT(4 + offset));` — normalizes to 0 or 1
- Affects the normal return path of the GPIO get operation
Record: Before returns 0/16/32/64/128; after returns 0/1. Normal path
change.

**Step 2.3: Bug Mechanism**
Category: Logic/correctness fix. The function returned values > 1,
violating the `gpio_chip::get()` API contract that requires 0, 1, or
negative error.
Record: API contract violation. `BIT(4+offset)` can be 16,32,64,128
instead of required 0/1.

**Step 2.4: Fix Quality**
- Obviously correct: `!!` is the standard C idiom for boolean
  normalization
- Minimal/surgical: exactly one character change conceptually
- Regression risk: zero — `!!` preserves boolean semantics
Record: Trivially correct, zero regression risk.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
The buggy line (`return val & BIT(4 + offset)`) was introduced in commit
`99f0fd540f539` ("gpio: tps65086: Add GPO driver for the TPS65086 PMIC")
by Andrew F. Davis, dated 2016-02-06. This went into v4.6. The bug has
been present since the driver was first created — approximately 10
years.
Record: Bug introduced in v4.6 (2016), present in ALL stable trees.

**Step 3.2: No Fixes: tag** — expected for autosel.

**Step 3.3: File History**
Recent changes to the file are mostly refactoring (GPIO callback rename,
devm conversion). None fix this issue.
Record: No related prior fixes. This is standalone.

**Step 3.4: Author**
Dmitry Torokhov is the Linux input subsystem maintainer and prolific
kernel contributor. He submitted multiple similar normalize patches:
- `fbd03587ba732` gpio: amd-fch
- `fb22bb9701d48` pinctrl: renesas: rza1
- `e2fa075d5ce19` iio: adc: ti-ads7950
- `2bb995e6155cb` net: phy: qcom: qca807x
Record: Trusted kernel developer. Systematic fix across multiple
drivers.

**Step 3.5: Dependencies**
The patch changes `val & BIT(4 + offset)` to `!!(val & BIT(4 + offset))`
— this is completely standalone with no dependencies.
Record: No dependencies. Applies cleanly on its own.

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1-4.2:** Lore was blocked by anti-bot protection. However, from
b4 dig on the related amd-fch patch (same author, same series), the
patches were submitted individually and reviewed by the GPIO subsystem
maintainer. The Link: header shows this is patch 6 of a series.

**Step 4.3:** The underlying issue was reported by Dmitry Torokhov
himself when he discovered `86ef402d805d` broke multiple drivers. He is
listed as `Reported-by` on `ec2cceadfae72` (the core workaround).

**Step 4.4-4.5:** The core workaround (`ec2cceadfae72`) explicitly has
`Cc: stable@vger.kernel.org`, indicating the upstream developers
consider the warning/normalization issue important for stable.
Record: Series of driver-level fixes coordinated with a core workaround.
Core fix is explicitly nominated for stable.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1-5.2:** `tps65086_gpio_get()` is registered as the `.get`
callback in `template_chip`. It's called by the GPIO core via
`gpiochip_get()` whenever any consumer reads this GPIO line.

**Step 5.3-5.4:** The function reads a register via `regmap_read()` and
returns a masked bit value. The GPIO core function `gpiochip_get()`
(line 3259 of gpiolib.c) calls it and then checks the return value:

```3267:3272:drivers/gpio/gpiolib.c
        if (ret > 1) {
                gpiochip_warn(gc,
                        "invalid return value from gc->get(): %d,
consider fixing the driver\n",
                        ret);
                ret = !!ret;
        }
```

This warning uses `dev_warn` (NOT rate-limited), so it fires on EVERY
GPIO read.

**Step 5.5:** Multiple similar drivers have the same bug — Dmitry's
series fixes several of them.
Record: Warning fires on every GPIO read. Not rate-limited.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1:** The buggy code exists since v4.6 — present in ALL stable
trees. For the 7.0.y tree specifically:
- `86ef402d805d` (strict checking, returns -EBADE for values > 1) —
  first in v6.15-rc1, present in v7.0
- `ec2cceadfae72` (normalize + warn instead of error) — present in v7.0

**Step 6.2:** The patch is a trivial one-line change. It will apply
cleanly to 7.0.y.

**Step 6.3:** No related fix already in stable for this specific driver.
Record: Both the strict check and the warn-and-normalize workaround are
in v7.0. Without this driver fix, every GPIO read emits a warning.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1:** GPIO driver (`drivers/gpio/`). Criticality: PERIPHERAL —
affects users of TPS65086 PMIC hardware specifically.

**Step 7.2:** The GPIO subsystem is actively maintained by Bartosz
Golaszewski.
Record: Peripheral subsystem, actively maintained.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1:** Affects users of TPS65086 PMIC hardware (embedded systems
using this Texas Instruments power management IC).

**Step 8.2:** Triggered on every GPIO read for this hardware. If the
GPIO is polled or frequently accessed, the warning fires repeatedly.

**Step 8.3:** Failure mode: Without this fix in v7.0.y, every GPIO read
emits an un-rate-limited `dev_warn()` message to dmesg. Severity: MEDIUM
— not a crash or corruption, but real user-visible log noise that can be
significant.

**Step 8.4:**
- BENEFIT: Eliminates repeated runtime warnings for TPS65086 users. Low-
  medium benefit.
- RISK: Essentially zero — `!!` is trivially correct.
- Ratio: Positive. Near-zero risk for a real improvement.
Record: Zero risk, eliminates un-rate-limited warning on every GPIO
read.

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence FOR backporting:**
- Fixes a real API contract violation present since v4.6
- Eliminates un-rate-limited `dev_warn()` on every GPIO read in v7.0
  (because `ec2cceadfae72` catches the violation)
- Trivially correct one-line fix with zero regression risk
- Part of a coordinated upstream effort (core workaround has `Cc:
  stable`)
- Applied by GPIO subsystem maintainer
- Written by a highly trusted kernel developer

**Evidence AGAINST:**
- The core already handles the value functionally (`ec2cceadfae72`
  normalizes it)
- The warning is "just" log noise, not a crash or corruption
- Peripheral hardware (TPS65086 PMIC only)

**Step 9.2: Stable Rules Checklist:**
1. Obviously correct? YES — `!!` normalization is trivially correct
2. Fixes real bug? YES — API violation causing repeated warnings
3. Important issue? MEDIUM — repeated dmesg warnings, not
   crash/corruption
4. Small and contained? YES — 1 line, 1 file
5. No new features? Correct — no new features
6. Applies to stable? YES — cleanly

**Step 9.3:** No special exception category, but trivially safe fix.

**Step 9.4: Decision**
The fix is a trivially correct, zero-risk, one-line change that
eliminates a repeated un-rate-limited warning emitted on every GPIO read
for TPS65086 hardware. In the v7.0 tree, the GPIO core workaround
(`ec2cceadfae72`, which is marked `Cc: stable`) catches this driver's
incorrect return value and normalizes it while printing a warning. This
driver-level fix is the proper solution. The coordinated upstream effort
(core workaround + individual driver fixes) demonstrates that the GPIO
maintainer considers these important for stable.

## Verification

- [Phase 1] Parsed tags: author is Dmitry Torokhov (input maintainer),
  applied by Bartosz Golaszewski (GPIO maintainer), patch 6 of series
- [Phase 2] Diff analysis: single line change `val & BIT(4+offset)` →
  `!!(val & BIT(4+offset))` in `tps65086_gpio_get()`
- [Phase 3] git blame: buggy code introduced in commit 99f0fd540f539
  (v4.6, 2016), present in all stable trees
- [Phase 3] git log --author: Dmitry submitted 4+ similar normalize
  patches across different drivers
- [Phase 4] b4 dig: found related amd-fch patch thread. Lore blocked by
  anti-bot for direct tps65086 thread
- [Phase 5] Grep of gpiolib.c: confirmed `gpiochip_get()` checks ret > 1
  and calls `gpiochip_warn()` (un-rate-limited `dev_warn`)
- [Phase 5] Grep of gpiolib.h: confirmed `gpiochip_warn` maps to
  `dev_warn` (not rate-limited)
- [Phase 6] git merge-base: confirmed `86ef402d805d` and `ec2cceadfae72`
  are both ancestors of v7.0
- [Phase 6] git show `ec2cceadfae72`: confirmed it has `Cc:
  stable@vger.kernel.org` and `Fixes: 86ef402d805d`
- [Phase 6] git tag --contains `86ef402d805d`: first in v6.15-rc1
- [Phase 6] git log v7.0.. -- gpio-tps65086.c: no changes after v7.0 tag
  (patch not yet applied)
- [Phase 8] Failure mode: un-rate-limited dev_warn on every GPIO read.
  Not crash/corruption, but real log noise.
- UNVERIFIED: Could not access lore discussion for the specific tps65086
  patch due to anti-bot protection

The fix is a trivially correct one-line change with zero risk that
silences a repeated runtime warning. It's part of a coordinated upstream
effort whose core component is already marked for stable. While it
doesn't fix a crash or corruption, it eliminates genuine user-visible
annoyance and properly fixes the driver's API contract violation.

**YES**

 drivers/gpio/gpio-tps65086.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-tps65086.c b/drivers/gpio/gpio-tps65086.c
index 84b17b83476f5..df770ecf28bc4 100644
--- a/drivers/gpio/gpio-tps65086.c
+++ b/drivers/gpio/gpio-tps65086.c
@@ -50,7 +50,7 @@ static int tps65086_gpio_get(struct gpio_chip *chip, unsigned offset)
 	if (ret < 0)
 		return ret;
 
-	return val & BIT(4 + offset);
+	return !!(val & BIT(4 + offset));
 }
 
 static int tps65086_gpio_set(struct gpio_chip *chip, unsigned int offset,
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] gpio: viperboard: normalize return value of gpio_get

[Sasha Levin]

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

[ Upstream commit c08381ad56a9cc111f893b2b21400ceb468cc698 ]

The GPIO get callback is expected to return 0 or 1 (or a negative error
code). Ensure that the value returned by vprbrd_gpiob_get() in the output
case is normalized to the [0, 1] range.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://patch.msgid.link/20260218190657.2974723-7-dmitry.torokhov@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Connection lost, reconnecting...
Retry attempt 1...
Now I have all the information needed for a comprehensive analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
Record: [gpio: viperboard] [normalize] [Normalize return value of
gpio_get callback to [0, 1] range]

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- `Signed-off-by: Dmitry Torokhov` - Author
- `Link:` - patch.msgid.link (message ID
  20260218190657.2974723-**7**-dmitry.torokhov@gmail.com - patch 7/7 in
  a series)
- `Signed-off-by: Bartosz Golaszewski` - GPIO subsystem maintainer
  applied it
- No Fixes: tag, no Cc: stable, no Reported-by, no Reviewed-by

Record: Missing Fixes: and Cc: stable tags (expected for candidates).
Maintainer SOB present. Part of a 7-patch series.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The commit says the GPIO `.get()` callback must return 0 or 1 (or
negative error). `vprbrd_gpiob_get()` in the output case returns
`gpio->gpiob_val & (1 << offset)`, which for offset > 0 returns values
like 2, 4, 8, etc., violating the API contract.

Record: Bug = API contract violation in GPIO get callback. Symptom =
non-normalized return value (e.g., 32 instead of 1 for offset 5). Root
cause = missing `!!()` normalization.

### Step 1.4: DETECT HIDDEN BUG FIXES
"Normalize" is equivalent to "fix incorrect return value." This is a
real bug fix - the function returns wrong values for the majority of
GPIO offsets (1-15 out of 16).

Record: This IS a bug fix, not cleanup.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: INVENTORY THE CHANGES
- `drivers/gpio/gpio-viperboard.c`: 1 line changed (+1/-1)
- Function modified: `vprbrd_gpiob_get()`
- Scope: single-file surgical fix, one line

Record: 1 file, 1 line changed, single function, minimal scope.

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**Before:** When GPIO B pin is set as output, `return gpio->gpiob_val &
(1 << offset)` returns a bit-masked value (0, 1, 2, 4, 8, ..., 32768).

**After:** `return !!(gpio->gpiob_val & (1 << offset))` returns 0 or 1.

Record: Before = returns arbitrary power-of-2 values. After = returns
normalized 0/1.

### Step 2.3: IDENTIFY THE BUG MECHANISM
Category: **Logic / correctness fix** - incorrect return value from API
callback.

The expression `(1 << offset)` for offset=5 yields 32. If the bit is
set, `gpiob_val & 32` returns 32, not 1. The `!!` operator normalizes
any truthy value to exactly 1.

Record: Logic bug - wrong return value for GPIO offsets > 0. Fix is
`!!()` normalization.

### Step 2.4: ASSESS THE FIX QUALITY
- Obviously correct: `!!` is the standard pattern used throughout the
  kernel for this exact purpose
- Minimal: one line
- The identical fix was applied to `vprbrd_gpioa_get()` in 2015 (commit
  `80776df4f53e8`)
- Zero regression risk

Record: Fix is obviously correct, minimal, proven pattern. Zero
regression risk.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
The buggy line (291) was introduced in commit `9d5b72de0d162` by Lars
Poeschel on 2012-11-05 - the original driver addition. This bug has
existed since the driver was first added.

Record: Buggy code from 2012, present in all stable trees since ~v3.8.

### Step 3.2: FOLLOW THE FIXES: TAG
No Fixes: tag present. However, sibling commit `e2fa075d5ce19` (iio:
adc: ti-ads7950, same author, same type of fix) has `Fixes: 86ef402d805d
("gpiolib: sanitize the return value of gpio_chip::get()")` and `Cc:
stable@vger.kernel.org`.

The commit `86ef402d805d` (v6.15-rc1, Feb 2025) made gpiolib reject non-
normalized values by returning `-EBADE`. This was then partially
reverted by `ec2cceadfae72` (Feb 2026, Cc: stable) to normalize + warn
instead of error.

Record: The bug was latent since 2012. It became a functional regression
in v6.15 when `86ef402d805d` started rejecting non-normalized values
with -EBADE.

### Step 3.3: CHECK FILE HISTORY
Commit `80776df4f53e8` (Dec 2015) by Linus Walleij applied the identical
fix to `vprbrd_gpioa_get()` but missed `vprbrd_gpiob_get()`. This commit
completes that work 10 years later.

Record: Prior art exists in the same file - identical fix applied to
gpioa in 2015, gpiob was missed.

### Step 3.4: CHECK THE AUTHOR
Dmitry Torokhov is a prolific kernel contributor (input subsystem
maintainer, Google). He authored the gpiolib normalization series fixing
this same class of bug across 7+ GPIO drivers.

Record: Author is an experienced, well-known kernel developer.

### Step 3.5: CHECK FOR DEPENDENCIES
This is patch 7/7 in a series of independent per-driver fixes. Each
patch is completely standalone. No dependencies.

Record: Fully standalone, no dependencies.

---

## PHASE 4: MAILING LIST RESEARCH

### Step 4.1: ORIGINAL PATCH DISCUSSION
Found via b4 am: This is patch 7/7 in a series:
1. gpio: bd9571mwv: normalize return value of gpio_get
2. gpio: cgbc: normalize return value of gpio_get
3. gpio: da9055: normalize return value of gpio_get
4. gpio: lp873x: normalize return value of gpio_get
5. gpio: stp-xway: normalize return value of gpio_get
6. gpio: tps65086: normalize return value of gpio_get
7. gpio: viperboard: normalize return value of gpio_get (this one)

No review comments were found in the mbox (no replies). The maintainer
(Bartosz Golaszewski) applied the patches directly.

Record: Part of a 7-patch series. No review discussion found. Applied by
GPIO maintainer.

### Step 4.2: REVIEWERS
The sibling iio commit had `Reviewed-by: Andy Shevchenko`, `Reviewed-by:
Bartosz Golaszewski`, and `Reviewed-by: Linus Walleij`. This GPIO series
was applied directly by the maintainer.

Record: Applied by subsystem maintainer Bartosz Golaszewski.

### Step 4.3-4.5: BUG REPORT AND STABLE HISTORY
The root cause was Dmitry Torokhov's report that `86ef402d805d` broke
many GPIO drivers. This led to both the gpiolib normalization fix
(ec2cceadfae72, Cc: stable) and the per-driver cleanup series.

Record: Dmitry Torokhov reported the broader issue, leading to both
framework and per-driver fixes.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1-5.4: FUNCTION ANALYSIS
`vprbrd_gpiob_get()` is registered as the `.get` callback for GPIO chip
B in `vprbrd_gpio_probe()` (line 428). It's called by the gpiolib
framework via `gpiochip_get()` → `gc->get()` whenever any GPIO consumer
reads a pin value on viperboard GPIO B.

The affected path is specifically the "output cache" early return at
line 290-291, which is taken whenever a pin configured as output is
read.

Record: Called via gpiolib framework from any GPIO consumer reading pin
values. Affected path = output pin value reads.

### Step 5.5: SIMILAR PATTERNS
The exact same bug pattern (`val & BIT(offset)` instead of `!!(val &
BIT(offset))`) was fixed in 7 drivers in this series alone, plus the
prior 2015 fix for gpioa in the same file.

Record: Systematic pattern across many GPIO drivers. Well-understood,
well-tested fix pattern.

---

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

### Step 6.1: BUGGY CODE IN STABLE?
The buggy line was introduced in 2012. It exists in ALL active stable
trees.

### Step 6.2: BACKPORT COMPLICATIONS
One-line change to ancient code. Will apply cleanly to all stable trees.

### Step 6.3: RELATED FIXES IN STABLE
`ec2cceadfae72` (gpiolib: normalize the return value on behalf of buggy
drivers) is Cc: stable and will be backported. This provides a
framework-level safety net, but the per-driver fix eliminates the
warning.

Record: gpiolib framework fix will be in stable too, but per-driver fix
prevents warnings.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: SUBSYSTEM CRITICALITY
Subsystem: drivers/gpio - device driver, GPIO subsystem.
Criticality: PERIPHERAL - viperboard is an obscure USB GPIO device.

### Step 7.2: SUBSYSTEM ACTIVITY
Moderate activity in GPIO subsystem overall, but viperboard itself has
minimal activity (last change was commit `d9d87d90cc0b1`).

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: WHO IS AFFECTED
Users of Nano River Technologies Viperboard USB GPIO hardware - a very
small population.

### Step 8.2: TRIGGER CONDITIONS
Any read of a GPIO B pin that is configured as output, at offsets 1-15.
Common operation for any viperboard GPIO user.

### Step 8.3: FAILURE MODE SEVERITY
- **On stable with 86ef402d805d but not ec2cceadfae72**: Returns -EBADE
  error instead of pin value - **MEDIUM** (functional regression)
- **On stable with both**: Produces kernel WARNING - **LOW**
- **On older stable without either**: GPIO consumers get wrong values
  (e.g., 32 instead of 1) - **MEDIUM** (incorrect behavior)

### Step 8.4: RISK-BENEFIT RATIO
**BENEFIT**: Fixes incorrect return value for all viperboard GPIO B
users. Eliminates kernel warnings.
**RISK**: Effectively zero - one-line `!!()` change, same pattern used
everywhere.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: EVIDENCE COMPILATION
**FOR backporting:**
- Real bug fix: incorrect API return value, present since 2012
- One-line, obviously correct (identical to fix applied to gpioa in
  2015)
- Zero regression risk
- Part of a series where sibling commits were explicitly tagged Cc:
  stable
- Fixes a functional regression on v6.15+ (where gpiolib returns -EBADE
  for non-normalized values)
- Standalone, no dependencies, applies cleanly to all stable trees

**AGAINST backporting:**
- Obscure hardware with very few users
- gpiolib framework fix (ec2cceadfae72, Cc: stable) already handles
  normalization at the framework level
- Severity is LOW-MEDIUM (worst case is a kernel WARNING with the
  framework fix in stable)
- No Fixes: or Cc: stable tags on this specific commit

### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **YES** - `!!()` pattern, identical to
   prior gpioa fix
2. Fixes a real bug? **YES** - incorrect return values from GPIO get
   callback
3. Important issue? **BORDERLINE** - functional regression on v6.15+,
   wrong values on older
4. Small and contained? **YES** - 1 line, 1 file
5. No new features? **YES**
6. Can apply to stable? **YES** - cleanly applies to all trees

### Step 9.3: EXCEPTION CATEGORIES
Not an exception category - this is a standard correctness fix.

### Step 9.4: DECISION
This is a small, safe, obviously correct fix for a real API contract
violation that has existed since 2012. While the hardware is obscure,
the fix is zero-risk and the same class of fix was explicitly marked for
stable in sibling commits. The `!!()` pattern is well-established and
was already applied to the other get function in this same file.

---

## Verification

- [Phase 1] Parsed tags: Signed-off-by by author (Torokhov) and
  maintainer (Golaszewski), Link to lore.
- [Phase 2] Diff analysis: Single line change `return gpio->gpiob_val &
  (1 << offset)` → `return !!(gpio->gpiob_val & (1 << offset))` in
  vprbrd_gpiob_get().
- [Phase 3] git blame: Buggy code introduced in 9d5b72de0d162
  (2012-11-05, original driver addition).
- [Phase 3] git show 80776df4f53e8: Confirmed identical fix was applied
  to vprbrd_gpioa_get() in Dec 2015 by Linus Walleij, but gpiob_get was
  missed.
- [Phase 3] git show 86ef402d805d: Confirmed this commit (v6.15-rc1)
  made gpiolib return -EBADE for non-normalized values.
- [Phase 3] git show ec2cceadfae72: Confirmed this commit (Cc: stable)
  partially reverts to normalize+warn instead of error.
- [Phase 3] git show e2fa075d5ce19: Confirmed sibling commit (iio: ti-
  ads7950) has Fixes: 86ef402d805d and Cc: stable.
- [Phase 4] b4 am: Confirmed this is patch 7/7 in a series of 7
  identical fixes across GPIO drivers.
- [Phase 4] Mbox review: No review comments found; applied directly by
  maintainer.
- [Phase 5] Verified vprbrd_gpiob_get registered as .get callback at
  line 428 of gpio-viperboard.c.
- [Phase 5] Verified gpiolib framework calls gc->get() via
  gpiochip_get() in gpiolib.c:3277.
- [Phase 6] Bug exists in all stable trees (code from 2012). Patch
  applies cleanly.
- [Phase 6] Confirmed ec2cceadfae72 is Cc: stable and provides
  framework-level normalization.
- [Phase 8] Risk: effectively zero for a `!!()` one-liner.

**YES**

 drivers/gpio/gpio-viperboard.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-viperboard.c b/drivers/gpio/gpio-viperboard.c
index 15e495c109d2a..89087fd48a819 100644
--- a/drivers/gpio/gpio-viperboard.c
+++ b/drivers/gpio/gpio-viperboard.c
@@ -288,7 +288,7 @@ static int vprbrd_gpiob_get(struct gpio_chip *chip,
 
 	/* if io is set to output, just return the saved value */
 	if (gpio->gpiob_out & (1 << offset))
-		return gpio->gpiob_val & (1 << offset);
+		return !!(gpio->gpiob_val & (1 << offset));
 
 	mutex_lock(&vb->lock);
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] pinctrl: amd: Support new ACPI ID AMDI0033

[Sasha Levin]

From: Basavaraj Natikar <Basavaraj.Natikar@amd.com>

[ Upstream commit 127e98c05c46654867faf5f578cb56d375b89092 ]

Add AMDI0033 to the AMD GPIO ACPI match table.
This lets the driver bind on new AMD platforms that expose this HID.

Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis Walkthrough

### PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line Parse**
Record: Subsystem `pinctrl: amd:`; action verb `Support` (effectively
"add"); summary: adds new ACPI HID `AMDI0033` to the AMD GPIO ACPI match
table.

**Step 1.2: Commit Message Tags**
Record: Tags present:
- `Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>` (AMD
  vendor author)
- `Signed-off-by: Linus Walleij <linusw@kernel.org>` (pinctrl subsystem
  maintainer)
- No `Fixes:`, no `Cc: stable`, no `Reported-by:`, no `Link:` — absence
  is expected for a review candidate.

**Step 1.3: Commit Body**
Record: Body states `Add AMDI0033 to the AMD GPIO ACPI match table. This
lets the driver bind on new AMD platforms that expose this HID.` No
stack traces, no crash symptoms — this is a hardware enablement patch,
not a crash fix.

**Step 1.4: Hidden Bug Fix?**
Record: Not a hidden bug fix. It is an explicit hardware-enablement (new
device ID) addition. Falls into the stable exception "NEW DEVICE IDs".

### PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
Record: 1 file modified, `drivers/pinctrl/pinctrl-amd.c`, +1/-0. Scope:
single-line addition inside `amd_gpio_acpi_match[]`. No functions
modified.

**Step 2.2: Code Flow Change**
Record: Before, the `acpi_device_id` table had `AMD0030`, `AMDI0030`,
`AMDI0031`. After, `AMDI0033` is an additional entry. With this change
the `amd_gpio` platform driver will match/bind on ACPI devices whose
`_HID` is `AMDI0033`.

**Step 2.3: Bug Mechanism Category**
Record: Category (h) — Hardware workaround / device ID addition. No
locking, no refcount, no error path, no memory safety change.

**Step 2.4: Fix Quality**
Record: Obviously correct. Identical in pattern to the 2021 `AMDI0031`
addition (commit `1ca46d3e43569`) and 2016 `AMDI0030` addition (commit
`42a44402ecb78`). Cannot regress existing platforms because adding an
entry to an ACPI match table only expands which devices bind; it does
not change behavior for existing IDs. Zero regression risk for systems
lacking `AMDI0033`.

### PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
Record: `git blame` on lines 1273–1280 shows the table was introduced in
`dbad75dd1f25e0` (Ken Xue, 2015). Prior ID additions:
- `AMDI0030` in `42a44402ecb78` (2016)
- `AMDI0031` in `1ca46d3e43569` (2021)
Both precedents for the same kind of change, and both the driver and its
ACPI table have existed since v4.1-era.

**Step 3.2: Fixes: tag**
Record: No `Fixes:` tag — N/A. This is not a bug fix commit.

**Step 3.3: Related Recent Changes**
Record: `git log --oneline -5 -- drivers/pinctrl/pinctrl-amd.c` shows
benign recent churn (header cleanup, IRQ hwirq access, PM debug
messages, treewide rename). No prerequisite refactor touches
`amd_gpio_acpi_match[]`.

**Step 3.4: Author**
Record: Basavaraj Natikar is an AMD engineer with a long history of AMD
pinctrl/platform fixes (`git log --author=Basavaraj` shows many prior
AMD pinctrl commits). The co-SoB is Linus Walleij, the pinctrl
maintainer. Both strong credibility signals.

**Step 3.5: Prerequisites**
Record: None. The match array already exists; only adds one entry.
Stands alone. Patch applies literally to the file's existing structure.

### PHASE 4: MAILING LIST RESEARCH

**Step 4.1 / 4.2: b4 dig results**
Record: `b4 dig -c 127e98c05c466` located the submission at `https://lor
e.kernel.org/all/20260327050616.3816318-1-Basavaraj.Natikar@amd.com/` (a
RESEND of the initial post). `b4 dig -a` shows only a single series
version (v1 / RESEND). `b4 dig -w` shows recipients: Basavaraj Natikar,
Shyam-sundar.S-k@amd.com (AMD), Linus Walleij (maintainer), `linux-
gpio@vger.kernel.org`. All appropriate people were included; the pinctrl
maintainer signed it off.

Note: Lore requires interactive JS (Anubis); direct WebFetch was blocked
so I could not read thread replies. Based on the patch having only a
RESEND (no revisions) and being applied by the maintainer via his own
SoB, there is no evidence of objections. UNVERIFIED: exact thread reply
content.

**Step 4.3 / 4.4 / 4.5**
Record: No Reported-by/Link tags; no bug report to follow. Not part of a
larger dependent series (single-patch submission). No prior stable
discussion — N/A for a trivial ID add.

### PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1–5.5**
Record: The modified entity is a data table, not a function. Impact
surface: the ACPI subsystem's platform-bus matcher reads this table at
driver registration to decide which ACPI devices the `amd_gpio` platform
driver probes. Adding an entry makes exactly one additional HID
(`AMDI0033`) bind to `amd_gpio_probe()`. Existing ID behavior is
unchanged. No other code needs updating; no quirks table search turned
up `AMDI0033` (Grep found the new ID only in `pinctrl-amd.c`).

### PHASE 6: STABLE TREE CROSS-REFERENCING

**Step 6.1: Does the code exist in stable?**
Record: The AMD pinctrl driver and its ACPI match table have existed
since 2015. Every active stable tree (5.4, 5.10, 5.15, 6.1, 6.6, 6.12,
6.17) contains `amd_gpio_acpi_match[]`. Adding one more entry applies
trivially.

**Step 6.2: Backport Complications**
Record: Clean apply expected across all active stable trees. The context
lines (`AMD0030`, `AMDI0030`, `AMDI0031` entries) are present in every
stable tree that contains the driver.

**Step 6.3: Related fixes already in stable?**
Record: No — this ID is genuinely new. Not a duplicate of anything.

### PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1: Subsystem**
Record: `drivers/pinctrl/pinctrl-amd.c` — AMD GPIO/pinctrl driver used
on essentially all modern AMD client platforms (laptops/desktops).
Criticality: IMPORTANT — without this binding, GPIO-driven devices
(trackpads, PM controls, power buttons, wake sources) on affected AMD
systems may not work, and wake-from-suspend can regress.

**Step 7.2: Activity**
Record: Actively maintained; regular but modest activity. New ACPI HIDs
appear every few years as AMD rolls out new platform silicon.

### PHASE 8: IMPACT AND RISK

**Step 8.1: Who's affected**
Record: Users of new AMD platforms (SoCs/APUs) whose firmware exposes
GPIO with `_HID "AMDI0033"`. Without this patch, the `amd_gpio` driver
never binds → no pinctrl/GPIO, and anything depending on it (e.g., I2C
HID trackpads routed through AMD GPIO interrupts, wake-on-GPIO) fails.

**Step 8.2: Trigger**
Record: Triggered at every boot on affected hardware. Extremely
deterministic — it's simply whether the driver binds or not.

**Step 8.3: Failure Mode Severity**
Record: Without the patch: non-functional input/power/wake peripherals
on new AMD platforms. Not a crash, but a severe hardware-enablement
functional regression (no keyboard/trackpad/wake). Severity HIGH for
affected users.

**Step 8.4: Risk-Benefit**
Record: BENEFIT: high for owners of new AMD hardware that lands on
stable kernels. RISK: near-zero — adding an ACPI match entry cannot
break existing hardware, cannot introduce UAF/locking/corruption, and
the driver's probe path is unchanged. This is the textbook safe stable
exception.

### PHASE 9: SYNTHESIS

**Step 9.1: Evidence**
For: Exactly matches the explicit stable exception "NEW DEVICE IDs —
trivial one-line additions to existing drivers that enable hardware
support." One-line addition. Maintainer SoB. Vendor author. Long-
established driver. Prior precedent `AMDI0031` was added the same way.
Clean apply.
Against: None of substance. No Fixes:/Cc: stable (expected for review
candidates, not a negative signal per the criteria).
Unresolved: Could not read lore thread replies directly due to Anubis.

**Step 9.2: Stable Rules**
1. Obviously correct and tested? Yes — trivial table entry, in mainline
   under the maintainer.
2. Fixes real issue? Yes — enables hardware that otherwise won't work.
3. Important? Yes — GPIO/pinctrl is foundational for input/power/wake on
   affected AMD systems.
4. Small and contained? Yes — +1 line in one file.
5. New feature or API? No — no new API, no new uapi.
6. Applies to stable? Yes — context is ancient and unchanged.

**Step 9.3: Exception Category**
Hits the "NEW DEVICE IDs" exception explicitly.

**Step 9.4: Decision**
Classic stable-worthy one-line ACPI ID add to an existing, mature
driver. Risk is near zero; benefit is real hardware enablement on new
AMD platforms.

## Verification

- [Phase 1] Read commit subject, body, and tags; confirmed no Fixes:/Cc:
  stable/Reported-by/Link tags; two SoBs (AMD author + pinctrl
  maintainer Linus Walleij).
- [Phase 2] Read the diff: single entry `{ "AMDI0033", 0},` appended
  between `AMDI0031` and terminator in `amd_gpio_acpi_match[]` in
  `drivers/pinctrl/pinctrl-amd.c` (lines ~1273–1278). Confirmed no
  function body changes.
- [Phase 2] Read `drivers/pinctrl/pinctrl-amd.c` lines 1270–1298 to
  confirm context and that `MODULE_DEVICE_TABLE(acpi, ...)` is
  unchanged.
- [Phase 3] `git blame drivers/pinctrl/pinctrl-amd.c -L 1273,1280`:
  table introduced by `dbad75dd1f25e0` (Ken Xue, 2015); `AMDI0030` added
  by `42a44402ecb78` (2016); `AMDI0031` added by `1ca46d3e43569` (2021).
  Confirms long-standing driver and precedent for the same kind of
  change.
- [Phase 3] `git log --oneline -5 -- drivers/pinctrl/pinctrl-amd.c`:
  recent churn is benign and unrelated to the match table.
- [Phase 3] `git log --oneline --author="Basavaraj" -10 --
  drivers/pinctrl/pinctrl-amd.c`: author has a substantive history of
  AMD pinctrl commits — established AMD platform engineer.
- [Phase 4] `b4 dig -c 127e98c05c466`: matched by patch-id; URL `https:/
  /lore.kernel.org/all/20260327050616.3816318-1-
  Basavaraj.Natikar@amd.com/`.
- [Phase 4] `b4 dig -c 127e98c05c466 -a`: only a single revision (v1 /
  RESEND); no evolution from reviewer feedback.
- [Phase 4] `b4 dig -c 127e98c05c466 -w`: original recipients included
  Linus Walleij (maintainer), linux-gpio list, and AMD reviewers —
  appropriate coverage.
- [Phase 5] Grep for `AMDI003[0-9]` across the tree: new ID occurs only
  in `drivers/pinctrl/pinctrl-amd.c`; existing `AMDI0030` references in
  `drivers/gpio/gpiolib-acpi-quirks.c` are quirk entries not dependent
  on this patch.
- [Phase 6] Confirmed by blame that the `amd_gpio_acpi_match[]` array
  structure has existed since 2015, so context applies cleanly to all
  active stable trees.
- [Phase 8] Impact reasoning is based on how ACPI platform driver
  binding works generically (match table controls probe); no user-bug-
  report was needed because the change is a pure hardware-enablement
  addition.
- UNVERIFIED: I could not directly read replies on the lore thread
  because lore.kernel.org is currently gated by Anubis anti-bot; however
  `b4 dig -a` showed no later revisions, and the maintainer's SoB on the
  committed patch indicates no unresolved objections.
- UNVERIFIED: I did not enumerate every stable branch's exact file state
  because this is a workspace-only checkout; however, since all
  preceding IDs (`AMDI0030`, `AMDI0031`) have been present since 2016
  and 2021 respectively and the match-table block has not been
  restructured, clean apply is expected on 5.4+.

This commit is a textbook stable exception: a trivial one-line ACPI
device ID addition to an existing, widely-used driver, authored by the
hardware vendor and signed off by the subsystem maintainer. Risk is
effectively zero; benefit is enabling GPIO/pinctrl on new AMD platforms
that would otherwise be non-functional.

**YES**

 drivers/pinctrl/pinctrl-amd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/pinctrl-amd.c b/drivers/pinctrl/pinctrl-amd.c
index 2af94ef564342..e3128b0045d22 100644
--- a/drivers/pinctrl/pinctrl-amd.c
+++ b/drivers/pinctrl/pinctrl-amd.c
@@ -1274,6 +1274,7 @@ static const struct acpi_device_id amd_gpio_acpi_match[] = {
 	{ "AMD0030", 0 },
 	{ "AMDI0030", 0},
 	{ "AMDI0031", 0},
+	{ "AMDI0033", 0},
 	{ },
 };
 MODULE_DEVICE_TABLE(acpi, amd_gpio_acpi_match);
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] gpio: da9055: normalize return value of gpio_get

[Sasha Levin]

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

[ Upstream commit 4d720b0d68e9a251d60804eace42aac800d7a79f ]

The GPIO get callback is expected to return 0 or 1 (or a negative error
code). Ensure that the value returned by da9055_gpio_get() is normalized
to the [0, 1] range.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://patch.msgid.link/20260218190657.2974723-3-dmitry.torokhov@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have a complete picture. Let me compile the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `gpio: da9055`
- Action verb: "normalize" (implies correcting incorrect behavior)
- Summary: Normalize the return value of `da9055_gpio_get()` to conform
  to the GPIO API contract of returning 0 or 1.

**Step 1.2: Tags**
- `Signed-off-by: Dmitry Torokhov` - author, well-known kernel developer
  (input subsystem maintainer)
- `Link: https://patch.msgid.link/20260218190657.2974723-3-
  dmitry.torokhov@gmail.com` - part 3 of a series
- `Signed-off-by: Bartosz Golaszewski` - GPIO subsystem maintainer,
  accepted the patch
- No Fixes: tag, no Cc: stable (expected for AUTOSEL candidates)
- No Reported-by or Tested-by tags

**Step 1.3: Commit Body**
The message explains: the GPIO `.get()` callback must return 0 or 1 (or
negative error). `da9055_gpio_get()` was not normalizing its return
value, potentially returning values like 2, 4, or 8.

**Step 1.4: Hidden Bug Fix Detection**
Yes - this is a real bug fix disguised as a "normalize" cleanup. The
`.get()` callback violates its API contract, and since commit
`86ef402d805d` in v6.15, the gpiolib framework actively checks for this
violation.

Record: This is a bug fix for API contract violation.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Change Inventory**
- Single file: `drivers/gpio/gpio-da9055.c`
- One line changed: `return ret & (1 << offset);` → `return !!(ret & (1
  << offset));`
- Function: `da9055_gpio_get()`
- Scope: single-line surgical fix

**Step 2.2: Code Flow Change**
Before: `ret & (1 << offset)` returns the raw bit value, which for
offset=1 is 2, for offset=2 is 4. The GPIO API contract requires 0 or 1.
After: `!!(ret & (1 << offset))` normalizes to boolean 0 or 1.

**Step 2.3: Bug Mechanism**
Category: Logic/correctness fix (API contract violation). The `1 <<
offset` mask for offset > 0 produces values > 1 when the bit is set.

**Step 2.4: Fix Quality**
Obviously correct. The `!!` operator is the standard C idiom for boolean
normalization. Zero regression risk - it only changes non-zero values >
1 to 1, which is the intended semantics.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
The buggy line was introduced in commit `04ed4279715f68` (2012-09-14) -
the original DA9055 GPIO driver by Ashish Jangam. The bug has existed
since the driver was created.

**Step 3.2: Related Fixes**
While this commit lacks a `Fixes:` tag, the **identical** fixes by the
same author for other drivers all reference `Fixes: 86ef402d805d
("gpiolib: sanitize the return value of gpio_chip::get()")`:
- `e2fa075d5ce19` (ti-ads7950) - has Fixes: + Cc: stable
- `2bb995e6155cb` (qca807x) - has Fixes:
- `fb22bb9701d48` (rza1) - has Fixes:
- `fbd03587ba732` (amd-fch) - has Fixes:

The missing tags on this da9055 commit appear to be an oversight.

**Step 3.3: File History**
No other recent changes to gpio-da9055.c that would conflict.

**Step 3.4: Author**
Dmitry Torokhov is a major kernel contributor (input subsystem
maintainer). He reported the issue that led to `ec2cceadfae72` (the
gpiolib normalize wrapper) and systematically fixed affected drivers.

**Step 3.5: Dependencies**
None. This is completely standalone - it just adds `!!` to one return
expression.

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1-4.2:** b4 dig could not find the da9055 commit specifically
(it's not yet in the tree). However, b4 found the related series
patches, confirming this is part of Dmitry's systematic effort to fix
non-compliant GPIO drivers.

**Step 4.3:** The bug report chain originates from `ec2cceadfae72`
discussion where Dmitry reported that `86ef402d805d` broke multiple
drivers.

**Step 4.4:** This is part of a series of driver-level fixes submitted
alongside the framework-level normalize wrapper. The da9055 fix is
standalone.

**Step 4.5:** Similar driver fixes from this same series were backported
to 6.19.y stable. The da9055 one was not, likely because it lacks
Fixes:/Cc:stable tags.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1:** Modified function: `da9055_gpio_get()`

**Step 5.2:** `da9055_gpio_get()` is registered as the `.get` callback
in the `reference_gp` gpio_chip structure. It is called by the gpiolib
framework via `gpiochip_get()` whenever any consumer reads a GPIO value
from this PMIC.

**Step 5.3:** The function reads register values via `da9055_reg_read()`
(I2C), then returns a masked bit value.

**Step 5.4:** Call chain: userspace/kernel consumer →
`gpiod_get_value_cansleep()` → `gpiod_get_raw_value_commit()` →
`gpio_chip_get_value()` → `gpiochip_get()` → `da9055_gpio_get()`. The
path is reachable from any GPIO consumer.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: CRITICAL FINDING - v6.15.y is broken:**

I verified the state of stable trees:

- **v6.12.y and earlier**: Do NOT have `86ef402d805d` (sanitize commit).
  The da9055 driver returns non-normalized values, but gpiolib doesn't
  check, so it "works" (though technically wrong). Fix is low-priority
  here.

- **v6.15.y**: HAS `86ef402d805d` (sanitize: `ret > 1 → -EBADE`). Does
  NOT have `ec2cceadfae72` (normalize wrapper). **The da9055 GPIO driver
  is BROKEN** - reading GPIO at offset 1 or 2 when active returns
  `-EBADE` (error) instead of 1.

- **v6.19.y**: HAS both sanitize and normalize wrapper. da9055 works but
  emits a warning on every read of an active GPIO with offset > 0.

- **v7.0.y**: Same as v6.19.y.

**Step 6.2:** Patch applies cleanly - the code hasn't changed since
2012.

**Step 6.3:** The da9055 normalize fix is NOT in any stable tree.

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1:** GPIO subsystem, driver for Dialog DA9055 PMIC - a specific
hardware device. Criticality: PERIPHERAL (specific hardware), but GPIO
is a fundamental interface.

**Step 7.2:** The da9055 driver has been stable/untouched since 2012.
The bug only became functional via the gpiolib sanitize commit in 6.15.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1:** Affected: Users of DA9055 PMIC hardware (Dialog
Semiconductor).

**Step 8.2:** Trigger: Any read of GPIO pin 1 or 2 when active. This is
a basic operation, not an edge case.

**Step 8.3:** Failure mode in v6.15.y: GPIO read returns `-EBADE` error
instead of the actual value. This breaks GPIO functionality for the
device. Severity: **HIGH** for affected hardware users.

**Step 8.4:**
- Benefit: Fixes actual GPIO breakage in 6.15.y, eliminates warnings in
  6.19.y/7.0.y
- Risk: Virtually zero - single `!!` addition, obviously correct boolean
  normalization
- Ratio: Very favorable

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
1. Fixes a real GPIO breakage in v6.15.y stable (returns -EBADE for
   active GPIOs at offset > 0)
2. Eliminates runtime warnings in v6.19.y and v7.0.y
3. Identical fixes for other drivers WERE tagged Fixes: + Cc: stable
4. Trivially correct 1-character change (`!!`)
5. Zero regression risk
6. The bug has existed since 2012 but became a real breakage in 6.15+
7. Accepted by GPIO subsystem maintainer Bartosz Golaszewski
8. Author is a major kernel contributor who reported the original
   framework issue

**Evidence AGAINST backporting:**
1. Missing Fixes: and Cc: stable tags (but likely an oversight given
   sibling commits have them)
2. DA9055 PMIC is old hardware with potentially few users

**Stable rules checklist:**
1. Obviously correct and tested? **YES** - trivial `!!` normalization
2. Fixes a real bug? **YES** - API contract violation causing -EBADE in
   6.15+
3. Important issue? **YES** - GPIO completely broken for this hardware
   in 6.15.y
4. Small and contained? **YES** - 1 character change
5. No new features? **YES** - pure fix
6. Applies to stable? **YES** - code unchanged since 2012

## Verification

- [Phase 1] Parsed tags: Link to patch.msgid.link (part 3 of series),
  signed off by GPIO maintainer
- [Phase 2] Diff analysis: single character change `!!` added to
  normalize return value in `da9055_gpio_get()`
- [Phase 3] git blame: buggy code from `04ed4279715f68` (2012), original
  DA9055 driver creation
- [Phase 3] Checked sibling commits: `e2fa075d5ce19`, `2bb995e6155cb`,
  `fb22bb9701d48` all have `Fixes: 86ef402d805d` and were tagged for
  stable
- [Phase 4] b4 dig confirmed series context via related commits
- [Phase 5] `da9055_gpio_get()` called by gpiolib framework via
  `gpiochip_get()` wrapper
- [Phase 6] v6.15.11 confirmed: has sanitize (`ret > 1 → -EBADE`) but
  NOT normalize wrapper → da9055 GPIO broken
- [Phase 6] v6.19.12 confirmed: has normalize wrapper → da9055 works
  with warning
- [Phase 6] v6.12.81 confirmed: no sanitize commit → no breakage (pre-
  existing mild API violation)
- [Phase 6] da9055 buggy line confirmed at line 58 in v6.15.11
- [Phase 8] Failure mode in 6.15.y: `gpiochip_get()` returns -EBADE for
  GPIO offsets 1,2 when active. Severity HIGH.

This is a trivially correct one-character fix that resolves a real GPIO
breakage in v6.15.y stable and eliminates runtime warnings in 6.19.y and
7.0.y. The missing Fixes: tag is clearly an oversight given that all
sibling commits from the same author and series have it. The risk is
effectively zero.

**YES**

 drivers/gpio/gpio-da9055.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-da9055.c b/drivers/gpio/gpio-da9055.c
index a09bd6eb93cfb..1949a6ea8ec61 100644
--- a/drivers/gpio/gpio-da9055.c
+++ b/drivers/gpio/gpio-da9055.c
@@ -55,7 +55,7 @@ static int da9055_gpio_get(struct gpio_chip *gc, unsigned offset)
 			return ret;
 	}
 
-	return ret & (1 << offset);
+	return !!(ret & (1 << offset));
 
 }
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] gpio: bd9571mwv: normalize return value of gpio_get

[Sasha Levin]

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

[ Upstream commit c43778680546dd379b3d8219c177b1a34ba87002 ]

The GPIO get callback is expected to return 0 or 1 (or a negative error
code). Ensure that the value returned by bd9571mwv_gpio_get() is
normalized to the [0, 1] range.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://patch.msgid.link/20260218190657.2974723-1-dmitry.torokhov@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have the full picture. Let me compile the complete analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1**: Subsystem: `gpio/bd9571mwv`. Action verb: "normalize"
(ensure correctness). Summary: Normalize the return value of the GPIO
get callback to comply with the API contract (0 or 1).

**Step 1.2**: Tags:
- `Signed-off-by: Dmitry Torokhov` - author, well-known kernel
  maintainer (input subsystem lead)
- `Link:` to patch.msgid.link for the original submission
- `Signed-off-by: Bartosz Golaszewski` - GPIO subsystem maintainer who
  applied it
- No `Fixes:` tag, no `Cc: stable`, no `Reported-by:` in this specific
  commit

**Step 1.3**: The commit message states the GPIO `get()` callback API
contract requires return values of 0 or 1 (or negative error). The
driver was returning `val & BIT(offset)` which can return values like 2
for offset 1.

**Step 1.4**: This IS a bug fix despite neutral "normalize" language. It
fixes an API contract violation that became a functional bug after
gpiolib changes.

## PHASE 2: DIFF ANALYSIS

**Step 2.1**: Single file changed (`drivers/gpio/gpio-bd9571mwv.c`),
single line modified. Function: `bd9571mwv_gpio_get()`.

**Step 2.2**: Before: `return val & BIT(offset)` returns 0, 1, 2, 4,
etc. depending on offset. After: `return !!(val & BIT(offset))` returns
0 or 1.

**Step 2.3**: Bug category: **Logic/correctness fix + API contract
violation**. The driver has `.ngpio = 2` (offsets 0 and 1). For offset
0, `BIT(0) = 1`, so the return was 0 or 1 (fine). For offset 1, `BIT(1)
= 2`, so the return was 0 or 2 (broken).

The critical context is commit `86ef402d805d` ("gpiolib: sanitize the
return value of gpio_chip::get()"), merged in v6.15-rc1, which made
gpiolib return `-EBADE` when `get()` returns > 1. This turned the API
violation into a **functional failure** for GPIO offset 1.

Subsequently, `ec2cceadfae72` ("gpiolib: normalize the return value of
gc->get() on behalf of buggy drivers"), merged in v7.0-rc2, softened
this to normalize the value with a warning instead of returning -EBADE.

**Step 2.4**: Fix quality: Trivially correct. `!!` is a well-established
C pattern for boolean normalization. Zero regression risk.

## PHASE 3: GIT HISTORY

**Step 3.1**: The buggy `return val & BIT(offset)` line was introduced
in `9384793036afb7` (2017-04-25) - the original driver addition by Marek
Vasut. This code has been present since ~v4.13.

**Step 3.2**: The commit under review has no Fixes: tag. However, the
identical fix in related drivers (`2bb995e6155cb` for qca807x,
`e2fa075d5ce19` for ti-ads7950) both have `Fixes: 86ef402d805d`. From
the mailing list discussion, Andrew Lunn asked Dmitry to add a Fixes:
tag on the qca807x version, and it was agreed to reference
`86ef402d805d`.

**Step 3.3**: `86ef402d805d` was introduced in v6.15-rc1. It is NOT in
v6.12 or v6.6 stable trees (confirmed by `git merge-base --is-
ancestor`). The safety-net `ec2cceadfae72` has `Cc: stable` and `Fixes:
86ef402d805d`, so it will be backported to v6.15.y.

**Step 3.4**: Dmitry Torokhov is a well-known kernel maintainer (Linux
input subsystem lead). He submitted multiple "normalize return value of
gpio_get" patches across different drivers simultaneously, all fixing
the same class of bug. He was also the reporter of the issue that led to
`ec2cceadfae72`.

**Step 3.5**: No prerequisites needed. The `!!` change is standalone.

## PHASE 4: MAILING LIST RESEARCH

From the mailing list discussion of the qca807x patch (same author, same
pattern):
- Andrew Lunn asked for a Fixes: tag and suggested `86ef402d805d`
- Linus Walleij gave Reviewed-by
- Bartosz Golaszewski (GPIO maintainer) gave Reviewed-by
- The author confirmed this is a fix for the gpiolib tightening
- The bd9571mwv patch was sent separately and routed through GPIO
  maintainer directly

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1**: Only `bd9571mwv_gpio_get()` is modified.

**Step 5.2**: This is called by gpiolib core (`gpiochip_get()` wrapper
at line 3259 of gpiolib.c), which validates the return value:

```3259:3275:/home/sasha/linux-autosel-7.0/drivers/gpio/gpiolib.c
static int gpiochip_get(struct gpio_chip *gc, unsigned int offset)
{
        int ret;

        lockdep_assert_held(&gc->gpiodev->srcu);

        /* Make sure this is called after checking for gc->get(). */
        ret = gc->get(gc, offset);
        if (ret > 1) {
                gpiochip_warn(gc,
                        "invalid return value from gc->get(): %d,
consider fixing the driver\n",
                        ret);
                ret = !!ret;
        }

        return ret;
}
```

**Step 5.4**: The call chain is: userspace GPIO access ->
gpiod_get_value() -> gpio_chip_get_value() -> gpiochip_get() ->
gc->get() (= bd9571mwv_gpio_get). This is reachable from userspace via
the GPIO chardev interface.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1**: The *original* bug (returning > 1) has existed since
v4.13, but it was harmless until `86ef402d805d` (v6.15-rc1). The code
that makes this a *real* bug only exists in v6.15+.

**Step 6.2**: Clean apply expected - the file has barely changed. Only
the one line being fixed.

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1**: GPIO driver for ROHM BD9571MWV/BD9574MWF PMIC (Renesas
R-Car platforms). Criticality: PERIPHERAL (specific embedded hardware).

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1**: Affects users of Renesas R-Car platforms with ROHM
BD9571MWV PMIC GPIO.

**Step 8.2**: Triggered any time GPIO offset 1 is read. Common operation
for users of this hardware.

**Step 8.3**:
- Without `ec2cceadfae72`: GPIO reads on offset 1 return -EBADE
  (functional failure, severity HIGH)
- With `ec2cceadfae72`: GPIO reads on offset 1 trigger a kernel warning
  (severity MEDIUM)

**Step 8.4**:
- BENEFIT: Fixes functional correctness for this driver; eliminates
  kernel warnings
- RISK: Essentially zero - one-character change (`!!` addition),
  obviously correct, same pattern applied to 5+ other drivers
- Ratio: Highly favorable

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- One-line, obviously correct fix (!! normalization)
- Fixes a real API contract violation that causes functional failure or
  warnings
- Same fix pattern applied to multiple drivers by the same author
- Related patches have `Fixes: 86ef402d805d` tag (omission in this patch
  appears accidental)
- Reviewed and applied by GPIO subsystem maintainer Bartosz Golaszewski
- Reviewed by Linus Walleij (on related patches)
- Zero regression risk
- The gpiolib wrapper `ec2cceadfae72` explicitly says "consider fixing
  the driver" in its warning message - this IS that fix

**Evidence AGAINST backporting:**
- No explicit `Fixes:` tag or `Cc: stable` on this specific commit
- The safety net `ec2cceadfae72` already prevents functional failure
  (converts to warning)
- Affects niche hardware (ROHM PMIC on Renesas platforms)
- The underlying issue (`86ef402d805d`) only exists in v6.15+, limiting
  stable tree applicability

**Stable rules checklist:**
1. Obviously correct? YES - `!!` is a trivial, standard normalization
2. Fixes a real bug? YES - API violation causing -EBADE or warnings
3. Important issue? MEDIUM - functional failure without safety net;
   warnings with it
4. Small and contained? YES - one line, one file
5. No new features? Correct
6. Can apply to stable? YES - clean apply expected

## Verification

- [Phase 1] Parsed tags: No Fixes: or Cc: stable on this commit
  (expected for AUTOSEL candidate)
- [Phase 2] Diff: single line `return val & BIT(offset)` → `return
  !!(val & BIT(offset))` in bd9571mwv_gpio_get()
- [Phase 3] git blame: buggy code from commit 9384793036afb7 (v4.13,
  2017), present since driver creation
- [Phase 3] git show 86ef402d805d: confirmed gpiolib sanitize commit in
  v6.15-rc1, returns -EBADE for get() > 1
- [Phase 3] git show ec2cceadfae72: confirmed safety net commit in
  v7.0-rc2, normalizes with warning
- [Phase 3] merge-base: 86ef402d805d IS in v6.15 (exit=0), NOT in v6.12
  (exit=1) or v6.6 (exit=1)
- [Phase 3] Related patches 2bb995e6155cb (qca807x) and e2fa075d5ce19
  (ti-ads7950) both have `Fixes: 86ef402d805d`
- [Phase 4] Mailing list (via b4 dig on related qca807x patch): Andrew
  Lunn confirmed Fixes: 86ef402d805d is appropriate; Linus Walleij and
  Bartosz Golaszewski provided Reviewed-by
- [Phase 5] Call chain verified: userspace → gpiod_get_value →
  gpio_chip_get_value → gpiochip_get → bd9571mwv_gpio_get
- [Phase 5] gpiolib.c line 3267-3272: confirmed validation wrapper
  checks for ret > 1 and emits warning
- [Phase 6] Driver file unchanged since 2021; clean apply expected
- [Phase 8] .ngpio = 2 confirmed at line 93; offset 1 returns BIT(1) =
  2, triggering the bug

The fix is a trivially correct one-line change that addresses a real API
contract violation. It eliminates either -EBADE errors (v6.15 without
safety net) or kernel warnings (v7.0 with safety net) when reading GPIO
offset 1. The fix carries essentially zero regression risk and is part
of a coordinated effort by the author to fix this class of bug across
multiple drivers, with identical patches in other drivers having
explicit `Fixes:` tags.

**YES**

 drivers/gpio/gpio-bd9571mwv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-bd9571mwv.c b/drivers/gpio/gpio-bd9571mwv.c
index 7c95bb36511e1..cc5b1746f2fe8 100644
--- a/drivers/gpio/gpio-bd9571mwv.c
+++ b/drivers/gpio/gpio-bd9571mwv.c
@@ -69,7 +69,7 @@ static int bd9571mwv_gpio_get(struct gpio_chip *chip, unsigned int offset)
 	if (ret < 0)
 		return ret;
 
-	return val & BIT(offset);
+	return !!(val & BIT(offset));
 }
 
 static int bd9571mwv_gpio_set(struct gpio_chip *chip, unsigned int offset,
-- 
2.53.0

[PATCH AUTOSEL 6.18] gpio: tegra: fix irq_release_resources calling enable instead of disable

[Sasha Levin]

From: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>

[ Upstream commit 1561d96f5f55c1bca9ff047ace5813f4f244eea6 ]

tegra_gpio_irq_release_resources() erroneously calls tegra_gpio_enable()
instead of tegra_gpio_disable(). When IRQ resources are released, the
GPIO configuration bit (CNF) should be cleared to deconfigure the pin as
a GPIO. Leaving it enabled wastes power and can cause unexpected behavior
if the pin is later reused for an alternate function via pinctrl.

Fixes: 66fecef5bde0 ("gpio: tegra: Convert to gpio_irq_chip")
Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>
Link: https://patch.msgid.link/20260407210247.1737938-1-samasth.norway.ananda@oracle.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 drivers/gpio/gpio-tegra.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
index 15a5762a82c25..b14052fe64ac6 100644
--- a/drivers/gpio/gpio-tegra.c
+++ b/drivers/gpio/gpio-tegra.c
@@ -595,7 +595,7 @@ static void tegra_gpio_irq_release_resources(struct irq_data *d)
 	struct tegra_gpio_info *tgi = gpiochip_get_data(chip);
 
 	gpiochip_relres_irq(chip, d->hwirq);
-	tegra_gpio_enable(tgi, d->hwirq);
+	tegra_gpio_disable(tgi, d->hwirq);
 }
 
 static void tegra_gpio_irq_print_chip(struct irq_data *d, struct seq_file *s)
-- 
2.53.0