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),
next prev parent 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 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.