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):
> > > 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
