linux-kernel - Re: [PATCH] mmc: sdhci-msm: Prefer asynchronous probe

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: <CAD=FV=WaWwJnquPy+9aB89-1OwKmYKJv2PpfOkgo94Z6J8uRUg@mail.gmail.com>
Date:   Thu, 3 Sep 2020 07:35:02 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     Veerabhadrarao Badiganti <vbadigan@...eaurora.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>
Subject: Re: [PATCH] mmc: sdhci-msm: Prefer asynchronous probe

Hi,

On Thu, Sep 3, 2020 at 1:10 AM Ulf Hansson <ulf.hansson@...aro.org> wrote:
>
> On Thu, 3 Sep 2020 at 01:43, Douglas Anderson <dianders@...omium.org> wrote:
> >
> > Turning on initcall debug on one system showed this:
> >   initcall sdhci_msm_driver_init+0x0/0x28 returned 0 after 34782 usecs
> >
> > The lion's share of this time (~33 ms) was in mmc_power_up().  This
> > shouldn't be terribly surprising since there are a few calls to delay
> > based on "power_delay_ms" and the default delay there is 10 ms.
> >
> > Because we haven't specified that we'd prefer asynchronous probe for
> > this driver then we'll wait for this driver to finish before we start
> > probes for more drivers.  While 33 ms doesn't sound like tons, every
> > little bit counts.
> >
> > There should be little problem with turning on asynchronous probe for
> > this driver.  It's already possible that previous drivers may have
> > turned on asynchronous probe so we might already have other things
> > (that probed before us) probing at the same time we are anyway.  This
> > driver isn't really providing resources (clocks, regulators, etc) that
> > other drivers need to probe and even if it was they should be handling
> > -EPROBE_DEFER.
> >
> > Let's turn this on and get a bit of boot speed back.
>
> Thanks for a very well written commit message!
>
> Indeed, I am sure many mmc host drivers could benefit from a similar
> change. At least regular platform drivers and amba drivers are pretty
> sure to work, but who knows.

Yeah, and many non-mmc drivers can benefit too, which is why I've been
sending several of these patches recently as I optimize boot perf on
the device that's sitting in front of me.  ;-)  I think the idea was
that eventually we'd want the kernel to just turn on async by default
everywhere, but at the time the flag was introduced there were too
many subtle bugs everywhere.  It feels like one way to get to the
point where we'd be confident that this is OK to turn on everywhere is
to just start turning it on in lots of places.  Once enough places
have it on then perhaps that will give folks confidence that it's OK
to turn on by default across the board.

If you'd like, I can post patches to update some other set of MMC host
drivers, either as one giant patch (hard to backport, but not as
spammy) or as a large pile of patches.  I've never played with
coccinelle so I'd probably fall back to doing this by hand.  I could
probably only test on a small handful (I think I have easy access to
dw-mmc-rockchip and sdhci-of-arasan besides the msm one I already
posted), so another option is that I could also just post for those
devices...  ...or we can just hope others will notice and start
posting similar patches themselves after testing.  Let me know what
you'd prefer.  ;-)

-Doug