All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Shehryar Ahmad <shehryar.amd@gmail.com>
Cc: nuno.sa@analog.com, Michael.Hennerich@analog.com,
	dlechner@baylibre.com, andy@kernel.org, robh@kernel.org,
	krzk+dt@kernel.org, conor+dt@kernel.org,
	gregkh@linuxfoundation.org, linux@analog.com,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-staging@lists.linux.dev, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 3/6] iio: accel: adis16201: prepare driver to support additional parts
Date: Mon, 14 Sep 2026 01:53:21 +0100	[thread overview]
Message-ID: <20260914015321.7a660ab5@jic23-hlaptop> (raw)
In-Reply-To: <20260913085307.13846-4-shehryar.amd@gmail.com>

On Sun, 13 Sep 2026 13:53:04 +0500
Shehryar Ahmad <shehryar.amd@gmail.com> wrote:

> Introduce adis16201_chip_info to hold per chip data and adis16201_state
> to wrap struct adis. Move adis16201 to this infrastructure. This
> prepares the driver to support additional chip variants by keeping
> chip-specific parameters in adis16201_chip_info. Additionally,
> adis16201_write_raw applies mask directly on value.
> 
> Signed-off-by: Shehryar Ahmad <shehryar.amd@gmail.com>

Sashiko spotted what seems to be an interesting bug..  Seems
the adis_buffer library code relies on channel ordering matching
scan_index ordering and that isn't true in this driver.
https://sashiko.dev/#/patchset/20260913085307.13846-1-shehryar.amd%40gmail.com

There should be no negative side effects reordering the
channels so I think that would makes sense to do.

The buffered data will be in a different order but that will at least
be the order the sysfs interface claims it is in!  If you don't
mind doing that as a precursor to this series that would be great.

See the spi transaction building in adis_update_scan_modes() for
where it is going wrong.

One small review comment inline that means making one more thing const
to simplify the code a little.

Thanks,

Jonathan

> ---
>  drivers/iio/accel/adis16201.c | 78 ++++++++++++++++++++++++-----------
>  1 file changed, 55 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/iio/accel/adis16201.c b/drivers/iio/accel/adis16201.c
> index 2ce5c409b..e0bf7df50 100644
> --- a/drivers/iio/accel/adis16201.c
> +++ b/drivers/iio/accel/adis16201.c
> @@ -87,6 +87,22 @@ enum adis16201_scan {
>  	ADIS16201_SCAN_TEMP,
>  };
>  
> +struct adis16201_chip_info {
> +	const char *name;
> +	const struct iio_chan_spec *arr_channels;
> +	unsigned int incli_scale_val2;
> +	u16 write_mask_incli;
> +	u16 diag_stat_mask;
> +	unsigned int read_bits_incli;
> +	unsigned int num_channels;
As mentioned below add:
	const struct adis_data *data;
> +};
> +
> +struct adis16201_state {
> +	struct adis adis;
> +	const struct adis16201_chip_info *info;
> +	struct adis_data data;
 and drop this.
> +};

>  
>  static const struct iio_chan_spec adis16201_channels[] = {
> @@ -217,6 +232,20 @@ static const struct iio_chan_spec adis16201_channels[] = {
>  	IIO_CHAN_SOFT_TIMESTAMP(7)
>  };
>  
> +static const struct adis16201_chip_info adis16201_chip_data = {
> +	.arr_channels = adis16201_channels,
> +	.incli_scale_val2 = 100000,
> +	.write_mask_incli = GENMASK(8, 0),
> +	.diag_stat_mask =
> +		BIT(ADIS16201_DIAG_STAT_SPI_FAIL_BIT) |
> +		BIT(ADIS16201_DIAG_STAT_FLASH_UPT_FAIL_BIT) |
> +		BIT(ADIS16201_DIAG_STAT_POWER_HIGH_BIT) |
> +		BIT(ADIS16201_DIAG_STAT_POWER_LOW_BIT),
> +	.read_bits_incli = 9,
> +	.num_channels = ARRAY_SIZE(adis16201_channels),
> +	.name = "adis16201",
> +};
> +
>  static const struct iio_info adis16201_info = {
>  	.read_raw = adis16201_read_raw,
>  	.write_raw = adis16201_write_raw,
> @@ -248,16 +277,12 @@ static const struct adis_data adis16201_data = {
>  	.timeouts = &adis16201_timeouts,
>  
>  	.status_error_msgs = adis16201_status_error_msgs,
> -	.status_error_mask = BIT(ADIS16201_DIAG_STAT_SPI_FAIL_BIT) |
> -		BIT(ADIS16201_DIAG_STAT_FLASH_UPT_FAIL_BIT) |
> -		BIT(ADIS16201_DIAG_STAT_POWER_HIGH_BIT) |
> -		BIT(ADIS16201_DIAG_STAT_POWER_LOW_BIT),

As below, leave this here. Just look to access this whole structure
via info.

>  };
>  
>  static int adis16201_probe(struct spi_device *spi)
>  {
>  	struct iio_dev *indio_dev;
> -	struct adis *st;
> +	struct adis16201_state *st;
>  	int ret;
>  
>  	indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*st));
> @@ -266,22 +291,29 @@ static int adis16201_probe(struct spi_device *spi)
>  
>  	st = iio_priv(indio_dev);
>  
> -	indio_dev->name = spi->dev.driver->name;
> +	st->info = spi_get_device_match_data(spi);
> +	if (!st->info)
> +		return -ENODATA;
> +
> +	indio_dev->name = st->info->name;
>  	indio_dev->info = &adis16201_info;
>  
> -	indio_dev->channels = adis16201_channels;
> -	indio_dev->num_channels = ARRAY_SIZE(adis16201_channels);
> +	indio_dev->channels = st->info->arr_channels;
> +	indio_dev->num_channels = st->info->num_channels;
>  	indio_dev->modes = INDIO_DIRECT_MODE;
>  
> -	ret = adis_init(st, indio_dev, spi, &adis16201_data);
> +	st->data = adis16201_data;
> +	st->data.status_error_mask = st->info->diag_stat_mask;
Given we don't have too many variants, I think rather than
this copy and update pattern I'd just have multiple instances
of the structure type of adis16201_data. Then put a pointer
to the relevant one in the info structure and just pass
in to adis_init() st->info->data.
Then you won't need the diag_stat_mask element.

Costs a little more static const data but simplifies the code
and I think that is the right trade off to make.

> +
> +	ret = adis_init(&st->adis, indio_dev, spi, &st->data);
>  	if (ret)
>  		return ret;
>  
> -	ret = devm_adis_setup_buffer_and_trigger(st, indio_dev, NULL);
> +	ret = devm_adis_setup_buffer_and_trigger(&st->adis, indio_dev, NULL);
>  	if (ret)
>  		return ret;
>  
> -	ret = __adis_initial_startup(st);
> +	ret = __adis_initial_startup(&st->adis);
>  	if (ret)
>  		return ret;
>  
> @@ -289,14 +321,14 @@ static int adis16201_probe(struct spi_device *spi)
>  }
>  
>  static const struct of_device_id adis16201_of_match[] = {
> -	{ .compatible = "adi,adis16201" },
> +	{ .compatible = "adi,adis16201", .data = &adis16201_chip_data },
>  	{ },
>  };
>  
>  MODULE_DEVICE_TABLE(of, adis16201_of_match);
>  
>  static const struct spi_device_id adis16201_ids[] = {
> -	{ .name = "adis16201", 0 },
> +	{ .name = "adis16201", .driver_data = (kernel_ulong_t)&adis16201_chip_data },
>  	{ },
>  };
>  


  reply	other threads:[~2026-09-14  0:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-13  8:53 [PATCH v2 0/6] iio: accel: merge adis16203 into mainline adis16201 and remove from staging Shehryar Ahmad
2026-09-13  8:53 ` [PATCH v2 1/6] iio: accel: adis16201: add SPI device ID table Shehryar Ahmad
2026-09-14  8:18   ` Andy Shevchenko
2026-09-13  8:53 ` [PATCH v2 2/6] iio: accel: adis16201: add OF " Shehryar Ahmad
2026-09-14  8:19   ` Andy Shevchenko
2026-09-13  8:53 ` [PATCH v2 3/6] iio: accel: adis16201: prepare driver to support additional parts Shehryar Ahmad
2026-09-14  0:53   ` Jonathan Cameron [this message]
2026-09-13  8:53 ` [PATCH v2 4/6] iio: accel: adis16201: add ADIS16203 support Shehryar Ahmad
2026-09-13  9:09   ` sashiko-bot
2026-09-14  0:56   ` Jonathan Cameron
2026-09-14  8:21   ` Andy Shevchenko
2026-09-13  8:53 ` [PATCH v2 5/6] staging: iio: accel: remove adis16203, merged into mainline adis16201 driver Shehryar Ahmad
2026-09-13  8:53 ` [PATCH v2 6/6] dt-bindings: iio: accel: adi,adis16201: add adis16203 compatible Shehryar Ahmad

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=20260914015321.7a660ab5@jic23-hlaptop \
    --to=jic23@kernel.org \
    --cc=Michael.Hennerich@analog.com \
    --cc=andy@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=linux@analog.com \
    --cc=nuno.sa@analog.com \
    --cc=robh@kernel.org \
    --cc=shehryar.amd@gmail.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 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.