[PATCH 0/2] gpio: fix regressions in GPIO hogs after the code refactoring

[PATCH 0/2] gpio: fix regressions in GPIO hogs after the code refactoring

[Bartosz Golaszewski]

Fix issues pointed out by sashiko.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Bartosz Golaszewski (2):
      gpio: don't process hogs on disabled nodes
      gpio: fix cleanup path on hog failure

 drivers/gpio/gpiolib.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
---
base-commit: a87737435cfa134f9cdcc696ba3080759d04cf72
change-id: 20260609-gpio-hogs-fixes-89101c999a89

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

[PATCH 1/2] gpio: don't process hogs on disabled nodes

[Bartosz Golaszewski]

The core hogging logic uses device_for_each_child_node_scoped(), which
iterates over all child firmware nodes without checking their
availability. Before the code was moved to the GPIO core, it correctly
used for_each_available_child_of_node_scoped() to skip disabled nodes.
Check if the node is available and skip it if not.

Closes: https://sashiko.dev/#/patchset/20260608210108.36248-1-dan%40reactivated.net
Fixes: d1d564ec4992 ("gpio: move hogs into GPIO core")
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/gpio/gpiolib.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 7bb6f114d64d9ce3eb930f1d79d0224bf7920c37..1fc7ee9e1158d21f7c75e6cb95c33f0af44835c8 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1052,7 +1052,8 @@ static int gpiochip_hog_lines(struct gpio_chip *gc)
 	int ret;
 
 	device_for_each_child_node_scoped(&gc->gpiodev->dev, fwnode) {
-		if (!fwnode_property_present(fwnode, "gpio-hog"))
+		if (!fwnode_device_is_available(fwnode) ||
+		    !fwnode_property_present(fwnode, "gpio-hog"))
 			continue;
 
 		ret = gpiochip_add_hog(gc, fwnode);

-- 
2.47.3

[PATCH 2/2] gpio: fix cleanup path on hog failure

[Bartosz Golaszewski]

If gpiochip_hog_lines() successfully processes some hogs but fails on
a later one, the error handling path in gpiochip_add_data_with_key()
jumps directly to err_remove_of_chip. This leaks resources allocated
earlier for ACPI, interrupts and hogs that were successfully processed.
Use the right label in error path.

Closes: https://sashiko.dev/#/patchset/20260608210108.36248-1-dan%40reactivated.net
Fixes: d1d564ec4992 ("gpio: move hogs into GPIO core")
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/gpio/gpiolib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 1fc7ee9e1158d21f7c75e6cb95c33f0af44835c8..0cd79906d95c60035db1f6adc49bcfcfd3cc751b 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1316,7 +1316,7 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data,
 
 	ret = gpiochip_hog_lines(gc);
 	if (ret)
-		goto err_remove_of_chip;
+		goto err_free_hogs;
 
 	ret = gpiochip_irqchip_init_valid_mask(gc);
 	if (ret)

-- 
2.47.3

Re: [PATCH 0/2] gpio: fix regressions in GPIO hogs after the code refactoring

[Mika Westerberg]

On Tue, Jun 09, 2026 at 02:17:48PM +0200, Bartosz Golaszewski wrote:
> Fix issues pointed out by sashiko.
> 
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> Bartosz Golaszewski (2):
>       gpio: don't process hogs on disabled nodes
>       gpio: fix cleanup path on hog failure

Both,

Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>

Re: [PATCH 1/2] gpio: don't process hogs on disabled nodes

[Andy Shevchenko]

On Tue, Jun 09, 2026 at 02:17:49PM +0200, Bartosz Golaszewski wrote:
> The core hogging logic uses device_for_each_child_node_scoped(), which
> iterates over all child firmware nodes without checking their
> availability. Before the code was moved to the GPIO core, it correctly
> used for_each_available_child_of_node_scoped() to skip disabled nodes.
> Check if the node is available and skip it if not.

...

>  	device_for_each_child_node_scoped(&gc->gpiodev->dev, fwnode) {
> -		if (!fwnode_property_present(fwnode, "gpio-hog"))
> +		if (!fwnode_device_is_available(fwnode) ||
> +		    !fwnode_property_present(fwnode, "gpio-hog"))
>  			continue;

Red herring. the device_for_each_child_node*() is already "available".

So, teach Sashiko to stop on this, not the first time...
https://elixir.bootlin.com/linux/v7.1-rc7/source/drivers/of/property.c#L1132

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 2/2] gpio: fix cleanup path on hog failure

[Andy Shevchenko]

On Tue, Jun 09, 2026 at 02:17:50PM +0200, Bartosz Golaszewski wrote:
> If gpiochip_hog_lines() successfully processes some hogs but fails on
> a later one, the error handling path in gpiochip_add_data_with_key()
> jumps directly to err_remove_of_chip. This leaks resources allocated
> earlier for ACPI, interrupts and hogs that were successfully processed.
> Use the right label in error path.

This seems legit, but there is still a problem with implementation of
gpiochip_hog_lines(). Ideally it should clean up the crap it left when it
poops. With that, this one will require a brand new label just before
acpi_gpiochip_remove().

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/2] gpio: don't process hogs on disabled nodes

[Bartosz Golaszewski]

On Tue, Jun 9, 2026 at 4:16 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Tue, Jun 09, 2026 at 02:17:49PM +0200, Bartosz Golaszewski wrote:
> > The core hogging logic uses device_for_each_child_node_scoped(), which
> > iterates over all child firmware nodes without checking their
> > availability. Before the code was moved to the GPIO core, it correctly
> > used for_each_available_child_of_node_scoped() to skip disabled nodes.
> > Check if the node is available and skip it if not.
>
> ...
>
> >       device_for_each_child_node_scoped(&gc->gpiodev->dev, fwnode) {
> > -             if (!fwnode_property_present(fwnode, "gpio-hog"))
> > +             if (!fwnode_device_is_available(fwnode) ||
> > +                 !fwnode_property_present(fwnode, "gpio-hog"))
> >                       continue;
>
> Red herring. the device_for_each_child_node*() is already "available".
>
> So, teach Sashiko to stop on this, not the first time...
> https://elixir.bootlin.com/linux/v7.1-rc7/source/drivers/of/property.c#L1132
>

Ah, dang it. Need to look more carefully at sashiko reports. I've seen
many false-positives lately.

Bart

Re: [PATCH 2/2] gpio: fix cleanup path on hog failure

[Bartosz Golaszewski]

On Tue, Jun 9, 2026 at 4:25 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Tue, Jun 09, 2026 at 02:17:50PM +0200, Bartosz Golaszewski wrote:
> > If gpiochip_hog_lines() successfully processes some hogs but fails on
> > a later one, the error handling path in gpiochip_add_data_with_key()
> > jumps directly to err_remove_of_chip. This leaks resources allocated
> > earlier for ACPI, interrupts and hogs that were successfully processed.
> > Use the right label in error path.
>
> This seems legit, but there is still a problem with implementation of
> gpiochip_hog_lines(). Ideally it should clean up the crap it left when it
> poops. With that, this one will require a brand new label just before
> acpi_gpiochip_remove().
>
> --
> With Best Regards,
> Andy Shevchenko
>
>

Let's get this to stable and then rework it better in v7.2?

Bart

Re: [PATCH 2/2] gpio: fix cleanup path on hog failure

[Andy Shevchenko]

On Tue, Jun 09, 2026 at 04:33:59PM +0200, Bartosz Golaszewski wrote:
> On Tue, Jun 9, 2026 at 4:25 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Tue, Jun 09, 2026 at 02:17:50PM +0200, Bartosz Golaszewski wrote:
> > > If gpiochip_hog_lines() successfully processes some hogs but fails on
> > > a later one, the error handling path in gpiochip_add_data_with_key()
> > > jumps directly to err_remove_of_chip. This leaks resources allocated
> > > earlier for ACPI, interrupts and hogs that were successfully processed.
> > > Use the right label in error path.
> >
> > This seems legit, but there is still a problem with implementation of
> > gpiochip_hog_lines(). Ideally it should clean up the crap it left when it
> > poops. With that, this one will require a brand new label just before
> > acpi_gpiochip_remove().
> 
> Let's get this to stable and then rework it better in v7.2?

Sure. With that idea in mind,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
(only patch 2/2).

-- 
With Best Regards,
Andy Shevchenko