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

[Sasha Levin <sashal@kernel.org>]

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