About regulator error events

[Mark Brown]

On Mon, Feb 27, 2023 at 02:05:42PM +0100, Sascha Hauer wrote:

> 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

Might also be a good idea to turn off any other supplies to the device
as well but yes.

> 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?

Sure.

> 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 ;)

The general issue is that if the regulators get upset enough to start
complaining something has generally gone really badly wrong and there
isn't anything constructive that can be done other than logging.  You
might potentially want to power off the system as a whole or something
too.  I do think any big actions are going to be userspace policy
things.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20230227/29d313d2/attachment.sig>