linux-kernel - [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-next>] [day] [month] [year] [list]

Message-Id: <20200902164303.1.I5e598a25222b4534c0083b61dbfa4e0e76f66171@changeid>
Date:   Wed,  2 Sep 2020 16:43:15 -0700
From:   Douglas Anderson <dianders@...omium.org>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     vbadigan@...eaurora.org, Douglas Anderson <dianders@...omium.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mmc@...r.kernel.org
Subject: [PATCH] mmc: sdhci-msm: Prefer asynchronous probe

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.

Signed-off-by: Douglas Anderson <dianders@...omium.org>
---

 drivers/mmc/host/sdhci-msm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index d4c02884cca8..9dd0dbb65382 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -2542,6 +2542,7 @@ static struct platform_driver sdhci_msm_driver = {
 		   .name = "sdhci_msm",
 		   .of_match_table = sdhci_msm_dt_match,
 		   .pm = &sdhci_msm_pm_ops,
+		   .probe_type = PROBE_PREFER_ASYNCHRONOUS,
 	},
 };
 
-- 
2.28.0.402.g5ffc5be6b7-goog