linux-kernel - Re: [PATCH v3 2/4] regulator: adapt fixed regulator driver to dt

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: <CAOesGMh-fpUSMvOGkq_b4DVzFUby6pnMmKDXQ=sFJpn+g4FzOw@mail.gmail.com>
Date:	Fri, 4 Nov 2011 15:09:32 -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 v3 2/4] regulator: adapt fixed regulator driver to dt

On Fri, Nov 4, 2011 at 2:57 PM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> On Fri, Nov 04, 2011 at 02:47:05PM -0700, Olof Johansson wrote:
>> On Fri, Nov 4, 2011 at 2:25 PM, Mark Brown
>
>> > I don't see how you can usefully do that, the task of plumbing a
>> > regulator into a board is largely orthogonal to the specific feature set
>> > of a given regulator.  The specific bindings for a fixed voltage
>> > regulator would be useful or unhelpful for most regultors controlled via
>> > I2C.
>
>> I meant more that the fixed regulators should reuse as much as
>> possible from the generic regulator bindings, instead of completely
>> forking them.
>
> That appears to be what's going on?  The fixed voltage regulator
> includes by reference the core regulator binding, all of the properties
> it defines with the possible exception of the supply name are not
> covered in the core binding.

The fixed-regulator binding makes no reference to the generic binding,
and the example includes no properties that are defined in that one.
So I definitely did not make that conclusion based on what I saw.

>> Then, depending on how they are controlled, there will be more
>> specific bindings. So the case of a gpio-controlled fixed regulator
>> would have a binding where the format of the properties to find the
>> gpio, etc, would be described. But things like voltage (without a
>> range, obviously) would be using the same bindings as the other
>> regulators.
>
> The only overlap I'm seeing is the voltage?
>
> The intended semantic for the voltage is rather different.  The core
> binding for the voltage specifies the range of voltages it is possible
> to set a regulator to on a given board and is used to give permission to
> the system to reconfigure the regulator.  The binding here tells the
> system what voltage a fixed voltage regulator is running at.  We could
> have the fixed voltage regulator read the same binding - though there's
> some risk of mild confusion it shouldn't be too bad.

Yeah, voltage is the obvious one where fixed would have a max and min
that is the same when you have a fixed regulator.

But even things like allowing (optional) attributes such as
startup-delay on non-fixed regulators could make sense. Keep in mind
that the device tree should focus on describing the hardware, not just
what the linux driver needs from it. So maybe instead of
startup-delay, specifying ramp-up speed instead of time needed until
power is good could be the way to go there.


-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/