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]
Message-ID: <cover.1683185765.git.mazziesaccount@gmail.com>
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ