linux-kernel - Re: Question about regulator API

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: <E1cI0YN-0000LW-8z@stardust.g4.wien.funkfeuer.at>
Date:   Fri, 16 Dec 2016 23:00:35 +0100
From:   Harald Geyer <harald@...ib.org>
To:     Mark Brown <broonie@...nel.org>
cc:     Liam Girdwood <lgirdwood@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: Question about regulator API

Mark Brown writes:
> On Fri, Dec 16, 2016 at 02:41:42PM +0100, Harald Geyer wrote:
> > Mark Brown writes:
> > > On Wed, Dec 14, 2016 at 03:52:54PM +0100, Harald Geyer wrote:
> 
> > > This doesn't feel like a regulator API problem exactly, a lot of what
> > > you're talking about here seems like you really need the devices to
> > > coopereate with each other and know what they're doing in order to work
> > > well together.
> 
> > I was hoping, that I somehow could get the necessary coordination from
> > the regulator framework. If the best I can get ATM is notifications, then
> > I'll try it and see what kind of code falls out of this.

Ok, tried that and it turns out there is no notification at
regulator_enable() ATM. I guess you'd merge a patch that added this
notification?

> > It still seems a bit of a limitation to me, that the only way to really
> > switch off a regulator is with regulator_force_disable(), which is quite
> > a hard hammer.
> 
> I really have no idea what sort of communication you're envisaging here
> - powering supplies down when other devices are trying to use them is a
> really serious thing with very substantial consequences for userspace,

Sure, this is why regulator_force_disable() is the wrong tool for the job.
I was more looking for something (call it regulator_shutdown()) that
* blocked until the regulator is actually off
* made all calls to regulator_enable() from other consumers block (or fail)
* maybe sent notifications to consumers, so that they have a chance to
  cooperate and call regulator_disable() at their earliest convenience.
* was undone by a call to either regulator_disable() or regulator_enable()
  from the consumer that initially called regulator_shutdown()

I haven't explored this in detail - maybe there are good reasons not to
have it.

As a convenience API there could be something like regulator_enable_wait()
(mirrored by regulator_shutdown_wait()) to avoid having identical
notification callbacks and timers in every consumer device. Of course this
would require adding timing information to struct regulator. If nobody
besides me has any use for that code, then maybe it's not a good idea.

> if the devices aren't cooperating at a level higher than the regulator
> API level it's unlikely to go well.

The devices would need to cooperate in the sense, that they call
regulator_disable() whenever they don't strictly need the supply, so that
regulator_shutdown() won't block forever, of course. But this is a good
idea, in terms of energy saving, anyway. The devices wouldn't need to
know the (timing) constraints of other consumers of the same supply - so
it's no hard cooperation.