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

Date:   Wed, 27 Jan 2021 12:01:55 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     unlisted-recipients:; (no To-header on input)
CC:     "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "angelogioacchino.delregno@...ainline.org" 
        <angelogioacchino.delregno@...ainline.org>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: short-circuit and over-current IRQs

Hi dee Ho peeps,

I just noticed the
390af53e04114f790d60b63802a4de9d815ade03 ("regulator: qcom-labibb:
Implement short-circuit and over-current IRQs")

in regulator tree. No worries - I haven't hit any problem with it :]
I've been working with ROHM BD9576MUF - which implements warning IRQs
for over/under-voltage and high temperature. (Short-circuit detection
does also generate IRQ but it also automatically shuts down the
regulators by HW). BD9576MUF does also keep the IRQ activated for as
long as the 'troubling condition' stays active in HW. This is why
BD9576MUF driver does also need to implement some logic to disable IRQ
for some time period just to keep CPU out of the IRQ loop.

https://lore.kernel.org/lkml/4d725ea6e9261f22d4c808b39013baf479f252dc.1611324968.git.matti.vaittinen@fi.rohmeurope.com/

My implementation lacks of the retry counter and regulator shut-down
(BD9576 has also OCP - "Over Current Protection/OVP - "Over Voltage
Protection"/TSD - "Thermal Shutdown" features so that HW will shut down
outputs if things get worse so those are not so crucial).

I've also had some hard time when trying to test this - I guess others
have faced similar problems too...

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 :]

I *might* be able to find some time to draft out some code for this
(not promising, I am currently having few patch series pending but I
could at least try) - but I am not able to do thorough testing with
BD9576... Any possibility to co-operate? Maybe we could try this also
onqcom-labibb? Or do you think this is overall just a dead idea?

Best Regards
	Matti Vaittinen