linux-kernel - Re: [UPDATED v3][PATCH 1/7] regulator: consumer interface

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: <20080312235715.GA15894@opensource.wolfsonmicro.com>
Date:	Wed, 12 Mar 2008 23:57:15 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	David Brownell <david-b@...bell.net>
Cc:	Liam Girdwood <lg@...nsource.wolfsonmicro.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Dmitry Baryshkov <dbaryshkov@...il.com>
Subject: Re: [UPDATED v3][PATCH 1/7] regulator: consumer interface

On Wed, Mar 12, 2008 at 01:52:46PM -0800, David Brownell wrote:
> On Wednesday 12 March 2008, Mark Brown wrote:

> > What do you see as being missing in the externally presented interface?

> It's not *presented* as a tree of power domains, and it's not clear
> that's the intended model.  Plus, what Liam said about the names
> being global, not local/logical.

Hrm.  I suspect that the documentation which Liam is currently writing
(together with some actual in-tree users) will help here.

> > As far as I can see the main difference between the two APIs on this
> > front is that the regulator API explicitly separates the interface used
> > to set up the tree from the interface used by consumers.

> I'd say that differently.  The clock framework *has* no such
> implementor/setup support ... which has caused problems for

Well, the platforms I've looked at do implement a fairly standard
registration API to set up their clocks, even if it's only used to
configure things for the particular SoC variant in use and does tend to
omit things not used on the platform in question.

> many new implementations.  I'm unclear on the status of some
> recent patches [1] from Dmitry Baryshkov to help address that.

That looks like it'd help a lot in making the feature set implemented by
the clock API consistent over platforms.

> Specifically, it's awkard even to do simple things like binding
> one of a SOC's programmable clocks onto an off-chip audio codec
> or video controller; that's got to go through platform_data or
> something similar.  And plugging in external clock generators ...
> not portably, no way!

> You seem to be aiming to not recreate those problems, which is good.

Right; any regulator API is going to need to cope with connecting
multiple chips together since that's such a core use case.

> > What might be nicer would be an API that platform code could use to map
> > regulators to device/name tuples.  The core could then search these when
> > a client calls regulator_get() (either by maintaining a separate table
> > or by setting up virtual regulators).

> Right.

We'll try to implement this before we next resubmit.

> > >     Power --> Regulator -+-> Switch-1 -+-> Switch-2 --> [Dev-A]
> > >                          |             |
> > >                          |             +-> [Dev-B], [Dev-C]
> > >                          |
> > >                          +-> [Dev-D], [Dev-E]

> > I don't see a particular problem fitting this into the structure of
> > the current API - to me the switches inflexible regulators with no
> > configurable voltage control of their own.

...

> That maps exactly to the clock tree model.  Not all clocks can
> support clk_set_rate() or clk_set_parent().  Not all power domains
> can support a set_voltage() call, etc.

That's the aim, and some of this works already.  For example, regulators
with no set_voltage() are supported by the core.

> This just suggests a bit of refocusing of your current code,
> so it'll be more widely applicable.

In API terms I'm not sure it even needs a refocusing - I think the API
can already support everything you're asking for in this subthread
except for the addition of an API to allow platforms to map a symbolic
name and device tuple to an actual regulator.  Some of the cases that
can be set up will require additional work in the core to support them
but doing that shouldn't affect anything that doesn't directly deal with
those cases.
--
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/