linux-kernel - Re: [PATCH v2 1/2] dt-bindings: hwmon: Add nct7802 bindings

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] [day] [month] [year] [list]

Date:   Fri, 8 Oct 2021 06:25:24 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Oskar Senft <osk@...gle.com>
Cc:     Rob Herring <robh@...nel.org>, Jean Delvare <jdelvare@...e.com>,
        Linux HWMON List <linux-hwmon@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        devicetree@...r.kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: hwmon: Add nct7802 bindings

On Fri, Oct 08, 2021 at 09:07:47AM -0400, Oskar Senft wrote:
> Hi Rob
> 
> > > > > +            temperature-sensors {
> > > > > +                ltd {
> > > > > +                  status = "disabled";
> > > >
> > > > Don't show status in examples.
> > > Hmm, ok. I found it useful to make clear that a sensor can be
> > > disabled, but maybe that's just always the case?
> >
> > Yeah, this case is a bit special. The node not being present also disables it.
> Oh, I didn't realize that a missing node defaults to "disabled". What
> I want to achieve is that if a node is not present, we don't configure
> it. The reason behind this is that the HW provides a mechanism to
> configure itself at power-up from a connected EEPROM. In that case
> we'd still want the list the nct7802 in the DTS, but without
> configuration. This effectively is the current behavior.
> 
> From what I understand from [1] and follow-ups, having the extra
> "temperature-sensors" level is actually not what we want here and I
> proposed a different solution in [2].
> 

Turns out this chip has another level of complexity, where a channel
can either be a temperature sensor or a voltage sensor. So, from dt
perspective, we don't have separate scoped for the different sensor
types.

I don't really like [2] to indicate voltage vs. temperature using "mode"
(it maps both sensor more and type into a single property),
but I agree that two levels doesn't really make sense here either.
That is where child naming may come in. We have "sensor" in your proposal,
and "input" in the tmp421 proposal. My thought on that was that we could
use the child name to distinguish sensor types.

    temperature-sensor@1 { /* RTD1 */
         reg = <0x1>;
         status = "okay";
         mode = "thermistor"; /* Any of "thermistor", "thermal-diode" */
    };

    voltage-sensor@3 { /* RTD3 */
         reg = <0x3>;
         status = "okay";
    };

or maybe

    sensor@1 { /* RTD1 */
         reg = <0x1>;
         status = "okay";
	 type = "temperature-sensor";
         mode = "thermistor"; /* Any of "thermistor", "thermal-diode" */
    };

    sensor@3 { /* RTD3 */
         reg = <0x3>;
         status = "okay";
	 type = "voltage-sensor";
    };

> On that background, I'm wondering how we could have compatibility with
> the previous behavior, where the individual sensors were not listed,
> and just defaulted to whatever the HW came up with, whether that was
> power-on defaults or loaded from an EEPROM.
> 
> What the code currently does is to check for the presence of
> "temperature-sensors" and only attempt to configure any of them if
> that top level node exists. This enables backwards-compatibility.
> Going forward, I would have done the same for sensor@X and only
> explicitly enable / disable the sensor if the node is present. If it's
> not present, I'd use the power-on / EEPROM-provided defaults.
> 

Makes sense to me.

Guenter

> Thanks
> Oskar.
> 
> [1] https://lore.kernel.org/linux-hwmon/20210924114636.GB2694238@roeck-us.net/
> [2] https://lore.kernel.org/linux-hwmon/CABoTLcQYHZbsgzXN7XXKQdDn8S-YsuE+ks9WShAEKcBJojEfcQ@mail.gmail.com/