devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Adamski <krzysztof.adamski@nokia.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Rob Herring <robh@kernel.org>, Jean Delvare <jdelvare@suse.com>,
	Linux HWMON List <linux-hwmon@vger.kernel.org>,
	devicetree@vger.kernel.org, Oskar Senft <osk@google.com>
Subject: Re: [PATCH 8/8] dt-bindings: hwmon: allow specifying channels for tmp421
Date: Fri, 24 Sep 2021 09:53:16 +0200	[thread overview]
Message-ID: <YU2D7L7QMgCJZUeb@localhost.localdomain> (raw)
In-Reply-To: <20210924002951.GA3027924@roeck-us.net>

Dnia Thu, Sep 23, 2021 at 05:29:51PM -0700, Guenter Roeck napisał(a):
>> If each kind of sensor is a different number space (e.g. 0-2), then
>> how you have it with 2 levels of nodes is appropriate. If you only
>> have one set of channel or input numbers, then they should all have
>> the same parent node. So is it current sensors 0,1,2 and temperature
>> sensors 0,1,2, or just input channels 0,1,2,3,4,5?
>>
>
>Each sensor type has its own number space.
>

But many sensors will have only one type of channels - like several
temperature sensors and nothing else. Like several temperature channels
on a temperature sensor, or several fans on a fan controller.

In such cases, we already define them with 1-level structure, like:
- npcm750-pwm-fan
- aspeed-pwm-tacho
- ina3221

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 maybe it makes sense to have 2 levels for complex devices that can
measure several independent entities or for devices which do not have a
clear concept of enumerated "channels" or "inputs", but we could skip it
for most others? After all, what is the benefit of having this
additional level if all we have is something like:

temperature-sensors {
     temperature1 {
	};

	temperature2 {
	};

	temperature3 {
	};
};

For most devices having an "index" or "reg" makes much more sense so:
temperature@1, or channel@1 feels like a more natural way to describe
them.

In any case, I'm quite confused right now on what would be the
conclusion of this discussion. How would you like the DT for TMP421 to
look like, after all?

As a side note, should the description of the tmp421 bindings be in
tmp421.yaml file (as it is in current patchset), or should it be
actually called "ti,tmp421.yaml"?

Krzysztof

  reply	other threads:[~2021-09-24  7:54 UTC|newest]

Thread overview: 43+ 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-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-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-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-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 [this message]
2021-09-24 11:46                 ` Guenter Roeck
2021-09-24 15:37                   ` Oskar Senft
2021-09-25 13:26                     ` Guenter Roeck
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=YU2D7L7QMgCJZUeb@localhost.localdomain \
    --to=krzysztof.adamski@nokia.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jdelvare@suse.com \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).