| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20220731130959.50826fc4@jic23-huawei>
Date: Sun, 31 Jul 2022 13:09:59 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Potin Lai <potin.lai.pt@...il.com>
Cc: Andy Shevchenko <andy.shevchenko@...il.com>,
Lars-Peter Clausen <lars@...afoo.de>,
Patrick Williams <patrick@...cx.xyz>,
Potin Lai <potin.lai@...ntatw.com>, linux-iio@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 2/2] iio: humidity: hdc100x: add manufacturer and
device ID check
On Thu, 28 Jul 2022 12:54:35 +0000
Potin Lai <potin.lai.pt@...il.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@...il.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);
Powered by blists - more mailing lists