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-grou... [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;