From: Mark Brown <broonie@kernel.org>
To: Luca Weiss <luca.weiss@fairphone.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
linux-kernel@vger.kernel.org,
Griffin Kroah-Hartman <griffin.kroah@fairphone.com>
Subject: Re: Unexpected behavior of of_regulator_get()?
Date: Thu, 30 Apr 2026 09:10:39 +0900 [thread overview]
Message-ID: <afKd_3FMvcOGcpfa@sirena.co.uk> (raw)
In-Reply-To: <DI5HOWHCCKKD.1SQFAA3L4QFDI@fairphone.com>
[-- Attachment #1: Type: text/plain, Size: 1493 bytes --]
On Wed, Apr 29, 2026 at 10:18:31AM +0200, Luca Weiss wrote:
> In a simplified version, we have this devicetree structure:
>
> gpio-keys {
> compatible = "gpio-keys";
>
> event-hall-sensor {
> label = "Hall Effect Sensor";
> vdd-supply = <&vreg_l10b>;
> };
I don't understand what this is supposed to describe.
> Looking through the code this seems to be caused by of_get_regulator()
> first doing of_parse_phandle(node, prop_name, 0) which is checking on
> the node itself.
> But then if this does not succeed, it calls
> of_get_child_regulator(dev->of_node, prop_name) which goes through every
> child node of the top-level device (gpio-keys) until it finds a
> regulator. So this will find the vdd-supply of event-hall-sensor even
> for key-volume-up and switch.
Why does this single device have multiple distinct supplies going into
it all called "SUPPLY"? That doesn't seem like the sort of thing that
happens in system designs. I would not expect to see multiple distinct
supplies with the same name going into the same device.
> A workaround from the driver side would be to check for the presence of
> vdd-supply on the child (fwnode_property_present(child, "vdd-supply"))
> before trying to get a regulator but I feel like resolving this in the
> regulator core would be the better solution?
I think we need to take a step back here and look at what the binding is
supposed to describe and what it is trying to accomplish.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2026-04-30 0:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-29 8:18 Unexpected behavior of of_regulator_get()? Luca Weiss
2026-04-30 0:10 ` Mark Brown [this message]
2026-04-30 6:44 ` Luca Weiss
2026-04-30 11:18 ` Mark Brown
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=afKd_3FMvcOGcpfa@sirena.co.uk \
--to=broonie@kernel.org \
--cc=griffin.kroah@fairphone.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luca.weiss@fairphone.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.