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

["Nuno Sá" <noname.nuno@gmail.com>]

On Thu, May 07, 2026 at 05:25:58PM +0000, Stan, Liviu wrote:
> 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.
> 

ack

> 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?
> 

Will defer this to Jonathan but if we can have a real of the coverage
given the temperature, I guess this is ok. Given that I think we don't have
a better channel (unless we add one?) for this. Or just extended_info...


> > 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.

Yes, I was aware of that but I think (I could be wrong) that the
simplifications it will bring will justify for the small "fixup" we'll
need to do on the driver.

- Nuno Sá
> 
> ...
> 
> I will address the rest of the comments in v2 as part of the restructuring.
> Thank you very much.
> 
> Liviu