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:57: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 1/3] iio: bu27034: Probe asynchronously
Message-ID: <e7088793e1868c77b1894b30cd026e8ed043ea7c.1683185765.git.mazziesaccount@gmail.com>
References: <cover.1683185765.git.mazziesaccount@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="aciMmrdY9RqkdmjW"
Content-Disposition: inline
In-Reply-To: <cover.1683185765.git.mazziesaccount@gmail.com>
Precedence: bulk


--aciMmrdY9RqkdmjW
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.

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

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-bu27=
034.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 =3D {
 	.driver =3D {
 		.name =3D "bu27034-als",
 		.of_match_table =3D bu27034_of_match,
+		.probe_type =3D PROBE_PREFER_ASYNCHRONOUS,
 	},
 	.probe_new =3D bu27034_probe,
 };
--=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

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

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

iQEzBAEBCAAdFiEEIx+f8wZb28fLKEhTeFA3/03aocUFAmRTZVkACgkQeFA3/03a
ocVt6QgAzTIOeNiwwPslvohllnSHS2DfMTZMJDXjJXn+lzji1prk8rKBfuCyYRHa
3nza52sa246JdTScrbx3bFY3nAN2UWbHKp93dacnrTecvk+YxaKfVtyRnHlDsBoh
6XTBQjW0XHz4pkGfjZYAg2VoaRSM6N4KR7/r88ls+5wSzz2wS03CaUovyQTNGCnO
ggrrA9F4w6nBp+4TDBX7Bn7SwNcUa2C0tHGFj3nFwBdqr0a9y1PGtTKXp3i+mELj
I9zr21IlI99VZSuM8ao4rIrXD8Lac/szHoXPIpBA8CUSVQ6bFXyJ2SQmjiG6oZTU
kJzyLAoh7ATDhqXnQ+7UUmH9W7MVQA==
=PJv1
-----END PGP SIGNATURE-----

--aciMmrdY9RqkdmjW--