Re: [PATCH 2/2] iio: temperature: ltc2983: Add support for ADT7604

[Jonathan Cameron]

On Tue, 12 May 2026 12:26:02 +0000
"Stan, Liviu" <Liviu.Stan@xxxxxxxxxx> wrote:

> On Tue, May 12, 2026, Nuno Sá wrote:
> > > > What I'm not too convinced is that coverage is relative to what? Well
> > > > it's a percentage so I guess we could not care and leave interpretation to
> > > > userspace (to know which device is dealing with). Still I wonder if a
> > > > new iio_chan_info wouldn't be more appropriate? In this case applied to
> > > > iio_resistance. So something like:
> > > >
> > > > in_resistance_coverage_ratio
> > > >
> > > > So it's clear what physical quantity coverage ratio is affecting.  
> > >
> > > I still think a new channel type is the right approach. Consider copper
> > > trace sensors - they also support a custom table, and when one is
> > > provided the chip outputs both a resistance result and a temperature
> > > result (the interpolation output), each in their own register bank. The
> > > current approach handles that with separate IIO_RESISTANCE and
> > > IIO_TEMP channels. So, for consistency, if we use a chan_info
> > > attribute for the leak detector coverage output, we would need to do
> > > the same for the copper trace temperature output. Since IIO_TEMP
> > > makes sense for the interpolation result for copper traces and
> > > because it is a distinct physical quantity output by the chip, I think it
> > > would make the most sense that leak detectors follow the same
> > > pattern and create a separate IIO channel.
> > >
> > > What do you think?
> > >  
> > 
> > Yeah, makes sense. Jonathan already put it very nicely for the distinct
> > channel case.  
> 
> Sorry, I saw the last two messages only after I sent my reply.
> 
> On Tue, May 12, 2026, Jonathan Cameron wrote:
> > > I do wonder if a complete type is what we want? How will we present it?
> > > 
> > > in_coverage_ratio?
> > > 
> > > What I'm not too convinced is that coverage is relative to what? Well
> > > it's a percentage so I guess we could not care and leave interpretation to
> > > userspace (to know which device is dealing with). Still I wonder if a
> > > new iio_chan_info wouldn't be more appropriate? In this case applied to
> > > iio_resistance. So something like:
> > > 
> > > in_resistance_coverage_ratio  
> > 
> > I'm perhaps missing something - as far as I understand it there is no meaningful
> > connection to resistance in what is being measured.
> > I think what you are proposing is similar to measuring current via voltage
> > drop over a sense resistor. We don't present that as modified voltage, we
> > present it as current.
> >
> > Here the thing being measured is coverage rather than resistance
> > so keeping resistance in there is confusing for the user.
> >
> > If we wanted a type to modify then we could do this as a modified area measurement.
> > Channel type IIO_AREA (which is new) and modifier IIO_MOD_RATIO (also new).  
> 
> On the implementation: you originally suggested IIO_COVERAGE_PERCENT,
> which would give in_coveragepercent0_raw in sysfs. The IIO_AREA + IIO_MOD_RATIO
> alternative would give in_area0_ratio_raw, which is more generic but less
> immediately obvious for a leak detector. Do you have a preference 
> between the two?

I wonder what other reasonable area sensors we'll get in future?
Maybe more specific is better here - like humidityrelative (we've never had
an absolute humidity sensor because they are really hard to build!)

Jonathan
> 
> Thanks,
> Liviu
>