Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 4 May 2023 10:56:13 +0300
From:   Matti Vaittinen <mazziesaccount@gmail.com>
To:     Matti Vaittinen <mazziesaccount@gmail.com>,
        Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Cc:     Matti Vaittinen <mazziesaccount@gmail.com>,
        Jonathan Cameron <jic23@kernel.org>,
        Lars-Peter Clausen <lars@metafoo.de>,
        linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [RFC PATCH 0/3] ROHM Sensor async probing
Message-ID: <cover.1683185765.git.mazziesaccount@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="HMqvFF/irSGb9lXc"
Content-Disposition: inline
Precedence: bulk


--HMqvFF/irSGb9lXc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=
=2Euk/

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

--=20
2.40.0


--=20
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 =3D]=20

--HMqvFF/irSGb9lXc
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEIx+f8wZb28fLKEhTeFA3/03aocUFAmRTZREACgkQeFA3/03a
ocUkkAgAg5V0CvjGZoviTnbB3F1zsUJA7iwlMwXeWxNCA3gNCUrmRLNbSJkvwpRU
YnCRW3SCcHObwr94Q8MCgr7DpZ/iVgMO38fQEX4GlS6d7bwB0M+LI/05OtaqEJ+t
d0xfhV+o8h5BtT8O2nt+IFYbvLwn3E5KPpq/O7tMG58X8pY0tkd0VaEHvdo+x0gM
eTbKebFBihJTryVDFr6hg+CXPEOxoqAk8nGVxOOGo1eqCyvX6oo7QnZx9m0b8grI
yUH9iJWFwvTVhGT5XUb4VP+rte1LVwTjvvmtH9M/0JRShOn1NqgKvPMkt505JIfP
AbG/TwU7sHg7wJ1skSS9KqWTjB2uBA==
=yMyu
-----END PGP SIGNATURE-----

--HMqvFF/irSGb9lXc--