[PATCH AUTOSEL 6.15 07/15] gpio: of: initialize local variable passed to the .of_xlate() callback

[Sasha Levin <sashal@kernel.org>]

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 17802d97492fa..c8a1f9d4a3edb 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -708,7 +708,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