Linux IIO development
 help / color / mirror / Atom feed
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);


  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