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

[Stan, Liviu]

Thank you for the comments, and I apologize for the late reply.

On Mon, Apr 28, 2026,  Nuno Sá wrote:
...
> > Both sensor types expose an IIO_RESISTANCE channel reading from
> > the resistance result register bank (0x060-0x00AF), added to
> > the regmap readable ranges. Scales are 1/1,024,000 for copper
> > trace (result in mOhm) and 1/1024 for leak detector (result
> > in Ohm).
> 
> But for userspace we report both in Ohm? That's the ABI AFAICT. In DT,
> you also mention IIO_TEMP is used:
> "IIO_TEMP reports coverage percentage"
> 
> Can you expand more on what the above means? Are we reporting milli
> degrees celcius to userspace?

Yes, both IIO_RESISTANCE channels report in Ω. The commit message was 
misleading, it described the register's native units (mΩ for copper trace,
Ω for leak detector), not the userspace output. The scales are chosen to 
cancel those units and give Ω in both cases.

As for the IIO_TEMP question, the chip's custom sensor table stores 
temperature in Kelvin (same as the LTC2984 custom RTD table). For the 
leak detector, coverage data is encoded as (P + 273.15) K, so when the 
chip converts Kelvin to Celsius on output, after the driver applies the 
1000/1024 scale, the IIO output is P * 1000 millidegrees C - 0% reads
as ~0 millidegrees, 100% reads as ~100000 millidegrees. But yes, the 
actual useable quantity is coverage percentage, not temperature. Is there
a more suitable existing IIO channel type for coverage percentage?

> I could not find the datasheet so I guess it's not yet public?

Correct, it is not public yet. Will upload the URL once it is.

...

> >  struct ltc2983_data {
> > @@ -272,6 +275,7 @@ struct ltc2983_rtd {
> >  	u32 r_sense_chan;
> >  	u32 excitation_current;
> >  	u32 rtd_curve;
> > +	bool sub_ohm;
> >  };
> >
> >  struct ltc2983_thermistor {
> > @@ -575,6 +579,10 @@ static int ltc2983_rtd_assign_chan(struct
> ltc2983_data *st,
> >  		if (ret)
> >  			return ret;
> >  	}
> > +
> > +	if (rtd->sub_ohm)
> > +		chan_val &= ~GENMASK(17, 0);
> > +
> >  	return __ltc2983_chan_assign_common(st, sensor, chan_val);
> >  }
> 
> I'm not sure if we shouldn't just treat the new types as new sensors
> instead of trying to push them in the existing one. I agree with Andy,
> the patch does not look great with respect to if() else() and going to
> deep in indentation.
> 
> >
> > @@ -758,83 +766,113 @@ ltc2983_rtd_new(const struct fwnode_handle
> *child, struct ltc2983_data *st,
> >  		return dev_err_ptr_probe(dev, ret,
> >  					 "Property reg must be given\n");
> >
> > -	ret = fwnode_property_read_u32(child, "adi,number-of-wires",
> &n_wires);
> > -	if (!ret) {
> > -		switch (n_wires) {
> > -		case 2:
> > -			rtd->sensor_config = LTC2983_RTD_N_WIRES(0);
> > -			break;
> > -		case 3:
> > -			rtd->sensor_config = LTC2983_RTD_N_WIRES(1);
> > -			break;
> > -		case 4:
> > -			rtd->sensor_config = LTC2983_RTD_N_WIRES(2);
> > -			break;
> > -		case 5:
> > -			/* 4 wires, Kelvin Rsense */
> > -			rtd->sensor_config = LTC2983_RTD_N_WIRES(3);
> > -			break;
> > -		default:
> > +	/* ADT7604 requires hardcoding sensor configuration bits to 0b1001
> */
> > +	if (st->info->has_copper_trace &&
> > +	    sensor->type == LTC2983_SENSOR_RTD_CUSTOM) {
> > +		rtd->sensor_config = 0x9;
> > +		if (sensor->chan < LTC2983_DIFFERENTIAL_CHAN_MIN)
> 
> Like the above, we have the following kind of condition all over the
> place. In DT we can just have a different type for these and map it to
> real value when creating the sensor.

I understand, I will introduce new adi,sensor-type enum values for 
copper trace and leak detector. The driver will map these to the 
hardware register values (18 and 27) and handle them in dedicated 
switch cases with dedicated functions (ltc2983_copper_trace_new() 
and ltc2983_leak_detector_new()), removing the has_copper_trace guards
from ltc2983_rtd_new() and ltc2983_thermistor_new() entirely. One 
tradeoff is that the adi,sensor-type values for the new sensors will 
now not coincide with the hardware register values in the ADT7604 
datasheet.

...

I will address the rest of the comments in v2 as part of the restructuring.
Thank you very much.

Liviu