linux-kernel - Re: [PATCH 2/2] regulator: fixed: Set PROBE_PREFER

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAD=FV=XWaWfDy+ZFjwq6hK4ssTtGjxRePzF2DooMAOg3fziZvw@mail.gmail.com>
Date:   Mon, 13 Mar 2023 12:49:37 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     mka@...omium.org, christian@...lschutter.com,
        Liam Girdwood <lgirdwood@...il.com>,
        linux-kernel@...r.kernel.org,
        Brian Norris <briannorris@...omium.org>,
        Saravana Kannan <saravanak@...gle.com>
Subject: Re: [PATCH 2/2] regulator: fixed: Set PROBE_PREFER_ASYNCHRONOUS

Hi,

On Mon, Mar 13, 2023 at 12:05 PM Mark Brown <broonie@...nel.org> wrote:
>
> On Mon, Mar 13, 2023 at 11:18:20AM -0700, Douglas Anderson wrote:
> > As of commit 218320fec294 ("regulator: core: Fix off-on-delay-us for
> > always-on/boot-on regulators"), we now might have a big delay during
> > probe of fixed regulators. That can have a significant boot speed
> > impact. Let's mitigate this by preferring async probe for fixed
> > regulators. The regulator framework itself has no issues with
> > regulators probing in an asynchronous way. The fixed regulator driver
> > is fairly straightforward and also has no issues.
>
> This is going to be true for all regulators...

Sure, that's true. So what are you suggesting?

There has always been a hope that someday we could just turn on async
probe everywhere. Folks at ChromeOS / Android at Google have looked at
this on and off over the years. Most recently +briannorris looked at
and described it as "no small task". There were a lot of kinks across
the various subsystems. I think +Saravana also has it on his wishlist
to tackle, too.

For the most part, the best we've been able to do is to identify
devices that happened to be involved in long delays at bootup and add
the flag to those devices after confirming that they worked OK. It's
not super elegant but it's pragmatic. That's what I've done here. If
there are other regulator drivers that are known to be involved in big
delays during probe time then we should add the flag there, too. Right
now, "off-on-delay" is only for fixed regulators, though there's no
real reason it shouldn't be applied to all regulators. I suppose some
of the other regulator related delays could affect pretty much any
regulator, though I guess normally those aren't associated with
always-on / boot-on regulators?

If you want, I can submit a pile of patches adding this flag to more
regulators. I did that in the past for mmc:

31ae403513be mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that are
newer than 5.4
d86472ae8b20 mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v5.4
a1a489197a07 mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that
existed in v4.19
7320915c8861 mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that
existed in v4.14
2a99f3fa85ea mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.9
21b2cec61c04 mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4

-Doug