On Fri, Sep 24, 2021 at 09:53:16AM +0200, Krzysztof Adamski wrote:

Dnia Thu, Sep 23, 2021 at 05:29:51PM -0700, Guenter Roeck napisał(a):

quoted

quoted

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 {
	};
};

I see your point. I think it would make sense to only use the two-level
approach for devices with more than one type of sensors.

Thanks,
Guenter

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