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 AACFF401A15 for ; Thu, 30 Apr 2026 11:18:06 +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=1777547886; cv=none; b=ddIv1cQ0t+NOnRiVMgB7XfTigL7nbI8GQ/PIU+k1q9Wu2KefVA47QoPzlA/7oj3qs5U+INa5yRU2xyVf3IdFgGei6Umz63RVxzu52ILoyTkH0fu2EpFPQJRWYjFGEYUQFtOzkXAljrlJxa1Qmxw3SbAzlTmTzbreVgAPjk+Izz0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777547886; c=relaxed/simple; bh=0gtaK/RR60PHNfVfuoEFaHxyJfPxRc//QHl5gZUD4dY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=T68d8fH9q9a/aICS+sJbYBP9T/5rbqb/o6J1DZw0Wlzwq8QIYh+mOXRQGzcPDCOJ1hDNsy5lwsKVRL49xp2WGSRkFGXj+KZv9r8cJafhJIkoLGUnpXxmmT3oQmbpGgBVjbbj0onf91m+ty96q9rVfv6fLh5kV9Lev5StlnfwDbg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZoOCaHuy; 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="ZoOCaHuy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 545F5C2BCC4; Thu, 30 Apr 2026 11:18:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777547886; bh=0gtaK/RR60PHNfVfuoEFaHxyJfPxRc//QHl5gZUD4dY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZoOCaHuyItjW+31B/5e7xzGTAHZsWWm18u4EuqvGNH2qVrnxqBaSa/t2iUvW4vnd3 0VUApcn469WmmhejrAqN/0n8/nnYlvxOd5WWvuq+8mYE7SnGefyfkffZse/OnS/h+1 G9KSl2YSK5BYOoo3sfREUARLp1oKVE7SIfkIlZQqYtxFneL4wb5EPcKh7C8HDzvr8V LrNJ8dHyHVSTolCofopExOTgBrKLOBvfIBNEu9WItceLtgT7lBr36oCo156oyvzzm+ cKwE13ixWA45t9MHXNnOdWhOHRMuoMmSjbvH8dE6OD8Ufn6IgqwwBcsksOH8aRgtuv HgFUdKvtvnaFg== Received: by finisterre.sirena.org.uk (Postfix, from userid 1000) id AED531AC585E; Thu, 30 Apr 2026 12:18:03 +0100 (BST) Date: Thu, 30 Apr 2026 20:18:03 +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="RLAfbYE16hyldu3V" Content-Disposition: inline In-Reply-To: X-Cookie: 667: --RLAfbYE16hyldu3V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Apr 30, 2026 at 08:44:40AM +0200, Luca Weiss wrote: > On Thu Apr 30, 2026 at 2:10 AM CEST, Mark Brown wrote: > > On Wed, Apr 29, 2026 at 10:18:31AM +0200, Luca Weiss wrote: > >> event-hall-sensor { > >> label = "Hall Effect Sensor"; > >> vdd-supply = <&vreg_l10b>; > >> }; > > I don't understand what this is supposed to describe. > Such hall effect sensor requires power, so the IC has a VDD/VCC pin Neither of which is "supply". > which needs to be powered, in order for the GPIO of the IC to trigger, > and that Linux can create an input event from it. So far this was mostly > described in devicetree using regulator-always-on because the devicetree > bindings & driver did not support that. I think at the point where you're shoehorning a separate device into the middle of a keyboard with a non-descriptive binding you're making problems - at some point someone is going to try to shoehorn something that has two supplies into the binding and everyone will be sad. These sorts of attempts to describe regulators in a "standard" way that doesn't correspond to the actual hardware generally cause problems like the AHCI ones. I'd just make a separate input device here, you're trying to solve a problem that you've actively created by not representing the hardware. > There's devm_regulator_get_optional() which gets a regulator for a given > device (on the gpio-keys level), and my expectation of > of_regulator_get() was that you point it at a devicetree node (e.g. the > event-hall-sensor subnode and it grabs the regulator from that node, not > from the parent (gpio-keys), nor from a different subnode of gpio-keys. of_regulator_get() is not intended to be used by anything other than framework code, the use case for a driver to use it would be that it's got bindings that don't map well onto Linux or it's just made a mess of it's bindings and needs to bodge it's way out of that situation. --RLAfbYE16hyldu3V Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmnzOmgACgkQJNaLcl1U h9Dqggf9HKB26xTohxdLuDfrfE8huGlhup1QSCxGJZeLx0XxZUdQfWrERpSXzSgm hKUWwOCFRULceeThA8qC8epoGh08nqTx1j+ykpflFNRu/U5ETH0WZNapIMTKEz4J S4h3C7nNDniFYt7o019U459OsPAPRurNjeLFlvzh3leoKYrnsL2DkN7rKV15nHnT 8eA9FYaNGWJzs+iTAbQo9QvBFf6Qpb6WtuSsKBaichjd2KyIe5rNz3MDouamf0J9 mPlQjwfR9D9Z6T6bYGZ14BRbBnaaarRrezh6Q4deh+DAlKnURJS6U37e5Hd8gxC+ Flz1cV/bDUknzpdeYwDDsZRs3a1yig== =cQcD -----END PGP SIGNATURE----- --RLAfbYE16hyldu3V--