linux-kernel - RE: [PATCH] regulator: da9063: disable unused voltage monitors

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

Message-ID: <OSAPR01MB50608227855EC6ABEA3A2CCAB08F9@OSAPR01MB5060.jpnprd01.prod.outlook.com>
Date:   Tue, 19 Jul 2022 09:21:57 +0000
From:   DLG Adam Thomson <DLG-Adam.Thomson.Opensource@...renesas.com>
To:     Benjamin Bara <bbara93@...il.com>,
        DLG Adam Thomson <DLG-Adam.Thomson.Opensource@...renesas.com>
CC:     "support.opensource@...semi.com" <support.opensource@...semi.com>,
        "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "lee.jones@...aro.org" <lee.jones@...aro.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Benjamin Bara <benjamin.bara@...data.com>,
        "richard.leitner@...ux.dev" <richard.leitner@...ux.dev>
Subject: RE: [PATCH] regulator: da9063: disable unused voltage monitors

On 14 July 2022 20:15, Benjamin Bara wrote:

> I have some use cases where certain modules (e.g. audio) are not required.
> Therefore, I have removed a couple of "always-on" from my DT to let the kernel
> decide if the regulators are needed.
> Since unfortunately some of the later disabled LDOs are monitored, the state
> becomes invalid.

Ok, understood.

> I am aware that the patch is not complete to handle the whole voltage
> monitoring of the da9063.
> So if wanted, I can extend the patch to store the vmon state when disabling
> it and restore it during the re-enable process (can also take a look for the
> handling while sleep/suspend).

The problem is your fix isn't really a fix. If the LDO you're disabling is the
last monitored LDO, and you turn off monitoring for that LDO, your GP_FB2 line
will no longer be asserted so you still have a problem. I guess one solution
might be to enable monitoring for rails you know will always be present in your
system and disable monitoring for the ones you know will be dynamically
disabled/enabled. Only problem here is making sure that ordering is right so
you don't get to a point where all rail monitoring is disabled whilst
enabling/disabling monitoring of the specified rails. IIRC the ordering in DT
is preseved in terms of handling though so this might be trivial.

>
> best regards & thanks again,
> bb
>
> P.S.
> I checked if there is some existing kind of framework for voltage
> monitoring of regulators, but I couldn't find something so far.
> I can imagine it might make sense to have a DT property for
> "regulator-monitor-voltage-on/-off" to override the OTP settings via DT,
> but I am not sure if this is something that is needed/wanted/required.

Initially I was thinking that hwmon/IIO might be the place to support something
like this but looking further I'm not sure that would work. In the absence of
an obvious place, device specific DT bindings might be the best approach, to
specify for each rail if it's monitored or not. If you did take that approach
you would need to make sure it doesn't impact existing users so the binding
*couldn't* simply be a boolean flag.