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
next prev parent 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