Received-SPF: pass (google.com: domain of linux-kernel+bounces-207329-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Sun, 9 Jun 2024 11:56:28 +0100
From: Jonathan Cameron <jic23@kernel.org>
To: Vasileios Amoiridis <vassilisamir@gmail.com>
Cc: dpfrey@gmail.com, himanshujha199640@gmail.com, lars@metafoo.de,
 linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
 mike.looijmans@topic.nl
Subject: Re: [PATCH v2 06/19] iio: chemical: bme680: Fix read/write ops to
 device by adding mutexes
Message-ID: <20240609115628.2beb4cb1@jic23-huawei>
In-Reply-To: <20240606212313.207550-7-vassilisamir@gmail.com>
References: <20240606212313.207550-1-vassilisamir@gmail.com>
	<20240606212313.207550-7-vassilisamir@gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu,  6 Jun 2024 23:22:58 +0200
Vasileios Amoiridis <vassilisamir@gmail.com> wrote:

> Add mutexes in the {read/write}_raw() functions of the device to
> guard the read/write of data from/to the device. This is necessary
> because for any operation other than temperature, multiple reads
> need to take place from the device. Even though regmap has a locking
> by itself, it won't protect us from multiple applications trying to
> read at the same time temperature and pressure since the pressure
> reading includes an internal temperature reading and there is nothing
> to ensure that this temperature+pressure reading will happen
> sequentially without any other operation interfering in the meantime.
> 
> Fixes: 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor")
> Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
> ---
>  drivers/iio/chemical/bme680_core.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/iio/chemical/bme680_core.c b/drivers/iio/chemical/bme680_core.c
> index 66177f7e94a8..92359032254a 100644
> --- a/drivers/iio/chemical/bme680_core.c
> +++ b/drivers/iio/chemical/bme680_core.c
> @@ -10,6 +10,7 @@
>   */
>  #include <linux/acpi.h>
>  #include <linux/bitfield.h>
> +#include <linux/cleanup.h>
>  #include <linux/delay.h>
>  #include <linux/device.h>
>  #include <linux/module.h>
> @@ -52,6 +53,7 @@ struct bme680_calib {
>  struct bme680_data {
>  	struct regmap *regmap;
>  	struct bme680_calib bme680;

Comment needed here on what data this lock protects.
It is far to easy to make wrong assumptions about locks so convention is
to always document their scope.

Otherwise lgtm (as do patches 1-5)

> +	struct mutex lock;
>  	u8 oversampling_temp;
>  	u8 oversampling_press;
>  	u8 oversampling_humid;
> @@ -827,6 +829,8 @@ static int bme680_read_raw(struct iio_dev *indio_dev,
>  {
>  	struct bme680_data *data = iio_priv(indio_dev);
>  
> +	guard(mutex)(&data->lock);
> +
>  	switch (mask) {
>  	case IIO_CHAN_INFO_PROCESSED:
>  		switch (chan->type) {
> @@ -871,6 +875,8 @@ static int bme680_write_raw(struct iio_dev *indio_dev,
>  {
>  	struct bme680_data *data = iio_priv(indio_dev);
>  
> +	guard(mutex)(&data->lock);
> +
>  	if (val2 != 0)
>  		return -EINVAL;
>  
> @@ -967,6 +973,7 @@ int bme680_core_probe(struct device *dev, struct regmap *regmap,
>  		name = bme680_match_acpi_device(dev);
>  
>  	data = iio_priv(indio_dev);
> +	mutex_init(&data->lock);
>  	dev_set_drvdata(dev, indio_dev);
>  	data->regmap = regmap;
>  	indio_dev->name = name;