linux-kernel - About regulator error events

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230227130542.GM32097@pengutronix.de>
Date:   Mon, 27 Feb 2023 14:05:42 +0100
From:   Sascha Hauer <sha@...gutronix.de>
To:     linux-kernel@...r.kernel.org
Cc:     Mark Brown <broonie@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>, kernel@...gutronix.de,
        linux-arm-kernel@...ts.infradead.org
Subject: About regulator error events

I have a board here which has some current limited power switches on it
and I wonder if I can do something reasonable with the error interrupt
pins these switches have.

The devices do not have a communication channel, instead they only have
an enable pin and an error interrupt pin. See
https://www.diodes.com/assets/Datasheets/AP22652_53_52A_53A.pdf for a
datasheet.  The devices come in two variants, one goes into current
limiting mode in case of overcurrent and the other variant switches off
until it gets re-enabled again.

At first sight it seemed logical to me to wire up the error interrupt
pins to REGULATOR_EVENT_OVER_CURRENT events. That was easy to do, but
now the question is: What can a regulator consumer do with these events?

The strategy I had in mind was to disable the regulator, enable it again
to see if the errors persists and if it does, permanently disable the
device.  Disabling the regulator only works though when there's only one
consumer.  With multiple consumers only the enable count decreases, but
the regulator itself stays enabled. This means implementing such a
policy at the consumer side is not generally possible. Implementing a
policy in the regulator core seems awkward as well, as a good strategy
likely differs between different consumers.

A first good step might be to notify the user somehow. While we can get
the overcurrent status of a regulator from
/sys/class/regulator/*/over_current there doesn't seem to be any way to
get a regulator event in userspace, right?  Would patches changing that
be welcomed?

There doesn't seem to be much prior art for handling regulator error
events in the kernel. It would be great to get some input what others do
in this situation, or to get some ideas what they would do if they had
the time to do so ;)

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |