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: <20161214181405.7hyn4b6yxdetzn5p@sirena.org.uk>
Date:   Wed, 14 Dec 2016 18:14:05 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Harald Geyer <harald@...ib.org>
Cc:     Liam Girdwood <lgirdwood@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: Question about regulator API

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.

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

> * 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.  From a regulator API point of view my first thought is
to use notifications to hook into the actual power on/off transitions
and then expressing the bit where the devices all work together at a
higher level.  It may be that a lot of that higher level coordination
just falls out of normal usage patterns do doesn't need explicitly
implementing, assuming the devices are only powered up during reads
anyway.  Using regulator_disable_deferred() in the driver may help
grease the wheels in terms of avoiding needless power bounces and
delays - just wait a little while before powering down in case you need
to power up again very soon after.

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.

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