From patchwork Thu May 4 07:56:13 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matti Vaittinen X-Patchwork-Id: 13230850 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EFDD6C77B78 for ; Thu, 4 May 2023 07:56:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229751AbjEDH4k (ORCPT ); Thu, 4 May 2023 03:56:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39512 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229522AbjEDH4j (ORCPT ); Thu, 4 May 2023 03:56:39 -0400 Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 550872728; Thu, 4 May 2023 00:56:38 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2ac7de2b72fso2053921fa.1; Thu, 04 May 2023 00:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683186996; x=1685778996; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=k7bTcKGL069SV5chj2exx/6OgP9rXCsK1lkREqDUd94=; b=W9Dmtdln7kVxUeZK0oWOLX0IRwjjID+s6UUVYH4DcuJ7V3FprETbIzGmy3KYv7a3zc cq7CxHPgrQLY/q/4wogcoU1kCkmGGiodnMMMUq9QRr6qcX1CI8Z+t3O8sa8ikMvxps7U MYUBiWZReuoLZwbEOkQ7hu5QSl2wCzHLrhSBOZvusjKm9ucLTv0mf0D4Hpp4QfS4xf3q M90Sl1pzxl4Pb7GGQM2YLjpjBXrPkO2WcY0vFC8Sc5klyWHRRr1j7z/iJEdaAK+50+Zf RenOGaglvXTQQggRUSfl2K6lyxhBaV9HLinZ/9KaR8jyJIFyFJndy7yJfXZWq80qgh6G yfqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683186996; x=1685778996; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=k7bTcKGL069SV5chj2exx/6OgP9rXCsK1lkREqDUd94=; b=HOf3mp0adhOy+yTlv2+SV8nPfzWi8XvbqUaL2YMwvPqJx4IxMKcSSw4/BkbmKZVVjF MYMB7s6bC3IQUifv3TiB8gIVosvL3HzmkwzxdzA7Q6NRpx5D5MNK2M8U76Aq+fNGs37Q 6YMoeeAE5ZTp1Gpudi8EU3qUQHf8/Lxfg0VBzCHt96nEtex1UyFs+652KMNqyahDDH6C BuYzPXV1WGmoYnRngvkACiXgHpJItIYvqvMycFhshzq4FvBO2qZu7edphUbAOjEnR859 X/a/gE0C0sUXg82rNXD2uInww3OLxMOOzHwrAACzDqKOlayYtGpw+4VZ6is//kQrkvc4 c0mQ== X-Gm-Message-State: AC+VfDw+HkYVgn+3kSekWb5cs5GiXFSBu9D9jWjEdi3PKt0fpmbZm1lK E2RuyoMGjpY6lS250KZKPXqjpXFKBM8= X-Google-Smtp-Source: ACHHUZ53g4ZDfA8bz/0ja2DcDq9diAHAvexxjuGej3G9kQ/E08mCx1H4pCkicfywpYSmD9S2UaqCEg== X-Received: by 2002:ac2:43b3:0:b0:4ee:d799:eca with SMTP id t19-20020ac243b3000000b004eed7990ecamr1479225lfl.40.1683186996275; Thu, 04 May 2023 00:56:36 -0700 (PDT) Received: from fedora (62-78-225-252.bb.dnainternet.fi. [62.78.225.252]) by smtp.gmail.com with ESMTPSA id a9-20020a056512020900b004f06aa3d856sm2552895lfo.3.2023.05.04.00.56.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 May 2023 00:56:35 -0700 (PDT) Date: Thu, 4 May 2023 10:56:13 +0300 From: Matti Vaittinen To: Matti Vaittinen , Matti Vaittinen Cc: Matti Vaittinen , Jonathan Cameron , Lars-Peter Clausen , linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [RFC PATCH 0/3] ROHM Sensor async probing Message-ID: MIME-Version: 1.0 Content-Disposition: inline Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org 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(+)