From: Jonathan Cameron <jic23@kernel.org>
To: Potin Lai <potin.lai.pt@gmail.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
Lars-Peter Clausen <lars@metafoo.de>,
Patrick Williams <patrick@stwcx.xyz>,
Potin Lai <potin.lai@quantatw.com>,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 2/2] iio: humidity: hdc100x: add manufacturer and device ID check
Date: Sun, 31 Jul 2022 13:09:59 +0100 [thread overview]
Message-ID: <20220731130959.50826fc4@jic23-huawei> (raw)
In-Reply-To: <20220728125435.3336618-3-potin.lai.pt@gmail.com>
On Thu, 28 Jul 2022 12:54:35 +0000
Potin Lai <potin.lai.pt@gmail.com> wrote:
> Add manufacturer and device ID checking during probe, and skip the
> checking if chip model not supported.
>
> Supported:
> - HDC1000
> - HDC1010
> - HDC1050
> - HDC1080
>
> Not supported:
> - HDC1008
>
> Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
I need some more information on the 'why' of this patch. There are a number
of drivers that do a similar ID check but in recent times, that approach has
been considered wrong because it breaks potential use of multiple compatible
entries in device tree. If a new device comes along and is backwards
compatible with an existing one (maybe has new features, but using them is
optional) then we want to have an entry that looks like
compatible = "ti,hdc1099", "ti,hdc1080"
If the new ID is not supported by the kernel that is being used, we still
want the driver to 'work' using the fallback compatible.
As such, we no generally do the following.
1) If we have a match to a device we know about but it's not the one the
firmware tells us to expect, print a warning but operate as if the firmware
had been correct - particularly if we know the parts aren't compatible
with each other. (this bit is optional as we should be able to assume firmware
doesn't do stupid things :)
2) If we don't match at all, print a warning about an unknown device but carry
on with assumption that the firmware is correct and this new device ID is
backwards compatible with the provided fallback compatible.
So if this is just a bit of defensive programming (rather than necessary for some
reason not yet explained) then change from returning an error on probe() to
printing an warning message but continuing anyway. (which is part (2) of the
above)
> ---
> drivers/iio/humidity/hdc100x.c | 67 ++++++++++++++++++++++++++++------
> 1 file changed, 56 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/iio/humidity/hdc100x.c b/drivers/iio/humidity/hdc100x.c
> index 0d514818635cb..31f18cc1cf63c 100644
> --- a/drivers/iio/humidity/hdc100x.c
> +++ b/drivers/iio/humidity/hdc100x.c
> @@ -34,6 +34,23 @@
> #define HDC100X_REG_CONFIG_ACQ_MODE BIT(12)
> #define HDC100X_REG_CONFIG_HEATER_EN BIT(13)
>
> +#define HDC100X_REG_MFR_ID 0xFE
> +#define HDC100X_REG_DEV_ID 0xFF
> +
> +#define HDC100X_MFR_ID 0x5449
> +
> +struct hdc100x_chip_data {
> + bool support_mfr_check;
> +};
> +
> +static const struct hdc100x_chip_data hdc100x_chip_data = {
> + .support_mfr_check = true,
> +};
> +
> +static const struct hdc100x_chip_data hdc1008_chip_data = {
> + .support_mfr_check = false,
> +};
> +
> struct hdc100x_data {
> struct i2c_client *client;
> struct mutex lock;
> @@ -351,8 +368,32 @@ static const struct iio_info hdc100x_info = {
> .attrs = &hdc100x_attribute_group,
> };
>
> +static int hdc100x_read_mfr_id(struct i2c_client *client)
> +{
> + return i2c_smbus_read_word_swapped(client, HDC100X_REG_MFR_ID);
> +}
> +
> +static int hdc100x_read_dev_id(struct i2c_client *client)
> +{
> + return i2c_smbus_read_word_swapped(client, HDC100X_REG_DEV_ID);
> +}
> +
> +static bool is_valid_hdc100x(struct i2c_client *client)
> +{
> + int mfr_id, dev_id;
> +
> + mfr_id = hdc100x_read_mfr_id(client);
> + dev_id = hdc100x_read_dev_id(client);
> + if (mfr_id == HDC100X_MFR_ID &&
> + (dev_id == 0x1000 || dev_id == 0x1050))
> + return true;
> +
> + return false;
> +}
> +
> static int hdc100x_probe(struct i2c_client *client)
> {
> + const struct hdc100x_chip_data *chip_data;
> struct iio_dev *indio_dev;
> struct hdc100x_data *data;
> int ret;
> @@ -361,6 +402,10 @@ static int hdc100x_probe(struct i2c_client *client)
> I2C_FUNC_SMBUS_BYTE | I2C_FUNC_I2C))
> return -EOPNOTSUPP;
>
> + chip_data = device_get_match_data(&client->dev);
> + if (chip_data->support_mfr_check && !is_valid_hdc100x(client))
> + return -EINVAL;
> +
> indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
> if (!indio_dev)
> return -ENOMEM;
> @@ -396,22 +441,22 @@ static int hdc100x_probe(struct i2c_client *client)
> }
>
> static const struct i2c_device_id hdc100x_id[] = {
> - { "hdc100x", 0 },
> - { "hdc1000", 0 },
> - { "hdc1008", 0 },
> - { "hdc1010", 0 },
> - { "hdc1050", 0 },
> - { "hdc1080", 0 },
> + { "hdc100X", (kernel_ulong_t)&hdc100x_chip_data },
> + { "hdc1000", (kernel_ulong_t)&hdc100x_chip_data },
> + { "hdc1008", (kernel_ulong_t)&hdc1008_chip_data },
> + { "hdc1010", (kernel_ulong_t)&hdc100x_chip_data },
> + { "hdc1050", (kernel_ulong_t)&hdc100x_chip_data },
> + { "hdc1080", (kernel_ulong_t)&hdc100x_chip_data },
> { }
> };
> MODULE_DEVICE_TABLE(i2c, hdc100x_id);
>
> static const struct of_device_id hdc100x_dt_ids[] = {
> - { .compatible = "ti,hdc1000" },
> - { .compatible = "ti,hdc1008" },
> - { .compatible = "ti,hdc1010" },
> - { .compatible = "ti,hdc1050" },
> - { .compatible = "ti,hdc1080" },
> + { .compatible = "ti,hdc1000", .data = &hdc100x_chip_data },
> + { .compatible = "ti,hdc1008", .data = &hdc1008_chip_data },
> + { .compatible = "ti,hdc1010", .data = &hdc100x_chip_data },
> + { .compatible = "ti,hdc1050", .data = &hdc100x_chip_data },
> + { .compatible = "ti,hdc1080", .data = &hdc100x_chip_data },
> { }
> };
> MODULE_DEVICE_TABLE(of, hdc100x_dt_ids);
next prev parent reply other threads:[~2022-07-31 11:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-28 12:54 [PATCH v5 0/2] iio: humidity: hdc100x: add manufacturer and device ID check Potin Lai
2022-07-28 12:54 ` [PATCH v5 1/2] iio: humidity: hdc100x: switch to probe_new callback Potin Lai
2022-07-28 20:41 ` Andy Shevchenko
2022-07-29 0:43 ` Potin Lai
2022-07-29 18:00 ` Andy Shevchenko
2022-07-28 12:54 ` [PATCH v5 2/2] iio: humidity: hdc100x: add manufacturer and device ID check Potin Lai
2022-07-28 20:42 ` Andy Shevchenko
2022-07-31 12:09 ` Jonathan Cameron [this message]
2022-08-01 1:50 ` Potin Lai
2022-08-01 8:22 ` Andy Shevchenko
2022-08-01 16:12 ` Patrick Williams
2022-08-01 16:26 ` Andy Shevchenko
2022-08-01 16:30 ` Andy Shevchenko
2022-08-06 17:12 ` Jonathan Cameron
2022-08-08 9:40 ` Krzysztof Kozlowski
2022-08-08 9:49 ` Andy Shevchenko
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=20220731130959.50826fc4@jic23-huawei \
--to=jic23@kernel.org \
--cc=andy.shevchenko@gmail.com \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patrick@stwcx.xyz \
--cc=potin.lai.pt@gmail.com \
--cc=potin.lai@quantatw.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