linux-kernel - Re: [PATCH] regulator: do not balance 'boot-on' coupled regulators without constraints

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]

Message-ID: <2f0e021d-387a-4693-882d-aba66e20dd2b@samsung.com>
Date:   Fri, 5 Jun 2020 15:37:32 +0200
From:   Marek Szyprowski <m.szyprowski@...sung.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        Dmitry Osipenko <digetx@...il.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Lucas Stach <l.stach@...gutronix.de>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Viresh Kumar <viresh.kumar@...aro.org>, peron.clem@...il.com,
        Nishanth Menon <nm@...com>, Stephen Boyd <sboyd@...nel.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Rafael Wysocki <rjw@...ysocki.net>,
        linux-samsung-soc@...r.kernel.org,
        Chanwoo Choi <cw00.choi@...sung.com>,
        Saravana Kannan <saravanak@...gle.com>
Subject: Re: [PATCH] regulator: do not balance 'boot-on' coupled regulators
 without constraints

Hi Mark,

On 05.06.2020 12:20, Mark Brown wrote:
> On Fri, Jun 05, 2020 at 08:37:24AM +0200, Marek Szyprowski wrote:
>
>> Balancing of the 'boot-on' coupled regulators must wait until the clients
>> set their constraints, otherwise the balancing code might change the
> No, this is not what boot-on means at all.  It is there for cases where
> we can't read the enable status from the hardware.  Trying to infer
> *anything* about the runtime behaviour from it being present or absent
> is very badly broken.

Okay, what about the 'always-on' property? I don't think that we need 
another property for annotating this behavior, as in my opinion this is 
just an implementation issue on the Linux kernel and regulator 
framework. Alternatively I can drop the property check, but then it 
won't be possible to have a regulator without a consumer, which follows 
the other one (although we still don't have a real use case for it).

If you don't like this idea at all, I will try to move this logic to the 
custom coupler again, although it would mean some code copying.

> Saravana (CCed) was working on some patches which tried to deal with
> some stuff around this for enables using the sync_state() callback.
> Unfortunately there's quite a few problems with the current approach
> (the biggest one from my point of view being that it's implemented so
> that it requires every single consumer of every device on the PMIC to
> come up but there's others at more of an implementation level).
I'm not sure if we really need such complex solution for this...

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland