[PATCH v2 1/1] iio: humidity: hdc100x: add manufacturer and device ID cehck

[PATCH v2 1/1] iio: humidity: hdc100x: add manufacturer and device ID cehck

[Potin Lai]

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>
---
LINK: [v1] https://lore.kernel.org/all/20220722172035.44977-1-potin.lai.pt@gmail.com/
                                                           
changes v1 --> v2:                       
- fix typo in commit message           
- change to use probe_new
- use device_get_match_data instead of i2c_of_match_device
---
 drivers/iio/humidity/hdc100x.c | 78 ++++++++++++++++++++++++++++------
 1 file changed, 64 insertions(+), 14 deletions(-)

diff --git a/drivers/iio/humidity/hdc100x.c b/drivers/iio/humidity/hdc100x.c
index 9e0fce917ce4c..8c69b4a610c4f 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,38 @@ static const struct iio_info hdc100x_info = {
 	.attrs = &hdc100x_attribute_group,
 };
 
-static int hdc100x_probe(struct i2c_client *client,
-			 const struct i2c_device_id *id)
+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)
+{
+	const struct of_device_id *match;
+	struct hdc100x_chip_data *data;
+	int mfr_id, dev_id;
+
+	data = device_get_match_data(&client->dev);
+	if (data) {
+		if (!data->support_mfr_check)
+			return true;
+	}
+
+	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)
 {
 	struct iio_dev *indio_dev;
 	struct hdc100x_data *data;
@@ -362,6 +409,9 @@ static int hdc100x_probe(struct i2c_client *client,
 				     I2C_FUNC_SMBUS_BYTE | I2C_FUNC_I2C))
 		return -EOPNOTSUPP;
 
+	if (!is_valid_hdc100x(client))
+		return -EOPNOTSUPP;
+
 	indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
 	if (!indio_dev)
 		return -ENOMEM;
@@ -397,22 +447,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);
@@ -422,7 +472,7 @@ static struct i2c_driver hdc100x_driver = {
 		.name	= "hdc100x",
 		.of_match_table = hdc100x_dt_ids,
 	},
-	.probe = hdc100x_probe,
+	.probe_new = hdc100x_probe,
 	.id_table = hdc100x_id,
 };
 module_i2c_driver(hdc100x_driver);
-- 
2.31.1

Re: [PATCH v2 1/1] iio: humidity: hdc100x: add manufacturer and device ID cehck

[Andy Shevchenko]

On Wed, Jul 27, 2022 at 8:46 AM 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

Thanks for an update, my comments below.

...

> +       const struct of_device_id *match;

Don't you have a compiler warning? Always compile your code with `make W=1`

...

> +       data = device_get_match_data(&client->dev);

> +       if (data) {

This check is redundant. Too much protective programming. Just oblige
that matched ID has to always have an associated data.

> +               if (!data->support_mfr_check)
> +                       return true;
> +       }

...

> -       .probe = hdc100x_probe,
> +       .probe_new = hdc100x_probe,

Make this a separate patch before the presented one.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 1/1] iio: humidity: hdc100x: add manufacturer and device ID cehck

[Potin Lai]

On 7/27/22 18:00, Andy Shevchenko wrote:
> On Wed, Jul 27, 2022 at 8:46 AM 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
> Thanks for an update, my comments below.
>
> ...
>
>> +       const struct of_device_id *match;
> Don't you have a compiler warning? Always compile your code with `make W=1`
>
> ...

You are correct, I will remove this unused variable.

>> +       data = device_get_match_data(&client->dev);
>> +       if (data) {
> This check is redundant. Too much protective programming. Just oblige
> that matched ID has to always have an associated data.
Is it guaranteed that device_get_match_data will not return NULL? I find some examples in other drivers, all of them have a check on returned data.

Will it be more appropriate if I move device_get_match_data to probe function, and return EINVAL when we get a NULL pointer from device_get_match_data?

>> +               if (!data->support_mfr_check)
>> +                       return true;
>> +       }
> ...
>
>> -       .probe = hdc100x_probe,
>> +       .probe_new = hdc100x_probe,
> Make this a separate patch before the presented one.
>
got it, will move this into a separate patch in next version.

thanks,
Potin

Re: [PATCH v2 1/1] iio: humidity: hdc100x: add manufacturer and device ID cehck

[Andy Shevchenko]

On Wed, Jul 27, 2022 at 12:42 PM Potin Lai <potin.lai.pt@gmail.com> wrote:
> On 7/27/22 18:00, Andy Shevchenko wrote:
> > On Wed, Jul 27, 2022 at 8:46 AM Potin Lai <potin.lai.pt@gmail.com> wrote:

...

> >> +       data = device_get_match_data(&client->dev);
> >> +       if (data) {
> > This check is redundant. Too much protective programming. Just oblige
> > that matched ID has to always have an associated data.
> Is it guaranteed that device_get_match_data will not return NULL? I find some examples in other drivers, all of them have a check on returned data.

No, but as I said you may guarantee that by obliging developers not to
shoot in their feet.

> Will it be more appropriate if I move device_get_match_data to probe function, and return EINVAL when we get a NULL pointer from device_get_match_data?

Why is this check needed? We do not like dead code.

> >> +               if (!data->support_mfr_check)
> >> +                       return true;
> >> +       }

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 1/1] iio: humidity: hdc100x: add manufacturer and device ID cehck

[Potin Lai]

Andy Shevchenko 於 7/27/2022 7:56 PM 寫道:
> On Wed, Jul 27, 2022 at 12:42 PM Potin Lai <potin.lai.pt@gmail.com> wrote:
>> On 7/27/22 18:00, Andy Shevchenko wrote:
>>> On Wed, Jul 27, 2022 at 8:46 AM Potin Lai <potin.lai.pt@gmail.com> wrote:
> ...
>
>>>> +       data = device_get_match_data(&client->dev);
>>>> +       if (data) {
>>> This check is redundant. Too much protective programming. Just oblige
>>> that matched ID has to always have an associated data.
>> Is it guaranteed that device_get_match_data will not return NULL? I find some examples in other drivers, all of them have a check on returned data.
> No, but as I said you may guarantee that by obliging developers not to
> shoot in their feet.
Thanks for the explanation, I will remove the checking part.

Potin
>> Will it be more appropriate if I move device_get_match_data to probe function, and return EINVAL when we get a NULL pointer from device_get_match_data?
> Why is this check needed? We do not like dead code.
>
>>>> +               if (!data->support_mfr_check)
>>>> +                       return true;
>>>> +       }