public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Mike Looijmans <mike.looijmans@topic.nl>
Cc: devicetree@vger.kernel.org, linux-iio@vger.kernel.org,
	Jonathan Cameron <jic23@kernel.org>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Liam Beguin <liambeguin@gmail.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Maksim Kiselev <bigunclemax@gmail.com>,
	Marcus Folkesson <marcus.folkesson@gmail.com>,
	Marius Cristea <marius.cristea@microchip.com>,
	Mark Brown <broonie@kernel.org>,
	Niklas Schnelle <schnelle@linux.ibm.com>,
	Okan Sahin <okan.sahin@analog.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/2] iio: adc: ti-ads1298: Add driver
Date: Tue, 6 Feb 2024 14:57:30 +0200	[thread overview]
Message-ID: <ZcIsuiuisQjTIxJv@smile.fi.intel.com> (raw)
In-Reply-To: <20240206065818.2016910-2-mike.looijmans@topic.nl>

On Tue, Feb 06, 2024 at 07:58:18AM +0100, Mike Looijmans wrote:
> Skeleton driver for the TI ADS1298 medical ADC. This device is
> typically used for ECG and similar measurements. Supports data
> acquisition at configurable scale and sampling frequency.

Thanks for an update, I have only a few style comments and a single one about
comparison (see below). If you are going to address them as suggested, feel
free to add

Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

to the next version.

...

> +/* Registers */
> +#define ADS1298_REG_ID		0x00
> +#define ADS1298_MASK_ID_FAMILY			GENMASK(7, 3)
> +#define ADS1298_MASK_ID_CHANNELS		GENMASK(2, 0)
> +#define ADS1298_ID_FAMILY_ADS129X		0x90
> +#define ADS1298_ID_FAMILY_ADS129XR		0xd0

+ Blank line? (And so on for all registers that have bitfields defined)

> +#define ADS1298_REG_CONFIG1	0x01
> +#define ADS1298_MASK_CONFIG1_HR			BIT(7)
> +#define ADS1298_MASK_CONFIG1_DR			GENMASK(2, 0)
> +#define ADS1298_SHIFT_DR_HR			6
> +#define ADS1298_SHIFT_DR_LP			7
> +#define ADS1298_LOWEST_DR			0x06

...

> +	factor = (rate >> ADS1298_SHIFT_DR_HR) / val;
> +	if (factor >= 128)

I just realized that this comparison is probably better in a form

	if (factor >= ADS1298_MASK_CONFIG1_HR)

as it points out why this is a special case in comparison to 'if (factor)'
below. What do you think?

> +		cfg = ADS1298_LOWEST_DR;
> +	else if (factor)
> +		cfg = ADS1298_MASK_CONFIG1_HR | ilog2(factor); /* Use HR mode */
> +	else
> +		cfg = ADS1298_MASK_CONFIG1_HR; /* Fastest possible */

...

> +		*val = (16 << (*val & ADS1298_MASK_CONFIG1_DR));

Outer parentheses are redundant.

...

> +	wasbusy = --priv->rdata_xfer_busy;

Why preincrement? How would it be different from postincrement?

> +	if (wasbusy) {

To me more robust code would look like

	if (wasbusy < 1)
		return;
	...
	if (wasbusy > 1)
		...

> +		/*
> +		 * DRDY interrupt occurred before SPI completion. Start a new
> +		 * SPI transaction now to retrieve the data that wasn't latched
> +		 * into the ADS1298 chip's transfer buffer yet.
> +		 */
> +		spi_async(priv->spi, &priv->rdata_msg);
> +		/*
> +		 * If more than one DRDY took place, there was an overrun. Since
> +		 * the sample is already lost, reset the counter to 1 so that
> +		 * we will wait for a DRDY interrupt after this SPI transaction.
> +		 */
> +		if (wasbusy > 1)
> +			priv->rdata_xfer_busy = 1;
> +	}

...

> +		/*
> +		 * for a single transfer mode we're kept in direct_mode until

For

> +		 * completion, avoiding a race with buffered IO.
> +		 */

...

> +	wasbusy = priv->rdata_xfer_busy++;

So, it starts from negative?

> +	/* When no SPI transfer in transit, start one now */
> +	if (!wasbusy)

To be compatible with above perhaps

	if (wasbusy < 1)

also makes it more robust (all negative numbers will be considered the same.

> +		spi_async(priv->spi, &priv->rdata_msg);

...

> +	struct device *dev = &priv->spi->dev;
> +	int ret;
> +	unsigned int val;

Better ordering is so called reversed xmas tree (longest lines first):

	struct device *dev = &priv->spi->dev;
	unsigned int val;
	int ret;

...

> +	/* Device initializes into RDATAC mode, which we don't want. */

No period at the end of one-line comments (be consistent in the style over
comments of the same class).

...

> +	dev_dbg(dev, "Found %s, %u channels\n", ads1298_family_name(val),
> +		(unsigned int)(4 + 2 * (val & ADS1298_MASK_ID_CHANNELS)));

Castings in printf() is a big red flag usually (it's rarely we need them).
Why is it here?

...

> +	/* VREF can be supplied externally. Otherwise use internal reference */

Better to use comma as it's one-line comment. Or make it multi-line with
respective periods.

...

> +		ret = devm_add_action_or_reset(dev, ads1298_reg_disable,
> +					       priv->reg_vref);

Can be one line.

> +		if (ret)
> +			return ret;

...

> +	ret = devm_add_action_or_reset(dev, ads1298_reg_disable,
> +				       priv->reg_avdd);

One line.

> +	if (ret)
> +		return ret;

...

> +	if (reset_gpio) {
> +		/* Minimum reset pulsewidth is 2 clock cycles */
> +		udelay(ADS1298_CLOCKS_TO_USECS(2));
> +		gpiod_set_value(reset_gpio, 0);

I would rewrite it as

		/* Minimum reset pulsewidth is 2 clock cycles */
		gpiod_set_value(reset_gpio, 1);
		udelay(ADS1298_CLOCKS_TO_USECS(2));
		gpiod_set_value(reset_gpio, 0);

to be sure we have a reset done correctly, and the comment will make more
sense.

> +	} else {
> +		ret = ads1298_write_cmd(priv, ADS1298_CMD_RESET);
> +		if (ret)
> +			return dev_err_probe(dev, ret, "RESET failed\n");
> +	}
> +	/* Wait 18 clock cycles for reset command to complete */
> +	udelay(ADS1298_CLOCKS_TO_USECS(18));

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2024-02-06 12:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.949ef384-8293-46b8-903f-40a477c056ae.ad72f8ca-a017-42d2-9c07-f17f282264d0@emailsignatures365.codetwo.com>
2024-02-06  6:58 ` [PATCH v3 1/2] dt-bindings: iio: adc: ti-ads1298: Add bindings Mike Looijmans
2024-02-06  6:58   ` [PATCH v3 2/2] iio: adc: ti-ads1298: Add driver Mike Looijmans
2024-02-06 12:57     ` Andy Shevchenko [this message]
2024-02-06 13:33       ` Mike Looijmans
2024-02-06 13:50         ` Andy Shevchenko
2024-02-06 14:25           ` Mike Looijmans
2024-02-06 14:47             ` Mike Looijmans
2024-02-06 15:09               ` Andy Shevchenko
2024-02-06 15:44                 ` Mike Looijmans
2024-02-06 16:32                   ` Andy Shevchenko
2024-02-06 17:38                     ` Mike Looijmans
2024-02-10 16:27                       ` Jonathan Cameron
2024-02-14  6:48                         ` Mike Looijmans
2024-02-14 14:08                           ` Jonathan Cameron
2024-02-06 15:07             ` Andy Shevchenko
2024-02-06 15:28   ` [PATCH v3 1/2] dt-bindings: iio: adc: ti-ads1298: Add bindings Conor Dooley

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=ZcIsuiuisQjTIxJv@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=bigunclemax@gmail.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jic23@kernel.org \
    --cc=lars@metafoo.de \
    --cc=lgirdwood@gmail.com \
    --cc=liambeguin@gmail.com \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcus.folkesson@gmail.com \
    --cc=marius.cristea@microchip.com \
    --cc=mike.looijmans@topic.nl \
    --cc=okan.sahin@analog.com \
    --cc=schnelle@linux.ibm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox