Messages in this thread | | | Date | Mon, 27 Feb 2023 17:31:40 +0000 | From | Mark Brown <> | 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. [unhandled content-type:application/pgp-signature] | |