[RFC PATCH 0/3] ROHM Sensor async probing

[RFC PATCH 0/3] ROHM Sensor async probing

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 2423 bytes --]

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/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk/

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/cover.1683105758.git.mazziesaccount@gmail.com/
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 =] 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[RFC PATCH 1/3] iio: bu27034: Probe asynchronously

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 2065 bytes --]

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: Matti Vaittinen <mazziesaccount@gmail.com>

---

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(+)

diff --git a/drivers/iio/light/rohm-bu27034.c b/drivers/iio/light/rohm-bu27034.c
index f85194fda6b0..183cf550af13 100644
--- a/drivers/iio/light/rohm-bu27034.c
+++ b/drivers/iio/light/rohm-bu27034.c
@@ -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 =] 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[RFC PATCH 2/3] iio: bu27008: Probe asynchronously

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]

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/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk/

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.

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>

---

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(+)

diff --git a/drivers/iio/light/rohm-bu27008.c b/drivers/iio/light/rohm-bu27008.c
index c04d845062ba..628d17036bb4 100644
--- a/drivers/iio/light/rohm-bu27008.c
+++ b/drivers/iio/light/rohm-bu27008.c
@@ -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 =] 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[RFC PATCH 3/3] iio: kx022a: Probe asynchronously

[Matti Vaittinen]

[-- Attachment #1: Type: text/plain, Size: 2363 bytes --]

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/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk/

Enable asynchronous probing for KX022A.

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>

---

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(+)

diff --git a/drivers/iio/accel/kionix-kx022a-i2c.c b/drivers/iio/accel/kionix-kx022a-i2c.c
index e6fd02d931b6..ee982206e5dd 100644
--- a/drivers/iio/accel/kionix-kx022a-i2c.c
+++ b/drivers/iio/accel/kionix-kx022a-i2c.c
@@ -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,
 };
diff --git a/drivers/iio/accel/kionix-kx022a-spi.c b/drivers/iio/accel/kionix-kx022a-spi.c
index 9cd047f7b346..f45a46899a5f 100644
--- a/drivers/iio/accel/kionix-kx022a-spi.c
+++ b/drivers/iio/accel/kionix-kx022a-spi.c
@@ -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 =] 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC PATCH 0/3] ROHM Sensor async probing

[Jonathan Cameron]

On Thu, 4 May 2023 10:56:13 +0300
Matti Vaittinen <mazziesaccount@gmail.com> wrote:

> 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/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk/
> 
> 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/cover.1683105758.git.mazziesaccount@gmail.com/
> 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.

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

> 
> ---
> 
> 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(+)
>