[PATCH v2] gpiolib: handle gpio-hogs only once

[Daniel Drake]

On 09/06/2026 13:39, Bartosz Golaszewski wrote:
> On Mon, 8 Jun 2026 23:01:08 +0200, Daniel Drake <dan at reactivated.net> said:
>> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
>> index 1e6dce430dca..b02d711289d0 100644
>> --- a/drivers/gpio/gpiolib.c
>> +++ b/drivers/gpio/gpiolib.c
>> @@ -1031,9 +1031,17 @@ static int gpiochip_hog_lines(struct gpio_chip *gc)
>>   		if (!fwnode_property_present(fwnode, "gpio-hog"))
>>   			continue;
>>
>> +		/* The hog may have been handled by another gpio_chip on the same fwnode */
>> +		if (is_of_node(fwnode) &&
>> +		    of_node_check_flag(to_of_node(fwnode), OF_POPULATED))
>> +			continue;
>> +
>>   		ret = gpiochip_add_hog(gc, fwnode);
>>   		if (ret)
>>   			return ret;
>> +
>> +		if (is_of_node(fwnode))
>> +			of_node_set_flag(to_of_node(fwnode), OF_POPULATED);
> 
> Sashiko correctly points out that on errors, the state will be corrupted. We
> could maybe move the clearing of the flag to gpiochip_free_hogs() and track its
> state when processing fwnodes in order not to clear it incorrectly?

I guess you are referring to:

> Does setting OF_POPULATED here cause state corruption if a secondary chip on a
> shared node fails to probe?
> When multiple gpio_chip instances share a device node, the first chip processes
> its hogs and sets OF_POPULATED. If a subsequent chip fails probe (for example,
> returning -EPROBE_DEFER), its cleanup path calls of_gpiochip_remove() which
> clears the flag for all hogs.
> If the flag is unconditionally cleared, will the deferred chip attempt to
> process the first chip's hogs on retry, fail due to a mismatch, and
> permanently abort probe?


I don't think this is actually an issue. If we have two gpio_chips 
sharing a device node, a first one with a hog that probes fine and a 
subsequent one that fails during probe, both of the gpio_chips will 
brought down and the flag is cleared. If it was a EPROBE_DEFER case 
which is then retried later, the first chip's hogs will be set up a 2nd 
time when the probe is retried.

It is true that the teardown of the 2nd gpio_chip would erase the 
OF_POPULATED flag of a gpio-hog node that it does not "own", but the 
first gpio_chip would also be torn down at the same time (and 
OF_POPULATED unset a 2nd time). This is not ideal, but harmless as far 
as I can see.

I don't quite follow the suggestion for doing the clearing better in 
gpiochip_free_hogs(). It would be neat if we could go from a hogged 
gpio_desc back to the fwnode, so that we could only unset OF_POPULATED 
on the fwnode at the point when we are really removing the hog, but I 
don't see a way to derive the gpio-hog fwnode from gpio_desc. Also, this 
would be complicated because one gpio-hog node can hog multiple gpios.

Let me know if I'm missing anything or if you have any preference to 
handle this differently!

Thanks
Daniel