linux-kernel - Re: [PATCH v3 2/2] hwmon: Add driver for Texas Instruments TMP464 and TMP468

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 16 Feb 2022 13:42:00 +0100
From:   Agathe Porte <agathe.porte@...ia.com>
To:     Guenter Roeck <linux@...ck-us.net>, linux-hwmon@...r.kernel.org
Cc:     Jean Delvare <jdelvare@...e.com>, Rob Herring <robh+dt@...nel.org>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Krzysztof Adamski <krzysztof.adamski@...ia.com>
Subject: Re: [PATCH v3 2/2] hwmon: Add driver for Texas Instruments TMP464 and
 TMP468

Hi Guenter,

Le 16/02/2022 à 08:07, Guenter Roeck a écrit :
> Add support for Texas Instruments TMP464 and TMP468 temperature sensor
> ICs.
>
> TI's TMP464 is an I2C temperature sensor chip. This chip is
> similar to TI's TMP421 chip, but with 16bit-wide registers (instead
> of 8bit-wide registers). The chip has one local sensor and four
> remote sensors. TMP468 is similar to TMP464 but has one local and
> eight remote sensors.
>
> Originally-from: Agathe Porte <agathe.porte@...ia.com>
> Cc: Agathe Porte <agathe.porte@...ia.com>
> Cc: Krzysztof Adamski <krzysztof.adamski@...ia.com>
> Signed-off-by: Guenter Roeck <linux@...ck-us.net>
> ---
> v3:
> - Added support for TMP468
> - Added support for various limits, temperature hysteresis, alarm attributes,
>    and update interval
> - Use regmap instead of local caching
> - Use static chip configuration
> - Unlock check if needed when loading driver, and lock it when unloading it
>    - Call tmp464_init_client() before calling tmp464_probe_from_dt()
>      since the latter changes registers, which requires the chip to be
>      unlocked.
> - Restore configuration register when unloading driver
> - ti,n-factor is optional, so don't fail if the property is not present
>
> Notes:
> - Tested with real TMP468. Module tested for TMP464.
> - I was not able to test with a system supporting devicetree;
>    especially negative values for "ti,n-factor" need testing
>    (and I wonder if of_property_read_s8() would be needed to
>     support this properly).

I just did the test on our system and both positive and negative value 
n-factor fails.

With the following overlay:

/dts-v1/;
/plugin/;
/ {
         fragment@0 {
                 target-path = "/soc/.../i2c@...mp464@49";
                 __overlay__ {
                         #address-cells = <1>;
                         #size-cells = <0>;

                         channel@0 {
                                 reg = <0x0>;
                                 label = "local";
                                 ti,n-factor = /bits/ 8 <(-10)>;
                         };

                         channel@1 {
                                 reg = <0x1>;
                                 label = "ch1";
                         };

                         channel@2 {
                                 reg = <0x2>;
                                 label = "ch2";
                         };

                         channel@3 {
                                 reg = <0x3>;
                                 label = "ch3";
                         };

                         channel@4 {
                                 reg = <0x4>;
                                 label = "ch4";
                         };
                 };
         };

};

I get the following probing error:

[ 3580.557425] tmp464: probe of 16-0049 failed with error -75

With a positive n-factor in the overlay (<(10)> instead of <(-10)>), the 
driver *does not load either*, with the same error message.

Without any n-factor set, the v3 driver you proposed loads just fine 
with the DT.

Any idea of where this could come from? This was probably not working in 
my own implementation either.

PS: check your spam folder eventually for my mail asking delivery 
details of the TMP464 samples.

Bests,

Agathe.