mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Rodrigo Alencar via B4 Relay
	<devnull+rodrigo.alencar.analog.com@kernel.org>
Cc: rodrigo.alencar@analog.com, linux-kernel@vger.kernel.org,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	Michael Hennerich <Michael.Hennerich@analog.com>,
	Lars-Peter Clausen <lars@metafoo.de>,
	David Lechner <dlechner@baylibre.com>,
	Andy Shevchenko <andy@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>
Subject: Re: [PATCH v4 08/11] iio: amplifiers: ad8366: prepare for device-tree support
Date: Sat, 14 Feb 2026 18:56:36 +0000	[thread overview]
Message-ID: <20260214185636.6b7e2c7d@jic23-huawei> (raw)
In-Reply-To: <20260210-iio-ad8366-update-v4-8-15505f7b15b4@analog.com>

On Tue, 10 Feb 2026 19:42:08 +0000
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:

> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> 
> Drop switch case on the enum ID in favor of extended chip info table,
> containing:
> - gain_step, indicating with sign the start of the code range;
> - num_channels, to indicate the number IIO channels;
> - pack_code() function to describe how SPI buffer is populated;
> 
> Which allowed for a simplified read_raw() and write_raw() callbacks.
> The probe() function was adjusted accordingly.

Making the reset call on all devices is a material change (probably fine)
that should be called out here.

> 
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>

> @@ -48,60 +53,58 @@ struct ad8366_state {
>  	unsigned char		data[2] __aligned(IIO_DMA_MINALIGN);
>  };
>  
> +static size_t ad8366_pack_code(struct ad8366_state *st)

See below. To me this is doing too much hidden stuff from point
of view of the caller. I think it needs some more explicit parameters.

> +{
> +	u8 ch_a = bitrev8(st->ch[0]) >> 2;
> +	u8 ch_b = bitrev8(st->ch[1]) >> 2;
> +
> +	put_unaligned_be16((ch_b << 6) | ch_a, &st->data[0]);
> +	return sizeof(__be16);
> +}

>  
> -static int ad8366_write(struct iio_dev *indio_dev,
> -			unsigned char ch_a, unsigned char ch_b)
> +static int ad8366_write_code(struct ad8366_state *st)
>  {
> -	struct ad8366_state *st = iio_priv(indio_dev);
> -	int ret;
> +	const struct ad8366_info *inf = st->info;
>  
> -	switch (st->type) {
> -	case ID_AD8366:
> -		ch_a = bitrev8(ch_a & 0x3F);
> -		ch_b = bitrev8(ch_b & 0x3F);
> +	if (inf->pack_code)
> +		spi_write(st->spi, st->data, inf->pack_code(st));

Check return value?

I'm also confused that this function now does two writes whereas it only
used to do one. 

This is a really confusing call as inf->pack_code() has side effects
that might not be obvious out here.  I'd have that callback explicitly
take the inputs and the output array so it's obvious what it can affect.
		count = inf->pack_code(st->chan, 2, st->chan_data);
or something along those lines.

>  
> -		st->data[0] = ch_b >> 4;
> -		st->data[1] = (ch_b << 4) | (ch_a >> 2);
> -		break;
> -	case ID_ADA4961:
> -		st->data[0] = ch_a & 0x1F;
> -		break;
> -	case ID_ADL5240:
> -		st->data[0] = (ch_a & 0x3F);
> -		break;
> -	case ID_HMC792:
> -	case ID_HMC1119:
> -		st->data[0] = ch_a;
> -		break;
> -	}
> -
> -	ret = spi_write(st->spi, st->data, indio_dev->num_channels);
> -	if (ret < 0)
> -		dev_err(&indio_dev->dev, "write failed (%d)", ret);
> -
> -	return ret;
> +	st->data[0] = st->ch[0];
> +	return spi_write(st->spi, st->data, 1);
>  }

>  static int ad8366_probe(struct spi_device *spi)
>  {
>  	struct device *dev = &spi->dev;
> @@ -261,35 +229,20 @@ static int ad8366_probe(struct spi_device *spi)
>  		return dev_err_probe(dev, ret, "Failed to get regulator\n");
>  
>  	st->spi = spi;
> -	st->type = spi_get_device_id(spi)->driver_data;
> +	st->info = &ad8366_infos[spi_get_device_id(spi)->driver_data];
>  
> -	switch (st->type) {
> -	case ID_AD8366:
> -		indio_dev->channels = ad8366_channels;
> -		indio_dev->num_channels = ARRAY_SIZE(ad8366_channels);
> -		break;
> -	case ID_ADA4961:
> -	case ID_ADL5240:
> -	case ID_HMC792:
> -	case ID_HMC1119:
> -		rstc = devm_reset_control_get_optional_exclusive_deasserted(dev, NULL);
> -		if (IS_ERR(rstc))
> -			return dev_err_probe(dev, PTR_ERR(rstc),
> -					     "Failed to get reset controller\n");
> +	rstc = devm_reset_control_get_optional_exclusive_deasserted(dev, NULL);

I was surprised not to see this change in the patch description.

I guess it's fine because if the chip doesn't have a reset it looks the same
as one that isn't wired?  Add a comment to say not all devices have resets or
add a flag to the info structure and go back to calling it only for devices
that at least have a reset pin.



> +	if (IS_ERR(rstc))
> +		return dev_err_probe(dev, PTR_ERR(rstc),
> +				     "Failed to get reset controller\n");
>  
> -		indio_dev->channels = ada4961_channels;
> -		indio_dev->num_channels = ARRAY_SIZE(ada4961_channels);
> -		break;
> -	default:
> -		return dev_err_probe(dev, -EINVAL, "Invalid device ID\n");
> -	}
> -
> -	st->info = &ad8366_infos[st->type];
>  	indio_dev->name = spi_get_device_id(spi)->name;
>  	indio_dev->info = &ad8366_info;
>  	indio_dev->modes = INDIO_DIRECT_MODE;
> +	indio_dev->channels = ad8366_channels;
> +	indio_dev->num_channels = st->info->num_channels;
>  
> -	ret = ad8366_write(indio_dev, 0, 0);
> +	ret = ad8366_write_code(st);
>  	if (ret < 0)
>  		return dev_err_probe(dev, ret, "failed to write initial gain\n");
>  
> 


  reply	other threads:[~2026-02-14 18:56 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-10 19:42 [PATCH v4 00/11] iio: amplifiers: ad8366: driver update and dt support Rodrigo Alencar via B4 Relay
2026-02-10 19:42 ` [PATCH v4 01/11] MAINTAINERS: Add missing maintainer entry for AD8366 driver Rodrigo Alencar via B4 Relay
2026-02-10 19:42 ` [PATCH v4 02/11] dt-bindings: iio: amplifiers: Add AD8366 support Rodrigo Alencar via B4 Relay
2026-02-10 19:42 ` [PATCH v4 03/11] iio: amplifiers: ad8366: remove unused include headers Rodrigo Alencar via B4 Relay
2026-02-10 19:57   ` Andy Shevchenko
2026-02-11 12:55     ` Rodrigo Alencar
2026-02-11 13:35       ` Andy Shevchenko
2026-02-14 18:30         ` Jonathan Cameron
2026-02-15  7:31           ` Andy Shevchenko
2026-02-15 16:03             ` Jonathan Cameron
2026-02-10 19:42 ` [PATCH v4 04/11] iio: amplifiers: ad8366: add local dev pointer to the probe function Rodrigo Alencar via B4 Relay
2026-02-10 19:58   ` Andy Shevchenko
2026-02-10 20:03     ` Andy Shevchenko
2026-02-14 18:34       ` Jonathan Cameron
2026-02-10 19:42 ` [PATCH v4 05/11] iio: amplifiers: ad8366: use devm_mutex_init() and drop mutex_init() Rodrigo Alencar via B4 Relay
2026-02-10 20:00   ` Andy Shevchenko
2026-02-14 18:36   ` Jonathan Cameron
2026-02-15  7:50     ` Andy Shevchenko
2026-02-10 19:42 ` [PATCH v4 06/11] iio: amplifiers: ad8366: replace reset-gpio with reset controller Rodrigo Alencar via B4 Relay
2026-02-14 18:37   ` Jonathan Cameron
2026-02-10 19:42 ` [PATCH v4 07/11] iio: amplifiers: ad8366: refactor device resource management Rodrigo Alencar via B4 Relay
2026-02-10 20:05   ` Andy Shevchenko
2026-02-11 12:10     ` Rodrigo Alencar
2026-02-11 13:30       ` Andy Shevchenko
2026-02-14 18:44         ` Jonathan Cameron
2026-02-10 19:42 ` [PATCH v4 08/11] iio: amplifiers: ad8366: prepare for device-tree support Rodrigo Alencar via B4 Relay
2026-02-14 18:56   ` Jonathan Cameron [this message]
2026-02-10 19:42 ` [PATCH v4 09/11] iio: amplifiers: ad8366: add device tree support Rodrigo Alencar via B4 Relay
2026-02-14 19:00   ` Jonathan Cameron
2026-02-10 19:42 ` [PATCH v4 10/11] iio: amplifiers: ad8366: consume enable gpio Rodrigo Alencar via B4 Relay
2026-02-10 19:42 ` [PATCH v4 11/11] iio: amplifiers: ad8366: update device support Rodrigo Alencar via B4 Relay
2026-02-14 19: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=20260214185636.6b7e2c7d@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Michael.Hennerich@analog.com \
    --cc=andy@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=devnull+rodrigo.alencar.analog.com@kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=krzk+dt@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=rodrigo.alencar@analog.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

Powered by JetHome