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

[Stan, Liviu]

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?

Thanks,
Liviu