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

Date:   Mon, 27 Feb 2023 17:31:40 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Matti Vaittinen <mazziesaccount@...il.com>
Cc:     Sascha Hauer <sha@...gutronix.de>, linux-kernel@...r.kernel.org,
        Liam Girdwood <lgirdwood@...il.com>, kernel@...gutronix.de,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: About regulator error events

On Mon, Feb 27, 2023 at 06:19:19PM +0200, Matti Vaittinen wrote:

> What was new is that the BD9576 also had configurable warning-level
> limits (stricter than the protection limits) - and when these were
> exceeded only a 'warning IRQ' was issued. This setup was requested
> from ROHM by a customer - and the information I received was the
> customer had a use-case where they wanted to do 'mitigation actions'
> before things get more severely off. Unfortunately, I never received
> the information about these 'mitigation actions' when I tried to ask
> what those could be. I am under impression that either out HW
> colleagues did not know the customer use-case in details, or that this
> information was 'top secret' (which seems to be the case pretty often
> :( )

That sounds like an industrial application with redundant instances
where you can fail the workload over to another system as thing start
failing.

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

> If it is obvious that disabling the regulator is required for
> preventing the damage, then it might be justified to use the
> regulator_force_disable()? Now, the question when this is obvious is

That is basically what it's there for, or at least such things when
detected from a consumer device (eg, over temperature warnings).
However it's an open question if you're likely to see a situation where
a regulator flagged a problem that critical and didn't autonomously shut
down.

> Now, I am not really sure but I have a feeling that ideally the
> regulator driver (provider, not the consumer) should have this
> information about the severity level in device-tree and select the use
> of notifier flag based on this. If an ERROR level event is emitted, it
> should mean the hardware has really failed and forced disable could be
> justified. If a WARNING level event is sent, then the handling should
> be more graceful - probably done by some very system specific driver.

It certainly seems like the regulator is a good place to inject the
configuration.

> My problem here is that I don't have the visibility or understanding
> regarding current use of those events. Not sure if all the hell would
> break loose if the regulators are forcibly shut down. By the very
> least I would expect such a consumer handling to be disabled by
> default - either via configs or via some runtime enable/disable
> mechanism.

Yeah, as we've discussed before AFAICT any real usage is entirely
downstream.

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