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: <200803111436.29073.david-b@pacbell.net>
Date:	Tue, 11 Mar 2008 13:36:28 -0800
From:	David Brownell <david-b@...bell.net>
To:	Liam Girdwood <lg@...nsource.wolfsonmicro.com>
Cc:	linux-arm-kernel@...ts.arm.linux.org.uk,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Subject: Re: [UPDATED v3][PATCH 1/7] regulator: consumer interface

On Tuesday 11 March 2008, Liam Girdwood wrote:
> On Mon, 2008-03-10 at 16:39 -0800, David Brownell wrote:
> > On Sunday 09 March 2008, Liam Girdwood wrote:
> > > 
> > > > > +struct regulator *__must_check regulator_get(struct device *dev,
> > > > > +                                            const char *id);
> > > > 
> > > > The semantics of "id" and "dev" are unspecified in this patch,
> > > > so this isn't a good definition of the consumer interface!
> > > 
> > > 'id' is really the regulator name and will be renamed in the next patch.
> > 
> > Still not helping.  How would a driver know what names to use?
> 
> Platform data i.e. "WM8350-DCDC1". The links I gave in a previous mail
> have examples for this wrt LED. Backlight drivers.

I looked at some of that code a while back and didn't find them
all that informative.  Probably because implementations can be
interpreted in many ways, and I'm trying to understand which
concepts you intend to promote here...

> > Are those names globally scoped, or local to the device?
> > 
> 
> They are global.

So it's somewhat unlike the clock API then ... enough that I'd
reconsider *why* it's different.  The clock API allows both
global names and locally scoped ones.

Surely it would be better to just let device drivers call
something like

	client = regulator_lookup(dev, "Vcc");

and have the board setup code bind the right regulator to
that name for a given device?  It could work same way that
platform devices use logically numbered (or sometimes, named)
resources for register memory and IRQs, and the way the clock
framework uses logical names for device clocks.

Example:  all USART controllers may use the same logical
clock name "usart", instead of global names like "usart0_clk",
"usart1_clk", "mck", etc (as appropriate).  In the same way,
"Vcc" could be a local name for various devices ... where
the global name might be board-specific like "WM8350-DCDC1".

I suspect I'm walking towards a notion of a "power domain"
here, which would of course be fed by a regulator but would
be explicitly shared by multiple devices.  That's a notion
which has come up before in power management discussions, as
needing some explicit support by the Linux PM framwork.  It
applies both inside modern PM-aware SOCs, and at the board
level.  (It feels to me like you've focussed so far on the
latter.)

How would you see your notion of a "regulator" (client?)
relating to a "power domain"?  My first thought is that
there's a one-to-one correspondence but they may not be
quite the same thing.  Example, one might want to ask the
domain what devices it supports ... so that you could ask
them all to power off.

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