linux-kernel - Re: [PATCH v4 1/4] regulator: helper routine to extract regulator_init

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]

Date:	Fri, 4 Nov 2011 14:34:35 -0700
From:	Olof Johansson <olof@...om.net>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Rajendra Nayak <rnayak@...com>, grant.likely@...retlab.ca,
	patches@...aro.org, tony@...mide.com,
	devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	linux-omap@...r.kernel.org, lrg@...com,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v4 1/4] regulator: helper routine to extract regulator_init_data

On Fri, Nov 4, 2011 at 2:29 PM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> On Fri, Nov 04, 2011 at 02:22:16PM -0700, Olof Johansson wrote:
>> On Fri, Nov 04, 2011 at 09:14:48PM +0000, Mark Brown wrote:
>
>> > The name will be fixed by the individual device bindings, this is
>> > specifying the general form of a supply property.  Each device binding
>> > will define the set of supplies that the device can use.
>
>> Ah, ok. It shouldn't be a part of this binding then and instead be added
>> to the bindings for the consumers.
>
> I think it's useful to define how consumers are supposed to do this
> somewhere - it is actually part of the core binding how consumers are
> supposed to do this.

Yeah, ok, but it shouldn't be part of the description of regulator
properties per se. See how gpio does it, defining how a gpio-specifier
is crafted. The equivalent should be done for regulators.

> There's also a bit of magic here for chained supplies with one regulator
> supplying another (eg, using a DCDC to drop the system supply down to a
> lower voltage to supply a bunch of LDOs for improved efficiency).

Describing that in the device tree using regulator-specifiers
shouldn't be too bad? The LDO will reference the DCDC as the parent
supply (or input or whatever language you prefer). They don't have to
be in the same topology, they will instead be under whatever
controller/bus they are on for control -- i2c, etc.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/