Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Drake <dan@reactivated.net>
To: Bartosz Golaszewski <brgl@kernel.org>
Cc: linux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linusw@kernel.org
Subject: Re: [PATCH v2] gpiolib: handle gpio-hogs only once
Date: Tue, 9 Jun 2026 21:48:03 +0100	[thread overview]
Message-ID: <b07f5bd8-26f8-4de4-becb-4f76f9d33361@reactivated.net> (raw)
In-Reply-To: <CAMRc=MfUd3nwpjgz-87hrpQ9AV6T8_1zwCm+tfYFurkYHKoKTw@mail.gmail.com>

On 09/06/2026 13:39, Bartosz Golaszewski wrote:
> On Mon, 8 Jun 2026 23:01:08 +0200, Daniel Drake <dan@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



  reply	other threads:[~2026-06-09 20:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-08 21:01 [PATCH v2] gpiolib: handle gpio-hogs only once Daniel Drake
2026-06-09 12:39 ` Bartosz Golaszewski
2026-06-09 20:48   ` Daniel Drake [this message]
2026-06-10  8:12     ` Bartosz Golaszewski
2026-06-10  8:13 ` Bartosz Golaszewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b07f5bd8-26f8-4de4-becb-4f76f9d33361@reactivated.net \
    --to=dan@reactivated.net \
    --cc=brgl@kernel.org \
    --cc=linusw@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox