[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <2588ea5c-630e-6509-689d-4c8fea358e9b@roeck-us.net>
Date: Wed, 3 Feb 2021 11:57:42 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: "Matwey V. Kornilov" <matwey.kornilov@...il.com>
Cc: Jean Delvare <jdelvare@...e.com>,
"open list:HARDWARE MONITORING" <linux-hwmon@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] hwmon: lm75: Add NXP LM75A to of_match list
On 2/3/21 9:13 AM, Matwey V. Kornilov wrote:
>
>
> сб, 30 янв. 2021 г. в 18:41, Guenter Roeck <linux@...ck-us.net <mailto:linux@...ck-us.net>>:
>>
>> On 1/30/21 2:38 AM, Matwey V. Kornilov wrote:
>> > NXP LM75A is compatible with original LM75A while it has improved
>> > 11-bit precision.
>> >
>> > https://www.nxp.com/docs/en/data-sheet/LM75A.pdf
>> >
>> > Signed-off-by: Matwey V. Kornilov <matwey@....msu.ru <mailto:matwey@....msu.ru>>
>> > ---
>> > drivers/hwmon/lm75.c | 4 ++++
>> > 1 file changed, 4 insertions(+)
>> >
>> > diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
>> > index 3aa7f9454f57..37dc903ebf54 100644
>> > --- a/drivers/hwmon/lm75.c
>> > +++ b/drivers/hwmon/lm75.c
>> > @@ -699,6 +699,10 @@ static const struct of_device_id __maybe_unused lm75_of_match[] = {
>> > .compatible = "national,lm75b",
>> > .data = (void *)lm75b
>> > },
>> > + {
>> > + .compatible = "nxp,lm75a",
>> > + .data = (void *)lm75b
>>
>> This should get a different identifier (such as lm75a_nxp or whatever)
>> because otherwise the results would be different on non-devicetree
>> systems which would only match "lm75a".
>>
>
> Sorry, I don't understand it. Non-devicetree systems won't use this table at all.
>
... and instantiate the driver with "lm75a", ie differently than on a devicetree
system. Some purist could then complain that they have to instantiate the driver
as lm75b even though it is a lm75a to get the higher resolution.
Besides, I just noticed that the resolution for the limit registers for nxp's
version of LM75A is different than the resolution of the temperature register.
That means that you'll need a separate entry for this chip anyway,
one that specifies a .default_resolution of 11 and .resolution_limits of 9.
Making things worse, that also applies to NXP's version of LM75B. And
the resolution of TI's version of LM75B/C is 9 bit for both temperature
and limit registers, which does make me wonder where the 11 bit in the
driver comes from ... oh, yes, that was commit 799fc602143024 ("hwmon:
(lm75) Add support for the NXP LM75B"). The devicetree table was added later,
and with that the entry was wrongly attributed to National and not to NXP.
So in reality we'd really need a number of additional entries to
match sensor and limit resolutions correctly.
National/TI: Resolution is always 9 bit for LM95 and LM95A/B/C.
NXP: Resolution is 11 bit for temperature, 9 bit for limits for LM75A/B.
Oh, as it turns out the limit register resolution for NXP's PCT2075 is
also 9 bit. Sigh.
Guenter
>>
>> > + },
>> > {
>> > .compatible = "maxim,max6625",
>> > .data = (void *)max6625
>> >
>>
>> Both "nxp,lm75a" and "nxp,lm75b" need to be added to
>> Documentation/devicetree/bindings/hwmon/lm75.yaml (in a separate
>> patch with copy to dt maintainers for review).
>>
>> Guenter
>
>
>
> --
> With best regards,
> Matwey V. Kornilov
Powered by blists - more mailing lists