linux-kernel - Re: [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-prev] [day] [month] [year] [list]

Message-ID: <20230506184727.344086c5@jic23-huawei>
Date:   Sat, 6 May 2023 18:47:27 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Matti Vaittinen <mazziesaccount@...il.com>
Cc:     Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
        Lars-Peter Clausen <lars@...afoo.de>,
        linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] ROHM Sensor async probing

On Thu, 4 May 2023 10:56:13 +0300
Matti Vaittinen <mazziesaccount@...il.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(+)
>