Re: [PATCH 1/2] dt-bindings: iio: temperature: Add ADT7604 support to adi,ltc2983

[Jonathan Cameron <jic23@kernel.org>]

On Wed, 6 May 2026 14:52:04 +0000
"Stan, Liviu" <Liviu.Stan@analog.com> wrote:

> Thanks for the comments, here are my answers:
> 
> On 28 Apr 2026, Jonathan Cameron wrote:
> > I don't know much about these temp sensors, but how is this different
> > in practice from a 2-wire RTD?  Obviously one is copper and the other
> > probably much more precise platinum but does that matter to us?  
> 
> The main practical differences are:
> 
> - The primary output is IIO_RESISTANCE, read from the resistance result
>    bank (0x0060-0x00AF). This bank is marked as reserved for the other 
>    devices

That bit we can bury in the driver.

> - Sensor configuration bits 21:18 are hardcoded to 0b1001 for all
>    copper trace configurations. For the sub-ohm variant, bits 17:0 are 
>    also zeroed; a >1Ω trace will have the excitation current and an 
>    optional custom table in those bits. For the existing custom RTD and
>    thermistor types, the custom table is required by the binding. For
>    copper trace, it is optional (and forbidden for the sub-ohm variant).
>    And for leak detector as well it is optional.

So working around this would require some constraints in the binding
triggered off the compatible - but doable I think.

> - When a custom table is present, a second IIO_TEMP channel also
>    appears, reading from the temperature bank. Same dual-output
>    behavior for leak detector.

This feels like a driver detail rather than a binding one.

> 
> That said, the hardware uses the same custom RTD mode (sensor
> type 18) internally.
> 
> > I'd go with "LTC2983 and similar" for the title now as it's
> > to long. Leave the description to list amount more info.
> >
> > Alphabetical order and it might be worth thinking about switching this
> > to a bulleted list with one device per line as it'll make adding new ones
> > neater. (obviously they are already not in numeric order, so fix that too ;)  
> 
> Will do.
> 
> > Is the absences of them enough to indicate this mode?  I.e. are there other
> > modes
> > with no specified excitation mode or custom rtd table?
> > 
> > I'm trying to work out if we can map this to the existing binding for
> > custom rtd just be adding more constraints + making existing ones more
> > specific.
> > 
> > I don't mind if we can't and have to add a new child node definition but
> > I'm not yet sure that's the case.  
> 
> You're right that the absence of both properties could imply sub-ohm mode, 
> so I think we could drop the boolean. But the issue with reusing rtd@ is that 
> adi,custom-rtd is currently required for sensor-type 18, and several 
> RTD-specific properties (adi,number-of-wires, adi,rtd-curve,
> adi,rsense-share) have no meaning for copper trace and would need to be 
> forbidden (they could also be ignored in the driver). In my opinion, separate 
> nodes for both copper trace and leak detectors would make sense, but I'm 
> happy to go whichever way you prefer.

Ok. Sounds like we could do either but the different node type is cleaner.
So fair enough - go with that if the DT maintainers are happy with it.
Just make sure to lay out some of this reasoning in the commit message.
> 
> > I'd avoid describing things as xx only as that tends to become wrong fast!
> > Better to put that as a conditional only (as you have below)
> > Maybe here you can say, (some parts only) or something like that.  
> 
> Will switch to "some parts only". 
> 
> Thanks,
> Liviu