linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Agathe Porte <agathe.porte@nokia.com>, linux-hwmon@vger.kernel.org
Cc: Jean Delvare <jdelvare@suse.com>,
	Rob Herring <robh+dt@kernel.org>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Krzysztof Adamski <krzysztof.adamski@nokia.com>
Subject: Re: [PATCH v3 2/2] hwmon: Add driver for Texas Instruments TMP464 and TMP468
Date: Wed, 16 Feb 2022 07:12:19 -0800	[thread overview]
Message-ID: <130a9cbe-ee0c-1908-1d62-0f3c674ca648@roeck-us.net> (raw)
In-Reply-To: <2f7780b8-ce67-6cd6-4097-d8113f557444@nokia.com>

On 2/16/22 04:42, Agathe Porte wrote:
> 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@nokia.com>
>> Cc: Agathe Porte <agathe.porte@nokia.com>
>> Cc: Krzysztof Adamski <krzysztof.adamski@nokia.com>
>> Signed-off-by: Guenter Roeck <linux@roeck-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@4/tmp464@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
> 

I think that may be caused by using of_property_read_s32() for reading
an 8-bit property. Can you try and replace of_property_read_s32()
with of_property_read_u8() and the variable it points to to s8 ?

	s8 val;
	...
	err = of_property_read_u8(child, "ti,n-factor", &val);

There is no of_property_read_s8(), so we can not use that,
but maybe using of_property_read_u8() does the trick.

Thanks,
Guenter

> 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.
> 


      reply	other threads:[~2022-02-16 15:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-16  7:07 [PATCH v3 1/2] dt-bindings: hwmon: add tmp464.yaml Guenter Roeck
2022-02-16  7:07 ` [PATCH v3 2/2] hwmon: Add driver for Texas Instruments TMP464 and TMP468 Guenter Roeck
2022-02-16 12:42   ` Agathe Porte
2022-02-16 15:12     ` Guenter Roeck [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=130a9cbe-ee0c-1908-1d62-0f3c674ca648@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=agathe.porte@nokia.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jdelvare@suse.com \
    --cc=krzysztof.adamski@nokia.com \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).