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

Date:   Wed, 14 Dec 2016 15:52:54 +0100
From:   Harald Geyer <harald@...ib.org>
To:     Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>
cc:     linux-kernel@...r.kernel.org
Subject: Question about regulator API

Hi all!

I have a quite complex situation with regulator consumers, which I'm not
sure how to handle best.

Suppose there is some quirky HW that after some random time crashes - i.e.
it doesn't respond to requests anymore at all. The driver can detect this
situation and the only way to fix it is to disable the supply for 2 seconds,
then enable it again. Also after enabling the power supply the driver needs
to wait 2 seconds before talking to the HW.

Now the complicated part: The HW is some kind of sensor which often is
used in an array of identical devices. To make the wiring simpler all
these devices are attatched to the same supply (and maybe the same bus),
however they are read independently and thus also are independent devices
from the kernel POV.

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

Any help or hints are appreciated.

TIA,
Harald