linux-kernel - Re: [PATCH] regulator: core: resolve supply voltage deferral silently

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: <20210902170613.GG11164@sirena.org.uk>
Date:   Thu, 2 Sep 2021 18:06:13 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Brian Norris <briannorris@...omium.org>
Cc:     Chen-Yu Tsai <wenst@...omium.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] regulator: core: resolve supply voltage deferral silently

On Wed, Sep 01, 2021 at 01:06:28PM -0700, Brian Norris wrote:
> On Wed, Sep 1, 2021 at 8:09 AM Mark Brown <broonie@...nel.org> wrote:

> > This doesn't make sense to me.  Why are we getting as far as trying to
> > read the voltage if we've been told to defer probe?  This suggests that
> > we ought to be doing this earlier on.  I see that the logic is already
> > there to handle a deferral being generated here but it looks off.

> Take a look at the commit this "Fixes":

> 21e39809fd7c ("regulator: vctrl: Avoid lockdep warning in enable/disable ops")

That driver change is at most tangentially related to the code that's
being updated, this is a prime example of just randomly shoving Fixes
lines onto things :( .  It's perfectly fine to send patches without a
Fixes line, adding them when they're not really related at best creates
noise and at worst causes problems with backporting (especially given
the whole pulling random commits into stable thing we have these days).

> Frankly, I'm not sure if we're abusing regulator framework features
> (particularly, around use of ->supply) in commit 21e39809fd7c, or if
> this is just a lacking area in the framework. I'm interested in
> whether you have thoughts on doing this Better(TM).

That's definitely an abuse of the API, the hardware design is pretty
much a gross hack anywhere as far as I remember.  As Chen-Yu says I'd
only expect this to be possible in the case where the supply is in
bypass mode and hasn't got its own parent.  In any case I can see why
it's happening now...

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)