Re: short-circuit and over-current IRQs

[Matti Vaittinen]

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