public inbox for linux-kernel-mentees@lists.linux-foundation.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Gabriel Shahrouzi <gshahrouzi@gmail.com>
Cc: gregkh@linuxfoundation.org, lars@metafoo.de,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-staging@lists.linux.dev, Michael.Hennerich@analog.com,
	sonic.zhang@analog.com, vapier@gentoo.org,
	skhan@linuxfoundation.org, linux-kernel-mentees@lists.linux.dev
Subject: Re: [PATCH v5 3/5] staging: iio: adc: ad7816: Introduce chip_info and use pointer matching
Date: Mon, 21 Apr 2025 13:34:23 +0100	[thread overview]
Message-ID: <20250421133423.3833e911@jic23-huawei> (raw)
In-Reply-To: <20250420014910.849934-4-gshahrouzi@gmail.com>

On Sat, 19 Apr 2025 21:49:08 -0400
Gabriel Shahrouzi <gshahrouzi@gmail.com> wrote:

> Introduce struct ad7816_chip_info to centralize static properties (e.g.
> name, max channels) that differ between chip variants (AD7816/7/8) but
> are constant for any specific type.
> 
> Store pointers to these instances in the of_device_id (.data) and
> spi_device_id (driver_data) tables. Retrieve the pointer in probe()
> using the firmware-independent device_get_match_data() and store it in
> the ad7816_state struct.
> 
> Signed-off-by: Gabriel Shahrouzi <gshahrouzi@gmail.com>
Hi Gabriel

A few minor things inline.

I think this went a little too far in splitting up changes and you should combine
patches 3 and 4 to avoid a nasty intermediate bit of code.

Jonathan

> ---
>  drivers/staging/iio/adc/ad7816.c | 55 +++++++++++++++++++++-----------
>  1 file changed, 37 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/staging/iio/adc/ad7816.c b/drivers/staging/iio/adc/ad7816.c
> index cad2e55aff3f9..39310ade770d0 100644
> --- a/drivers/staging/iio/adc/ad7816.c
> +++ b/drivers/staging/iio/adc/ad7816.c
> @@ -41,8 +41,28 @@
>   * struct ad7816_state - chip specific information
>   */
>  
> +struct ad7816_chip_info {
> +	const char *name;
> +	u8 max_channels;

Something called max_channels should be the number of channels.
If you called it max_channel then it could be used for the maximum channel
number present. I assume that is what you have here as otherwise the
ad7816 has no channels which seems odd!

> +};
> +
> +static const struct ad7816_chip_info ad7816_info_ad7816 = {
> +	.name = "ad7816",
> +	.max_channels = 0,
> +};
> +
> +static const struct ad7816_chip_info ad7817_info_ad7817 = {
> +	.name = "ad7817",
> +	.max_channels = 3,
> +};
> +
> +static const struct ad7816_chip_info ad7818_info_ad7818 = {
> +	.name = "ad7818",
> +	.max_channels = 1,
> +};
> +
>  struct ad7816_state {
> -	kernel_ulong_t id;
> +	const struct ad7816_chip_info *chip_info;
>  	struct spi_device *spi_dev;
>  	struct gpio_desc *rdwr_pin;
>  	struct gpio_desc *convert_pin;
> @@ -52,12 +72,6 @@ struct ad7816_state {
>  	u8  mode;
>  };
>  
> -enum ad7816_type {
> -	ID_AD7816,
> -	ID_AD7817,
> -	ID_AD7818,
> -};
> -
>  /*
>   * ad7816 data access by SPI
>   */
> @@ -84,7 +98,7 @@ static int ad7816_spi_read(struct ad7816_state *chip, u16 *data)
>  		gpiod_set_value(chip->convert_pin, 1);
>  	}
>  
> -	if (chip->id == ID_AD7816 || chip->id == ID_AD7817) {
> +	if (chip->chip_info == &ad7816_info_ad7816 || chip->chip_info == &ad7817_info_ad7817) {

Hmm. I'd be tempted to squash the next patch with this one simply to avoid this
horrible intermediate state where you match on pointers.

It is all part of moving from the enum over to data so I think is
fine in one patch.

>  		while (gpiod_get_value(chip->busy_pin))
>  			cpu_relax();
>  	}
> @@ -353,6 +367,7 @@ static int ad7816_probe(struct spi_device *spi_dev)
>  {
>  	struct ad7816_state *chip;
>  	struct iio_dev *indio_dev;
> +	const struct ad7816_chip_info *info;
>  	int i, ret;
>  
>  	indio_dev = devm_iio_device_alloc(&spi_dev->dev, sizeof(*chip));
> @@ -362,11 +377,15 @@ static int ad7816_probe(struct spi_device *spi_dev)
>  	/* this is only used for device removal purposes */
>  	dev_set_drvdata(&spi_dev->dev, indio_dev);
>  
> +	info = device_get_match_data(&spi_dev->dev);
> +	if (!info)
> +		return -ENODEV;
> +	chip->chip_info = info;
> +
>  	chip->spi_dev = spi_dev;
>  	for (i = 0; i <= AD7816_CS_MAX; i++)
>  		chip->oti_data[i] = 203;
>  
> -	chip->id = spi_get_device_id(spi_dev)->driver_data;
>  	chip->rdwr_pin = devm_gpiod_get(&spi_dev->dev, "rdwr", GPIOD_OUT_HIGH);
>  	if (IS_ERR(chip->rdwr_pin)) {
>  		ret = PTR_ERR(chip->rdwr_pin);
> @@ -382,7 +401,7 @@ static int ad7816_probe(struct spi_device *spi_dev)
>  			ret);
>  		return ret;
>  	}
> -	if (chip->id == ID_AD7816 || chip->id == ID_AD7817) {
> +	if (chip->chip_info == &ad7816_info_ad7816 || chip->chip_info == &ad7817_info_ad7817) {
>  		chip->busy_pin = devm_gpiod_get(&spi_dev->dev, "busy",
>  						GPIOD_IN);
>  		if (IS_ERR(chip->busy_pin)) {
> @@ -393,7 +412,7 @@ static int ad7816_probe(struct spi_device *spi_dev)
>  		}
>  	}
>  
> -	indio_dev->name = spi_get_device_id(spi_dev)->name;
> +	indio_dev->name = chip->chip_info->name;
>  	indio_dev->info = &ad7816_info;
>  	indio_dev->modes = INDIO_DIRECT_MODE;
>  
> @@ -420,18 +439,18 @@ static int ad7816_probe(struct spi_device *spi_dev)
>  }
>  
>  static const struct of_device_id ad7816_of_match[] = {
> -	{ .compatible = "adi,ad7816", },
> -	{ .compatible = "adi,ad7817", },
> -	{ .compatible = "adi,ad7818", },
> +	{ .compatible = "adi,ad7816", .data = &ad7816_info_ad7816 },
> +	{ .compatible = "adi,ad7817", .data = &ad7817_info_ad7817 },
> +	{ .compatible = "adi,ad7818", .data = &ad7818_info_ad7818 },
>  	{ }
>  };
>  MODULE_DEVICE_TABLE(of, ad7816_of_match);
>  
>  static const struct spi_device_id ad7816_id[] = {
> -	{ "ad7816", ID_AD7816 },
> -	{ "ad7817", ID_AD7817 },
> -	{ "ad7818", ID_AD7818 },
> -	{}
> +	{ "ad7816", (kernel_ulong_t)&ad7816_info_ad7816 },
> +	{ "ad7817", (kernel_ulong_t)&ad7817_info_ad7817 },
> +	{ "ad7818", (kernel_ulong_t)&ad7818_info_ad7818 },
> +	{ }
>  };
>  
>  MODULE_DEVICE_TABLE(spi, ad7816_id);


  reply	other threads:[~2025-04-21 12:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-20  1:49 [PATCH v5 0/5] staging: iio: adc: ad7816: Fix channel handling and refactor Gabriel Shahrouzi
2025-04-20  1:49 ` [PATCH v5 1/5] staging: iio: adc: ad7816: Allow channel 7 for all devices Gabriel Shahrouzi
2025-04-21 12:29   ` Jonathan Cameron
2025-04-20  1:49 ` [PATCH v5 2/5] staging: iio: adc: ad7816: Rename state structure Gabriel Shahrouzi
2025-04-20  1:49 ` [PATCH v5 3/5] staging: iio: adc: ad7816: Introduce chip_info and use pointer matching Gabriel Shahrouzi
2025-04-21 12:34   ` Jonathan Cameron [this message]
2025-04-20  1:49 ` [PATCH v5 4/5] staging: iio: adc: ad7816: Use chip_info for device capabilities Gabriel Shahrouzi
2025-04-21 12:35   ` Jonathan Cameron
2025-04-20  1:49 ` [PATCH v5 5/5] staging: iio: adc: ad7816: Simplify channel validation using chip_info Gabriel Shahrouzi
2025-04-21 12:37   ` Jonathan Cameron
2025-04-21 11:31 ` [PATCH v5 0/5] staging: iio: adc: ad7816: Fix channel handling and refactor Jonathan Cameron
2025-04-21 13:49   ` Gabriel Shahrouzi

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=20250421133423.3833e911@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=Michael.Hennerich@analog.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gshahrouzi@gmail.com \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel-mentees@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=skhan@linuxfoundation.org \
    --cc=sonic.zhang@analog.com \
    --cc=vapier@gentoo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox