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 <[email protected]>
---
LINK: [v1] https://lore.kernel.org/all/[email protected]/
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
On Wed, Jul 27, 2022 at 8:46 AM Potin Lai <[email protected]> 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
On 7/27/22 18:00, Andy Shevchenko wrote:
> On Wed, Jul 27, 2022 at 8:46 AM Potin Lai <[email protected]> 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
On Wed, Jul 27, 2022 at 12:42 PM Potin Lai <[email protected]> wrote:
> On 7/27/22 18:00, Andy Shevchenko wrote:
> > On Wed, Jul 27, 2022 at 8:46 AM Potin Lai <[email protected]> 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
Andy Shevchenko 於 7/27/2022 7:56 PM 寫道:
> On Wed, Jul 27, 2022 at 12:42 PM Potin Lai <[email protected]> wrote:
>> On 7/27/22 18:00, Andy Shevchenko wrote:
>>> On Wed, Jul 27, 2022 at 8:46 AM Potin Lai <[email protected]> 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;
>>>> + }