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

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

[Sasha Levin]

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

[ Upstream commit 5a32ebabb6819fafce99e7bc6575ca568af6d22a ]

The GPIO get callback is expected to return 0 or 1 (or a negative error
code). Ensure that the value returned by lp873x_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-4-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 I need. Let me compile the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `gpio: lp873x`
- Action: "normalize" (correctness fix, ensuring API compliance)
- Summary: Normalize return value of `gpio_get` callback to [0, 1] range
Record: [gpio: lp873x] [normalize] [Fix return value to comply with GPIO
API contract]

**Step 1.2: Tags**
- `Signed-off-by: Dmitry Torokhov` - Author, major kernel contributor
  (input subsystem maintainer, also contributes to GPIO)
- `Link: https://patch.msgid.link/20260218190657.2974723-4-
  dmitry.torokhov@gmail.com` - Patch 4 in a series
- `Signed-off-by: Bartosz Golaszewski` - GPIO subsystem maintainer
  applied it
- No Fixes: tag (expected for AUTOSEL candidates)
- No Cc: stable tag
Record: Author is a well-known kernel maintainer. Patch applied by GPIO
subsystem maintainer.

**Step 1.3: Commit Body**
The commit message explains the GPIO `.get()` callback API contract: it
must return 0, 1, or negative error. The lp873x driver violated this.
Record: Bug = API contract violation. Return value is non-normalized
(can return values > 1 like 16).

**Step 1.4: Hidden Bug Fix?**
Yes. "normalize" disguises a real correctness bug. The driver returns
`val & BIT(offset * BITS_PER_GPO)` which for offset=1 returns 16 (not 0
or 1). This violates the GPIO API contract.
Record: This IS a bug fix despite "normalize" language.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file: `drivers/gpio/gpio-lp873x.c`, 1 line changed
- Function modified: `lp873x_gpio_get()`
Record: Minimal single-line change in one function.

**Step 2.2: Code Flow Change**
Before: `return val & BIT(offset * BITS_PER_GPO);` - returns 0 or
BIT(offset*4), which for offset=1 is 16.
After: `return !!(val & BIT(offset * BITS_PER_GPO));` - returns 0 or 1.
Record: Changes return value normalization on the normal code path.

**Step 2.3: Bug Mechanism**
Category: Logic/correctness fix (type g). `BITS_PER_GPO` is 4. For
offset=0, `BIT(0)=1` (fine). For offset=1, `BIT(4)=16` (bug - returns 16
instead of 1).

This interacts critically with `86ef402d805d` (sanitizer added in
v6.15):
- **Original sanitizer** (v6.15): Returns `-EBADE` if `ret > 1` --
  meaning GPO2 reads would FAIL with an error
- **Revised sanitizer** (v7.0, commit `ec2cceadfae72`): Warns and
  normalizes to `!!ret`
- **Without sanitizer** (v6.14 and older): Non-normalized value
  propagated to consumers

Record: API violation; offset=1 returns 16 instead of 1. Can cause
-EBADE errors in some stable tree versions.

**Step 2.4: Fix Quality**
Trivially correct. `!!` is the standard C idiom for boolean
normalization. Zero regression risk.
Record: Obviously correct, minimal, zero risk.

## PHASE 3: GIT HISTORY

**Step 3.1: Blame**
The buggy line (`return val & BIT(...)`) was introduced in
`83f141030cec88` (2016-08-31, v4.9) - the original driver. Bug present
since inception.
Record: Bug exists since v4.9, present in all stable trees.

**Step 3.2: Fixes Tag**
No Fixes: tag present. However, sister commits reference `Fixes:
86ef402d805d`. The lp873x commit likely should have had this tag.
Record: Sister commits all have `Fixes: 86ef402d805d`.

**Step 3.3: File History**
Only 2 changes since v6.6: `30d15b8949828` (GPIO set callback rename)
and `d9d87d90cc0b1` (rename back). Neither affects `lp873x_gpio_get()`.
The fix applies cleanly to all stable trees.
Record: Standalone fix, no prerequisites for the get() function.

**Step 3.4: Author**
Dmitry Torokhov is the input subsystem maintainer and a very active
kernel contributor. He authored multiple similar GPIO normalization
fixes (`fbd03587ba732` for amd-fch, `2bb995e6155cb` for qca807x,
`e2fa075d5ce19` for ti-ads7950). He also reported the issue that led to
the gpiolib sanitizer fix `ec2cceadfae72`.
Record: Highly trusted author. Systematic fix across multiple drivers.

**Step 3.5: Dependencies**
None. The change to `lp873x_gpio_get()` is self-contained - the function
hasn't changed since 2016.
Record: No dependencies. Clean apply expected.

## PHASE 4: MAILING LIST

**Step 4.1-4.2**: Lore is behind a bot protection wall. However, b4 dig
confirmed the series and the sister patches. The patch was accepted by
the GPIO subsystem maintainer (Bartosz Golaszewski).

**Step 4.3: Bug Context**
The framework-level fix `ec2cceadfae72` was prompted by Dmitry Torokhov
reporting that `86ef402d805d` broke multiple drivers. Bartosz
Golaszewski then:
1. Changed the sanitizer from -EBADE to warn+normalize
2. CC'd stable on that fix
3. Accepted all driver-level fixes from Dmitry

**Step 4.4: Series Context**
This is patch 4 in a series of GPIO normalization fixes. Each patch is
independent (different drivers).

**Step 4.5: Stable Discussion**
The sister commit `e2fa075d5ce19` (ti-ads7950) explicitly has `Cc:
<Stable@vger.kernel.org>`. The framework fix `ec2cceadfae72` also has
`Cc: stable`. This lp873x patch appears to have missed the Cc: stable
tag despite being the same class of fix.
Record: Sister patches have Cc: stable. This one appears to have been
missed.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1-5.2**: `lp873x_gpio_get` is called via the `.get` callback in
`template_chip`. The GPIO framework calls it through `gpiochip_get()` ->
`gpio_chip_get_value()` -> gpiod_get_value/gpiod_get_raw_value paths.

**Step 5.4**: Call chain: userspace GPIO access -> gpiod_get_value() ->
gpio_chip_get_value() -> gpiochip_get() -> lp873x_gpio_get(). Reachable
from userspace via the GPIO chardev interface.

Record: Reachable from userspace, called on every GPIO read of this
device.

## PHASE 6: CROSS-REFERENCING

**Step 6.1**: The buggy code exists in all stable trees (since v4.9).
The lp873x driver has barely changed.

**Step 6.2**: The `lp873x_gpio_get()` function is unchanged since 2016.
The fix should apply cleanly to all stable trees.

**Step 6.3**: No related fixes for this specific driver in stable.

Record: Clean backport expected to all active stable trees.

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1**: GPIO subsystem - IMPORTANT level. GPIO is used widely in
embedded/IoT systems.
**Step 7.2**: The lp873x is a TI PMIC used in embedded/industrial
systems (BeagleBone, etc.).
Record: Peripheral driver but with real embedded users.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1**: Affects users of LP873x PMIC GPO2 (offset=1). The LP873x
is used on TI AM335x/AM57xx platforms.

**Step 8.2**: Triggered on every GPIO read of GPO2. Impact varies by
stable tree:
- v6.15+ with only `86ef402d805d`: Returns -EBADE error (FUNCTIONAL
  BREAKAGE)
- v7.0+ with `ec2cceadfae72`: Warning in dmesg
- v6.14 and older: Non-normalized value to consumers (potential subtle
  bugs)

**Step 8.3**: Severity varies: MEDIUM (warning + potential wrong
behavior) to HIGH (functional breakage with -EBADE in certain stable
trees)

**Step 8.4**: BENEFIT: Eliminates API violation, prevents -EBADE errors
in some trees, removes warning. RISK: Essentially zero (single `!!`
addition).

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR:**
1. Trivial 1-line fix, obviously correct (`!!` normalization)
2. Fixes real API contract violation (returning 16 instead of 1)
3. Zero regression risk
4. Sister patches (`e2fa075d5ce19`, `2bb995e6155cb`) have `Cc: stable`
   and `Fixes:` tags
5. Author is highly trusted kernel maintainer
6. Applied by GPIO subsystem maintainer
7. Bug present since v4.9 - affects all stable trees
8. In some stable trees (v6.15+), the unfixed driver causes -EBADE
   functional errors
9. Clean backport expected - function unchanged since 2016

**Evidence AGAINST:**
1. No Fixes: tag or Cc: stable on this specific commit (likely
   oversight)
2. Low user population (LP873x PMIC users only)
3. Impact in latest stable trees is "just" a warning (with the sanitizer
   normalization)

**Stable Rules Checklist:**
1. Obviously correct? **YES** - `!!` is standard normalization
2. Fixes real bug? **YES** - API violation, wrong return values
3. Important issue? **MEDIUM-HIGH** - can cause -EBADE in some trees
4. Small and contained? **YES** - 1 line, 1 file
5. No new features? **YES** - pure fix
6. Can apply to stable? **YES** - function unchanged since 2016

## Verification

- [Phase 1] Parsed tags: Author is Dmitry Torokhov, applied by GPIO
  maintainer Bartosz Golaszewski. No Fixes:/Cc:stable.
- [Phase 2] Diff analysis: 1 line changed in `lp873x_gpio_get()`, `val &
  BIT(...)` -> `!!(val & BIT(...))`. For offset=1, changes return from
  16 to 1.
- [Phase 3] git blame: buggy line from `83f141030cec88` (v4.9,
  2016-08-31), present in all stable trees.
- [Phase 3] git show `86ef402d805d`: sanitizer that returns -EBADE for
  ret > 1, first in v6.15.
- [Phase 3] git show `ec2cceadfae72`: follow-up changing -EBADE to
  warn+normalize, has `Cc: stable`.
- [Phase 3] Sister commits `2bb995e6155cb` (qca807x) and `e2fa075d5ce19`
  (ti-ads7950): both have `Fixes: 86ef402d805d` and one has `Cc:
  stable`.
- [Phase 3] git log: only 2 unrelated changes to lp873x since v6.6 (GPIO
  set callback renames), neither affect get().
- [Phase 4] b4 dig: confirmed sister patches found on lore. Lore itself
  blocked by bot protection.
- [Phase 5] Call chain: userspace -> gpiod_get_value -> gpiochip_get ->
  lp873x_gpio_get. Reachable from userspace.
- [Phase 6] Function `lp873x_gpio_get()` is identical in all stable
  trees since v4.9. Clean apply expected.
- [Phase 8] BITS_PER_GPO=4, offset=1 returns BIT(4)=16, confirmed via
  computation.
- UNVERIFIED: Could not directly access lore.kernel.org discussion for
  this specific patch due to bot protection. Relied on b4 dig and sister
  patch analysis.

The fix is a trivially correct 1-line normalization that fixes a real
API violation present since v4.9. Sister patches in the same series have
explicit stable nominations. The risk is essentially zero.

**YES**

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

diff --git a/drivers/gpio/gpio-lp873x.c b/drivers/gpio/gpio-lp873x.c
index 5376708a81bfe..f4413fa5a8110 100644
--- a/drivers/gpio/gpio-lp873x.c
+++ b/drivers/gpio/gpio-lp873x.c
@@ -55,7 +55,7 @@ static int lp873x_gpio_get(struct gpio_chip *chip, unsigned int offset)
 	if (ret < 0)
 		return ret;
 
-	return val & BIT(offset * BITS_PER_GPO);
+	return !!(val & BIT(offset * BITS_PER_GPO));
 }
 
 static int lp873x_gpio_set(struct gpio_chip *chip, unsigned int offset,
-- 
2.53.0

[PATCH AUTOSEL 6.18] pinctrl: intel: Fix the revision for new features (1kOhm PD, HW debouncer)

[Sasha Levin]

From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

[ Upstream commit a4337a24d13e9e3b98a113e71d6b80dc5ed5f8c4 ]

The 1kOhm pull down and hardware debouncer are features of the revision 0.92
of the Chassis specification. Fix that in the code accordingly.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

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

diff --git a/drivers/pinctrl/intel/pinctrl-intel.c b/drivers/pinctrl/intel/pinctrl-intel.c
index d68cef4ec52ac..103eccc742a53 100644
--- a/drivers/pinctrl/intel/pinctrl-intel.c
+++ b/drivers/pinctrl/intel/pinctrl-intel.c
@@ -1606,7 +1606,7 @@ int intel_pinctrl_probe(struct platform_device *pdev,
 		value = readl(regs + REVID);
 		if (value == ~0u)
 			return -ENODEV;
-		if (((value & REVID_MASK) >> REVID_SHIFT) >= 0x94) {
+		if (((value & REVID_MASK) >> REVID_SHIFT) >= 0x92) {
 			community->features |= PINCTRL_FEATURE_DEBOUNCE;
 			community->features |= PINCTRL_FEATURE_1K_PD;
 		}
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] gpio: cgbc: normalize return value of gpio_get

[Sasha Levin]

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

[ Upstream commit 49621f1c97788216f2f10f1a9e903f216e289f5d ]

The GPIO get callback is expected to return 0 or 1 (or a negative error
code). Ensure that the value returned by cgbc_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-2-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 for a complete analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `gpio: cgbc:`
- Action verb: "normalize" (implies correcting incorrect behavior)
- Summary: Normalizes the return value of the GPIO get callback to the
  [0, 1] range

**Step 1.2: Tags**
- `Signed-off-by: Dmitry Torokhov` - author, prolific kernel/input/GPIO
  contributor
- `Link:` to lore patch submission
- `Signed-off-by: Bartosz Golaszewski` - GPIO subsystem maintainer who
  applied it
- No `Fixes:` tag, no `Cc: stable` tag (but sibling patches in the same
  series DO have these tags)

**Step 1.3: Commit Body**
- Clearly states the API contract: GPIO get callback must return 0, 1,
  or negative error
- States the driver violates this by returning non-normalized values
  (e.g., 2, 4, 8, etc.)
- The fix "normalizes" to [0, 1]

**Step 1.4: Hidden Bug Fix Detection**
- YES - this is a bug fix. The driver violates the gpio_chip API
  contract. With the gpiolib sanitization commit (86ef402d805d) present
  in v6.15+, this violation causes either `-EBADE` errors or runtime
  warnings.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file changed: `drivers/gpio/gpio-cgbc.c`
- 2 lines removed, 2 lines added (net 0 change)
- Function modified: `cgbc_gpio_get()`
- Scope: single-file, single-function surgical fix

**Step 2.2: Code Flow Change**
- BEFORE: `return (int)(val & (u8)BIT(offset));` — returns the raw bit
  value (could be 1, 2, 4, 8, 16, 32, 64, 128)
- AFTER: `return !!(val & BIT(offset));` — returns 0 or 1
- Also removes unnecessary `else` after `return ret`

**Step 2.3: Bug Mechanism**
- Category: Logic/correctness fix (API contract violation)
- The `BIT(offset)` for offset > 0 yields values > 1 (BIT(1)=2,
  BIT(2)=4, etc.)
- The old code masks `val` with `BIT(offset)`, returning the bit's
  position value rather than 0/1
- With gpiolib sanitize (86ef402d805d in v6.15+), returning values > 1
  triggers `-EBADE` or a warning

**Step 2.4: Fix Quality**
- Obviously correct: `!!` is the standard C idiom for boolean
  normalization
- Minimal/surgical: 2-line change in a single function
- Zero regression risk: `!!` can only produce 0 or 1, which is exactly
  what's expected
- The fix is identical in pattern to all 6 other patches in the series

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
- The buggy `return (int)(val & (u8)BIT(offset))` line was introduced by
  commit `4342bf63b64b0` (Thomas Richard, 2024-10-01) when the cgbc GPIO
  driver was first created in v6.13-rc1.

**Step 3.2: Fixes Target**
- The commit doesn't have a `Fixes:` tag, but the sibling patches
  reference `Fixes: 86ef402d805d ("gpiolib: sanitize the return value of
  gpio_chip::get()")`, which was added in v6.15-rc1.

**Step 3.3: Related Changes**
- This is part of a 7-patch series by Dmitry Torokhov, all normalizing
  gpio_get return values across different drivers.
- The gpiolib core workaround (ec2cceadfae72) landed in v7.0-rc2, adding
  normalization + warning in gpiolib itself.
- The cgbc_gpio_get function has been unchanged since its creation — no
  conflicting changes.

**Step 3.4: Author**
- Dmitry Torokhov is a highly respected kernel developer (input
  subsystem maintainer, Google). He reported the problem with the
  gpiolib sanitize commit and contributed the driver-side fixes.

**Step 3.5: Dependencies**
- The fix touches only `cgbc_gpio_get()` which is unchanged since the
  driver was created. No dependencies on any other patches.
- The diff applies cleanly to any tree containing the cgbc driver
  (v6.13+).

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1: Original Patch Discussion**
- Patch 2/7 in series `[PATCH 1/7] gpio: bd9571mwv: normalize return
  value of gpio_get`
- 11 messages in thread. Applied by Bartosz Golaszewski (GPIO
  maintainer).
- Discussion revealed Dmitry recommended reverting 86ef402d805d for
  stable but keeping it for 7.0. Bartosz instead sent ec2cceadfae72 to
  normalize in gpiolib core (with `Cc: stable`).

**Step 4.2: Reviewers**
- Applied directly by Bartosz Golaszewski (GPIO subsystem maintainer)
- No explicit Reviewed-by on the cgbc patch, but the entire series was
  applied together

**Step 4.3-4.5: Bug Context**
- The underlying issue is well-documented: commit 86ef402d805d broke
  many GPIO drivers that returned non-normalized values. The cgbc driver
  is one of them.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1-5.4: Function Analysis**
- `cgbc_gpio_get()` is the `.get` callback for the cgbc GPIO chip,
  assigned at probe time (line 173)
- It's called by gpiolib core (`gpiochip_get()`) whenever any consumer
  reads this GPIO
- For Congatec Board Controller GPIO, this affects 14 GPIO pins (pins
  0-13)
- Pins with offset > 0 would return values > 1, triggering the bug

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Code Existence in Stable**
- cgbc driver: exists in v6.13+ stable trees
- gpiolib sanitize (86ef402d805d): exists in v6.15+ stable trees
- gpiolib normalize workaround (ec2cceadfae72, `Cc: stable`): exists in
  v7.0, will be backported to v6.15+

**Step 6.2: Backport Complexity**
- The `cgbc_gpio_get()` function is IDENTICAL in all stable trees from
  v6.13 onwards
- The patch applies cleanly to any tree with the cgbc driver

**Step 6.3: Impact Matrix**
- **v6.13-v6.14 stable**: Driver exists, sanitize check absent. Bug is
  latent (no user-visible effect since gpiolib didn't check). Low
  priority.
- **v6.15+ stable**: Driver AND sanitize check exist. Without
  ec2cceadfae72: driver returns `-EBADE` for pins > 0 (broken!). With
  ec2cceadfae72 but without this fix: driver works but triggers a
  warning on every `gpio_get` for pins 1-13.

## PHASE 7: SUBSYSTEM CONTEXT

- Subsystem: GPIO (`drivers/gpio/`) - IMPORTANT, used by many
  embedded/SBC platforms
- The Congatec Board Controller is used in embedded industrial computing
- Criticality: PERIPHERAL (specific hardware), but users of this
  hardware depend on it

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
- Users of Congatec Board Controller hardware with GPIO

**Step 8.2: Trigger Conditions**
- Any read of GPIO pins 1-13 (offset > 0) triggers the bug
- This is a normal operation path, not an edge case

**Step 8.3: Failure Severity**
- Without gpiolib workaround: GPIO reads return error (-EBADE) for most
  pins → MEDIUM-HIGH (driver broken)
- With gpiolib workaround: Warning emitted on every read → LOW-MEDIUM
  (functional but noisy)

**Step 8.4: Risk-Benefit**
- BENEFIT: Fixes incorrect driver behavior, eliminates runtime warnings,
  prevents potential breakage
- RISK: Virtually zero — `!!` normalization is trivially correct
- RATIO: Very favorable

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
1. Fixes a real API contract violation that causes warnings or errors in
   v6.15+ trees
2. 2-line change, trivially correct (`!!` normalization)
3. Sibling patches in the same series have `Fixes:` and `Cc: stable`
   tags
4. Applied by GPIO subsystem maintainer
5. Author is a top-tier kernel developer
6. Zero regression risk
7. Clean apply to all stable trees containing the driver

**Evidence AGAINST backporting:**
1. The gpiolib core workaround (ec2cceadfae72) already handles this at
   the framework level
2. No explicit `Fixes:` or `Cc: stable` on this specific patch
3. For v6.13-v6.14 where the sanitize check doesn't exist, the bug is
   latent

**Stable Rules Checklist:**
1. Obviously correct? YES — `!!` is trivially correct
2. Fixes a real bug? YES — API violation causing errors/warnings
3. Important issue? MEDIUM — driver broken or warning-spewing without
   fix
4. Small and contained? YES — 2 lines in 1 function
5. No new features? Correct — pure bug fix
6. Applies to stable? YES — cleanly

## Verification

- [Phase 1] Parsed tags: Signed-off-by Dmitry Torokhov and Bartosz
  Golaszewski, Link to patch submission
- [Phase 2] Diff analysis: 2 lines changed in `cgbc_gpio_get()`,
  `(int)(val & (u8)BIT(offset))` → `!!(val & BIT(offset))`
- [Phase 3] git blame: buggy code introduced in 4342bf63b64b0
  (v6.13-rc1), present in stable 6.13+
- [Phase 3] git show 86ef402d805d: confirmed sanitize commit in
  v6.15-rc1, makes non-[0,1] returns an error
- [Phase 3] git show ec2cceadfae72: confirmed gpiolib normalize
  workaround in v7.0-rc2 with `Cc: stable`
- [Phase 3] git tag --contains: verified cgbc in v6.13+, sanitize in
  v6.15+, normalize in v7.0
- [Phase 3] git diff shows `cgbc_gpio_get()` unchanged since driver
  creation — clean apply
- [Phase 4] b4 mbox: found 11-message thread, all 7 patches applied by
  Bartosz Golaszewski
- [Phase 4] Mailing list discussion: Dmitry recommended reverting
  sanitize for stable; Bartosz instead sent gpiolib normalize fix
- [Phase 4] Sibling patches (e2fa075d5ce19, 2bb995e6155cb,
  fb22bb9701d48) all have `Fixes: 86ef402d805d` and `Cc: stable`
- [Phase 5] `cgbc_gpio_get()` is the `.get` callback called by gpiolib
  on every GPIO read
- [Phase 6] Confirmed driver exists in 6.13+ and sanitize check in
  6.15+; patch applies cleanly
- [Phase 8] For offset > 0, `BIT(offset)` yields values 2-128; returning
  these violates API and triggers warnings/errors

The fix is small, surgical, trivially correct, and eliminates incorrect
API behavior that causes runtime warnings in stable trees. The sibling
patches explicitly target stable. The absence of `Cc: stable` on this
specific patch appears to be an oversight or inconsistency within the
series.

**YES**

 drivers/gpio/gpio-cgbc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-cgbc.c b/drivers/gpio/gpio-cgbc.c
index 0efa1b61001ad..84b5ed3c6e22b 100644
--- a/drivers/gpio/gpio-cgbc.c
+++ b/drivers/gpio/gpio-cgbc.c
@@ -47,8 +47,8 @@ static int cgbc_gpio_get(struct gpio_chip *chip, unsigned int offset)
 
 	if (ret)
 		return ret;
-	else
-		return (int)(val & (u8)BIT(offset));
+
+	return !!(val & BIT(offset));
 }
 
 static int __cgbc_gpio_set(struct gpio_chip *chip, unsigned int offset,
-- 
2.53.0