From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1BEC33624A8 for ; Fri, 8 May 2026 09:18:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778231905; cv=none; b=WzqOc87TN53HBUYPNxWtFS+d3fe9/SN34eq7Dy8Q/0yId5Jkrybf2atV6+7mRoxR8pY1aG+LPxydodMGnHCQhQG3jBQwfkbqwT5fenkAMjaDonYr+T1IV6sYgJdDP6XhElorJ3AdmiIbR81H8VnG2Z3//LI6ZEChFuBjyN1oyLk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778231905; c=relaxed/simple; bh=x87VvY9k09CMD6ZDoAc6MgD8HfCyyOZtXGs0mQHknbs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=HLBkYC8qV8+MnLSdd0e+kGzflKDhjM2Qkb2WVpFe0F8jBxI9wPVh+E/68xGeFXRUbbAeEuN7Vro7x4JpuI7wdHFDpY6QvLfBcoKaiP9b/y5d2h0kF4z92IwSTt3MxIkoTssqbYXlLNAZf6Osg0989851035PLkrilu6+UOcTp9w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=OeYIyQgW; arc=none smtp.client-ip=209.85.221.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="OeYIyQgW" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-44a5174670eso1081866f8f.1 for ; Fri, 08 May 2026 02:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778231902; x=1778836702; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=ku/ICma2gxDE2kcR48qisRKKRusKewtK808/1tsRoR8=; b=OeYIyQgWI020jpfSKEuD1phpdmINy0V8DiSQUJzfZtNjOFFq7/ZyTZ/17Mg1NwnLFt deId3MoO2FPEzJLEgLYziJX2rhNP/8iH4PoOfXvDv9jo7FzRFrrDHV1HbkkKaHLTnQ25 HkeMsQEqrtw7ZgUyOEiVdFoDGKKp/jHWN2dov3vIStagvvCMrtJV3z9cl64wO2R3xbwU Y0cKuC9CQPrnUtBZEuryKcukh/8NLRQkTRv66msUJa3VWkbBBUZRd8oKgR1m1pSJsu9p FDO2u42MhLZi62jh557xAgJv1SqobCbbj/0OJoAzm95+0plG8BZWFrHzcLZAxvrlSOOj TE7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778231902; x=1778836702; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ku/ICma2gxDE2kcR48qisRKKRusKewtK808/1tsRoR8=; b=VDcHAYqZ5fuVNbAtWb4Jj6fNTwN3K+eaW0Sny86M4a7u4BWc+Y9x0QdO7vec3F/CxC zAgZuyeh80Ypy/v0O+3VLYl/JJdrgK37XwB/4eElVigFaCU9DNzZQvaG2JYq+PFDFwzZ EMYoetrTpvA9xJEume30qV0zHY+rcIwt0TimlrFvBmWRFZ+JJG32b/nfPiPX7SFeIm9X vIqlrG9HIKoIS7g100caR9L2hvSYhtsM+3OUwQs43eJ98OXLecf/4lgEURRLibimp+dT JaHbcutWoCxG4YHP/tDk8N+7cM+jxcv3tiBeRAR4vL2pP9VZOJEs2pVKQDlCSdKXK7Yz juOQ== X-Forwarded-Encrypted: i=1; AFNElJ/N2xjuyXq2xtTmNwYWJz/8tQmda7I4oqYSqlO2QLsXomBFqDnyMOCEV0H+MAfKprugNAE/yTgrAhO3ztk=@vger.kernel.org X-Gm-Message-State: AOJu0Yxf8XnaDFygpOCiDzuIwJz1Zkx+ErXb2eKY7lIY6+EMtA0ViLz9 r6g5Whwkbm3jI9GbddUbKaVmqLzEgVMebmS+gU9FOrBBy91VngRbL6pG X-Gm-Gg: Acq92OHuNW3ERYhmcu3RAWuhcg/h2+WtbzPRT9r2QtgGh8B5ajTepO6AgWjVX4b81PQ GwQrkNRLBlcdedkgLlJE9PPQWwMwASiJwVLMCWpjfbf+ecopSTXHRbOztmmIUdRKm76jZsTIXOZ RXBrJOtM1blN+y0pnaiKwCUxhmKAfW1MsGdDT3+6x7rd7EmamGY1k8o/CVCPREm+GtYp37IUVmo HrJbs2dGBsmy3FjF2lvAeRe9roroL8VP6EBNvdYwnmHarktgFw6Vc7fQu+HJ0Bhc7rmX0l6uxp7 gludGW51DfBehCwQZVeLCMLRnUv04ML13Z+tnkqEhI0fKTsNnGBpI5RKF0HftkqRqgc2/ClSH+8 rMNlEA/vU0JcU/8JWRNsej9+NCMVgqUoI2BtC80O4kuVbwt4t4uHWBYK3QZE2pwIj1GG4DD/JJT vduotiYbQ2fkn6ilw= X-Received: by 2002:a05:6000:4210:b0:43b:9a9f:8956 with SMTP id ffacd0b85a97d-4515ce1c80fmr18257155f8f.22.1778231902269; Fri, 08 May 2026 02:18:22 -0700 (PDT) Received: from nsa ([148.63.225.166]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4548e4bbebdsm3214464f8f.5.2026.05.08.02.18.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 May 2026 02:18:21 -0700 (PDT) Date: Fri, 8 May 2026 10:19:15 +0100 From: Nuno =?utf-8?B?U8Oh?= To: "Stan, Liviu" Cc: Lars-Peter Clausen , "Hennerich, Michael" , "Sa, Nuno" , Jonathan Cameron , David Lechner , Andy Shevchenko , Rob Herring , Krzysztof Kozlowski , Conor Dooley , "linux-iio@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 2/2] iio: temperature: ltc2983: Add support for ADT7604 Message-ID: References: <20260427132526.272716-1-liviu.stan@analog.com> <20260427132526.272716-3-liviu.stan@analog.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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