On 1/30/21 2:10 AM, Matwey V. Kornilov wrote:
> There is a logical flaw in lm75_probe() function introduced in
>
> e97a45f1b460 ("hwmon: (lm75) Add OF device ID table")
>
> Note, that of_device_get_match_data() returns NULL when no match
> found. This is the case when OF node exists but has unknown
> compatible line, while the module is still loaded via i2c
> detection.
>
> arch/powerpc/boot/dts/fsl/p2041rdb.dts:
>
> lm75b@48 {
> compatible = "nxp,lm75a";
> reg = <0x48>;
> };
>
> In this case, the sensor is mistakenly considered as ADT75 variant.
> The simplest way to handle this issue is to make the LM75 code
> zero.
>
This doesn't really solve the problem since it would match _all_
non-existing entries with lm75 (instead of whatever is intended).
That doesn't matter for lm75a, but it would matter if someone
would enter, say, "bla,adt75".
On a side note, "nxp,lm75a" (nor "nxp,lm75", for that matter) is not a
documented compatible string for this driver. If anything, we would
need a means to explicitly reject such undefined compatible strings.
One option might be to define the first entry in enum lm75_type
explicitly as invalid, check for it and reject it if returned.
Guenter
> Fixes: e97a45f1b460 ("hwmon: (lm75) Add OF device ID table")
> Signed-off-by: Matwey V. Kornilov <[email protected]>
> ---
> drivers/hwmon/lm75.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
> index e447febd121a..3aa7f9454f57 100644
> --- a/drivers/hwmon/lm75.c
> +++ b/drivers/hwmon/lm75.c
> @@ -25,12 +25,12 @@
> */
>
> enum lm75_type { /* keep sorted in alphabetical order */
> + lm75 = 0, /* except of lm75 which is default fallback */
> adt75,
> ds1775,
> ds75,
> ds7505,
> g751,
> - lm75,
> lm75a,
> lm75b,
> max6625,
>
