| Message ID | 20221028141411.5.Ia458a69e1d592bfa4f04cde7018bbc7486f91a23@changeid (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 015e4b05c377dc5e066e88737bff9990d5ac358d |
| Headers | show |
| Series | [1/5] platform/chrome: cros_ec_lpc: Move mec_init/destroy to device probe/remove | expand |
diff --git a/drivers/platform/chrome/cros_ec_spi.c b/drivers/platform/chrome/cros_ec_spi.c index 7360b3ff6e4f..21143dba8970 100644 --- a/drivers/platform/chrome/cros_ec_spi.c +++ b/drivers/platform/chrome/cros_ec_spi.c @@ -834,6 +834,7 @@ static struct spi_driver cros_ec_driver_spi = { .name = "cros-ec-spi", .of_match_table = cros_ec_spi_of_match, .pm = &cros_ec_spi_pm_ops, + .probe_type = PROBE_PREFER_ASYNCHRONOUS, }, .probe = cros_ec_spi_probe, .remove = cros_ec_spi_remove,
This driver often takes on the order of 10ms to start, but in some cases as much as 600ms [1]. It shouldn't have many cross-device dependencies to race with, nor racy access to shared state with other drivers, so this should be a relatively low risk change. This driver was pinpointed as part of a survey of top slowest initcalls (i.e., are built in, and probing synchronously) on a lab of ChromeOS systems. [1] 600ms was especially surprising to me, so I checked a little deeper. This driver is used to interface with Embedded Controllers besides just the traditional laptop power-state controller -- it also interfaces with some fingerprint readers, which may start up in parallel with the kernel, or which may not even be present on some SKUs, despite having a node for it. Thus, our time is wasted just timing out talking to it. At least we can do that without blocking everyone else. Signed-off-by: Brian Norris <briannorris@chromium.org> --- drivers/platform/chrome/cros_ec_spi.c | 1 + 1 file changed, 1 insertion(+)