Message ID | 20231121-dev-iio-backend-v1-6-6a3d542eba35@analog.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2b07:b0:403:3b70:6f57 with SMTP id io7csp521027vqb; Tue, 21 Nov 2023 02:19:15 -0800 (PST) X-Google-Smtp-Source: AGHT+IERY1oPO1fEiK9FveU5wFPa9/+KUo2Or7AeFcDZ78kDmqeTJAX/sVA//0c5KSKQj4FYTHvY X-Received: by 2002:a05:6a00:10c1:b0:6cb:bfc1:d3cb with SMTP id d1-20020a056a0010c100b006cbbfc1d3cbmr1076506pfu.16.1700561955183; Tue, 21 Nov 2023 02:19:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700561955; cv=none; d=google.com; s=arc-20160816; b=YDDNWizvbEsDqgjJduYQvU7PeBuRlb9dxV1OPSg/NRLUSu/VA/LMJQS7z44oC/N+ih r4UJG1qCMQ9XZaBLEeNrQzYLC/+WW7mNclNkygGHZ2lHa4KGpAHv4G9SNrp9XPqMUaj+ aHpJTlqwXT1Ku+Vq2KvsRqM3GjJ6YbNO833x3aydM/b5D0sy5h85hG71aEcsg+RPlXWc XvM7PkIZqS3IgqhxPqnwJoQ8OvPLs+xcHtLNGzAGr2zdJMIUG0tdpqCZN2Ew0EpmPRJd ww++pm93wSir8cKI2CWvhctXQaW4qBRCaTGb8omUke904AOHslL6JohzcSsMsiaSFqUf Gqhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:reply-to:cc:to:in-reply-to:references:message-id :content-transfer-encoding:mime-version:subject:date:from :dkim-signature; bh=mPCkF8r2gjDEwjA2exXfcObrLZoc5dRWaBYNS8IwX7w=; fh=phDggtdq/mZScnogaJFJfeRDE2XPpZpUuxL35p15uks=; b=D5q+nraKMVA3MqYsHIDJfmRx+L+VW93s0Yx7hxVvcOu3iUeRi3WpbWztsn46ApOPuz 5bJ8zozjXm+DfWHQp/3LxLv/AIE/qO0iCoJGqR9uPcF4jD2sg3cPiu9wscI58uDECr0d dPX11p3kg8nLstmfjSIoWvbm7o9cjEewy/Pag/COK2hC202cLPYTLWzgrhc7wk6cIiql 6LcVR9zheIjSwXLl5HKAew4otP3AejSdTK1iL9604qTbEaWZ7SAwSy8ZYaQCUVWM8KVC LnU+Z991Ew+Y3pbn4F1qjBTO5L9615wxUX1dxQ2NKgVnC9tCAanoMlKW4MTHQ9XtxFTI eDeQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=eM9cxBHG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id h2-20020a056a00230200b006cbbd597aa1si1245203pfh.242.2023.11.21.02.19.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Nov 2023 02:19:15 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=eM9cxBHG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id EC47F810438F; Tue, 21 Nov 2023 02:17:44 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233680AbjKUKRn (ORCPT <rfc822;ouuuleilei@gmail.com> + 99 others); Tue, 21 Nov 2023 05:17:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48392 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232875AbjKUKRY (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 21 Nov 2023 05:17:24 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1250011C for <linux-kernel@vger.kernel.org>; Tue, 21 Nov 2023 02:17:21 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPS id 756A9C433CD; Tue, 21 Nov 2023 10:17:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1700561839; bh=0BvXHNAq6MxvTFFypFKVLfm202ysR+MbTta68aDgcfw=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=eM9cxBHG3fTojuudhsxbw1lZ7Gau0JELf/VvK07u5vpOTcme0gJ4xu+Itj8nCrBSS pQ69EQgUShyyhjHqyvtNK2fVLPjWzmn3347UIdDPX5pmrsJ9BNyBTiTtY5sWz3020C 1pF2EKHPSBIM7uYjXbgTbtpIiVU8tqs+yJIhruao5qJns1oBXNxyzQgSuqsAuc5rj5 j/4tC4i/BSgLYG/bNh5GL4Lb/bNJZgxQBh9frk9hEv1o+hRZ74LtQrT9pUsmM0NKwJ Mddy82xhpqFXPLV5KIcEOMEJ6uUrRPtQ/JJQjqjP0EiQQXm3lH0T31LaKT20IKzTiv Rj83/7XWraOOw== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63334C61D92; Tue, 21 Nov 2023 10:17:19 +0000 (UTC) From: Nuno Sa via B4 Relay <devnull+nuno.sa.analog.com@kernel.org> Date: Tue, 21 Nov 2023 11:20:19 +0100 Subject: [PATCH 06/12] iio: adc: ad9467: add mutex to struct ad9467_state MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20231121-dev-iio-backend-v1-6-6a3d542eba35@analog.com> References: <20231121-dev-iio-backend-v1-0-6a3d542eba35@analog.com> In-Reply-To: <20231121-dev-iio-backend-v1-0-6a3d542eba35@analog.com> To: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-iio@vger.kernel.org Cc: Olivier MOYSAN <olivier.moysan@foss.st.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Rafael J. Wysocki" <rafael@kernel.org>, Rob Herring <robh+dt@kernel.org>, Frank Rowand <frowand.list@gmail.com>, Jonathan Cameron <jic23@kernel.org>, Lars-Peter Clausen <lars@metafoo.de>, Michael Hennerich <Michael.Hennerich@analog.com>, Nuno Sa <nuno.sa@analog.com> X-Mailer: b4 0.12.4 X-Developer-Signature: v=1; a=ed25519-sha256; t=1700562016; l=1622; i=nuno.sa@analog.com; s=20231116; h=from:subject:message-id; bh=g3tcVMAWnAaNpfd4zR0L8lXR29z5KekLRZe6sxMF/hk=; b=c73pLlPBK+gRvwbzpMIaQzg2/RJK0F0Puv/XvfzcIUdIwAgeIeOujPcKeq6HBext2kU07mya6 y+9u9e194XEB1j4VRHh9o3JjEgyQO25ay/PCBtt95QyHrc9TUVacvKt X-Developer-Key: i=nuno.sa@analog.com; a=ed25519; pk=3NQwYA013OUYZsmDFBf8rmyyr5iQlxV/9H4/Df83o1E= X-Endpoint-Received: by B4 Relay for nuno.sa@analog.com/20231116 with auth_id=100 X-Original-From: Nuno Sa <nuno.sa@analog.com> Reply-To: <nuno.sa@analog.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Tue, 21 Nov 2023 02:17:45 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783168452415838918 X-GMAIL-MSGID: 1783168452415838918 |
Series |
iio: add new backend framework
|
|
Commit Message
Nuno Sa via B4 Relay
Nov. 21, 2023, 10:20 a.m. UTC
From: Nuno Sa <nuno.sa@analog.com> When calling ad9467_set_scale(), multiple calls to ad9467_spi_write() are done which means we need to properly protect the whole operation so we are sure we will be in a sane state if two concurrent calls occur. Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC") Signed-off-by: Nuno Sa <nuno.sa@analog.com> --- drivers/iio/adc/ad9467.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
Comments
On Tue, Nov 21, 2023 at 4:17 AM Nuno Sa via B4 Relay <devnull+nuno.sa.analog.com@kernel.org> wrote: > > From: Nuno Sa <nuno.sa@analog.com> > > When calling ad9467_set_scale(), multiple calls to ad9467_spi_write() > are done which means we need to properly protect the whole operation so > we are sure we will be in a sane state if two concurrent calls occur. > > Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC") > Signed-off-by: Nuno Sa <nuno.sa@analog.com> > --- > drivers/iio/adc/ad9467.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c > index 04474dbfa631..91821dee03b7 100644 > --- a/drivers/iio/adc/ad9467.c > +++ b/drivers/iio/adc/ad9467.c > @@ -4,7 +4,7 @@ > * > * Copyright 2012-2020 Analog Devices Inc. > */ > - > +#include <linux/cleanup.h> > #include <linux/module.h> > #include <linux/mutex.h> Ah, the case of the misplaced header from the previous patch is solved. :-) > #include <linux/device.h> > @@ -122,6 +122,8 @@ struct ad9467_state { > unsigned int output_mode; > > struct gpio_desc *pwrdown_gpio; > + /* protect against concurrent accesses to the device */ > + struct mutex lock; > }; > > static int ad9467_spi_read(struct spi_device *spi, unsigned int reg) > @@ -162,6 +164,7 @@ static int ad9467_reg_access(struct adi_axi_adc_conv *conv, unsigned int reg, > int ret; > > if (!readval) { > + guard(mutex)(&st->lock); > ret = ad9467_spi_write(spi, reg, writeval); > if (ret) > return ret; > @@ -310,6 +313,7 @@ static int ad9467_set_scale(struct adi_axi_adc_conv *conv, int val, int val2) > if (scale_val[0] != val || scale_val[1] != val2) > continue; > > + guard(mutex)(&st->lock); > ret = ad9467_spi_write(st->spi, AN877_ADC_REG_VREF, > info->scale_table[i][1]); > if (ret < 0) > > -- > 2.42.1 > > Alternately, this could probably be solved with spi_bus_lock/unlock and spi_sync_locked rather than introducing a new mutex.
On Thu, 2023-11-30 at 15:50 -0600, David Lechner wrote: > On Tue, Nov 21, 2023 at 4:17 AM Nuno Sa via B4 Relay > <devnull+nuno.sa.analog.com@kernel.org> wrote: > > > > From: Nuno Sa <nuno.sa@analog.com> > > > > When calling ad9467_set_scale(), multiple calls to ad9467_spi_write() > > are done which means we need to properly protect the whole operation so > > we are sure we will be in a sane state if two concurrent calls occur. > > > > Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC") > > Signed-off-by: Nuno Sa <nuno.sa@analog.com> > > --- > > drivers/iio/adc/ad9467.c | 6 +++++- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c > > index 04474dbfa631..91821dee03b7 100644 > > --- a/drivers/iio/adc/ad9467.c > > +++ b/drivers/iio/adc/ad9467.c > > @@ -4,7 +4,7 @@ > > * > > * Copyright 2012-2020 Analog Devices Inc. > > */ > > - > > +#include <linux/cleanup.h> > > #include <linux/module.h> > > #include <linux/mutex.h> > > Ah, the case of the misplaced header from the previous patch is solved. :-) > Yeps, it needs to be in this patch :) > > #include <linux/device.h> > > @@ -122,6 +122,8 @@ struct ad9467_state { > > unsigned int output_mode; > > > > struct gpio_desc *pwrdown_gpio; > > + /* protect against concurrent accesses to the device */ > > + struct mutex lock; > > }; > > > > static int ad9467_spi_read(struct spi_device *spi, unsigned int reg) > > @@ -162,6 +164,7 @@ static int ad9467_reg_access(struct adi_axi_adc_conv *conv, > > unsigned int reg, > > int ret; > > > > if (!readval) { > > + guard(mutex)(&st->lock); > > ret = ad9467_spi_write(spi, reg, writeval); > > if (ret) > > return ret; > > @@ -310,6 +313,7 @@ static int ad9467_set_scale(struct adi_axi_adc_conv *conv, > > int val, int val2) > > if (scale_val[0] != val || scale_val[1] != val2) > > continue; > > > > + guard(mutex)(&st->lock); > > ret = ad9467_spi_write(st->spi, AN877_ADC_REG_VREF, > > info->scale_table[i][1]); > > if (ret < 0) > > > > -- > > 2.42.1 > > > > > > Alternately, this could probably be solved with spi_bus_lock/unlock > and spi_sync_locked rather than introducing a new mutex. Hmm, typically you just have your own lock. No reason to lock the spi bus. And I also have some plans to eventually change this to regmap :) - Nuno Sá
On Fri, 01 Dec 2023 09:49:38 +0100 Nuno Sá <noname.nuno@gmail.com> wrote: > On Thu, 2023-11-30 at 15:50 -0600, David Lechner wrote: > > On Tue, Nov 21, 2023 at 4:17 AM Nuno Sa via B4 Relay > > <devnull+nuno.sa.analog.com@kernel.org> wrote: > > > > > > From: Nuno Sa <nuno.sa@analog.com> > > > > > > When calling ad9467_set_scale(), multiple calls to ad9467_spi_write() > > > are done which means we need to properly protect the whole operation so > > > we are sure we will be in a sane state if two concurrent calls occur. > > > > > > Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC") > > > Signed-off-by: Nuno Sa <nuno.sa@analog.com> > > > --- > > > drivers/iio/adc/ad9467.c | 6 +++++- > > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c > > > index 04474dbfa631..91821dee03b7 100644 > > > --- a/drivers/iio/adc/ad9467.c > > > +++ b/drivers/iio/adc/ad9467.c > > > @@ -4,7 +4,7 @@ > > > * > > > * Copyright 2012-2020 Analog Devices Inc. > > > */ > > > - > > > +#include <linux/cleanup.h> > > > #include <linux/module.h> > > > #include <linux/mutex.h> > > > > Ah, the case of the misplaced header from the previous patch is solved. :-) > > > > Yeps, it needs to be in this patch :) > > > > #include <linux/device.h> > > > @@ -122,6 +122,8 @@ struct ad9467_state { > > > unsigned int output_mode; > > > > > > struct gpio_desc *pwrdown_gpio; > > > + /* protect against concurrent accesses to the device */ > > > + struct mutex lock; > > > }; > > > > > > static int ad9467_spi_read(struct spi_device *spi, unsigned int reg) > > > @@ -162,6 +164,7 @@ static int ad9467_reg_access(struct adi_axi_adc_conv *conv, > > > unsigned int reg, > > > int ret; > > > > > > if (!readval) { > > > + guard(mutex)(&st->lock); > > > ret = ad9467_spi_write(spi, reg, writeval); > > > if (ret) > > > return ret; > > > @@ -310,6 +313,7 @@ static int ad9467_set_scale(struct adi_axi_adc_conv *conv, > > > int val, int val2) > > > if (scale_val[0] != val || scale_val[1] != val2) > > > continue; > > > > > > + guard(mutex)(&st->lock); > > > ret = ad9467_spi_write(st->spi, AN877_ADC_REG_VREF, > > > info->scale_table[i][1]); > > > if (ret < 0) > > > > > > -- > > > 2.42.1 > > > > > > > > > > Alternately, this could probably be solved with spi_bus_lock/unlock > > and spi_sync_locked rather than introducing a new mutex. > > Hmm, typically you just have your own lock. No reason to lock the spi bus. And I also > have some plans to eventually change this to regmap :) Bus lock typically implies that we can't let other users grab the bus in between for reasons like the chip select needing to be held. I'm not keen on it being used if the locking is just needed for a specific driver to deal with its associated device and driver state. Jonathan > > - Nuno Sá >
On Tue, 21 Nov 2023 11:20:19 +0100 Nuno Sa via B4 Relay <devnull+nuno.sa.analog.com@kernel.org> wrote: > From: Nuno Sa <nuno.sa@analog.com> > > When calling ad9467_set_scale(), multiple calls to ad9467_spi_write() > are done which means we need to properly protect the whole operation so > we are sure we will be in a sane state if two concurrent calls occur. > > Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC") > Signed-off-by: Nuno Sa <nuno.sa@analog.com> > --- > drivers/iio/adc/ad9467.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c > index 04474dbfa631..91821dee03b7 100644 > --- a/drivers/iio/adc/ad9467.c > +++ b/drivers/iio/adc/ad9467.c > @@ -4,7 +4,7 @@ > * > * Copyright 2012-2020 Analog Devices Inc. > */ > - > +#include <linux/cleanup.h> > #include <linux/module.h> > #include <linux/mutex.h> > #include <linux/device.h> > @@ -122,6 +122,8 @@ struct ad9467_state { > unsigned int output_mode; > > struct gpio_desc *pwrdown_gpio; > + /* protect against concurrent accesses to the device */ Not very specific. Concurrent access usually fine at granularity of individual read/write as the bus locks protect it. What state is actually being protected? A shared buffer or some state that we need to ensure remains consistent between driver and device? > + struct mutex lock; > }; > > static int ad9467_spi_read(struct spi_device *spi, unsigned int reg) > @@ -162,6 +164,7 @@ static int ad9467_reg_access(struct adi_axi_adc_conv *conv, unsigned int reg, > int ret; > > if (!readval) { > + guard(mutex)(&st->lock); > ret = ad9467_spi_write(spi, reg, writeval); > if (ret) > return ret; > @@ -310,6 +313,7 @@ static int ad9467_set_scale(struct adi_axi_adc_conv *conv, int val, int val2) > if (scale_val[0] != val || scale_val[1] != val2) > continue; > > + guard(mutex)(&st->lock); > ret = ad9467_spi_write(st->spi, AN877_ADC_REG_VREF, > info->scale_table[i][1]); > if (ret < 0) >
On Mon, 2023-12-04 at 15:23 +0000, Jonathan Cameron wrote: > On Tue, 21 Nov 2023 11:20:19 +0100 > Nuno Sa via B4 Relay <devnull+nuno.sa.analog.com@kernel.org> wrote: > > > From: Nuno Sa <nuno.sa@analog.com> > > > > When calling ad9467_set_scale(), multiple calls to ad9467_spi_write() > > are done which means we need to properly protect the whole operation so > > we are sure we will be in a sane state if two concurrent calls occur. > > > > Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC") > > Signed-off-by: Nuno Sa <nuno.sa@analog.com> > > --- > > drivers/iio/adc/ad9467.c | 6 +++++- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c > > index 04474dbfa631..91821dee03b7 100644 > > --- a/drivers/iio/adc/ad9467.c > > +++ b/drivers/iio/adc/ad9467.c > > @@ -4,7 +4,7 @@ > > * > > * Copyright 2012-2020 Analog Devices Inc. > > */ > > - > > +#include <linux/cleanup.h> > > #include <linux/module.h> > > #include <linux/mutex.h> > > #include <linux/device.h> > > @@ -122,6 +122,8 @@ struct ad9467_state { > > unsigned int output_mode; > > > > struct gpio_desc *pwrdown_gpio; > > + /* protect against concurrent accesses to the device */ > Not very specific. Concurrent access usually fine at granularity of > individual read/write as the bus locks protect it. What state > is actually being protected? A shared buffer or some state that we > need to ensure remains consistent between driver and device? At this point not any buffer/data... Just making sure things remain consistent (typical case when you have multiple reads/writes to the device). That's why a tried to emphasize "accesses to the device". Maybe I should make it explicit I'm speaking about multiple reads/writes. - Nuno Sá >
On Mon, 04 Dec 2023 17:10:01 +0100 Nuno Sá <noname.nuno@gmail.com> wrote: > On Mon, 2023-12-04 at 15:23 +0000, Jonathan Cameron wrote: > > On Tue, 21 Nov 2023 11:20:19 +0100 > > Nuno Sa via B4 Relay <devnull+nuno.sa.analog.com@kernel.org> wrote: > > > > > From: Nuno Sa <nuno.sa@analog.com> > > > > > > When calling ad9467_set_scale(), multiple calls to ad9467_spi_write() > > > are done which means we need to properly protect the whole operation so > > > we are sure we will be in a sane state if two concurrent calls occur. > > > > > > Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC") > > > Signed-off-by: Nuno Sa <nuno.sa@analog.com> > > > --- > > > drivers/iio/adc/ad9467.c | 6 +++++- > > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c > > > index 04474dbfa631..91821dee03b7 100644 > > > --- a/drivers/iio/adc/ad9467.c > > > +++ b/drivers/iio/adc/ad9467.c > > > @@ -4,7 +4,7 @@ > > > * > > > * Copyright 2012-2020 Analog Devices Inc. > > > */ > > > - > > > +#include <linux/cleanup.h> > > > #include <linux/module.h> > > > #include <linux/mutex.h> > > > #include <linux/device.h> > > > @@ -122,6 +122,8 @@ struct ad9467_state { > > > unsigned int output_mode; > > > > > > struct gpio_desc *pwrdown_gpio; > > > + /* protect against concurrent accesses to the device */ > > Not very specific. Concurrent access usually fine at granularity of > > individual read/write as the bus locks protect it. What state > > is actually being protected? A shared buffer or some state that we > > need to ensure remains consistent between driver and device? > > At this point not any buffer/data... Just making sure things remain consistent > (typical case when you have multiple reads/writes to the device). That's why a tried > to emphasize "accesses to the device". Maybe I should make it explicit I'm speaking > about multiple reads/writes. Talk about the data or state rather than the access to it. Something like 'ensure consistent state obtained on multiple related accesses.' Or if it's RMW then say that. > > - Nuno Sá > > >
diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c index 04474dbfa631..91821dee03b7 100644 --- a/drivers/iio/adc/ad9467.c +++ b/drivers/iio/adc/ad9467.c @@ -4,7 +4,7 @@ * * Copyright 2012-2020 Analog Devices Inc. */ - +#include <linux/cleanup.h> #include <linux/module.h> #include <linux/mutex.h> #include <linux/device.h> @@ -122,6 +122,8 @@ struct ad9467_state { unsigned int output_mode; struct gpio_desc *pwrdown_gpio; + /* protect against concurrent accesses to the device */ + struct mutex lock; }; static int ad9467_spi_read(struct spi_device *spi, unsigned int reg) @@ -162,6 +164,7 @@ static int ad9467_reg_access(struct adi_axi_adc_conv *conv, unsigned int reg, int ret; if (!readval) { + guard(mutex)(&st->lock); ret = ad9467_spi_write(spi, reg, writeval); if (ret) return ret; @@ -310,6 +313,7 @@ static int ad9467_set_scale(struct adi_axi_adc_conv *conv, int val, int val2) if (scale_val[0] != val || scale_val[1] != val2) continue; + guard(mutex)(&st->lock); ret = ad9467_spi_write(st->spi, AN877_ADC_REG_VREF, info->scale_table[i][1]); if (ret < 0)