linux-kernel - Re: [PATCH v3 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]

Message-ID: <CABoTLcSMDPQvhgmUL5aE_df++pg4qN+cmf=31J9WPVnKnT6k7g@mail.gmail.com>
Date:   Sat, 9 Oct 2021 07:57:17 -0400
From:   Oskar Senft <osk@...gle.com>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Jean Delvare <jdelvare@...e.com>, Rob Herring <robh+dt@...nel.org>,
        linux-hwmon@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH v3 1/2] dt-bindings: hwmon: Add nct7802 bindings

Hi everyone

> > Document bindings for the Nuvoton NCT7802Y driver.
> >
> > Signed-off-by: Oskar Senft <osk@...gle.com>
>
> Please pdon't expect from reviewers to figure out what changed
> between versions and provide change logs.
Uh, I'm sorry, I'm new to the Linux upstreaming game. I'm used to
using code review tools like Gerrit, which help with that.

Changes from "PATCH v2 1/2" to "PATCH v4 1/2" (v3 was sent with a
typo, so please ignore v3):
- Removed extra layer "temperature-sensors" as discussed.
- Renamed "sensor" to "input" as discussed.
- Renamed "mode" to "sensor-type" to indicate temperature or voltage.
- Added "temperature-mode" to indicate "thermistor" or "thermal-diode".
- Removed description attributes from "sensor-type" and didn't add for
"temperature-mode", since they would have just repeated the names of
the properties.
- Numbered sensors 0 (LTD) and 1..3 (RTD1..3).

Some notes:
- While 1..3 are "natural numberings", there's no equivalent for "0"
in the datasheet - the name "0" is arbitrary. An alternative would be
to name this sensor "ltd" instead of "input", since it's not
configurable (beyond disabling it).
- I wasn't sure what the correct way is to enforce a match from
"input@X" to "reg = <X>", so I listed the inputs individually.
Technically RTD1 and RTD2 could be done as "patternProperties", if we
could enforce the match between @X and reg.

I hope I included all the various comments and discussion points both
from PATCH v2 and from the "tmp421" thread [1]. Please let me know if
I missed anything.

Does this proposal match the general thinking and goals for
dt-bindings for hwmon devices?

Thanks
Oskar.

[1] https://lore.kernel.org/linux-hwmon/20210924114636.GB2694238@roeck-us.net/