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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 27 Jan 2021 14:56:47 +0200
From:   Matti Vaittinen <matti.vaittinen@...rohmeurope.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "angelogioacchino.delregno@...ainline.org" 
        <angelogioacchino.delregno@...ainline.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: short-circuit and over-current IRQs

Hello Mark,

Nice to hear from you. :)

On Wed, 2021-01-27 at 12:27 +0000, Mark Brown wrote:
> On Wed, Jan 27, 2021 at 12:01:55PM +0000, Vaittinen, Matti wrote:
> 
> > Anyways - I was wondering if this is common thing amongst many
> > PMICs?
> > If yes - then, perhaps some generally useful regulator helper could
> > be
> > added to help implementing the IRQ disabling + scheduling worker to
> > check status and re-enable IRQs? I think it *might* save some time
> > in
> > the future - and help making same mistakes many times :]
> 
> If we've got two that's enough for a helper.  TBH I'm a bit surprised
> that people are implementing hardware that leaves the outputs enabled
> when it detects this sort of error, it's something that's usually an
> emergency that needs shutting off quickly to prevent hardware damage.

I can only speak for BD9576MUF - which has two limits for monitored
entity (temperature/voltage). One limit being 'warning' limit (or
'detection' as data-sheet says), the other being 'protection' limit.

I don't know guys who designed HW - I am located to a remote spot on
the other side of the world and on top of that I am the odd "SW guy" so
it's better to keep me out of the HW R&D decisions and especially the
customers ;) - but I *guess* the idea has been that consumer driver(s)
could do some 'recovery action' at 'warning' limit (which might make
sense for example when temperature is increased to 'high' but not yet
'damaging' - I guess there is something that can be done with
over/under voltages too...) and only kill the power if that doesn't
help and situation (with temperature/voltage) gets worse.

What I don't like is the fact that HW keeps IRQ asserted instead of
having a state machine which would only generate IRQ when condition
changes + status register to read current condition.

I will see if I can cook-up something decent - but as I said, I would
appreciate any/all testing if I get patch crafted :)

Best Regards
	Matti