linux-kernel - Re: [PATCH] REGULATOR: core add 3 new modes/statuses

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] [day] [month] [year] [list]

Message-ID: <20120321114944.GA3226@opensource.wolfsonmicro.com>
Date:	Wed, 21 Mar 2012 11:49:46 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Graeme Gregory <gg@...mlogic.co.uk>
Cc:	linux-kernel@...r.kernel.org, lrg@...com
Subject: Re: [PATCH] REGULATOR: core add 3 new modes/statuses

On Wed, Mar 21, 2012 at 10:49:56AM +0000, Graeme Gregory wrote:
> On 21/03/2012 00:29, Mark Brown wrote:
> > On Tue, Mar 20, 2012 at 09:50:58PM +0000, Graeme Gregory wrote:

> >> USBBOOST this effectively turns the regulator around instead of using

> > In theory this could be done by other things so we should probably have
> > a better name, though in practice I'd be surprised to see many others.
> > It does totally break the idea of a mode, though - it's a massive change
> > in what the regulator does.

> Im not attached to the name, I just chose it as BOOST is a type of SMPS
> as well as being the common name for this function within TI. I do see
> what you mean by it not really fitting the "mode" descriptor well!

Plain BOOST does seem OK as a name - it was the USB bit.

> > Like I say I'm not entirely clear here, I keep meaning to try coding up
> > the custom API and see how it feels using it in a system - any thoughts?
> > Probably won't take me that long...

> This Im not really sure on, I don't see much info on the actual use of
> bypass mode in real devices yet. twl6035 uses it to power LDOUSB direct
> from USB bus intead of using the internal SMPS. But so far that is the
> only usecase I know of. Which of course means in bypass mode we not only
> have to change parent to some non existent virtual regulator but also
> enabled bypass mode.

There's some other stuff deployed already, though mostly internally to
drivers as the regulators concerned aren't generic regulators but are
internal to the device.

> > You also get this for ganging multiple regulators together to give a
> > higher power output, though normally you want variability so this has to
> > be handled at the hardware level.  This one also has an impact on how we
> > handle voltage changes, it'd be good if we could arrange things so that
> > get_voltage() and set_voltage() work through/with a regulator that's
> > tracking.

> I could see this also working if you set a parent regulator with a
> TRACKING flag so the framework knows the link. The other thing to
> consider is the twl6035 when you disable the parent SMPS on the LDO in
> tracking mode the LDO then switches to non tracking mode and uses its
> own configuration. When you turn SMPS back on it switch back to tracking
> mode.

That one is even more fun, it's relatively straightforward if they both
have the same configuration but otherwise...

> Altogether it looks like adding these features requires a lot more work
> than I had originally hoped :-(

> I guess the best way for me to proceed is to start to think about each
> of these "modes" individually and see what support I actually need from
> regulator framework to get them implemented.

Yeah, probably.  It's more likely something will happen about bypass
mode without you doing anything but I wouldn't rely on it.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)