linux-kernel - Re: [PATCH] regulator: core: Skip balancing of the enabled regulators in regulator

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: <9268b455-ec66-97e1-909d-f964ac31c0ef@samsung.com>
Date:   Tue, 8 Oct 2019 14:38:55 +0200
From:   Marek Szyprowski <m.szyprowski@...sung.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     linux-kernel@...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>,
        linux-samsung-soc@...r.kernel.org,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Kamil Konieczny <k.konieczny@...sung.com>
Subject: Re: [PATCH] regulator: core: Skip balancing of the enabled
 regulators in regulator_enable()

Hi Mark,

On 08.10.2019 14:06, Mark Brown wrote:
> On Tue, Oct 08, 2019 at 02:01:15PM +0200, Marek Szyprowski wrote:
>> On 08.10.2019 13:50, Mark Brown wrote:
>>> This then means that for users that might legitimately enable and
>>> disable regulators that need to be constrained are forced to change the
>>> voltage when they enable the regualtors in order to have their
>>> constraints take effect which seems bad.  I'd rather change the the
>>> cpufreq consumers to either not do the enable (since there really should
>>> be an always-on constraint this should be redundant, we might need to
>>> fix the core to take account of their settings though I think we lost
>>> that) or to set the voltage to whatever they need prior to doing their
>>> first enable, that seems more robust.
>> Well, I'm open for other ways of fixing this issue. Calling enable on
>> always-on regulator imho should not change its rate...
> Yes, although there is the whole "don't touch things until a consumer
> tells us to" thing going on.  I had expected that this was kicking in
> because we weren't paying attention to the constraints of disabled
> regulators but I can't see the code implementing that any more so I
> guess we removed it at some point (it was always debatable).

Then if I get it right, the issue is caused by the commit 7f93ff73f7c8 
("opp: core: add regulators enable and disable"). I've checked and 
indeed reverting it fixes Peach Pi to boot properly. The question is if 
this is desired behavior or not?

I've CC: Viresh, Kamil and Bartlomiej, here is the link to the beginning 
of this thread:

https://lkml.org/lkml/2019/10/8/265

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