On Sat, Jan 30, 2021 at 04:43:46PM +0100, AngeloGioacchino Del Regno wrote:
> Il 29/01/21 10:14, Matti Vaittinen ha scritto:

Please delete unneeded context from mails when replying.  Doing this
makes it much easier to find your reply in the message, helping ensure
it won't be missed by people scrolling through the irrelevant quoted
material.

> > > It's not that we shouldn't implement support for warnings, it's that
> > > they're not the common case for hardware and so won't line up with
> > > behaviour for other users.

> ....but anyway, I have no idea what would you do when a warning is
> triggered: make a good example, please...

> I mean, take for example the "usual display": you are delivering power
> to a DriverIC (which is most of the times undocumented), your display
> starts drawing more than expected, so... uh.. so what?
> You shut it down? You reboot the DrIC?
> I can't imagine a DrIC reboot to restore the power draw...

As I've said several times now if you're getting anywhere near the point
where individual chips are starting to generate this sort of hardwired
alarms rather than specialist hardware monitoring stuff then something
will usually be very badly wrong.  If there's an actual fault developed
then very likely there is nothing that will fix it and it's merely a
case of preventing further or escallating physical damage to the system.
If it's something like a thermal warning then possibly waiting for
things to cool down might help.  The fact that it's hard to do anything
constructive about these issues on an individual device level is why
there's not code doing so upstream, if things have got to this point
then the ship has sailed.

Typical reactions would include things like going down to the lowest
available OPP, turning off some or all functionality of the system or
just plain shutting down the entire system.  The main distinction with a
warning rather than an error is that you know the regulator is still
operating.  If the regulator has encountered an actual error then you
don't know what state the devices it is supplying will be in, this means
that for example the driver getting the notification won't be able to
assume that the device will respond to register I/O or retain any state
it may have had.

> Keep in mind, though, that at least the qcom-labibb regulator does *not*
> support what you propose: that one has auto-shutdown (OVP) enabled by
> default (and *cannot* be disabled), no auto-shutdown on OCP (and no way
> to enable it).

This is very standard, the stuff that's baked into the devices tends to
be minimally configurable.