linux-kernel - Re: short-circuit and over-current IRQs

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] [day] [month] [year] [list]

Date:   Mon, 1 Feb 2021 13:17:28 +0000
From:   Mark Brown <broonie@...nel.org>
To:     AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...ainline.org>
Cc:     matti.vaittinen@...rohmeurope.com,
        "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: short-circuit and over-current IRQs

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.

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