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

Message-ID: <20210925133658.GA1740158@roeck-us.net>
Date:   Sat, 25 Sep 2021 06:36:58 -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@...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, Sep 24, 2021 at 11:17:51AM -0400, Oskar Senft wrote:
> Hi Rob
> 
> > > +maintainers:
> > > +  - Guenter Roeck <linux@...ck-us.net>
> >
> > Should be someone that cares about this h/w, not who applies patches.
> 
> Hmm, ok. After talking with Guenter, I thought that would be him. But
> I can add myself, too, since we're obviously using that HW. Is that
> what you mean?

FWIW, this happens to be one of the cases where I am also the driver 
author, and I still have a test board with the chip.

Guenter

> 
> > > +    properties:
> > > +      ltd:
> > > +        type: object
> > > +        description: Internal Temperature Sensor ("LTD")
> >
> > No child properties?
> 
> Yes. We really just want the ability to enable / disable that sensor.
> What's the correct way in the YAML to describe that? Same for RTD3.
> 
> > > +          "type":
> > > +            description: Sensor type (3=thermal diode, 4=thermistor).
> >
> > 2nd time I've seen this property this week[1]. Needs to be more specific
> > than just 'type'.
> 
> Ha yes, the example in [1] came from this patch. I went with this name
> to stay in-line with the sysfs name, being "tempX_type". In the
> hardware this would be called "mode".
> 
> My original proposal [2] was to have this property a string list named
> "nuvoton,rtd-modes" with a set of accepted values, i.e. basically an
> enum. Splitting this string list into individual sensors makes sense.
> 
> The other question that remains open (at least in my view), is whether
> naming the sensors "ltd, rtd1, rtd2, rtd3" is the right approach or if
> we should really go to naming them "sensor@X" with a reg property set
> to X. Note that ltd and rtd3 do not accept any additional
> configuration beyond "is enabled" (i.e. "status").
> 
> > > +            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?
> 
> I appreciate your other comments and will fix them in the next version
> of the patch. But I'd like to get clarity wrt. recommended sensor and
> property naming in the device tree before sending that.
> 
> Thoughts?
> 
> Thanks
> Oskar.
> 
> > [1] https://lore.kernel.org/all/CAL_Jsq+NXuF+F7OE3vyEbTUj6sxyMHVWHXbCuPPoFaKjpyZREQ@mail.gmail.com/
> [2] https://lore.kernel.org/all/20210910130337.2025426-1-osk@google.com/