linux-kernel - Re: Regulator supplies when using Device Tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120328193341.GD3232@opensource.wolfsonmicro.com>
Date:	Wed, 28 Mar 2012 20:33:42 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Michael Bohan <mbohan@...eaurora.org>
Cc:	rnayak@...com, lrg@...com, LKML <linux-kernel@...r.kernel.org>,
	linux-arm-msm@...r.kernel.org
Subject: Re: Regulator supplies when using Device Tree

On Wed, Mar 28, 2012 at 12:19:45PM -0700, Michael Bohan wrote:
> On 3/28/2012 3:09 AM, Mark Brown wrote:
> >On Tue, Mar 27, 2012 at 06:38:30PM -0700, Michael Bohan wrote:

> >Absolutely not, that would be broken.  The whole point here is that
> >supplies of all kinds are always requested with the name the chip uses
> >for the supply.

> Within the regulator driver, we currently have to do an
> of_get_property(of_node, "foo-supply", NULL) to determine whether
> the device has a supply, and thus whether we should assign
> rdesc->supply_name to "foo" or not when calling

No, this would be completely idiotic.  Please think about what I'm
saying here.  To repeat, supplies of all kinds are always requested with
the name the chip uses for the supply.  This means that any machine
binding is *totally* irrelevant to the regulator driver.

> regulator_register(). Is there a better way to do this? If we don't
> do this check for the case where a device does not have a supply
> specified in the Device Tree, then regulator_register() will fail.

Obviously there's a better way to do this.  For one thing as soon as we
find ourselves saying "let's open code this in every single driver"
we've got a clear abstraction problem...

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)