Commit 4cd56dbd authored by Matti Vaittinen's avatar Matti Vaittinen Committed by Jonathan Cameron

iio: bu27034: Probe asynchronously

Devices which may take a while to initialize during probe and which have
no strong reason to probe synchronously can request asynchronous probing
as default probe strategy. This can speed-up start times on some
platforms.

The BU27034 gets probe delayed for at least two reasons. It enables the
supply regulator, (which is likely to have ramp-up delay if it was
disabled) and additionally it delays while the sensor itself is
initializing.

Changing to asynchronous probing may cause problems. Some of which are
discussed in:
https://lore.kernel.org/all/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk/

Enabling async probing for the ROHM BU27034 should be fairly safe to try
though as there is no in-tree users for it yet. If the async probing
appears to be an issue we can switch easily back to synchronous (or
better yet, fix the actual problem).

Enable asynchronous probing for BU27034.
Signed-off-by: default avatarMatti Vaittinen <mazziesaccount@gmail.com>
Link: https://lore.kernel.org/r/e7088793e1868c77b1894b30cd026e8ed043ea7c.1683185765.git.mazziesaccount@gmail.comSigned-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
parent e0b79724
......@@ -1486,6 +1486,7 @@ static struct i2c_driver bu27034_i2c_driver = {
.driver = {
.name = "bu27034-als",
.of_match_table = bu27034_of_match,
.probe_type = PROBE_PREFER_ASYNCHRONOUS,
},
.probe_new = bu27034_probe,
};
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment