linux-kernel - [RFC PATCH 0/3] ROHM Sensor async probing

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]

Date:   Thu, 4 May 2023 10:56:13 +0300
From:   Matti Vaittinen <mazziesaccount@...il.com>
To:     Matti Vaittinen <mazziesaccount@...il.com>,
        Matti Vaittinen <matti.vaittinen@...rohmeurope.com>
Cc:     Matti Vaittinen <mazziesaccount@...il.com>,
        Jonathan Cameron <jic23@...nel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [RFC PATCH 0/3] 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/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 =] 

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)