[PATCH] iio: temperature: ltc2983: avoid string comparison for leak detector

[PATCH] iio: temperature: ltc2983: avoid string comparison for leak detector

[Carlos Casadiego via B4 Relay]

From: Carlos Casadiego <cdcp206@gmail.com>

GCC can determine at compile time that propname cannot match
"adi,custom-leak-detector" when __ltc2983_custom_sensor_new() is
inlined for some callers, triggering a -Wstring-compare warning.

Pass an explicit flag for leak detectors instead of deriving the sensor
type from the firmware property name. This preserves the existing
conversion behavior and avoids the constant string comparison.

Fixes: 3dd0c048409e ("iio: temperature: ltc2983: Add support for ADT7604")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202609120045.OxEsKLIn-lkp@intel.com/
Signed-off-by: Carlos Casadiego <cdcp206@gmail.com>
---
 drivers/iio/temperature/ltc2983.c | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/iio/temperature/ltc2983.c b/drivers/iio/temperature/ltc2983.c
index 6efb5252a773..38c5e81f5f88 100644
--- a/drivers/iio/temperature/ltc2983.c
+++ b/drivers/iio/temperature/ltc2983.c
@@ -472,7 +472,8 @@ static int __ltc2983_chan_custom_sensor_assign(struct ltc2983_data *st,
 static struct ltc2983_custom_sensor *
 __ltc2983_custom_sensor_new(struct ltc2983_data *st, const struct fwnode_handle *fn,
 			    const char *propname, const bool is_steinhart,
-			    const u32 resolution, const bool has_signed)
+			    const u32 resolution, const bool has_signed,
+			    const bool is_leak_detector)
 {
 	struct ltc2983_custom_sensor *new_custom;
 	struct device *dev = &st->spi->dev;
@@ -545,7 +546,7 @@ __ltc2983_custom_sensor_new(struct ltc2983_data *st, const struct fwnode_handle
 			 * to µK so __convert_to_raw() produces the correct hardware
 			 * encoding: P + 273.15 K.
 			 */
-			if ((index % 2) != 0 && !strcmp(propname, "adi,custom-leak-detector"))
+			if ((index % 2) != 0 && is_leak_detector)
 				temp = temp * 1000000 + 273150000;
 
 			if ((index % 2) != 0)
@@ -836,7 +837,7 @@ ltc2983_thermocouple_new(const struct fwnode_handle *child, struct ltc2983_data
 
 		thermo->custom = __ltc2983_custom_sensor_new(st, child,
 							     propname, false,
-							     16384, true);
+							     16384, true, false);
 		if (IS_ERR(thermo->custom))
 			return ERR_CAST(thermo->custom);
 	}
@@ -950,7 +951,8 @@ ltc2983_rtd_new(const struct fwnode_handle *child, struct ltc2983_data *st,
 	if (sensor->type == LTC2983_SENSOR_RTD_CUSTOM) {
 		rtd->custom = __ltc2983_custom_sensor_new(st, child,
 							  "adi,custom-rtd",
-							  false, 2048, false);
+							  false, 2048, false,
+							  false);
 		if (IS_ERR(rtd->custom))
 			return ERR_CAST(rtd->custom);
 	}
@@ -1068,7 +1070,7 @@ ltc2983_thermistor_new(const struct fwnode_handle *child, struct ltc2983_data *s
 		thermistor->custom = __ltc2983_custom_sensor_new(st, child,
 								 propname,
 								 steinhart,
-								 64, false);
+								 64, false, false);
 		if (IS_ERR(thermistor->custom))
 			return ERR_CAST(thermistor->custom);
 	}
@@ -1184,7 +1186,7 @@ ltc2983_copper_trace_new(const struct fwnode_handle *child, struct ltc2983_data
 						 "adi,custom-copper-trace is required for >1 ohm copper trace\n");
 
 		ct->custom = __ltc2983_custom_sensor_new(st, child, "adi,custom-copper-trace",
-							 false, 2048, false);
+							 false, 2048, false, false);
 		if (IS_ERR(ct->custom))
 			return ERR_CAST(ct->custom);
 
@@ -1275,7 +1277,7 @@ ltc2983_leak_detector_new(const struct fwnode_handle *child, struct ltc2983_data
 					 "adi,custom-leak-detector is required for leak detectors\n");
 
 	ld->custom = __ltc2983_custom_sensor_new(st, child, "adi,custom-leak-detector",
-						 false, 16, false);
+						 false, 16, false, true);
 	if (IS_ERR(ld->custom))
 		return ERR_CAST(ld->custom);
 
@@ -1488,7 +1490,7 @@ static struct ltc2983_sensor *ltc2983_temp_new(struct fwnode_handle *child,
 					 sensor->chan);
 
 	temp->custom = __ltc2983_custom_sensor_new(st, child, "adi,custom-temp",
-						   false, 4096, true);
+						   false, 4096, true, false);
 	if (IS_ERR(temp->custom))
 		return ERR_CAST(temp->custom);
 

---
base-commit: d2f2868d2f487b418f68db2ef5bd7cf41722ee68
change-id: 20260929-iio-ltc2983-fix-string-compare-c919244f019d

Best regards,
--  
Carlos Casadiego <cdcp206@gmail.com>

Re: [PATCH] iio: temperature: ltc2983: avoid string comparison for leak detector

[Andy Shevchenko]

On Tue, Sep 29, 2026 at 12:38:22PM -0500, Carlos Casadiego via B4 Relay wrote:

+Cc: Nathan

> GCC can determine at compile time that propname cannot match
> "adi,custom-leak-detector" when __ltc2983_custom_sensor_new() is
> inlined for some callers, triggering a -Wstring-compare warning.
> 
> Pass an explicit flag for leak detectors instead of deriving the sensor
> type from the firmware property name. This preserves the existing
> conversion behavior and avoids the constant string comparison.

...

>  __ltc2983_custom_sensor_new(struct ltc2983_data *st, const struct fwnode_handle *fn,
>  			    const char *propname, const bool is_steinhart,
> -			    const u32 resolution, const bool has_signed)
> +			    const u32 resolution, const bool has_signed,
> +			    const bool is_leak_detector)

Can we get rid of those strange const qualifiers for booleans. What are they for?

...

> -			if ((index % 2) != 0 && !strcmp(propname, "adi,custom-leak-detector"))
> +			if ((index % 2) != 0 && is_leak_detector)
>  				temp = temp * 1000000 + 273150000;

Hmm... I consider that the compiler warning is just a noise which we should
ignore or disable. It's doubtfully useful as if it may prove the always false
or always true cases, it doesn't mean there won't be other cases in the future.
Do we have any discussion on that warning before?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] iio: temperature: ltc2983: avoid string comparison for leak detector

[Nuno Sá]

On Wed, Sep 30, 2026 at 12:52:16PM +0300, Andy Shevchenko wrote:
> On Tue, Sep 29, 2026 at 12:38:22PM -0500, Carlos Casadiego via B4 Relay wrote:
> 
> +Cc: Nathan
> 
> > GCC can determine at compile time that propname cannot match
> > "adi,custom-leak-detector" when __ltc2983_custom_sensor_new() is
> > inlined for some callers, triggering a -Wstring-compare warning.
> > 
> > Pass an explicit flag for leak detectors instead of deriving the sensor
> > type from the firmware property name. This preserves the existing
> > conversion behavior and avoids the constant string comparison.
> 
> ...
> 
> >  __ltc2983_custom_sensor_new(struct ltc2983_data *st, const struct fwnode_handle *fn,
> >  			    const char *propname, const bool is_steinhart,
> > -			    const u32 resolution, const bool has_signed)
> > +			    const u32 resolution, const bool has_signed,
> > +			    const bool is_leak_detector)
> 
> Can we get rid of those strange const qualifiers for booleans. What are they for?

Obviously nothing. They came from a time where I thought they added some readability
value :).

> 
> ...
> 
> > -			if ((index % 2) != 0 && !strcmp(propname, "adi,custom-leak-detector"))
> > +			if ((index % 2) != 0 && is_leak_detector)
> >  				temp = temp * 1000000 + 273150000;
> 
> Hmm... I consider that the compiler warning is just a noise which we should
> ignore or disable. It's doubtfully useful as if it may prove the always false
> or always true cases, it doesn't mean there won't be other cases in the future.
> Do we have any discussion on that warning before?
> 

While I agree with the above, I'm not against the change of having the
boolean against the string comparison (and the warning would be just a
side effect and not the main motivation for the change).

- Nuno Sá

> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 

Re: [PATCH] iio: temperature: ltc2983: avoid string comparison for leak detector

[Nathan Chancellor]

On Wed, Sep 30, 2026 at 12:52:16PM +0300, Andy Shevchenko wrote:
> Hmm... I consider that the compiler warning is just a noise which we should
> ignore or disable. It's doubtfully useful as if it may prove the always false
> or always true cases, it doesn't mean there won't be other cases in the future.
> Do we have any discussion on that warning before?

I don't think there has been a discussion around -Wstring-compare
before. Unfortunately, it seems like clang's -Wstring-compare is
different from GCC's -Wstring-compare. clang's is basically a subwarning
in GCC's -Waddress and GCC's -Wstring-compare does not really have an
equivalent in clang proper (it seems like it might be a clang-tidy
check IIUC?):

  https://godbolt.org/z/zzT4WsoT8

So if we want to disable -Wstring-compare, we should only do it for GCC
in my opinion.

-- 
Cheers,
Nathan