ROHM Sensor async probing

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.

There is however some caveats listed for asynchronous probing for example here:
https://lore.kernel.org/all/[email protected]/

I don't know how tolerant IIO users are what comes to asynchronous probing but I _guess_ this is (and should be) handled pretty well. Still, guessing could be said to be somewhat sub-optimal when doing kernel development :) Hence this RFC - if someone has better understanding on async probing when using IIO, please let me know!

As far as I know these drivers do not currently have in-tree users. Furthemore, they are so new they don't probably have many user-space users either. In fact, the BU27034 is not yet in any official releases and BU27008 is not merged in any official trees yet. Thus, testing out async probing with them should not break existing users. KX022A is also relatively new and I don't think it has yet been widely used either.

Finally, if asynchronous probing does break things, then:
a) We should try fix the thing preventing async probe.
b) We can pretty easily revert back to synchronous probing.

Please note that the patch 2 depends on
https://lore.kernel.org/lkml/[email protected]/
which is not yet in-tree. If the feed-back from this RFC is positive, then I will squash this change to that series when re-spinning it next time.

Please note that the patch 3 depends on bu27034 series which is expected to land on 6.4-rc1.

---

Matti Vaittinen (3):
iio: bu27034: Probe asynchronously
iio: bu27008: Probe asynchronously
iio: kx022a: Probe asynchronously

 drivers/iio/accel/kionix-kx022a-i2c.c | 1 +
 drivers/iio/accel/kionix-kx022a-spi.c | 1 +
 drivers/iio/light/rohm-bu27008.c      | 1 +
 drivers/iio/light/rohm-bu27034.c      | 1 +
 4 files changed, 4 insertions(+)

2.40.0


-- 
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND

~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =] 

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/[email protected]/

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.

---

I am unsure if this change is 100% safe - but I don't immediately see the harm. Please let me know if some of you have more experience on problems when using asynchronous probing with IIO devices.

---
 drivers/iio/light/rohm-bu27034.c | 1 +
 1 file changed, 1 insertion(+)

index f85194fda6b0..183cf550af13 100644
@@ -1500,6 +1500,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,
 };

2.40.0


-- 
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND

~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =] 

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 BU27008 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/[email protected]/

Enabling async probing for the ROHM BU27008 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 BU27008.

---

I am unsure if this change is 100% safe - but I don't immediately see the harm. Please let me know if some of you have more experience on problems when using asynchronous probing with IIO devices.

---
 drivers/iio/light/rohm-bu27008.c | 1 +
 1 file changed, 1 insertion(+)

index c04d845062ba..628d17036bb4 100644
@@ -982,6 +982,7 @@ static struct i2c_driver bu27008_i2c_driver = {
 	.driver = {
 		.name = "bu27008",
 		.of_match_table = bu27008_of_match,
+		.probe_type = PROBE_PREFER_ASYNCHRONOUS,
 	},
 	.probe_new = bu27008_probe,
 };

2.40.0


-- 
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND

~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =] 

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 KX022A 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/[email protected]/

Enable asynchronous probing for KX022A.

---

I am unsure if this change is 100% safe - but I don't immediately see the harm. Please let me know if some of you have more experience on problems when using asynchronous probing with IIO devices.

---
 drivers/iio/accel/kionix-kx022a-i2c.c | 1 +
 drivers/iio/accel/kionix-kx022a-spi.c | 1 +
 2 files changed, 2 insertions(+)

index e6fd02d931b6..ee982206e5dd 100644
@@ -40,6 +40,7 @@ static struct i2c_driver kx022a_i2c_driver = {
 	.driver = {
 		.name  = "kx022a-i2c",
 		.of_match_table = kx022a_of_match,
+		.probe_type = PROBE_PREFER_ASYNCHRONOUS,
 	  },
 	.probe_new    = kx022a_i2c_probe,
 };

index 9cd047f7b346..f45a46899a5f 100644
@@ -46,6 +46,7 @@ static struct spi_driver kx022a_spi_driver = {
 	.driver = {
 		.name   = "kx022a-spi",
 		.of_match_table = kx022a_of_match,
+		.probe_type = PROBE_PREFER_ASYNCHRONOUS,
 	},
 	.probe = kx022a_spi_probe,
 	.id_table = kx022a_id,

2.40.0


-- 
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND

~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =] 

Generally it should be fine, but given that weird things sometimes happen we don't apply a blanket policy and it's up to individual driver maintainers to give it a go. Also it's only worth doing if a driver is significantly slow for some reason..

I've hit problems with async probe before (usually showing up bugs that weren't visible before), but not in IIO drivers.

So I've applied patches 1 and 3. Plenty of time for people to shout if they can see a problem though.

Jonathan