Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Sender: Guenter Roeck <groeck7@gmail.com>
Subject: Re: [PATCH] dt-bindings: hwmon: Add nct7802 bindings
To:     Oskar Senft <osk@google.com>
Cc:     linux-hwmon@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org, Jean Delvare <jdelvare@suse.com>,
        Rob Herring <robh+dt@kernel.org>
References: <20210910130337.2025426-1-osk@google.com>
 <71c17c47-ca9e-e9d2-7b89-cc25b512c06a@roeck-us.net>
 <CABoTLcRZ43EUVzbqWniu64PkB7Yx4RMYKjaBxaSihk+k0Ca-gA@mail.gmail.com>
 <722b27f6-4390-9b5b-f6f2-75ce9e967d12@roeck-us.net>
 <CABoTLcSdkmuBxd5Yh6z2Oqm1-_Vd4J5Ni1i1qq5s07mWu7Ndew@mail.gmail.com>
 <20210914150859.GB3457579@roeck-us.net>
 <CABoTLcQfS5-UL92NR9vbc2YrGJv3oQPYCqAm-diNoq-tkHP_hQ@mail.gmail.com>
 <c410eba9-f6cf-4dbf-797f-48afde9c1898@roeck-us.net>
 <CABoTLcQWXerMWPvWUqjykiNcx9oGoP8aEcuDwcQ36yu-CBc0pA@mail.gmail.com>
From:   Guenter Roeck <linux@roeck-us.net>
Message-ID: <382858f5-e833-d4b9-f189-449671992ba5@roeck-us.net>
Date:   Thu, 16 Sep 2021 12:34:57 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <CABoTLcQWXerMWPvWUqjykiNcx9oGoP8aEcuDwcQ36yu-CBc0pA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 9/16/21 12:19 PM, Oskar Senft wrote:
>      Hi Guenter
> 
>>> Would it be acceptable to simply number the sensors and document which
>>> sensor has which number?
>>>
>>> Something like this:
>>> 0 = LTD
>>> 1 = RTD1
>>> ...
>>>
>> That might be a possibility, though it would have to be well defined
>> for each chip (nct7802 also has voltage sensors). We'll have to discuss
>> this with Rob.
>>
>> Personally I think I would prefer using a type qualifier - that seems
>> cleaner. But that is really a matter of opinion.
> 
> Another existing way I found is in ltc2978. Following that, we could
> do it as follows:
> 
> i2c {
>      #address-cells = <1>;
>      #size-cells = <0>;
> 
>      nct7802@28 {
>          compatible = "nuvoton,nct7802";
>          reg = <0x28>;
>          #address-cells = <1>;
>          #size-cells = <0>;
> 
>          sensors {
>              ltd {
>                  status = "okay";
>                  label = "my local temperature";
>              };
> 
>              rtd1 {
>                  status = "okay";
>                  mode = <0x2>; /* 3904 transistor */
>                  label = "other temperature";
>              };
> 
>              rtd3 {
>                  status = "okay";
>                  mode = <0x3>; /* thermal diode */
>                  label = "3rd temperature";
>             };
>          };
>      };
> };
> 

Ah, using the node name as indication for both sensor type and
index ? SGTM, though we'd really need input from Rob.
I guess one could also consider something more generic like
"temperature-sensor@0", "voltage-sensor@0", and so on (instead
of [mis-]using reg and a sensor-type field).

Thanks,
Guenter

> 
>>> The NCT7802Y can self-program from an EEPROM, so I assume we should
>>> honor the "power-up configuration" obtained from there? I.e. if no
>>> configuration is provided in the device tree, the driver should use
>>> whatever configuration the chip has when the driver is loaded.
>>>
>> Definitely yes. My question was more what to do if the information
>> in devicetree nodes is incomplete.
> I think there are two cases:
> 1) If the new "sensor" tree is missing, the driver should behave as it
> does today to not break existing users.
> 2) If the new "sensor" tree is present, then each of the sensors that
> should be disabled needs to have "status = 'okay'" and have the mode
> set (unless it's LTD). In the above example, rtd2 is missing and would
> therefore be considered disabled.
> 
> Does that make sense? I still need to find out whether this is
> actually valid DT and how to express that in the YAML, though ...
> 
> Thanks
> Oskar.
>