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 X-Spam-Level: X-Spam-Status: No, score=-12.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 331DCC433E2 for ; Sat, 29 Aug 2020 15:46:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 08BF020707 for ; Sat, 29 Aug 2020 15:46:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598715991; bh=AheSshfe92OtbNQk0Y5YnL36d07LMk/Bwp5WrwRwW/8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=W25wYOuIzSTDwZFfe2qVrjSKMQUHKhdO9QpScINTJNqu9eRUCO3tqsXgWz+gtF2wI T6ct5d2operpDhmVp21JrHZNn2aQv8r7bfBwSpk125JFoc48ImIWi+pzTzX4zlUXPZ L+CFJXr/eqzqZaB+En7x+KxZQ6gFzp3aNk3tOAKk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728367AbgH2Pq2 (ORCPT ); Sat, 29 Aug 2020 11:46:28 -0400 Received: from mail.kernel.org ([198.145.29.99]:51950 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728196AbgH2PqT (ORCPT ); Sat, 29 Aug 2020 11:46:19 -0400 Received: from archlinux (cpc149474-cmbg20-2-0-cust94.5-4.cable.virginm.net [82.4.196.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A981A20707; Sat, 29 Aug 2020 15:46:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598715978; bh=AheSshfe92OtbNQk0Y5YnL36d07LMk/Bwp5WrwRwW/8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=xFkSuODyEMu7scime7X76raA4n6sWN3AdwLpRB0qK1Rdc0IWkRyClkmKnRUBUriNg lwdIHHz47eCBAdC6YfYGpV5GhU/XPHYoq88pMjRcI5qz5WzE0g/JSwgOR5RBg8PHwK 8vbqk9SMaORV8BmDSp7vcYlm0NNZnh/msT7Cgkvk= Date: Sat, 29 Aug 2020 16:46:13 +0100 From: Jonathan Cameron To: Alexandru Ardelean Cc: Fabrice Gasnier , Alexandru Ardelean , linux-iio , linux-stm32@st-md-mailman.stormreply.com, LKML , linux-arm-kernel@lists.infradead.org, alexandre.torgue@st.com, Sergiu Cuciurean Subject: Re: [PATCH v2] iio: stm32-dac: Replace indio_dev->mlock with own device lock Message-ID: <20200829164613.3be1b2b1@archlinux> In-Reply-To: References: <20200826063850.47625-1-alexandru.ardelean@analog.com> <20200826120042.200364-1-alexandru.ardelean@analog.com> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 27 Aug 2020 13:00:36 +0300 Alexandru Ardelean wrote: > On Thu, Aug 27, 2020 at 12:03 PM Fabrice Gasnier wrote: > > > > On 8/27/20 10:55 AM, Alexandru Ardelean wrote: > > > On Wed, Aug 26, 2020 at 3:03 PM Alexandru Ardelean > > > wrote: > > >> From: Sergiu Cuciurean > > >> > > >> As part of the general cleanup of indio_dev->mlock, this change replaces > > >> it with a local lock. The lock protects against potential races when > > >> reading the CR reg and then updating, so that the state of pm_runtime > > >> is consistent between the two operations. > > >> > > >> Signed-off-by: Sergiu Cuciurean > > >> Signed-off-by: Alexandru Ardelean > > >> --- > > > Forgot the changelog here. > > > Apologies. > > > > > > Changelog v1 -> v2: > > > * removed whitespace change for 'common' field > > > * updated comment about the lock usage > > > > Hi Alexandru, > > > > Sorry if I missed it... is there an update on the comment :-) ? > > For a moment there, I thought I didn't. > GMail's threading is confusing. > > ---------------------------------------------------------------------------- > As part of the general cleanup of indio_dev->mlock, this change replaces > it with a local lock. The lock protects against potential races when > reading the CR reg and then updating, so that the state of pm_runtime > is consistent between the two operations. > ---------------------------------------------------------------------------- I think this got confused... see below. > > > > > Best Regards, > > Fabrice > > > > > >> drivers/iio/dac/stm32-dac.c | 12 ++++++++---- > > >> 1 file changed, 8 insertions(+), 4 deletions(-) > > >> > > >> diff --git a/drivers/iio/dac/stm32-dac.c b/drivers/iio/dac/stm32-dac.c > > >> index 092c796fa3d9..7a8aed476850 100644 > > >> --- a/drivers/iio/dac/stm32-dac.c > > >> +++ b/drivers/iio/dac/stm32-dac.c > > >> @@ -26,9 +26,11 @@ > > >> /** > > >> * struct stm32_dac - private data of DAC driver > > >> * @common: reference to DAC common data > > >> + * @lock: lock to protect the data buffer during regmap ops The original comment was: In this particular case I'm not sure that's what mlock was being used for. I think it's about avoiding races around checking if powered down and actually doing it. And Fabrice's reply: Hi Sergiu, Indeed, purpose is to protect against a race here when reading CR, and updating it via regmap (this also makes the subsequent pm_runtime calls to be balanced based on this). (Side note: there is no data buffer involved for the DAC.) Could you please update the comment ? Thanks, Fabrice > > >> */ > > >> struct stm32_dac { > > >> struct stm32_dac_common *common; > > >> + struct mutex lock; > > >> }; 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 X-Spam-Level: X-Spam-Status: No, score=-12.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 919CCC433E6 for ; Sat, 29 Aug 2020 15:48:00 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2EE8820707 for ; Sat, 29 Aug 2020 15:48:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="aiDTSWtj"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="xFkSuODy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2EE8820707 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=GkpWJ1hbj47rrrDnzOZxsFHKs+xNVi2yw7krZcDU5iQ=; b=aiDTSWtjjGTXcJfXT3xHjex44 SxhO8WpRBKJ8LwyM8pjWpazMx8aUObH3TMdQZ600OrE1V5s8rDJPTO2CSiQQ7yWdq+g65Wz94tE9a VPnjUPw2z5l+kwSjmAV2C3eAjFMn81UAF9KJ48kvG18mxnQovdPh+SvqgyZRSJBO1jzx/vzkr9Hau DF1i5FuWfoJ5CPNevQAJ/xaVqsLdQ2q2b3iwVhYGz7N+PiNCW8vNW2u3c072lj7iK+hLvX4lNDII7 9vhSgEyekBAt3cEnyxLkCa3+1MuW2tsWBnDKefXZZGOS6/7h0PMrcQcvJJsaU4Bn93T5rs96g8aXy iiNDVwIAg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kC33d-0002ok-41; Sat, 29 Aug 2020 15:46:21 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kC33b-0002oO-AX for linux-arm-kernel@lists.infradead.org; Sat, 29 Aug 2020 15:46:20 +0000 Received: from archlinux (cpc149474-cmbg20-2-0-cust94.5-4.cable.virginm.net [82.4.196.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A981A20707; Sat, 29 Aug 2020 15:46:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598715978; bh=AheSshfe92OtbNQk0Y5YnL36d07LMk/Bwp5WrwRwW/8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=xFkSuODyEMu7scime7X76raA4n6sWN3AdwLpRB0qK1Rdc0IWkRyClkmKnRUBUriNg lwdIHHz47eCBAdC6YfYGpV5GhU/XPHYoq88pMjRcI5qz5WzE0g/JSwgOR5RBg8PHwK 8vbqk9SMaORV8BmDSp7vcYlm0NNZnh/msT7Cgkvk= Date: Sat, 29 Aug 2020 16:46:13 +0100 From: Jonathan Cameron To: Alexandru Ardelean Subject: Re: [PATCH v2] iio: stm32-dac: Replace indio_dev->mlock with own device lock Message-ID: <20200829164613.3be1b2b1@archlinux> In-Reply-To: References: <20200826063850.47625-1-alexandru.ardelean@analog.com> <20200826120042.200364-1-alexandru.ardelean@analog.com> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200829_114619_528546_E0081584 X-CRM114-Status: GOOD ( 28.88 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alexandre.torgue@st.com, linux-iio , LKML , Sergiu Cuciurean , Alexandru Ardelean , Fabrice Gasnier , linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 27 Aug 2020 13:00:36 +0300 Alexandru Ardelean wrote: > On Thu, Aug 27, 2020 at 12:03 PM Fabrice Gasnier wrote: > > > > On 8/27/20 10:55 AM, Alexandru Ardelean wrote: > > > On Wed, Aug 26, 2020 at 3:03 PM Alexandru Ardelean > > > wrote: > > >> From: Sergiu Cuciurean > > >> > > >> As part of the general cleanup of indio_dev->mlock, this change replaces > > >> it with a local lock. The lock protects against potential races when > > >> reading the CR reg and then updating, so that the state of pm_runtime > > >> is consistent between the two operations. > > >> > > >> Signed-off-by: Sergiu Cuciurean > > >> Signed-off-by: Alexandru Ardelean > > >> --- > > > Forgot the changelog here. > > > Apologies. > > > > > > Changelog v1 -> v2: > > > * removed whitespace change for 'common' field > > > * updated comment about the lock usage > > > > Hi Alexandru, > > > > Sorry if I missed it... is there an update on the comment :-) ? > > For a moment there, I thought I didn't. > GMail's threading is confusing. > > ---------------------------------------------------------------------------- > As part of the general cleanup of indio_dev->mlock, this change replaces > it with a local lock. The lock protects against potential races when > reading the CR reg and then updating, so that the state of pm_runtime > is consistent between the two operations. > ---------------------------------------------------------------------------- I think this got confused... see below. > > > > > Best Regards, > > Fabrice > > > > > >> drivers/iio/dac/stm32-dac.c | 12 ++++++++---- > > >> 1 file changed, 8 insertions(+), 4 deletions(-) > > >> > > >> diff --git a/drivers/iio/dac/stm32-dac.c b/drivers/iio/dac/stm32-dac.c > > >> index 092c796fa3d9..7a8aed476850 100644 > > >> --- a/drivers/iio/dac/stm32-dac.c > > >> +++ b/drivers/iio/dac/stm32-dac.c > > >> @@ -26,9 +26,11 @@ > > >> /** > > >> * struct stm32_dac - private data of DAC driver > > >> * @common: reference to DAC common data > > >> + * @lock: lock to protect the data buffer during regmap ops The original comment was: In this particular case I'm not sure that's what mlock was being used for. I think it's about avoiding races around checking if powered down and actually doing it. And Fabrice's reply: Hi Sergiu, Indeed, purpose is to protect against a race here when reading CR, and updating it via regmap (this also makes the subsequent pm_runtime calls to be balanced based on this). (Side note: there is no data buffer involved for the DAC.) Could you please update the comment ? Thanks, Fabrice > > >> */ > > >> struct stm32_dac { > > >> struct stm32_dac_common *common; > > >> + struct mutex lock; > > >> }; _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel