All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vasileios Amoiridis <vassilisamir@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Vasileios Amoiridis <vassilisamir@gmail.com>,
	jic23@kernel.org, lars@metafoo.de, ang.iglesiasg@gmail.com,
	mazziesaccount@gmail.com, ak@it-klinger.de,
	petre.rodan@subdimension.ro, phil@raspberrypi.com,
	579lpy@gmail.com, linus.walleij@linaro.org,
	semen.protsenko@linaro.org, linux-iio@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 6/6] iio: pressure: Add triggered buffer support for BMP280 driver
Date: Wed, 20 Mar 2024 18:46:02 +0100	[thread overview]
Message-ID: <20240320174602.GA36450@vamoiridPC> (raw)
In-Reply-To: <ZfrFc9GF0_Jix5YT@smile.fi.intel.com>

On Wed, Mar 20, 2024 at 01:16:03PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 19, 2024 at 01:29:25AM +0100, Vasileios Amoiridis wrote:
> > BMP2xx, BMP3xx, and BMP5xx use consecutive buffers for their
> > temperature, pressure and humidity readings. This facilitates
> > the use of burst reads in order to acquire data much faster
> > and in a different way from the one used in oneshot captures.
> > 
> > BMP085 and BMP180 use a completely different measurement
> > process that is well defined and is used in their buffer_handler().
> 
> ...
> 
> >  	ret = regmap_bulk_read(data->regmap, BMP280_REG_TEMP_MSB,
> > -			       data->buf, sizeof(data->buf));
> > +			       data->buf, BMP280_NUM_TEMP_BYTES);
> 
> >  	ret = regmap_bulk_read(data->regmap, BMP280_REG_PRESS_MSB,
> > -			       data->buf, sizeof(data->buf));
> > +			       data->buf, BMP280_NUM_PRESS_BYTES);
> 
> >  	ret = regmap_bulk_read(data->regmap, BMP280_REG_HUMIDITY_MSB,
> > -			       &data->be16, sizeof(data->be16));
> > +			       &data->be16, BME280_NUM_HUMIDITY_BYTES);
> 
> > -	adc_humidity = be16_to_cpu(data->be16);
> > +	adc_humidity = get_unaligned_be16(&data->be16);
> 
> >  	ret = regmap_bulk_read(data->regmap, BMP380_REG_TEMP_XLSB,
> > -			       data->buf, sizeof(data->buf));
> > +			       data->buf, BMP280_NUM_TEMP_BYTES);
> 
> >  	ret = regmap_bulk_read(data->regmap, BMP380_REG_PRESS_XLSB,
> > -			       data->buf, sizeof(data->buf));
> > +			       data->buf, BMP280_NUM_PRESS_BYTES);
> 
> >  	ret = regmap_bulk_read(data->regmap, BMP580_REG_TEMP_XLSB, data->buf,
> > -			       sizeof(data->buf));
> > +			       BMP280_NUM_TEMP_BYTES);
> 
> >  	ret = regmap_bulk_read(data->regmap, BMP580_REG_PRESS_XLSB, data->buf,
> > -			       sizeof(data->buf));
> > +			       BMP280_NUM_PRESS_BYTES);
> 
> These smell to me as candidates to a separate patch with more explanation why.
> (Yes, with the definitions you introduced.) But I leave it to Jonathan to
> decide if we need to split.
> 
> ...
> 
> The below are applicable to the bmp280_buffer_handler(),
> bmp380_buffer_handler() implementations as well.
> 
> ...
> 
> > +	/* Burst read data registers */
> > +	ret = regmap_bulk_read(data->regmap, BMP580_REG_TEMP_XLSB,
> > +			       data->buf, 6);
> 
> Magic size.
> 

Hi Andy,

Thank you again for your feedback. When I was writing it, it was 
looking as a magic number to me as well but then I though that 
since I put the comment above it could be obvious. Now that I see 
it again, I think it was not a good idea and maybe some type of 
definition like

	#define BMP280_BURST_READ_NUM_BYTES 6
	#define BME280_BURST_READ_NUM_BYTES 8

could look better and be more intuitive.

> ...
> 
> > +	/* Temperature calculations */
> > +	memcpy(&chan_value, &data->buf[3], 3);
> 
> _le24() + sign_extend32()?
> 

In the next line from your comment the _le24 or _be24 takes place.
If the sign_extend32() is needed here, shouldn't it also be used
in all the oneshot captures as well?

> ...
> 
> > +	/* Pressure calculations */
> > +	memcpy(&chan_value, &data->buf[0], 3);
> 
> _le24() + sign_extend32()?
> 
> ...
> 
> >  	/*
> > -	 * Maximum number of consecutive bytes read for a temperature or
> > -	 * pressure measurement is 3.
> > +	 * Maximum number of a burst read for temperature, pressure, humidity
> > +	 * is 8 bytes.
> >  	 */
> > -	if (val_size > 3)
> > +	if (val_size > 8)
> 
> sizeof() / new definition for the buf[] size?
> 

In a previous commit that I was fixing this SPI driver, Jonathan had mentioned
that there is no need for a specific definition since it will only be used
here so that's why I kept it as is.

Cheers,
Vasilis
> >  		return -EINVAL;
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 

  reply	other threads:[~2024-03-20 17:46 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-19  0:29 [PATCH v3 0/6] Series to add triggered buffer support to BMP280 driver Vasileios Amoiridis
2024-03-19  0:29 ` [PATCH v3 1/6] iio: pressure: BMP280 core driver headers sorting Vasileios Amoiridis
2024-03-20 11:00   ` Andy Shevchenko
2024-03-24 11:14     ` Jonathan Cameron
2024-03-19  0:29 ` [PATCH v3 2/6] iio: pressure: Introduce new cleanup routines to BMP280 driver *_raw() functions Vasileios Amoiridis
2024-03-20 11:00   ` Andy Shevchenko
2024-03-20 11:04     ` Andy Shevchenko
2024-03-24 11:20   ` Jonathan Cameron
2024-03-19  0:29 ` [PATCH v3 3/6] iio: pressure: Generalize read_{temp/press/humid}() functions Vasileios Amoiridis
2024-03-20 11:04   ` Andy Shevchenko
2024-03-24 11:36   ` Jonathan Cameron
2024-04-02 17:55     ` Vasileios Amoiridis
2024-04-06 10:02       ` Jonathan Cameron
2024-03-19  0:29 ` [PATCH v3 4/6] iio: pressure: Add SCALE and RAW values for channels Vasileios Amoiridis
2024-03-20 11:05   ` Andy Shevchenko
2024-03-19  0:29 ` [PATCH v3 5/6] iio: pressure: Add timestamp and scan_masks for BMP280 driver Vasileios Amoiridis
2024-03-20 11:07   ` Andy Shevchenko
2024-03-20 18:45     ` Vasileios Amoiridis
2024-03-20 20:38       ` Andy Shevchenko
2024-03-20 21:31         ` Vasileios Amoiridis
2024-03-21 11:22           ` Andy Shevchenko
2024-03-24 11:43   ` Jonathan Cameron
2024-03-19  0:29 ` [PATCH v3 6/6] iio: pressure: Add triggered buffer support " Vasileios Amoiridis
2024-03-20 11:16   ` Andy Shevchenko
2024-03-20 17:46     ` Vasileios Amoiridis [this message]
2024-03-20 21:25       ` Andy Shevchenko
2024-03-20 21:35         ` Vasileios Amoiridis
2024-03-24 11:55       ` Jonathan Cameron
2024-03-24 12:14   ` Jonathan Cameron
2024-04-02 18:08     ` Vasileios Amoiridis
2024-04-06 10:02       ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240320174602.GA36450@vamoiridPC \
    --to=vassilisamir@gmail.com \
    --cc=579lpy@gmail.com \
    --cc=ak@it-klinger.de \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=ang.iglesiasg@gmail.com \
    --cc=jic23@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mazziesaccount@gmail.com \
    --cc=petre.rodan@subdimension.ro \
    --cc=phil@raspberrypi.com \
    --cc=semen.protsenko@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.