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 324B9ECAAD8 for ; Tue, 20 Sep 2022 15:13:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230110AbiITPNK (ORCPT ); Tue, 20 Sep 2022 11:13:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54254 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230388AbiITPNI (ORCPT ); Tue, 20 Sep 2022 11:13:08 -0400 Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 867255A3EE for ; Tue, 20 Sep 2022 08:13:07 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id y2so1798975qkl.11 for ; Tue, 20 Sep 2022 08:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date; bh=H/fELBq8CrA1DvGdURv9OEhTBXymuyG0Ndt8d3ITimI=; b=odqvhHE4k7/usvdUB+d9hXNls03VbsjsLLXsqVMWrIxb23eU4DkX5vrM83VTLppWKR ymCHStOYHe2be/kpoRTfwTZRUih7KT3hKhI+EwPdNWOworFuN5vnqpv5ga5Q2CmWxQI4 vBZbTCdhXulCvdJxEBXNPZsjosvrBDFPMj8wZ+qAhGlKaVpt5KG0lES84qXE7u/zCbrD gxEWm2RSk2S9pVLQtOYUlYm/2H7Oe6Qw5ll0092KQVutYVagKSLJ+FsgJOq9N9cKYiY4 7feqMG6EocZdNCOboZ/98Q0ELa4zmBDN6KPGZHkN6mjeGrt2rbZIjbOCIO66f138shzq hK0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=H/fELBq8CrA1DvGdURv9OEhTBXymuyG0Ndt8d3ITimI=; b=2DKIiiH6ZxnRaQvLlkQlHi3hUL7YjQUAWCNTvWu7bbLua63OLjqZa46qeDwf+wsN2e k31PNTUc617Omm2EjfyWwlxygeRVp415Y3Oaw0obTY+e5py7Cg4xwe8W9GaQIyBVu/AU bierguyZr4F6wn146zoulRnh3hF8pX5mjugkkWBGVclNAJRecG/zE26coJgd+tmu1oFf NV/Ms2B5i8Esb8PSFWz47XmAFbPpSmKd4qN2YyLmMn4V8MJQcIxIDsLYQ1hbfNnerVJG YGM8Ii3i+pUbjYIXwd3xbOV7itVboGrszO0iVR8RrgNUMtHRAJY9FyfdBETTn7379X8/ 2rIw== X-Gm-Message-State: ACrzQf1RtDIgKutqMXoLr6jJQp3ZMxk+hx8CutHk9j1rwT2oY4IaGLzO 7gPmRlnpkUgoiixRexOwPkeC21qKf7/ON1yjpY8= X-Google-Smtp-Source: AMsMyM7fL5q6SxxEBDkVEF8PUG8Ss/gYOHVmtrul7fepLnHVvvy+tkwmPheD5VX2p+fX+A0Nn5TkJJig9fnXZsuGYMI= X-Received: by 2002:a05:620a:410e:b0:6bc:5cdc:88ec with SMTP id j14-20020a05620a410e00b006bc5cdc88ecmr17318786qko.734.1663686786455; Tue, 20 Sep 2022 08:13:06 -0700 (PDT) MIME-Version: 1.0 References: <20220920112821.975359-1-nuno.sa@analog.com> <20220920112821.975359-4-nuno.sa@analog.com> In-Reply-To: From: Andy Shevchenko Date: Tue, 20 Sep 2022 18:12:30 +0300 Message-ID: Subject: Re: [PATCH 03/15] iio: adc: axp288_adc: do not use internal iio_dev lock To: "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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org 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: > > > > ... > > > > > > > > info =3D iio_priv(indio_dev); > > > > > > + mutex_init(&info->lock); > > > > > > info->irq =3D platform_get_irq(pdev, 0); > > > > > > if (info->irq < 0) > > > > > > return info->irq; > > > > > > > > > > Consider initializing it as late as possible, like after IRQ retr= ieval > > > > > in this context (maybe even deeper, but no context available). Di= tto > > > > > for the rest of the series. > > > > > > > > Any special reason for it (maybe related to lockdep :wondering: ) ?= Just > > > > curious as I never noticed such a pattern when initializing mutexes= . > > > > > > Yes. Micro-optimization based on the rule "don't create a resource in > > > case of known error". > > > > > > OTOH, you have to be sure that the mutex (and generally speaking a > > > locking) should be initialized early enough. > > Typically not really needed during probe... 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". > > Note that "micro" in the above can be multiplied by 'k', where 'k' is > > the amount of deferred probes (probably not the case here, but again, > > "generally speaking"). > > Well, I don't think 'mutex_init()' does that much that really matters in > these patches but ok, that rule is indeed a good practice that sometimes > makes a difference. And since I will definitely need a v2, I can make tha= t > change. Where applicable, the best place is probably before registering t= he > IIO device... Some drivers are pedantic and want to have mutex_destroy() to be called, it also reduces the surface of returning with an undestroyed object (let's not discuss the usefulness of such destruction, but in principle). --=20 With Best Regards, Andy Shevchenko