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: <200811121600.34399.david-b@pacbell.net>
Date:	Wed, 12 Nov 2008 16:00:34 -0800
From:	David Brownell <david-b@...bell.net>
To:	Liam Girdwood <lrg@...mlogic.co.uk>
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 Wednesday 12 November 2008, Liam Girdwood wrote:
> 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:
>
> > > 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.

Not refcounting enables/disables gets to be a PITA though; that's
why the the IRQ and clock frameworks gave up on the not-counted
versions of their enable/disable calls a long time ago.

The typical problem scenario is that two parts of the same driver
have independent needs to make sure something is enabled.  If it's
not OK to enable() something that's already enabled(), the driver
itself will need to reinvent a refcounting scheme.

That kind of refcount patch would be a net code shrink anyway.  :)

> Fwiw, the main design intention here was to have a 1:1 mapping between a
> consumer device and a struct regulator 

As in, an LCD display and its touchscreen might be in
the same power domain (regulator_dev, internal to the
framework) but would have different regulator structs.

In that case the most likely scenario would be two
drivers needing to enable() so it's not trying to
talk to controllers that are powered off.  Voltage
would normally be fixed.

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

Right, I wasn't talking about changing that model.

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