linux-kernel - Re: [patch 2.6.28-rc3] regulator: add REGULATOR_MODE

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: <1226528635.6727.256.camel@vega.slimlogic.co.uk>
Date:	Wed, 12 Nov 2008 22:23:55 +0000
From:	Liam Girdwood <lrg@...mlogic.co.uk>
To:	David Brownell <david-b@...bell.net>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Mark Brown <broonie@...ena.org.uk>
Subject: Re: [patch 2.6.28-rc3] regulator: add REGULATOR_MODE_OFF

On Wed, 2008-11-12 at 11:25 +0000, Mark Brown wrote:
> On Mon, Nov 10, 2008 at 08:56:19PM -0800, David Brownell wrote:
> > On Monday 10 November 2008, Mark Brown wrote:
> 
> > > > imply REGULATOR_MODE_OFF ... another CPU may need to keep
> > > > it in some other state.
> 
> > > regulator_disable() needn't imply that the regulator will actually be
> > > off -
> 
> > Would you say that also for regulator_ops.disable() though?
> 
> If we ignore regulator_force_disable() (which isn't used yet) for the
> moment I'd actually say that in your case with non-software enables it's
> reasonable for it to still be powered by some other part of the system.
> Mainly because it's proably easier to just ignore the other enables than
> it is to explain to the rest of the system that there are others it
> can't know about.
> 
> > Less surprising/confusing would be if regulator_{en,dis}able() did
> > its own refcounting and called down to regulator_dev when changing
> > a per-client refcount to/from zero.  (Easy patch, for later.)
> 
> Yeah, either way is fine for me - don't know if Liam has a strong
> opinion.  The main benefit of not doing it is that encourages people to
> avoid consumers sharing the clients which causes problems when clients
> share the regulator.
> 

Fwiw, the main design intention here was to have a 1:1 mapping between a
consumer device and a struct regulator so that we could easily store per
consumer power data (for mode switching, easier debug, sysfs) and avoid
any issues between sharing the clients. I'd be happy for this change as
long as we can keep the per consumer data.

Thanks

Liam

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