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
| ||
|
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/
Powered by blists - more mailing lists