From mboxrd@z Thu Jan 1 00:00:00 1970 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 827DEC32771 for ; Wed, 21 Sep 2022 09:07:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231217AbiIUJHC (ORCPT ); Wed, 21 Sep 2022 05:07:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59548 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231374AbiIUJGt (ORCPT ); Wed, 21 Sep 2022 05:06:49 -0400 Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 011578E0D5 for ; Wed, 21 Sep 2022 02:06:37 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id o7so3481366qkj.10 for ; Wed, 21 Sep 2022 02:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date; bh=9yV4LRGhFt6LFezVpqUP0yfiNpoAntmY3wUwChWwW9U=; b=bGHmKdAYmokUvBZFszMEhy8CAuunlB33rKcKvqPQ5aT59FnJC0V3Koq5360OvzZy8S vwsVdqwDE0mUQHBbxEgdIa5h5MG4gqYRVHXRwO7EP3CvjGtqvoGt+kBG05skb953IjX0 4OMU7wsjKRXvq5RvQShmO6VPyc0Nxrs8j78GYrtQLJCIDaDrPjdyYHCEkthIkG/9+yWb ANq3vYIyHIyhOWvC/NE3TNP5Myfa4FxLYcyaByyh6/4gmAAIO0c5T2SXFwAwN7sogjan JKEyoMgE+YfQmPEeuO4R9lVsi2zRPbm850gBoLNXNFC/69oo9PNswP56Xvu2HdcuLTsT hUHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date; bh=9yV4LRGhFt6LFezVpqUP0yfiNpoAntmY3wUwChWwW9U=; b=WDogfjdC8/k4X3l2gyUtEdInWxlph5PQHgcmrL1RehXFkEwuvrQyXHC1sDUojzDo5M 6e/ZSWG0u1CEE13imSWGCcVwptK6VCfV6/klhfrQAtFONgVFQu4qmXv3fjgy70rE7Lc+ m87qexujHOT9/FbPjLLtigYHaZmnqvqIcRaJnlVR9E1imBQHH0tq76I9eDo5W5d9d4PJ L3iKU1VQga9ggbJ6TOcbmHNvLnmKMeDMDTajpwCBea6uK9OzDqO5VAAgEdevI6wjfLII jeyv2+VuO8uINkWceJQH10/ZXmdkSvijfP/kDjkMsBV2iq+7dJR8uAIzeI5d/u3OOT/o kg6w== X-Gm-Message-State: ACrzQf3z6bdqecH++HPYxqWaZ0KJ7WQRX5kVkkGXPyqk/ARthiYBoaOL aNZ1427tP1dw9tE/cBdZum4= X-Google-Smtp-Source: AMsMyM4dQV8egMsweegXJYpUsa6C3UbUT/6NomoUjurqa142TdTcGXBwyUnxuUmBXYVZPvh5vJVp4g== X-Received: by 2002:a05:620a:ceb:b0:6cf:468f:ae66 with SMTP id c11-20020a05620a0ceb00b006cf468fae66mr3349088qkj.591.1663751196479; Wed, 21 Sep 2022 02:06:36 -0700 (PDT) Received: from p200300f6ef036f005de6a4d0d791ed01.dip0.t-ipconnect.de (p200300f6ef036f005de6a4d0d791ed01.dip0.t-ipconnect.de. [2003:f6:ef03:6f00:5de6:a4d0:d791:ed01]) by smtp.gmail.com with ESMTPSA id ay43-20020a05620a17ab00b006ce76811a07sm1553998qkb.75.2022.09.21.02.06.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Sep 2022 02:06:36 -0700 (PDT) Message-ID: Subject: Re: [PATCH 03/15] iio: adc: axp288_adc: do not use internal iio_dev lock From: Nuno =?ISO-8859-1?Q?S=E1?= To: Andy Shevchenko , "Sa, Nuno" Cc: "linux-arm-kernel@lists.infradead.org" , "linux-rockchip@lists.infradead.org" , "linux-amlogic@lists.infradead.org" , "linux-imx@nxp.com" , "linux-iio@vger.kernel.org" , Chunyan Zhang , "Hennerich, Michael" , Martin Blumenstingl , Sascha Hauer , Cixi Geng , Kevin Hilman , Vladimir Zapolskiy , Pengutronix Kernel Team , Alexandru Ardelean , Fabio Estevam , Andriy Tryshnivskyy , Haibo Chen , Shawn Guo , Hans de Goede , Miquel Raynal , Jerome Brunet , Heiko Stuebner , Florian Boor , "Regus, Ciprian" , Lars-Peter Clausen , Jonathan Cameron , Neil Armstrong , Baolin Wang , Jyoti Bhayana , Chen-Yu Tsai , Orson Zhai Date: Wed, 21 Sep 2022 11:07:50 +0200 In-Reply-To: References: <20220920112821.975359-1-nuno.sa@analog.com> <20220920112821.975359-4-nuno.sa@analog.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org On Tue, 2022-09-20 at 18:12 +0300, Andy Shevchenko wrote: > On Tue, Sep 20, 2022 at 4:46 PM Sa, Nuno wrote: > > > -----Original Message----- > > > From: Andy Shevchenko > > > Sent: Tuesday, September 20, 2022 3:39 PM > > > On Tue, Sep 20, 2022 at 4:37 PM Andy Shevchenko > > > wrote: > > > > On Tue, Sep 20, 2022 at 4:18 PM Sa, Nuno > > > > wrote: > > > > > > On Tue, Sep 20, 2022 at 2:28 PM Nuno S=C3=A1 > > > > > > > > > wrote: > > >=20 > > > ... > > >=20 > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 info =3D iio_priv(= indio_dev); > > > > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mutex_init(&info->lock)= ; > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 info->irq =3D plat= form_get_irq(pdev, 0); > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (info->irq < 0) > > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return info->irq; > > > > > >=20 > > > > > > Consider initializing it as late as possible, like after > > > > > > IRQ retrieval > > > > > > in this context (maybe even deeper, but no context > > > > > > available). Ditto > > > > > > for the rest of the series. > > > > >=20 > > > > > Any special reason for it (maybe related to lockdep > > > > > :wondering: ) ? Just > > > > > curious as I never noticed such a pattern when initializing > > > > > mutexes. > > > >=20 > > > > Yes. Micro-optimization based on the rule "don't create a > > > > resource in > > > > case of known error". > > > >=20 > > > > OTOH, you have to be sure that the mutex (and generally > > > > speaking a > > > > locking) should be initialized early enough. > >=20 > > Typically not really needed during probe... >=20 > Actually as long as you expose the ABI to the user anything can > happen, means that your code should be ready to receive the requests > in any possible callbacks / file ops. Same applies to the IRQ > handler. > So it's very important to initialize locking just in time. Hence I > can > say that "typically it needs to be carefully placed". >=20 Yes, I'm aware of that... For some reason I just thought about code paths directly on probe. Anyways, hopefully these drivers mostly do the right thing and register the IIO device as late as possible (ideally the last thing to be done). The same goes for IRQs and for IIO, when used as part of triggered buffering, the lock is often only used in the trigger handler which means it's only reachable after the ABI is exposed...=20 - Nuno S=C3=A1 > >=20