[PATCH AUTOSEL 6.12 06/12] gpio: of: initialize local variable passed to the .of_xlate() callback

[PATCH AUTOSEL 6.12 06/12] gpio: of: initialize local variable passed to the .of_xlate() callback

[Sasha Levin]

From: Alexander Stein <alexander.stein@ew.tq-group.com>

[ Upstream commit d563e7f95c933816efe531c3a48e22bc099c0f55 ]

of_flags is passed down to GPIO chip's xlate function, so ensure this one
is properly initialized as - if the xlate callback does nothing with it
- we may end up with various configuration errors like:

    gpio-720 (enable): multiple pull-up, pull-down or pull-disable enabled, invalid configuration

Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Link: https://lore.kernel.org/r/20250708083829.658051-1-alexander.stein@ew.tq-group.com
[Bartosz: tweaked the commit message]
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Based on my analysis, here's my determination:

**YES**

This commit should be backported to stable kernel trees for the
following reasons:

1. **It fixes a real bug that affects users**: The uninitialized
   `of_flags` variable can contain random stack data that gets passed to
   GPIO chip's xlate callback and subsequently converted to GPIO lookup
   flags. This can lead to spurious error messages like "multiple pull-
   up, pull-down or pull-disable enabled, invalid configuration" when
   random bits in the uninitialized variable match the OF_GPIO_PULL_UP
   (0x10), OF_GPIO_PULL_DOWN (0x20), or OF_GPIO_PULL_DISABLE (0x40)
   flags.

2. **The fix is small and contained**: The change is minimal - just
   initializing `enum of_gpio_flags of_flags = 0;` instead of leaving it
   uninitialized. This is a single-line change that doesn't affect any
   other functionality.

3. **Clear cause and effect**: The code path shows that:
   - `of_flags` is declared uninitialized in `of_find_gpio()` (line 702)
   - It's passed by reference to `of_get_named_gpiod_flags()` (line 708)
   - Which passes it to `of_xlate_and_get_gpiod_flags()` (line 422-423)
   - Which passes it to the chip's `of_xlate()` callback (line 146)
   - If the xlate callback doesn't modify the flags (which is valid
     behavior), the uninitialized value is preserved
   - The uninitialized value is then converted by
     `of_convert_gpio_flags()` (line 720)
   - Random bits can trigger invalid configuration detection in the GPIO
     subsystem

4. **No architectural changes**: This is a straightforward bug fix that
   doesn't introduce new features or change any APIs.

5. **Minimal risk of regression**: Initializing a variable to zero is
   extremely low risk. The worst case would be if some driver was
   inadvertently relying on the undefined behavior, but that would be a
   bug in that driver.

6. **Affects core GPIO subsystem**: The bug is in the core GPIO OF code
   path that's used by many GPIO controllers, making it important to fix
   across all supported kernels.

The commit clearly fixes a bug where uninitialized memory can cause
false error conditions, making it an excellent candidate for stable
backporting according to the stable tree rules.

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

diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index 36f8c7bb79d81..2fbee14570b66 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -699,7 +699,7 @@ struct gpio_desc *of_find_gpio(struct device_node *np, const char *con_id,
 			       unsigned int idx, unsigned long *flags)
 {
 	char propname[32]; /* 32 is max size of property name */
-	enum of_gpio_flags of_flags;
+	enum of_gpio_flags of_flags = 0;
 	const of_find_gpio_quirk *q;
 	struct gpio_desc *desc;
 
-- 
2.39.5

[PATCH AUTOSEL 6.12 10/12] pinctrl: aw9523: fix can_sleep flag for GPIO chip

[Sasha Levin]

From: Milan Krstic <milan.krstic@gmail.com>

[ Upstream commit 5285b5ed04ab6ad40f7b654eefbccd6ae8cbf415 ]

The GPIO expander is connected via I2C, thus the can_sleep flag has to
be set to true. This fixes spurious "scheduling while atomic" bugs
in the kernel ringbuffer.

Signed-off-by: David Bauer <mail@david-bauer.net>
Signed-off-by: Milan Krstic <milan.krstic@gmail.com>
Link: https://lore.kernel.org/20250703143039.5809-1-milan.krstic@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

**YES**

This commit should be backported to stable kernel trees.

## Extensive Explanation:

This is a critical bug fix that addresses a **sleep-in-atomic-context**
issue in the aw9523 GPIO expander driver. Here's why this is an
excellent candidate for stable backporting:

### 1. **Clear Bug Fix**
The commit fixes a concrete bug where the driver incorrectly sets
`can_sleep = false` for a GPIO chip that communicates over I2C. As
evidenced in the code:
- The GPIO operations (`aw9523_gpio_get`, `aw9523_gpio_set`, etc.) all
  use `mutex_lock(&awi->i2c_lock)` and `regmap` operations
- All GPIO operations involve I2C transactions through
  `regmap_read/write`
- I2C operations can sleep and cannot be called from atomic contexts

### 2. **Causes Real User-Visible Issues**
The commit message explicitly states this causes "spurious 'scheduling
while atomic' bugs in the kernel ringbuffer". These are serious kernel
warnings that indicate the system is attempting to sleep in contexts
where sleeping is not allowed, which can lead to:
- System instability
- Kernel warnings flooding the log
- Potential deadlocks or system hangs

### 3. **Simple, Low-Risk Fix**
The fix is a one-line change from `gc->can_sleep = false;` to
`gc->can_sleep = true;`. This is:
- Minimal in scope
- Only affects the metadata about the GPIO chip
- Doesn't change any actual functionality
- Just correctly declares the chip's sleeping requirements

### 4. **Similar to Previously Backported Commits**
Looking at the similar commits:
- Commit #1 (gpio-adp5588): Fixed sleep-in-atomic bugs - **BACKPORTED**
- Commit #3 (ltc2992): Fixed the same `can_sleep` flag issue for another
  I2C GPIO chip - **BACKPORTED**

Both of these commits addressed the exact same class of bug and were
deemed suitable for stable backporting.

### 5. **Long-standing Bug**
The bug has existed since the driver was initially introduced (commit
576623d70661), meaning all kernel versions with this driver are
affected. The original implementation incorrectly set `gc->can_sleep =
false`.

### 6. **Meets Stable Kernel Criteria**
According to stable kernel rules, this fix:
- Fixes a real bug that users can hit
- Is already in Linus's tree (merged)
- Is small and self-contained
- Doesn't add new features
- Has minimal risk of regression

The commit is essential for proper operation of systems using the AW9523
GPIO expander, preventing kernel warnings and potential system
instability when GPIOs are accessed from non-sleeping contexts.

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

diff --git a/drivers/pinctrl/pinctrl-aw9523.c b/drivers/pinctrl/pinctrl-aw9523.c
index 1374f30166bc3..1fe01e4cd2107 100644
--- a/drivers/pinctrl/pinctrl-aw9523.c
+++ b/drivers/pinctrl/pinctrl-aw9523.c
@@ -784,7 +784,7 @@ static int aw9523_init_gpiochip(struct aw9523 *awi, unsigned int npins)
 	gc->set_config = gpiochip_generic_config;
 	gc->parent = dev;
 	gc->owner = THIS_MODULE;
-	gc->can_sleep = false;
+	gc->can_sleep = true;
 
 	return 0;
 }
-- 
2.39.5