From: Guenter Roeck <linux@roeck-us.net>
To: Oskar Senft <osk@google.com>
Cc: Krzysztof Adamski <krzysztof.adamski@nokia.com>,
Rob Herring <robh@kernel.org>, Jean Delvare <jdelvare@suse.com>,
Linux HWMON List <linux-hwmon@vger.kernel.org>,
devicetree@vger.kernel.org
Subject: Re: [PATCH 8/8] dt-bindings: hwmon: allow specifying channels for tmp421
Date: Sat, 25 Sep 2021 06:26:31 -0700 [thread overview]
Message-ID: <20210925132631.GB1240690@roeck-us.net> (raw)
In-Reply-To: <CABoTLcQYHZbsgzXN7XXKQdDn8S-YsuE+ks9WShAEKcBJojEfcQ@mail.gmail.com>
On Fri, Sep 24, 2021 at 11:37:00AM -0400, Oskar Senft wrote:
> > > In many cases the channels are "shared" - we have 3 voltage, 3 current and 3
> > > power sensors but in fact they are not separate sensors but 3 channels
> > > each able to measure 3 different things and they may share some common
> > > properties in each channel (so current, voltage and power may be
> > > calculated bases on the same shunt resistor or correction factor). An
> > > example being adi,ltc2992. In those cases it doesn't make sense to have
> > > two levels as how would you describe the shared parent? Call it generic
> > > "channels"?
>
> So in that case (e.g. for the nct7802, see [1]) do we want just
> 1-level, maybe like this:
>
> nct7802@28 {
> compatible = "nuvoton,nct7802";
> reg = <0x28>;
>
> sensor@1 { /* RTD1 */
> reg = <0x1>;
> status = "okay";
> mode = "thermistor"; /* Any of "thermistor", "thermal-diode",
> "voltage" */
> };
>
> sensor@2 { /* RTD2 */
> reg = <0x2>;
> status = "okay";
> mode = "thermal-diode"; /* Any of "thermistor",
> "thermal-diode", "voltage" */
> };
>
> sensor@3 { /* RTD3 */
> reg = <0x3>;
> status = "okay";
> mode = "voltage"; /* Any of "thermistor", "voltage" */
> };
>
> sensor@4 { /* LTD */
> reg = <0x4>; /* using the same number as in sysfs */
Numbering in sysfs is not relevant here; the index should always start with 0.
> status = "okay";
> /* No mode configuration for LTD */
> };
> };
>
> In this example, RTD1, RTD2 and LTD would be temperature sensors and
> RTD3 would be a voltage sensor.
>
> Would that make more sense? Is the use of strings acceptable?
>
I don't think so. I am quite sure that rtd3 is still a temperature,
and I am not sure if other sensor types on that chip may need dt
configuration.
I have limited internet acces for the next week or so; I'll look
into this further after I am back.
Guenter
> Thanks
> Oskar.
>
> [1] https://lore.kernel.org/all/20210921004627.2786132-1-osk@google.com/
next prev parent reply other threads:[~2021-09-25 13:26 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-07 13:41 [PATCH 0/8] Add per channel properies support in tmp421 Krzysztof Adamski
2021-09-07 13:42 ` [PATCH 1/8] dt-bindings: hwmon: add missing tmp421 binding Krzysztof Adamski
2021-09-20 22:21 ` Rob Herring
2021-09-07 13:42 ` [PATCH 2/8] hwmon: (tmp421) introduce MAX_CHANNELS define Krzysztof Adamski
2021-09-07 13:43 ` [PATCH 3/8] hwmon: (tmp421) introduce a channel struct Krzysztof Adamski
2021-09-07 13:43 ` [PATCH 4/8] hwmon: (tmp421) add support for defining labels from DT Krzysztof Adamski
2021-09-07 15:46 ` Guenter Roeck
2021-09-07 17:49 ` Krzysztof Adamski
2021-09-07 17:55 ` Guenter Roeck
2021-09-07 18:08 ` Krzysztof Adamski
2021-09-07 18:28 ` kernel test robot
2021-09-07 18:28 ` kernel test robot
2021-09-09 17:29 ` kernel test robot
2021-09-09 17:29 ` kernel test robot
2021-09-09 17:29 ` [RFC PATCH] hwmon: tmp421_probe_child_from_dt() can be static kernel test robot
2021-09-09 17:29 ` kernel test robot
2021-09-07 13:43 ` [PATCH 5/8] hwmon: (tmp421) support disabling channels from DT Krzysztof Adamski
2021-09-07 15:33 ` Guenter Roeck
2021-09-07 13:45 ` [PATCH 6/8] hwmon: (tmp421) support specifying n-factor via DT Krzysztof Adamski
2021-09-07 15:42 ` Guenter Roeck
2021-09-07 13:46 ` [PATCH 7/8] hwmon: (tmp421) really disable channels Krzysztof Adamski
2021-09-07 15:37 ` Guenter Roeck
2021-09-07 19:52 ` kernel test robot
2021-09-07 19:52 ` kernel test robot
2021-09-09 20:40 ` kernel test robot
2021-09-09 20:40 ` kernel test robot
2021-09-09 20:40 ` [RFC PATCH] hwmon: tmp421_disable_channels() can be static kernel test robot
2021-09-09 20:40 ` kernel test robot
2021-09-07 13:46 ` [PATCH 8/8] dt-bindings: hwmon: allow specifying channels for tmp421 Krzysztof Adamski
2021-09-07 15:46 ` Guenter Roeck
2021-09-07 18:04 ` Krzysztof Adamski
2021-09-20 22:24 ` Rob Herring
2021-09-21 12:58 ` Guenter Roeck
2021-09-21 19:06 ` Rob Herring
2021-09-21 20:52 ` Guenter Roeck
2021-09-21 21:21 ` Oskar Senft
2021-09-21 22:03 ` Oskar Senft
2021-09-23 15:30 ` Rob Herring
2021-09-24 0:29 ` Guenter Roeck
2021-09-24 7:53 ` Krzysztof Adamski
2021-09-24 11:46 ` Guenter Roeck
2021-09-24 15:37 ` Oskar Senft
2021-09-25 13:26 ` Guenter Roeck [this message]
2021-10-08 12:55 ` Oskar Senft
2021-10-08 13:11 ` Guenter Roeck
2021-09-22 7:22 ` Krzysztof Adamski
2021-09-22 12:39 ` Guenter Roeck
2021-09-22 18:32 ` Krzysztof Adamski
2021-09-23 0:38 ` Guenter Roeck
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=20210925132631.GB1240690@roeck-us.net \
--to=linux@roeck-us.net \
--cc=devicetree@vger.kernel.org \
--cc=jdelvare@suse.com \
--cc=krzysztof.adamski@nokia.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=osk@google.com \
--cc=robh@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.