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: <E1cHslb-0000g0-0V@stardust.g4.wien.funkfeuer.at>
Date:   Fri, 16 Dec 2016 14:41:42 +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 Wed, Dec 14, 2016 at 03:52:54PM +0100, Harald Geyer wrote:
> 
> > Thus the following constraints should be met:
> > * When user space asks
> >   the driver to read a device, it needs to "claim" the supply and
> >   ensure that it has been up for at least 2 seconds before proceeding
> >   to read the HW. The supply would be "locked" enabled.
> >   (I think this is standard regulator API.)
> > * When HW failure is detected, the driver needs to tell the supply to
> >   turn off for at least 2 seconds, wait for all other devices to
> >   release the supply so it can actually be turned off, then wait
> >   for the off period, then start over again.
> >   (This is easy only with getting the supply exclusively.)
> 
> You need to use a notification to figure out when the supply is actually
> off.

I see.
 
> > * It should be possible to read multiple devices quickly when
> >   everything is okay and working. (Having 6 2-second delays accumulate
> >   would be quite annoying.)
> >   (This won't work with exclusive supply usage.)
> 
> Similarly using a notification to discover when the supply is on would
> help here.

Ok.
 
> > * Optionally: If all devices are idle the supply would be enabled
> > if short response time is desired, but disabled if power saving is
> > desired.
> >
> > Can this somehow be solved with the existing API? If not, do you think
> > it would be reasonable/possible to extend the API to cover situations
> > like the one described above?
> 
> 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.

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.

> You'd end up with the devices all ignoring each other but keeping track
> of when the supply was last enabled and disabled and individually
> keeping timers to make sure that the needed delays are taken care of.
> Userspace would then turn up and read all the devices, they'd then
> do the enables and disables as though they were working alone but
> coordinate through the notifications. If device A powered things up then
> device B would know the power was already on via the notifications and
> when it came on so could take account of that when doing its own delays.

This only works as long as every consumer of the supply is cooperating
(which is my personal use case but doesn't look very future proof). I guess
there has to be some pain for using quirky, unreliable HW... ;)

Thanks for your input, it has been very helpful!