From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 600FF40DFC1 for ; Thu, 30 Apr 2026 00:10:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777507843; cv=none; b=hBmO47SXM4Wy6dzobwqJXwFgR2TrOfcV90UVy5zkptp3ZXzQwpWU1/7rbEhoO728jNNnwJaj7lPyyf6yQRXkNM1kiU27N7KmnUm5eSRy6SRfWj/JoIsEJ1+ly0+LquFWBKG5Qg2vi3FjEJJ+D81zMFiEfj0KV8aKkiX7QsT02ro= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777507843; c=relaxed/simple; bh=HG6iVJFcNDfAzbfsDkCD5qCan24eo4XOhCPjEXWb/Ac=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ikc5uV1bOOHCWLuQE67CqDVWXbQcXiYyC70NcqzBaocx/RSXEgXNuV7FyH+cpHE/90IKy6KJ4JMRe9VNtYRB2FICD+AI/gVyTHaiH5XECMWlt+RtURNohoMhU6pJxlv/pgu3a9zlPSj0B8mGHrgk+rXMpvUyVtKO70AbiAbWun4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PprTJypW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PprTJypW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CAC9CC2BCC7; Thu, 30 Apr 2026 00:10:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777507843; bh=HG6iVJFcNDfAzbfsDkCD5qCan24eo4XOhCPjEXWb/Ac=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PprTJypWAiGloKU3j0TTyothPgJu71ce5csi0y+SKYWNDBnZz8CyzQFHnNu+ebmGv kxTCU2PIQHqHKqRV1D4gM6CUT0DjIfdWcPidU99I8g0SxyCKSjM/jwOvvAq769oYNk 4VyehWFWmJmKUZ2tuQFxW28t1Tyw5D4oOoSxfzEWIdYAi3sOQfRdamkkm8A6Ng3jiq hzCBBTCvUSfctQkyKaAXYydteBUPw9bmFBjW++xcSM/BywYF0KXZFEFgXHcBgPi7QX QSvrtuyTb0InWCOBl91OZkoMbeR1+Z4va6WkzxsF7gqoPnP9ggcOex+jy5BLirlhGY LH2hZoRnwS1gA== Received: by finisterre.sirena.org.uk (Postfix, from userid 1000) id F337B1AC5859; Thu, 30 Apr 2026 01:10:39 +0100 (BST) Date: Thu, 30 Apr 2026 09:10:39 +0900 From: Mark Brown To: Luca Weiss Cc: Liam Girdwood , linux-kernel@vger.kernel.org, Griffin Kroah-Hartman Subject: Re: Unexpected behavior of of_regulator_get()? Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RvGmSREj7CIG/tJv" Content-Disposition: inline In-Reply-To: X-Cookie: 667: --RvGmSREj7CIG/tJv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 29, 2026 at 10:18:31AM +0200, Luca Weiss wrote: > In a simplified version, we have this devicetree structure: >=20 > gpio-keys { > compatible =3D "gpio-keys"; >=20 > event-hall-sensor { > label =3D "Hall Effect Sensor"; > vdd-supply =3D <&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. =20 --RvGmSREj7CIG/tJv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmnynf8ACgkQJNaLcl1U h9Ao3wgAgpcTnmdq4+5eFoUqztvQHyfaL8L7JLOAM/UxpcGDKPyVFZVDvIN9KPzi ME03+UDtmsUx9cmowXgwoyj0m4d9o7iA/69EzuSQ08W7bR12oDyBzivainguPh5t uxOeg5DqBmxQeI/1yGrgL5v2BBxRwvEn6BiNLlrFFnBU5WJcFJyFGW4nkfZcHtbZ AnuFwgiBSXb6bycR62PzKAhpIzPGVU702KBxfxvAs6dcx2KYJIXbBd250fYEvM/t pRI4QQGnlNIFKRt7Xr07KeHydFVicDyJYij+j3X1oHQTUAbMii2RPFmWrAUGrynh 3DPB6cNYgxSCGQSgk3UKe3Pgc/MUUg== =2pew -----END PGP SIGNATURE----- --RvGmSREj7CIG/tJv--