devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Dumitru Ceclan <mitrutzceclan@gmail.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Ceclan Dumitru <dumitru.ceclan@analog.com>
Subject: Re: [PATCH v4 4/5] iio: amplifiers: hmc425a: use pointers in match table
Date: Sun, 21 Jan 2024 16:57:21 +0000	[thread overview]
Message-ID: <20240121165721.475d35c2@jic23-huawei> (raw)
In-Reply-To: <20240117125124.8326-5-mitrutzceclan@gmail.com>

On Wed, 17 Jan 2024 14:51:13 +0200
Dumitru Ceclan <mitrutzceclan@gmail.com> wrote:

> Change the match table to use pointers instead of device ids.
> Alignment of the hmc425a_state was changed because of the const
>  specifier for hmc425a_chip_info.
> 
> Signed-off-by: Dumitru Ceclan <mitrutzceclan@gmail.com>
Hi Dumitru

The remaining use of type in here and deriving from structure offsets is
not nice.  Add a trivial callback for the stuff in write_raw() that needs
to be different and is currently in a switch statement.
Then get rid of the type enum completely if possible.

> ---
>  drivers/iio/amplifiers/hmc425a.c | 39 ++++++++++++++++++--------------
>  1 file changed, 22 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/iio/amplifiers/hmc425a.c b/drivers/iio/amplifiers/hmc425a.c
> index e1162a500daf..b116b54e4206 100644
> --- a/drivers/iio/amplifiers/hmc425a.c
> +++ b/drivers/iio/amplifiers/hmc425a.c
> @@ -37,11 +37,11 @@ struct hmc425a_chip_info {
>  };
>  
>  struct hmc425a_state {
> -	struct	mutex lock; /* protect sensor state */
> -	struct	hmc425a_chip_info *chip_info;
> -	struct	gpio_descs *gpios;
> -	enum	hmc425a_type type;
> -	u32	gain;
> +	struct				mutex lock; /* protect sensor state */
> +	const struct			hmc425a_chip_info *chip_info;
> +	struct				gpio_descs *gpios;
> +	enum				hmc425a_type type;
> +	u32				gain;

This illustrates why I'm not keen on manual alignment like this. Generates 
churn that makes it hard to spot the actual changes.  To avoid this happening
again I'd suggest a single space is fine for all lines and don't align them
at all!

>  };
>  
>  static int hmc425a_write(struct iio_dev *indio_dev, u32 value)
> @@ -58,7 +58,7 @@ static int hmc425a_write(struct iio_dev *indio_dev, u32 value)
>  
>  static int hmc425a_gain_dB_to_code(struct hmc425a_state *st, int val, int val2, int *code)
>  {
> -	struct hmc425a_chip_info *inf = st->chip_info;
> +	const struct hmc425a_chip_info *inf = st->chip_info;
>  	int gain, temp;
>  
>  	if (val < 0)
> @@ -187,15 +187,6 @@ static const struct iio_chan_spec hmc425a_channels[] = {
>  	HMC425A_CHAN(0),
>  };
>  
> -/* Match table for of_platform binding */
> -static const struct of_device_id hmc425a_of_match[] = {
> -	{ .compatible = "adi,hmc425a", .data = (void *)ID_HMC425A },
> -	{ .compatible = "adi,hmc540s", .data = (void *)ID_HMC540S },
> -	{ .compatible = "adi,adrf5740", .data = (void *)ID_ADRF5740 },
> -	{},
> -};
> -MODULE_DEVICE_TABLE(of, hmc425a_of_match);
> -
>  static struct hmc425a_chip_info hmc425a_chip_info_tbl[] = {
>  	[ID_HMC425A] = {
>  		.name = "hmc425a",
> @@ -226,6 +217,18 @@ static struct hmc425a_chip_info hmc425a_chip_info_tbl[] = {
>  	},
>  };
>  
> +/* Match table for of_platform binding */
> +static const struct of_device_id hmc425a_of_match[] = {
> +	{ .compatible = "adi,hmc425a",
> +	  .data = &hmc425a_chip_info_tbl[ID_HMC425A]},
> +	{ .compatible = "adi,hmc540s",
> +	  .data = &hmc425a_chip_info_tbl[ID_HMC540S]},
> +	{ .compatible = "adi,adrf5740",
> +	  .data = &hmc425a_chip_info_tbl[ID_ADRF5740]},
> +	{},

Nice to drop that trailing comma whilst here.  No need for one on a 'terminator'
of such an array as by definition nothing should ever be added after it.

> +};
> +MODULE_DEVICE_TABLE(of, hmc425a_of_match);
> +
>  static int hmc425a_probe(struct platform_device *pdev)
>  {
>  	struct iio_dev *indio_dev;
> @@ -237,14 +240,16 @@ static int hmc425a_probe(struct platform_device *pdev)
>  		return -ENOMEM;
>  
>  	st = iio_priv(indio_dev);
> -	st->type = (uintptr_t)device_get_match_data(&pdev->dev);
>  
> -	st->chip_info = &hmc425a_chip_info_tbl[st->type];
> +	st->chip_info = device_get_match_data(&pdev->dev);
>  	indio_dev->num_channels = st->chip_info->num_channels;
>  	indio_dev->channels = st->chip_info->channels;
>  	indio_dev->name = st->chip_info->name;
>  	st->gain = st->chip_info->default_gain;
>  
> +	/* Compute index of the acquired chip info in the array */
> +	st->type = st->chip_info - hmc425a_chip_info_tbl;

Definitely not a good idea. If you need a type field, put it in the chip_info_tbl
but you should not need one anyway because type is rarely what matters
but rather data or behavior (via a callback) needed for a given device.
Here it looks like a callback is needed for the few lines in write_raw()
that are fiddly to express as data.

> +
>  	st->gpios = devm_gpiod_get_array(&pdev->dev, "ctrl", GPIOD_OUT_LOW);
>  	if (IS_ERR(st->gpios))
>  		return dev_err_probe(&pdev->dev, PTR_ERR(st->gpios),


  reply	other threads:[~2024-01-21 16:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-17 12:51 [PATCH v4 0/5] Add support for LTC6373 Dumitru Ceclan
2024-01-17 12:51 ` [PATCH v4 1/5] dt-bindings: iio: hmc425a: add conditional GPIO array size constraints Dumitru Ceclan
2024-01-17 12:51 ` [PATCH v4 2/5] dt-bindings: iio: hmc425a: add entry for LTC6373 Dumitru Ceclan
2024-01-17 12:51 ` [PATCH v4 3/5] iio: amplifiers: hmc425a: move conversion logic Dumitru Ceclan
2024-01-21 17:07   ` Jonathan Cameron
2024-01-17 12:51 ` [PATCH v4 4/5] iio: amplifiers: hmc425a: use pointers in match table Dumitru Ceclan
2024-01-21 16:57   ` Jonathan Cameron [this message]
2024-01-17 12:51 ` [PATCH v4 5/5] iio: amplifiers: hmc425a: add support for LTC6373 Instrumentation Amplifier Dumitru Ceclan
2024-01-21 17:14   ` Jonathan Cameron
2024-01-26  9:18   ` Petre Rodan

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=20240121165721.475d35c2@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dumitru.ceclan@analog.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mitrutzceclan@gmail.com \
    --cc=robh+dt@kernel.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;
as well as URLs for NNTP newsgroup(s).