| 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 14:25:10 -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> Subject: Re: [UPDATED v3][PATCH 1/7] regulator: consumer interface On Tuesday 11 March 2008, David Brownell wrote: > 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. Actually, it's clearly not one-to-one. Counter-example: a 3V3 regulator powering one of a SOC's I/O power domains, which is managed by a digital switch. That same regulator can power several I/O devices too. It may even feed a 1V8 regulator. So the relationship is probably that regulators define a domain ... but such domains can be subdivided. There's a tree; it's probably more shallow than the clock tree. And enable/disable primitives probably map best to power domains, not all of which are entire regulators. - 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