In this patch series, we move the callback from probe to probe_new, and add
manufacturer and device ID check for hdc100x driver.
LINK: [v1] https://lore.kernel.org/all/[email protected]/
LINK: [v2] https://lore.kernel.org/all/[email protected]/
LINK: [v3] 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
changes v2 --> v3:
- move probe_new part into a separate patch
- remove unsed variable
- remove redundant checking of matched data
changes v3 --> v4:
- move ID support checking to probe()
- add hdc100x_chip_data pointer into hdc100x_data for accessing in future
Potin Lai (2):
iio: humidity: hdc100x: switch to probe_new callback
iio: humidity: hdc100x: add manufacturer and device ID check
drivers/iio/humidity/hdc100x.c | 74 +++++++++++++++++++++++++++-------
1 file changed, 60 insertions(+), 14 deletions(-)
--
2.31.1
Andy Shevchenko 於 7/28/2022 7:58 PM 寫道:
> On Thursday, July 28, 2022, 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
>>
>> Signed-off-by: Potin Lai <[email protected]>
>> ---
>> drivers/iio/humidity/hdc100x.c | 69 ++++++++++++++++++++++++++++------
>> 1 file changed, 58 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/iio/humidity/hdc100x.c b/drivers/iio/humidity/
>> hdc100x.c
>> index 0d514818635cb..be1244577921d 100644
>> --- a/drivers/iio/humidity/hdc100x.c
>> +++ b/drivers/iio/humidity/hdc100x.c
>> @@ -34,7 +34,25 @@
>> #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 {
>> + const struct hdc100x_chip_data *chip_data;
>
>
> I don’t know why you added it here without any use right now, but even with
> that adding as a first member makes code suboptimal due to an additional
> pointer arithmetic. Use bloat-o-meter to see the difference.
>
Sorry, I think I misunderstood your comment in your previous reply.
(Introducing a temporary variable for struct device pointer might also help in future to refactor to make code neater.)
Thank you for introduce me the bloat-o-meter tool, I will have a check with it.
But I think I will just remove the pointer for now.
Thanks,
Potin
>
>
>> struct i2c_client *client;
>> struct mutex lock;
>> u16 config;
>> @@ -351,8 +369,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 +403,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;
>> @@ -368,6 +414,7 @@ static int hdc100x_probe(struct i2c_client *client)
>> data = iio_priv(indio_dev);
>> i2c_set_clientdata(client, indio_dev);
>> data->client = client;
>> + data->chip_data = chip_data;
>> mutex_init(&data->lock);
>>
>> indio_dev->name = dev_name(&client->dev);
>> @@ -396,22 +443,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);
>> --
>> 2.31.1
>>
>>
On Thu, Jul 28, 2022 at 2:40 PM Potin Lai <[email protected]> wrote:
> Andy Shevchenko 於 7/28/2022 7:58 PM 寫道:
> > On Thursday, July 28, 2022, Potin Lai <[email protected]> wrote:
Please, remove the unneeded context when replying!
...
> Sorry, I think I misunderstood your comment in your previous reply.
> (Introducing a temporary variable for struct device pointer might also help in future to refactor to make code neater.)
It was about
struct device *dev = &client->dev;
but as I said it may be done in a separate patch.
--
With Best Regards,
Andy Shevchenko