[PATCH RFC 0/6] Battery temperature ADC plumbing on Qualcomm platforms

[PATCH RFC 0/6] Battery temperature ADC plumbing on Qualcomm platforms

[Luca Weiss]

This is an RFC which implements a potential solution to get battery
temperature readings working on for example smartphones with Qualcomm
SoCs.

The solution chosen in downstream Qualcomm kernels is exposing
ADC_BAT_THERM_PU* in the ADC driver as temperature channels with the
lookup table ("struct vadc_map_pt") for the specific NTC found in a
device's battery patched to adjust the lookup table.

The high level solution proposed here:
* ADC driver provides temperature channel in (milli)volt as IIO channel
* generic-adc-thermal driver converts voltage to temperature based on
  provided lookup table from DT (driver has one IIO channel input, one
  IIO channel output)
* The fuel gauge driver can use that temperature IIO channel to expose
  battery temperature via the power supply device

Variants/alternatives considered:

1. Do not implement IIO device in generic-adc-thermal

Without an IIO channel and using thermal zone directly it becomes more
difficult. You cannot get thermal zone by reference (e.g.
thermal-sensors = <&foo>;). The function thermal_zone_get_zone_by_name()
exists but lookup by name is kinda clunky. Adding by-phandle support
might be possible but is lots of work. It also doesn't really look like
thermal-sensor is really meant to be used by other drivers. E.g.
there's also no "thermal-sensor-names" property to designate passing
multiple thermal sensors. So I believe IIO is a better fitting API for
this.

2. Expose IIO channel as temperature in ADC driver

This would require passing in the temperature lookup table somehow to
the ADC driver via DT. I think this passes too many details about the
hardware that's connected into the ADC driver. While possible, at least
for Qcom ADC there's no precedent yet.

3. Add temperature-lookup-table as property to simple-battery

Since the NTC is a part of the battery pack, adding a
temperature-lookup-table property to simple-battery would make sense
instead of having this lookup table be standalone in the
generic-adc-thermal node. However being able to re-use the existing code
in generic-adc-thermal lead me to the current proposal.

Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Luca Weiss (6):
      iio: adc: qcom-spmi-adc5: Add battery thermal channels
      dt-bindings: thermal: generic-adc: Document #io-channel-cells
      thermal/drivers/generic-adc: Register as IIO device
      thermal/drivers/generic-adc: Allow probe without TZ registration
      arm64: dts: qcom: pm7250b: Define battery temperature ADC channels
      arm64: dts: qcom: sm7225-fairphone-fp4: Add battery temperature node

 .../bindings/thermal/generic-adc-thermal.yaml      |  4 ++
 arch/arm64/boot/dts/qcom/pm7250b.dtsi              | 24 +++++++
 arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts  | 83 ++++++++++++++++++++++
 drivers/iio/adc/qcom-spmi-adc5.c                   |  6 ++
 drivers/iio/adc/qcom-vadc-common.c                 | 16 +++++
 drivers/thermal/thermal-generic-adc.c              | 68 ++++++++++++++++--
 include/linux/iio/adc/qcom-vadc-common.h           |  3 +
 7 files changed, 198 insertions(+), 6 deletions(-)
---
base-commit: 6063257da111c7639d020c5f15bfb37fb839d8b6
change-id: 20251010-bat-temp-adc-8539bf0b85bc

Best regards,
-- 
Luca Weiss <luca.weiss@fairphone.com>

[PATCH RFC 1/6] iio: adc: qcom-spmi-adc5: Add battery thermal channels

[Luca Weiss]

Add the BAT_THERM channels with millivolt as output, which can then be
used along with information regarding the NTC in the battery, to get the
actual battery temperature.

A static lookup table in the ADC driver won't work since different
devices have different Ohm and Beta values in their battery NTCs, for
example a NTC can be 10kOhm & B=3435K.

Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
 drivers/iio/adc/qcom-spmi-adc5.c         |  6 ++++++
 drivers/iio/adc/qcom-vadc-common.c       | 16 ++++++++++++++++
 include/linux/iio/adc/qcom-vadc-common.h |  3 +++
 3 files changed, 25 insertions(+)

diff --git a/drivers/iio/adc/qcom-spmi-adc5.c b/drivers/iio/adc/qcom-spmi-adc5.c
index af3c2f659f5e..6ad75368d3a3 100644
--- a/drivers/iio/adc/qcom-spmi-adc5.c
+++ b/drivers/iio/adc/qcom-spmi-adc5.c
@@ -543,6 +543,12 @@ static const struct adc5_channels adc5_chans_pmic[ADC5_MAX_CHANNEL] = {
 					SCALE_HW_CALIB_DEFAULT)
 	[ADC5_XO_THERM_100K_PU]	= ADC5_CHAN_TEMP("xo_therm", 0,
 					SCALE_HW_CALIB_XOTHERM)
+	[ADC5_BAT_THERM_30K_PU]	= ADC5_CHAN_VOLT("bat_therm_30k_pu", 0,
+					SCALE_HW_CALIB_THERM_VOLT)
+	[ADC5_BAT_THERM_100K_PU] = ADC5_CHAN_VOLT("bat_therm_100k_pu", 0,
+					SCALE_HW_CALIB_THERM_VOLT)
+	[ADC5_BAT_THERM_400K_PU] = ADC5_CHAN_VOLT("bat_therm_400k_pu", 0,
+					SCALE_HW_CALIB_THERM_VOLT)
 	[ADC5_BAT_ID_100K_PU]	= ADC5_CHAN_TEMP("bat_id", 0,
 					SCALE_HW_CALIB_DEFAULT)
 	[ADC5_AMUX_THM1_100K_PU] = ADC5_CHAN_TEMP("amux_thm1_100k_pu", 0,
diff --git a/drivers/iio/adc/qcom-vadc-common.c b/drivers/iio/adc/qcom-vadc-common.c
index b03cf584b165..09a13e2b0ef4 100644
--- a/drivers/iio/adc/qcom-vadc-common.c
+++ b/drivers/iio/adc/qcom-vadc-common.c
@@ -309,6 +309,10 @@ static int qcom_vadc_scale_hw_calib_therm(
 				const struct u32_fract *prescale,
 				const struct adc5_data *data,
 				u16 adc_code, int *result_mdec);
+static int qcom_vadc_scale_hw_calib_therm_volt(
+				const struct u32_fract *prescale,
+				const struct adc5_data *data,
+				u16 adc_code, int *result_mdec);
 static int qcom_vadc7_scale_hw_calib_therm(
 				const struct u32_fract *prescale,
 				const struct adc5_data *data,
@@ -333,6 +337,7 @@ static int qcom_vadc7_scale_hw_calib_die_temp(
 static const struct qcom_adc5_scale_type scale_adc5_fn[] = {
 	[SCALE_HW_CALIB_DEFAULT] = {qcom_vadc_scale_hw_calib_volt},
 	[SCALE_HW_CALIB_THERM_100K_PULLUP] = {qcom_vadc_scale_hw_calib_therm},
+	[SCALE_HW_CALIB_THERM_VOLT] = {qcom_vadc_scale_hw_calib_therm_volt},
 	[SCALE_HW_CALIB_XOTHERM] = {qcom_vadc_scale_hw_calib_therm},
 	[SCALE_HW_CALIB_THERM_100K_PU_PM7] = {
 					qcom_vadc7_scale_hw_calib_therm},
@@ -583,6 +588,17 @@ static int qcom_vadc_scale_hw_calib_therm(
 				 voltage, result_mdec);
 }
 
+static int qcom_vadc_scale_hw_calib_therm_volt(
+				const struct u32_fract *prescale,
+				const struct adc5_data *data,
+				u16 adc_code, int *result_uv)
+{
+	*result_uv = qcom_vadc_scale_code_voltage_factor(adc_code,
+				prescale, data, 1000);
+
+	return 0;
+}
+
 static int qcom_vadc_scale_hw_calib_die_temp(
 				const struct u32_fract *prescale,
 				const struct adc5_data *data,
diff --git a/include/linux/iio/adc/qcom-vadc-common.h b/include/linux/iio/adc/qcom-vadc-common.h
index aa21b032e861..3ae091fa93d7 100644
--- a/include/linux/iio/adc/qcom-vadc-common.h
+++ b/include/linux/iio/adc/qcom-vadc-common.h
@@ -93,6 +93,8 @@ struct vadc_linear_graph {
  *	voltage (uV) with hardware applied offset/slope values to adc code.
  * SCALE_HW_CALIB_THERM_100K_PULLUP: Returns temperature in millidegC using
  *	lookup table. The hardware applies offset/slope to adc code.
+ * SCALE_HW_CALIB_THERM_VOLT: Returns voltage in uV of a temperature channel.
+ *	The hardware applies offset/slope to adc code.
  * SCALE_HW_CALIB_XOTHERM: Returns XO thermistor voltage in millidegC using
  *	100k pullup. The hardware applies offset/slope to adc code.
  * SCALE_HW_CALIB_THERM_100K_PU_PM7: Returns temperature in millidegC using
@@ -114,6 +116,7 @@ enum vadc_scale_fn_type {
 	SCALE_PMI_CHG_TEMP,
 	SCALE_HW_CALIB_DEFAULT,
 	SCALE_HW_CALIB_THERM_100K_PULLUP,
+	SCALE_HW_CALIB_THERM_VOLT,
 	SCALE_HW_CALIB_XOTHERM,
 	SCALE_HW_CALIB_THERM_100K_PU_PM7,
 	SCALE_HW_CALIB_PMIC_THERM,

-- 
2.51.0

[PATCH RFC 2/6] dt-bindings: thermal: generic-adc: Document #io-channel-cells

[Luca Weiss]

Document the property to allow using this sensor with io-channels.

Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
 Documentation/devicetree/bindings/thermal/generic-adc-thermal.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/thermal/generic-adc-thermal.yaml b/Documentation/devicetree/bindings/thermal/generic-adc-thermal.yaml
index 12e6418dc24d..317fc39ed46a 100644
--- a/Documentation/devicetree/bindings/thermal/generic-adc-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/generic-adc-thermal.yaml
@@ -24,6 +24,9 @@ properties:
   '#thermal-sensor-cells':
     const: 0
 
+  "#io-channel-cells":
+    const: 0
+
   io-channels:
     maxItems: 1
 
@@ -58,6 +61,7 @@ examples:
     thermal-sensor {
         compatible = "generic-adc-thermal";
         #thermal-sensor-cells = <0>;
+        #io-channel-cells = <0>;
         io-channels = <&ads1015 1>;
         io-channel-names = "sensor-channel";
         temperature-lookup-table = <

-- 
2.51.0

[PATCH RFC 3/6] thermal/drivers/generic-adc: Register as IIO device

[Luca Weiss]

Register an IIO channel to allow reading the temperature using the IIO
interface.

Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
 drivers/thermal/thermal-generic-adc.c | 56 +++++++++++++++++++++++++++++++++++
 1 file changed, 56 insertions(+)

diff --git a/drivers/thermal/thermal-generic-adc.c b/drivers/thermal/thermal-generic-adc.c
index ee3d0aa31406..14aef682e0fb 100644
--- a/drivers/thermal/thermal-generic-adc.c
+++ b/drivers/thermal/thermal-generic-adc.c
@@ -7,6 +7,7 @@
  * Author: Laxman Dewangan <ldewangan@nvidia.com>
  */
 #include <linux/iio/consumer.h>
+#include <linux/iio/iio.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/platform_device.h>
@@ -23,6 +24,10 @@ struct gadc_thermal_info {
 	int nlookup_table;
 };
 
+struct gadc_iio {
+	struct gadc_thermal_info *gti;
+};
+
 static int gadc_thermal_adc_to_temp(struct gadc_thermal_info *gti, int val)
 {
 	int temp, temp_hi, temp_lo, adc_hi, adc_lo;
@@ -115,10 +120,44 @@ static int gadc_thermal_read_linear_lookup_table(struct device *dev,
 	return 0;
 }
 
+static int gadc_adc_read_raw(struct iio_dev *indio_dev,
+			     struct iio_chan_spec const *chan,
+			     int *val, int *val2, long mask)
+{
+	struct gadc_iio *data = iio_priv(indio_dev);
+	int iio_val;
+	int ret;
+
+	switch (mask) {
+	case IIO_CHAN_INFO_PROCESSED:
+		ret = iio_read_channel_processed(data->gti->channel, &iio_val);
+		if (ret < 0)
+			return ret;
+
+		*val = gadc_thermal_adc_to_temp(data->gti, iio_val);
+		return IIO_VAL_INT;
+	default:
+		return -EINVAL;
+	}
+}
+
+static const struct iio_info gadc_adc_info = {
+	.read_raw = &gadc_adc_read_raw,
+};
+
+static const struct iio_chan_spec gadc_adc_channels[] = {
+	{
+		.type = IIO_TEMP,
+		.info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
+	},
+};
+
 static int gadc_thermal_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct gadc_thermal_info *gti;
+	struct iio_dev *indio_dev;
+	struct gadc_iio *data;
 	int ret;
 
 	if (!dev->of_node) {
@@ -153,6 +192,23 @@ static int gadc_thermal_probe(struct platform_device *pdev)
 
 	devm_thermal_add_hwmon_sysfs(dev, gti->tz_dev);
 
+	indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
+	if (!indio_dev)
+		return -ENOMEM;
+
+	data = iio_priv(indio_dev);
+	data->gti = gti;
+
+	indio_dev->name = pdev->name;
+	indio_dev->modes = INDIO_DIRECT_MODE;
+	indio_dev->info = &gadc_adc_info;
+	indio_dev->channels = gadc_adc_channels;
+	indio_dev->num_channels = ARRAY_SIZE(gadc_adc_channels);
+
+	ret = devm_iio_device_register(dev, indio_dev);
+	if (ret)
+		return dev_err_probe(dev, ret, "Failed to register IIO device\n");
+
 	return 0;
 }
 

-- 
2.51.0

Re: [PATCH RFC 3/6] thermal/drivers/generic-adc: Register as IIO device

[Jonathan Cameron]

On Fri, 10 Oct 2025 13:22:01 +0200
Luca Weiss <luca.weiss@fairphone.com> wrote:

> Register an IIO channel to allow reading the temperature using the IIO
> interface.
> 
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Just one question below.

>  static int gadc_thermal_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
>  	struct gadc_thermal_info *gti;
> +	struct iio_dev *indio_dev;
> +	struct gadc_iio *data;
>  	int ret;
>  
>  	if (!dev->of_node) {
> @@ -153,6 +192,23 @@ static int gadc_thermal_probe(struct platform_device *pdev)
>  
>  	devm_thermal_add_hwmon_sysfs(dev, gti->tz_dev);
>  
> +	indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
> +	if (!indio_dev)
> +		return -ENOMEM;
> +
> +	data = iio_priv(indio_dev);
> +	data->gti = gti;
> +
> +	indio_dev->name = pdev->name;
what does this end up as?

obviously we don't really care what name the user space interface we
aren't using advertises but this should be something part number like.

> +	indio_dev->modes = INDIO_DIRECT_MODE;
> +	indio_dev->info = &gadc_adc_info;
> +	indio_dev->channels = gadc_adc_channels;
> +	indio_dev->num_channels = ARRAY_SIZE(gadc_adc_channels);
> +
> +	ret = devm_iio_device_register(dev, indio_dev);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "Failed to register IIO device\n");
> +
>  	return 0;
>  }
>  
> 

[PATCH RFC 4/6] thermal/drivers/generic-adc: Allow probe without TZ registration

[Luca Weiss]

If the devicetree node is not referenced in a zone under /thermal-zones,
devm_thermal_of_zone_register will fail with -ENODEV.

Since the driver is now also registering as an IIO device, allow the
probe to continue without the thermal zone.

Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
 drivers/thermal/thermal-generic-adc.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/thermal/thermal-generic-adc.c b/drivers/thermal/thermal-generic-adc.c
index 14aef682e0fb..d31533927be6 100644
--- a/drivers/thermal/thermal-generic-adc.c
+++ b/drivers/thermal/thermal-generic-adc.c
@@ -183,14 +183,14 @@ static int gadc_thermal_probe(struct platform_device *pdev)
 						    &gadc_thermal_ops);
 	if (IS_ERR(gti->tz_dev)) {
 		ret = PTR_ERR(gti->tz_dev);
-		if (ret != -EPROBE_DEFER)
-			dev_err(dev,
-				"Thermal zone sensor register failed: %d\n",
-				ret);
-		return ret;
-	}
+		if (ret == -EPROBE_DEFER)
+			return ret;
 
-	devm_thermal_add_hwmon_sysfs(dev, gti->tz_dev);
+		dev_info(dev, "Thermal zone sensor register failed: %d\n",
+			 ret);
+	} else {
+		devm_thermal_add_hwmon_sysfs(dev, gti->tz_dev);
+	}
 
 	indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
 	if (!indio_dev)

-- 
2.51.0

[PATCH RFC 5/6] arm64: dts: qcom: pm7250b: Define battery temperature ADC channels

[Luca Weiss]

Add the definition for these ADC channels to the PM7250B definition.

Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
 arch/arm64/boot/dts/qcom/pm7250b.dtsi | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/pm7250b.dtsi b/arch/arm64/boot/dts/qcom/pm7250b.dtsi
index 0761e6b5fd8d..c96089520548 100644
--- a/arch/arm64/boot/dts/qcom/pm7250b.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm7250b.dtsi
@@ -156,6 +156,22 @@ channel@1e {
 				label = "chg_mid";
 			};
 
+			channel@2a {
+				reg = <ADC5_BAT_THERM_30K_PU>;
+				qcom,hw-settle-time = <200>;
+				qcom,pre-scaling = <1 1>;
+				qcom,ratiometric;
+				label = "bat_therm_30k";
+			};
+
+			channel@4a {
+				reg = <ADC5_BAT_THERM_100K_PU>;
+				qcom,hw-settle-time = <200>;
+				qcom,pre-scaling = <1 1>;
+				qcom,ratiometric;
+				label = "bat_therm_100k";
+			};
+
 			channel@4b {
 				reg = <ADC5_BAT_ID_100K_PU>;
 				qcom,hw-settle-time = <200>;
@@ -164,6 +180,14 @@ channel@4b {
 				label = "bat_id";
 			};
 
+			channel@6a {
+				reg = <ADC5_BAT_THERM_400K_PU>;
+				qcom,hw-settle-time = <200>;
+				qcom,pre-scaling = <1 1>;
+				qcom,ratiometric;
+				label = "bat_therm_400k";
+			};
+
 			channel@83 {
 				reg = <ADC5_VPH_PWR>;
 				qcom,pre-scaling = <1 3>;

-- 
2.51.0

[PATCH RFC 6/6] arm64: dts: qcom: sm7225-fairphone-fp4: Add battery temperature node

[Luca Weiss]

Add a generic-adc-thermal node to convert the voltage read by the
battery temperature ADC into degree Celsius using the provided lookup
table.

This will later be used as input for the fuel gauge node (QGauge on the
PM7250B).

Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
 arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts | 83 +++++++++++++++++++++++
 1 file changed, 83 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts b/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
index 71e87ab92955..24855cec7880 100644
--- a/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
+++ b/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
@@ -107,6 +107,89 @@ rear_cam_sensor: thermal-sensor-rear-cam {
 		io-channel-names = "sensor-channel";
 	};
 
+	bat_therm_sensor: thermal-sensor-bat-therm {
+		compatible = "generic-adc-thermal";
+		#thermal-sensor-cells = <0>;
+		#io-channel-cells = <0>;
+		io-channels = <&pm7250b_adc ADC5_BAT_THERM_30K_PU>;
+		io-channel-names = "sensor-channel";
+		/*
+		 * Voltage to temperature table for 10kΩ (B=3435K) NTC with a
+		 * 1.875V reference and 30kΩ pull-up.
+		 */
+		temperature-lookup-table = <
+			(-40000) 1673
+			(-38000) 1649
+			(-36000) 1623
+			(-34000) 1596
+			(-32000) 1566
+			(-30000) 1535
+			(-28000) 1502
+			(-26000) 1467
+			(-24000) 1430
+			(-22000) 1392
+			(-20000) 1352
+			(-18000) 1311
+			(-16000) 1269
+			(-14000) 1226
+			(-12000) 1182
+			(-10000) 1138
+			 (-8000) 1093
+			 (-6000) 1049
+			 (-4000) 1004
+			 (-2000) 960
+			       0 917
+			    2000 874
+			    4000 832
+			    6000 791
+			    8000 752
+			   10000 713
+			   12000 676
+			   14000 640
+			   16000 606
+			   18000 573
+			   20000 541
+			   22000 511
+			   24000 483
+			   26000 455
+			   28000 430
+			   30000 405
+			   32000 382
+			   34000 360
+			   36000 340
+			   38000 320
+			   40000 302
+			   42000 285
+			   44000 269
+			   46000 253
+			   48000 239
+			   50000 225
+			   52000 213
+			   54000 201
+			   56000 190
+			   58000 179
+			   60000 169
+			   62000 160
+			   64000 152
+			   66000 143
+			   68000 136
+			   70000 128
+			   72000 122
+			   74000 115
+			   76000 109
+			   78000 104
+			   80000 98
+			   82000 93
+			   84000 89
+			   86000 84
+			   88000 80
+			   90000 76
+			   92000 73
+			   94000 69
+			   96000 66
+			   98000 63>;
+	};
+
 	thermal-zones {
 		chg-skin-thermal {
 			thermal-sensors = <&pm7250b_adc_tm 0>;

-- 
2.51.0

Re: [PATCH RFC 0/6] Battery temperature ADC plumbing on Qualcomm platforms

[Nuno Sá]

On Fri, 2025-10-10 at 13:21 +0200, Luca Weiss wrote:
> This is an RFC which implements a potential solution to get battery
> temperature readings working on for example smartphones with Qualcomm
> SoCs.
> 
> The solution chosen in downstream Qualcomm kernels is exposing
> ADC_BAT_THERM_PU* in the ADC driver as temperature channels with the
> lookup table ("struct vadc_map_pt") for the specific NTC found in a
> device's battery patched to adjust the lookup table.
> 
> The high level solution proposed here:
> * ADC driver provides temperature channel in (milli)volt as IIO channel
> * generic-adc-thermal driver converts voltage to temperature based on
>   provided lookup table from DT (driver has one IIO channel input, one
>   IIO channel output)
> * The fuel gauge driver can use that temperature IIO channel to expose
>   battery temperature via the power supply device
> 
> Variants/alternatives considered:
> 
> 1. Do not implement IIO device in generic-adc-thermal
> 
> Without an IIO channel and using thermal zone directly it becomes more
> difficult. You cannot get thermal zone by reference (e.g.
> thermal-sensors = <&foo>;). The function thermal_zone_get_zone_by_name()
> exists but lookup by name is kinda clunky. Adding by-phandle support
> might be possible but is lots of work. It also doesn't really look like
> thermal-sensor is really meant to be used by other drivers. E.g.
> there's also no "thermal-sensor-names" property to designate passing
> multiple thermal sensors. So I believe IIO is a better fitting API for
> this.

The only thing that I dislike is that using IIO just feels like hacking around
the lack of an inkernel interface (as you pointed out and which IIO provides)
for thermal devices. My main question is, what makes this device an IIO device
despite the fact that we (you) want to use the IIO inkernel API (IIUC)? AFAIU,
the sensor is already being implemented as the ADC driver and this is just
convenience.

Anyways, that said, there's precedent (at least in 2 places) about registering
IIO devices outside of the subsystem.

Maybe we need the concept of an IIO proxy for the IIO inkernel interface. Like
consumers of IIO devices that can use some the measurements (channels), do
something with them and then be IIO providers. I guess I'm already rambling :)
 
> 
> 2. Expose IIO channel as temperature in ADC driver
> 
> This would require passing in the temperature lookup table somehow to
> the ADC driver via DT. I think this passes too many details about the
> hardware that's connected into the ADC driver. While possible, at least
> for Qcom ADC there's no precedent yet.

Not really familiar with the HW setup but (just for my understanding) why it
would not make sense to pass that info to the IIO driver? I guess that table is
just not part of the ADC?

> 
> 3. Add temperature-lookup-table as property to simple-battery
> 
> Since the NTC is a part of the battery pack, adding a
> temperature-lookup-table property to simple-battery would make sense
> instead of having this lookup table be standalone in the
> generic-adc-thermal node. However being able to re-use the existing code
> in generic-adc-thermal lead me to the current proposal.

What about turning it into a small lib module? No idea where to put it though.
But while I was thinking about this, your option 3 looks the one that makes more
sense to me.

My 2 cents!
- Nuno Sá


> 
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
> Luca Weiss (6):
>       iio: adc: qcom-spmi-adc5: Add battery thermal channels
>       dt-bindings: thermal: generic-adc: Document #io-channel-cells
>       thermal/drivers/generic-adc: Register as IIO device
>       thermal/drivers/generic-adc: Allow probe without TZ registration
>       arm64: dts: qcom: pm7250b: Define battery temperature ADC channels
>       arm64: dts: qcom: sm7225-fairphone-fp4: Add battery temperature node
> 
>  .../bindings/thermal/generic-adc-thermal.yaml      |  4 ++
>  arch/arm64/boot/dts/qcom/pm7250b.dtsi              | 24 +++++++
>  arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts  | 83
> ++++++++++++++++++++++
>  drivers/iio/adc/qcom-spmi-adc5.c                   |  6 ++
>  drivers/iio/adc/qcom-vadc-common.c                 | 16 +++++
>  drivers/thermal/thermal-generic-adc.c              | 68 ++++++++++++++++--
>  include/linux/iio/adc/qcom-vadc-common.h           |  3 +
>  7 files changed, 198 insertions(+), 6 deletions(-)
> ---
> base-commit: 6063257da111c7639d020c5f15bfb37fb839d8b6
> change-id: 20251010-bat-temp-adc-8539bf0b85bc
> 
> Best regards,

Re: [PATCH RFC 0/6] Battery temperature ADC plumbing on Qualcomm platforms

[David Lechner]

On 10/10/25 6:21 AM, Luca Weiss wrote:
> This is an RFC which implements a potential solution to get battery
> temperature readings working on for example smartphones with Qualcomm
> SoCs.
> 

...

> 3. Add temperature-lookup-table as property to simple-battery
> 
> Since the NTC is a part of the battery pack, adding a
> temperature-lookup-table property to simple-battery would make sense
> instead of having this lookup table be standalone in the
> generic-adc-thermal node. However being able to re-use the existing code
> in generic-adc-thermal lead me to the current proposal.
> 
Did you consider creating a specific compatible string for the battery pack?
Then the battery node could have the io-channels property for the ADC
connected to the temperature sensor. Then a specific battery driver could
handle the conversion as needed rather than filling the devicetree with
conversion tables.

The simple-battery bindings are already far from simple! So I would not
be inclined to add more to it.

Re: [PATCH RFC 0/6] Battery temperature ADC plumbing on Qualcomm platforms

[Hans de Goede]

Hi All,

Luca thank you for Cc-ing me.

On 10-Oct-25 10:56 PM, David Lechner wrote:
> On 10/10/25 6:21 AM, Luca Weiss wrote:
>> This is an RFC which implements a potential solution to get battery
>> temperature readings working on for example smartphones with Qualcomm
>> SoCs.
>>
> 
> ...
> 
>> 3. Add temperature-lookup-table as property to simple-battery
>>
>> Since the NTC is a part of the battery pack, adding a
>> temperature-lookup-table property to simple-battery would make sense
>> instead of having this lookup table be standalone in the
>> generic-adc-thermal node. However being able to re-use the existing code
>> in generic-adc-thermal lead me to the current proposal.
>>
> Did you consider creating a specific compatible string for the battery pack?
> Then the battery node could have the io-channels property for the ADC
> connected to the temperature sensor. Then a specific battery driver could
> handle the conversion as needed rather than filling the devicetree with
> conversion tables.

That will require a driver update, filling the driver (and thus memory)
with conversion tables each time a new battery model (one model phone
can have multiple battery revisions) comes out.

That seems undesirable. To me these conversion tables are very much
something which belongs in DT rather then being hardcoded in
the driver.

Also contrast this to ACPI where there actually is a mechanism defined
for thermal lookup tables and there all these things typically just
work when the ACPI tables are written properly. IMHO we want to move
more towards this direction where things just work without requiring
kernel code changes for every new model.

And we already have a mechanism in DT to map an ADC voltage to
a temperature in the generic-adc-thermal driver.

So all that is left to do really is to come up with a clean way
to export the temperature from the generic-adc-thermal driver
to the generic-adc-battery driver.

> The simple-battery bindings are already far from simple! So I would not
> be inclined to add more to it.

I think we all agree on this and we also don't want to duplicate
the generic-adc-thermal bindings + code implementing that functionality.

IMHO not wanting to duplicate the bindings + functionality applies to
both: a) directly exporting an IIO temp channel from the ADC driver and
b) adding volt -> temp mapping functionality to the simple-battery bindings.

So that basically leaves us with coming up with a way for
the generic-adc-battery code to consume the temperature coming out of
the generic-adc-thermal code and there are 2 ways to do this:

1. Modify the generic-adc-thermal driver to export an IIO channel
2. Modify the thermal-zone core to allow referencing to a thermal-zone
   with a phandle *and* modify generic-adc-battery to be able to
   optionally get the temperature from a thermal-zone instead of
   from an IIO-channel

Of these two options 1. clear is the most KISS option. SO I agree with
Luca that 1. as implemented in this series is the best way forward.

Regards,

Hans

Re: [PATCH RFC 0/6] Battery temperature ADC plumbing on Qualcomm platforms

[Jonathan Cameron]

On Sat, 11 Oct 2025 11:52:43 +0200
Hans de Goede <hansg@kernel.org> wrote:

> Hi All,
> 
> Luca thank you for Cc-ing me.
> 
> On 10-Oct-25 10:56 PM, David Lechner wrote:
> > On 10/10/25 6:21 AM, Luca Weiss wrote:  
> >> This is an RFC which implements a potential solution to get battery
> >> temperature readings working on for example smartphones with Qualcomm
> >> SoCs.
> >>  
> > 
> > ...
> >   
> >> 3. Add temperature-lookup-table as property to simple-battery
> >>
> >> Since the NTC is a part of the battery pack, adding a
> >> temperature-lookup-table property to simple-battery would make sense
> >> instead of having this lookup table be standalone in the
> >> generic-adc-thermal node. However being able to re-use the existing code
> >> in generic-adc-thermal lead me to the current proposal.
> >>  
> > Did you consider creating a specific compatible string for the battery pack?
> > Then the battery node could have the io-channels property for the ADC
> > connected to the temperature sensor. Then a specific battery driver could
> > handle the conversion as needed rather than filling the devicetree with
> > conversion tables.  
> 
> That will require a driver update, filling the driver (and thus memory)
> with conversion tables each time a new battery model (one model phone
> can have multiple battery revisions) comes out.
> 
> That seems undesirable. To me these conversion tables are very much
> something which belongs in DT rather then being hardcoded in
> the driver.
> 
> Also contrast this to ACPI where there actually is a mechanism defined
> for thermal lookup tables and there all these things typically just
> work when the ACPI tables are written properly. IMHO we want to move
> more towards this direction where things just work without requiring
> kernel code changes for every new model.
> 
> And we already have a mechanism in DT to map an ADC voltage to
> a temperature in the generic-adc-thermal driver.
> 
> So all that is left to do really is to come up with a clean way
> to export the temperature from the generic-adc-thermal driver
> to the generic-adc-battery driver.
> 
> > The simple-battery bindings are already far from simple! So I would not
> > be inclined to add more to it.  
> 
> I think we all agree on this and we also don't want to duplicate
> the generic-adc-thermal bindings + code implementing that functionality.
> 
> IMHO not wanting to duplicate the bindings + functionality applies to
> both: a) directly exporting an IIO temp channel from the ADC driver and
> b) adding volt -> temp mapping functionality to the simple-battery bindings.
> 
> So that basically leaves us with coming up with a way for
> the generic-adc-battery code to consume the temperature coming out of
> the generic-adc-thermal code and there are 2 ways to do this:
> 
> 1. Modify the generic-adc-thermal driver to export an IIO channel

Other than the fact this is embedded in an existing driver, this is just
a case of modelling an analog sensor in IIO. There's an ancient accelerometer
that does this and the analog fronted ends handle things like potential dividers
which are similar but with far simpler DT than this.

So conceptually I have no problem with the approach.

If we were starting from scratch we might have had an explicit representation
of the thermal sensor analog part (like our accelerometer), and then done

Generic temperature device sensor driver is consumer of the ADC channel.
generic-adc-thermal is consumer of the generic temp device sensor.

But retrofitting that split may be a pain (I haven't looked at this though so
maybe not!)



> 2. Modify the thermal-zone core to allow referencing to a thermal-zone
>    with a phandle *and* modify generic-adc-battery to be able to
>    optionally get the temperature from a thermal-zone instead of
>    from an IIO-channel
> 
> Of these two options 1. clear is the most KISS option. SO I agree with
> Luca that 1. as implemented in this series is the best way forward.
> 
> Regards,
> 
> Hans
> 
>