[PATCH v2 0/5] Battery temperature ADC plumbing on Qualcomm platforms

[PATCH v2 0/5] Battery temperature ADC plumbing on Qualcomm platforms

[Luca Weiss]

This implements a 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. Patching a kernel
per-device is obviously nothing we can put upstream.

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

See RFC for other variants or alternatives considered.

Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Changes in v2:
- Rebase on linux-next (a different patch to add IIO to
  generic-adc-thermal has already landed upstream)
- Un-mark as RFC
- Link to v1: https://lore.kernel.org/r/20251010-bat-temp-adc-v1-0-d51ec895dac6@fairphone.com

---
Luca Weiss (5):
      iio: adc: qcom-spmi-adc5: Add battery thermal channels
      dt-bindings: thermal: generic-adc: Document #io-channel-cells
      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              | 20 +++---
 include/linux/iio/adc/qcom-vadc-common.h           |  3 +
 7 files changed, 147 insertions(+), 9 deletions(-)
---
base-commit: 8dd3bcb7855ad929d732f48e8a2307fdab6a5667
change-id: 20251010-bat-temp-adc-8539bf0b85bc

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

[PATCH v2 1/5] 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 3bf4c49726a7..ce037994b019 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.53.0

[PATCH v2 2/5] 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.53.0

Re: [PATCH v2 2/5] dt-bindings: thermal: generic-adc: Document #io-channel-cells

[Rob Herring]

On Fri, Feb 20, 2026 at 10:19:06AM +0100, Luca Weiss wrote:
> Document the property to allow using this sensor with io-channels.

Why? On the surface, it looks like you are adding a provider property to 
a consumer. Maybe that's right? 

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

Re: [PATCH v2 2/5] dt-bindings: thermal: generic-adc: Document #io-channel-cells

[Luca Weiss]

On Mon Feb 23, 2026 at 7:48 PM CET, Rob Herring wrote:
> On Fri, Feb 20, 2026 at 10:19:06AM +0100, Luca Weiss wrote:
>> Document the property to allow using this sensor with io-channels.
>
> Why? On the surface, it looks like you are adding a provider property to 
> a consumer. Maybe that's right? 

Correct, commit 3762f5851ac5a65dcccadf73dbe853b1b346f561
("thermal/drivers/thermal-generic-adc: Add temperature sensor channel")
added support for this in the driver, this documents the dt parts of it.

Regards
Luca

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

[PATCH v2 3/5] 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[0], allow the
probe to continue without the thermal zone.

We also can't use gadc_thermal_get_temp anymore because we haven't
necessarily initialized tz_dev.

[0] commit 3762f5851ac5 ("thermal/drivers/thermal-generic-adc: Add temperature sensor channel")

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

diff --git a/drivers/thermal/thermal-generic-adc.c b/drivers/thermal/thermal-generic-adc.c
index 7c844589b153..4852e584468b 100644
--- a/drivers/thermal/thermal-generic-adc.c
+++ b/drivers/thermal/thermal-generic-adc.c
@@ -86,14 +86,16 @@ static int gadc_thermal_read_raw(struct iio_dev *indio_dev,
 				 int *val, int *val2, long mask)
 {
 	struct gadc_thermal_info *gtinfo = iio_priv(indio_dev);
+	int iio_val;
 	int ret;
 
 	switch (mask) {
 	case IIO_CHAN_INFO_PROCESSED:
-		ret = gadc_thermal_get_temp(gtinfo->tz_dev, val);
-		if (ret)
+		ret = iio_read_channel_processed(gtinfo->channel, &iio_val);
+		if (ret < 0)
 			return ret;
 
+		*val = gadc_thermal_adc_to_temp(gtinfo, iio_val);
 		return IIO_VAL_INT;
 
 	default:
@@ -197,14 +199,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);
+	}
 
 	return gadc_iio_register(&pdev->dev, gti);
 }

-- 
2.53.0

Re: [PATCH v2 3/5] thermal/drivers/generic-adc: Allow probe without TZ registration

[Andy Shevchenko]

On Fri, Feb 20, 2026 at 10:19:07AM +0100, Luca Weiss wrote:
> If the devicetree node is not referenced in a zone under /thermal-zones,
> devm_thermal_of_zone_register will fail with -ENODEV.

devm_thermal_of_zone_register()

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

Isn't it dangerous?

> We also can't use gadc_thermal_get_temp anymore because we haven't

gadc_thermal_get_temp()

> necessarily initialized tz_dev.

> [0] commit 3762f5851ac5 ("thermal/drivers/thermal-generic-adc: Add temperature sensor channel")

You can make it a Link tag:

Link: https://git.kernel.org/torvalds/c/3762f5851ac5 [0]

> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>

...

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

I believe it's better to return all possible errors. If you see the
similarities with regulator APIs, then use an explicit check for -ENODEV.

> -	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);
> +	}

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 3/5] thermal/drivers/generic-adc: Allow probe without TZ registration

[Luca Weiss]

On Fri Feb 20, 2026 at 11:50 AM CET, Andy Shevchenko wrote:
> On Fri, Feb 20, 2026 at 10:19:07AM +0100, Luca Weiss wrote:
>> If the devicetree node is not referenced in a zone under /thermal-zones,
>> devm_thermal_of_zone_register will fail with -ENODEV.
>
> devm_thermal_of_zone_register()

Ack

>
>> Since the driver is now also registering as an IIO device[0], allow the
>> probe to continue without the thermal zone.
>
> Isn't it dangerous?

Why? The idea is that generic-adc-thermal is the middleman to convert
from one IIO input to one IIO output, and is purely informational, so
that user space can get some temperature value to display somewhere.

How thermal management will be hooked up in the future to charger
drivers is a bit out of scope here I'd say. There's not even any cooling
support in the power supply core anymore, that was ripped out a while
ago if I'm not mistaken.

>
>> We also can't use gadc_thermal_get_temp anymore because we haven't
>
> gadc_thermal_get_temp()

Ack

>
>> necessarily initialized tz_dev.
>
>> [0] commit 3762f5851ac5 ("thermal/drivers/thermal-generic-adc: Add temperature sensor channel")
>
> You can make it a Link tag:
>
> Link: https://git.kernel.org/torvalds/c/3762f5851ac5 [0]

Ack

>
>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>
> ...
>
>>  	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;
>
> I believe it's better to return all possible errors. If you see the
> similarities with regulator APIs, then use an explicit check for -ENODEV.

Sure, will update this.

Regards
Luca

>
>> -	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);
>> +	}

Re: [PATCH v2 3/5] thermal/drivers/generic-adc: Allow probe without TZ registration

[Andy Shevchenko]

On Fri, Feb 20, 2026 at 12:31:36PM +0100, Luca Weiss wrote:
> On Fri Feb 20, 2026 at 11:50 AM CET, Andy Shevchenko wrote:
> > On Fri, Feb 20, 2026 at 10:19:07AM +0100, Luca Weiss wrote:

...

> >> Since the driver is now also registering as an IIO device[0], allow the
> >> probe to continue without the thermal zone.
> >
> > Isn't it dangerous?

> Why?

Just asking to see if haven't missed anything potentially dangerous for HW
at run-time.

> The idea is that generic-adc-thermal is the middleman to convert
> from one IIO input to one IIO output, and is purely informational, so
> that user space can get some temperature value to display somewhere.
> 
> How thermal management will be hooked up in the future to charger
> drivers is a bit out of scope here I'd say. There's not even any cooling
> support in the power supply core anymore, that was ripped out a while
> ago if I'm not mistaken.

Okay, so there is no possibility to get some thermal issues on running
legacy HW (that relies on thermal to be present). If it's the case, no
worries then.

-- 
With Best Regards,
Andy Shevchenko

[PATCH v2 4/5] 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.53.0

Re: [PATCH v2 4/5] arm64: dts: qcom: pm7250b: Define battery temperature ADC channels

[Konrad Dybcio]

On 2/20/26 10:19 AM, Luca Weiss wrote:
> Add the definition for these ADC channels to the PM7250B definition.
> 
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

[PATCH v2 5/5] 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 b697051a0aaa..7857003099a6 100644
--- a/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
+++ b/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
@@ -108,6 +108,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.53.0

Re: [PATCH v2 5/5] arm64: dts: qcom: sm7225-fairphone-fp4: Add battery temperature node

[Konrad Dybcio]

On 2/20/26 10:19 AM, Luca Weiss wrote:
> 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 b697051a0aaa..7857003099a6 100644
> --- a/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
> +++ b/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
> @@ -108,6 +108,89 @@ rear_cam_sensor: thermal-sensor-rear-cam {
>  		io-channel-names = "sensor-channel";
>  	};
>  
> +	bat_therm_sensor: thermal-sensor-bat-therm {

nit: this should be a little higher

> +		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.
> +		 */

I think this looks good. Is this data going to be correct for all/most
devices (i.e. is there a single battery sku)?

Konrad

Re: [PATCH v2 5/5] arm64: dts: qcom: sm7225-fairphone-fp4: Add battery temperature node

[Luca Weiss]

On Fri Feb 20, 2026 at 11:00 AM CET, Konrad Dybcio wrote:
> On 2/20/26 10:19 AM, Luca Weiss wrote:
>> 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 b697051a0aaa..7857003099a6 100644
>> --- a/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
>> +++ b/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
>> @@ -108,6 +108,89 @@ rear_cam_sensor: thermal-sensor-rear-cam {
>>  		io-channel-names = "sensor-channel";
>>  	};
>>  
>> +	bat_therm_sensor: thermal-sensor-bat-therm {
>
> nit: this should be a little higher

meh, it's surprisingly easy to miss this sorting stuff. Will fix in v3.

>
>> +		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.
>> +		 */
>
> I think this looks good. Is this data going to be correct for all/most
> devices (i.e. is there a single battery sku)?

Yes, from my info there's just a single battery SKU, so that makes it
easy here.

For Fairphone 3 there's two battery SKUs:

* (Fuji) F3AC with NTC 100kOhm B=4100, ID resistor 10kOhm
* (Kayo) F3AC1 with NTC 100kOhm B=4050, ID resistor 49.9kOhm

In reality, one can probably ignore the difference between the LUT for
either B value since it only differs by a marginal amount, but
conceptually I'm not sure how this should really be resolved.

We could have both battery definitions in the dtb, and then the charging
driver could determine the battery that's actually present in the
system (based on the BATT_ID measurement), but given the design here
now, I'm not sure how this temperature lookup table would be propagated
to the rest of the system...

Regards
Luca

Re: [PATCH v2 5/5] arm64: dts: qcom: sm7225-fairphone-fp4: Add battery temperature node

[Konrad Dybcio]

On 2/20/26 11:40 AM, Luca Weiss wrote:
> On Fri Feb 20, 2026 at 11:00 AM CET, Konrad Dybcio wrote:
>> On 2/20/26 10:19 AM, Luca Weiss wrote:
>>> 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 b697051a0aaa..7857003099a6 100644
>>> --- a/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
>>> +++ b/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
>>> @@ -108,6 +108,89 @@ rear_cam_sensor: thermal-sensor-rear-cam {
>>>  		io-channel-names = "sensor-channel";
>>>  	};
>>>  
>>> +	bat_therm_sensor: thermal-sensor-bat-therm {
>>
>> nit: this should be a little higher
> 
> meh, it's surprisingly easy to miss this sorting stuff. Will fix in v3.
> 
>>
>>> +		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.
>>> +		 */
>>
>> I think this looks good. Is this data going to be correct for all/most
>> devices (i.e. is there a single battery sku)?
> 
> Yes, from my info there's just a single battery SKU, so that makes it
> easy here.
> 
> For Fairphone 3 there's two battery SKUs:
> 
> * (Fuji) F3AC with NTC 100kOhm B=4100, ID resistor 10kOhm
> * (Kayo) F3AC1 with NTC 100kOhm B=4050, ID resistor 49.9kOhm
> 
> In reality, one can probably ignore the difference between the LUT for
> either B value since it only differs by a marginal amount, but
> conceptually I'm not sure how this should really be resolved.
> 
> We could have both battery definitions in the dtb, and then the charging
> driver could determine the battery that's actually present in the
> system (based on the BATT_ID measurement), but given the design here
> now, I'm not sure how this temperature lookup table would be propagated
> to the rest of the system...

The path of least resistance (pun intended) would probably be to make
generic-adc-thermal consume an ID channel and accept a number of LUTs..

That sounds sensible since most battery ID mechanisms are probably also
ADC-based and one would hope (tm) that the values output by these ADC channels
would then be distinct enough for the driver to have an easy time confidently
selecting one of the options (or a fallback)

That said, this is just my guesstimates and perhaps the IIO folks could comment
on that

Konrad

Re: [PATCH v2 5/5] arm64: dts: qcom: sm7225-fairphone-fp4: Add battery temperature node

[Luca Weiss]

On Fri Feb 20, 2026 at 11:51 AM CET, Konrad Dybcio wrote:
> On 2/20/26 11:40 AM, Luca Weiss wrote:
>> On Fri Feb 20, 2026 at 11:00 AM CET, Konrad Dybcio wrote:
>>> On 2/20/26 10:19 AM, Luca Weiss wrote:
>>>> 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 b697051a0aaa..7857003099a6 100644
>>>> --- a/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
>>>> +++ b/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
>>>> @@ -108,6 +108,89 @@ rear_cam_sensor: thermal-sensor-rear-cam {
>>>>  		io-channel-names = "sensor-channel";
>>>>  	};
>>>>  
>>>> +	bat_therm_sensor: thermal-sensor-bat-therm {
>>>
>>> nit: this should be a little higher
>> 
>> meh, it's surprisingly easy to miss this sorting stuff. Will fix in v3.
>> 
>>>
>>>> +		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.
>>>> +		 */
>>>
>>> I think this looks good. Is this data going to be correct for all/most
>>> devices (i.e. is there a single battery sku)?
>> 
>> Yes, from my info there's just a single battery SKU, so that makes it
>> easy here.
>> 
>> For Fairphone 3 there's two battery SKUs:
>> 
>> * (Fuji) F3AC with NTC 100kOhm B=4100, ID resistor 10kOhm
>> * (Kayo) F3AC1 with NTC 100kOhm B=4050, ID resistor 49.9kOhm
>> 
>> In reality, one can probably ignore the difference between the LUT for
>> either B value since it only differs by a marginal amount, but
>> conceptually I'm not sure how this should really be resolved.
>> 
>> We could have both battery definitions in the dtb, and then the charging
>> driver could determine the battery that's actually present in the
>> system (based on the BATT_ID measurement), but given the design here
>> now, I'm not sure how this temperature lookup table would be propagated
>> to the rest of the system...
>
> The path of least resistance (pun intended) would probably be to make
> generic-adc-thermal consume an ID channel and accept a number of LUTs..

Not the worst idea ;)

>
> That sounds sensible since most battery ID mechanisms are probably also
> ADC-based and one would hope (tm) that the values output by these ADC channels
> would then be distinct enough for the driver to have an easy time confidently
> selecting one of the options (or a fallback)

Charger / fuel guage and everything else battery-related would also need
to get the correct battery properties for the actual one present, not
just this generic-adc-thermal driver.

But I feel like soon DT maintainers will say that Linux shouldn't
dynamically detect hardware that's present and the DT should be the
absolute source of truth. That works fine in simple cases, but in case
of interchangeable batteries, display panels, camera sensors, this won't
work. *Something* needs to determine what's actually there.

And for most of the ways to detect which of those are present in the
device that is booting, you need half a kernel to power up the various
hardware and do some basic communication to figure out what's there. Of
course you could say that's U-Boot's job for example but not sure you
want to add a CCI (I2C), ADC driver and much more...

Regards
Luca

> That said, this is just my guesstimates and perhaps the IIO folks could comment
> on that
>
> Konrad

Re: [PATCH v2 5/5] arm64: dts: qcom: sm7225-fairphone-fp4: Add battery temperature node

[Dmitry Baryshkov]

On Fri, Feb 20, 2026 at 12:26:48PM +0100, Luca Weiss wrote:
> On Fri Feb 20, 2026 at 11:51 AM CET, Konrad Dybcio wrote:
> > On 2/20/26 11:40 AM, Luca Weiss wrote:
> >> On Fri Feb 20, 2026 at 11:00 AM CET, Konrad Dybcio wrote:
> >>> On 2/20/26 10:19 AM, Luca Weiss wrote:
> >>>> 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 b697051a0aaa..7857003099a6 100644
> >>>> --- a/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
> >>>> +++ b/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
> >>>> @@ -108,6 +108,89 @@ rear_cam_sensor: thermal-sensor-rear-cam {
> >>>>  		io-channel-names = "sensor-channel";
> >>>>  	};
> >>>>  
> >>>> +	bat_therm_sensor: thermal-sensor-bat-therm {
> >>>
> >>> nit: this should be a little higher
> >> 
> >> meh, it's surprisingly easy to miss this sorting stuff. Will fix in v3.
> >> 
> >>>
> >>>> +		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.
> >>>> +		 */
> >>>
> >>> I think this looks good. Is this data going to be correct for all/most
> >>> devices (i.e. is there a single battery sku)?
> >> 
> >> Yes, from my info there's just a single battery SKU, so that makes it
> >> easy here.
> >> 
> >> For Fairphone 3 there's two battery SKUs:
> >> 
> >> * (Fuji) F3AC with NTC 100kOhm B=4100, ID resistor 10kOhm
> >> * (Kayo) F3AC1 with NTC 100kOhm B=4050, ID resistor 49.9kOhm
> >> 
> >> In reality, one can probably ignore the difference between the LUT for
> >> either B value since it only differs by a marginal amount, but
> >> conceptually I'm not sure how this should really be resolved.
> >> 
> >> We could have both battery definitions in the dtb, and then the charging
> >> driver could determine the battery that's actually present in the
> >> system (based on the BATT_ID measurement), but given the design here
> >> now, I'm not sure how this temperature lookup table would be propagated
> >> to the rest of the system...
> >
> > The path of least resistance (pun intended) would probably be to make
> > generic-adc-thermal consume an ID channel and accept a number of LUTs..
> 
> Not the worst idea ;)
> 
> >
> > That sounds sensible since most battery ID mechanisms are probably also
> > ADC-based and one would hope (tm) that the values output by these ADC channels
> > would then be distinct enough for the driver to have an easy time confidently
> > selecting one of the options (or a fallback)
> 
> Charger / fuel guage and everything else battery-related would also need
> to get the correct battery properties for the actual one present, not
> just this generic-adc-thermal driver.
> 
> But I feel like soon DT maintainers will say that Linux shouldn't
> dynamically detect hardware that's present and the DT should be the
> absolute source of truth. That works fine in simple cases, but in case
> of interchangeable batteries, display panels, camera sensors, this won't
> work. *Something* needs to determine what's actually there.

How is it handled for the Android boots? I assume there are (at least)
two DTBOs and the correct one is being selected somehow (via the msm-id
/ board-id?). Or does ABL pass some kind of battery identifier to the
kernel?

> 
> And for most of the ways to detect which of those are present in the
> device that is booting, you need half a kernel to power up the various
> hardware and do some basic communication to figure out what's there. Of
> course you could say that's U-Boot's job for example but not sure you
> want to add a CCI (I2C), ADC driver and much more...

-- 
With best wishes
Dmitry

Re: [PATCH v2 5/5] arm64: dts: qcom: sm7225-fairphone-fp4: Add battery temperature node

[Luca Weiss]

On Sat Feb 21, 2026 at 3:49 AM CET, Dmitry Baryshkov wrote:
> On Fri, Feb 20, 2026 at 12:26:48PM +0100, Luca Weiss wrote:
>> On Fri Feb 20, 2026 at 11:51 AM CET, Konrad Dybcio wrote:
>> > On 2/20/26 11:40 AM, Luca Weiss wrote:
>> >> On Fri Feb 20, 2026 at 11:00 AM CET, Konrad Dybcio wrote:
>> >>> On 2/20/26 10:19 AM, Luca Weiss wrote:
>> >>>> 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 b697051a0aaa..7857003099a6 100644
>> >>>> --- a/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
>> >>>> +++ b/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
>> >>>> @@ -108,6 +108,89 @@ rear_cam_sensor: thermal-sensor-rear-cam {
>> >>>>  		io-channel-names = "sensor-channel";
>> >>>>  	};
>> >>>>  
>> >>>> +	bat_therm_sensor: thermal-sensor-bat-therm {
>> >>>
>> >>> nit: this should be a little higher
>> >> 
>> >> meh, it's surprisingly easy to miss this sorting stuff. Will fix in v3.
>> >> 
>> >>>
>> >>>> +		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.
>> >>>> +		 */
>> >>>
>> >>> I think this looks good. Is this data going to be correct for all/most
>> >>> devices (i.e. is there a single battery sku)?
>> >> 
>> >> Yes, from my info there's just a single battery SKU, so that makes it
>> >> easy here.
>> >> 
>> >> For Fairphone 3 there's two battery SKUs:
>> >> 
>> >> * (Fuji) F3AC with NTC 100kOhm B=4100, ID resistor 10kOhm
>> >> * (Kayo) F3AC1 with NTC 100kOhm B=4050, ID resistor 49.9kOhm
>> >> 
>> >> In reality, one can probably ignore the difference between the LUT for
>> >> either B value since it only differs by a marginal amount, but
>> >> conceptually I'm not sure how this should really be resolved.
>> >> 
>> >> We could have both battery definitions in the dtb, and then the charging
>> >> driver could determine the battery that's actually present in the
>> >> system (based on the BATT_ID measurement), but given the design here
>> >> now, I'm not sure how this temperature lookup table would be propagated
>> >> to the rest of the system...
>> >
>> > The path of least resistance (pun intended) would probably be to make
>> > generic-adc-thermal consume an ID channel and accept a number of LUTs..
>> 
>> Not the worst idea ;)
>> 
>> >
>> > That sounds sensible since most battery ID mechanisms are probably also
>> > ADC-based and one would hope (tm) that the values output by these ADC channels
>> > would then be distinct enough for the driver to have an easy time confidently
>> > selecting one of the options (or a fallback)
>> 
>> Charger / fuel guage and everything else battery-related would also need
>> to get the correct battery properties for the actual one present, not
>> just this generic-adc-thermal driver.
>> 
>> But I feel like soon DT maintainers will say that Linux shouldn't
>> dynamically detect hardware that's present and the DT should be the
>> absolute source of truth. That works fine in simple cases, but in case
>> of interchangeable batteries, display panels, camera sensors, this won't
>> work. *Something* needs to determine what's actually there.
>
> How is it handled for the Android boots? I assume there are (at least)
> two DTBOs and the correct one is being selected somehow (via the msm-id
> / board-id?). Or does ABL pass some kind of battery identifier to the
> kernel?

On downstream the Linux driver will do the selection, there you have two
batterydata nodes in the dtb with each their qcom,batt-id-kohm property
and the driver will choose the correct one at runtime.

Similar with multiple display panels, but I think there usually the
'detection' happens via what's passed on cmdline from the bootloader.
But not with two dtbs, the driver is selecting the correct panel from
one dtb.

For cameras, the camera stack is 95% in user space, so it's not quite
comparable but also there usually I think there it's trying probe camera
#1, if it fails try probing camera #2.

Regards
Luca

>
>> 
>> And for most of the ways to detect which of those are present in the
>> device that is booting, you need half a kernel to power up the various
>> hardware and do some basic communication to figure out what's there. Of
>> course you could say that's U-Boot's job for example but not sure you
>> want to add a CCI (I2C), ADC driver and much more...

Re: [PATCH v2 5/5] arm64: dts: qcom: sm7225-fairphone-fp4: Add battery temperature node

[Dmitry Baryshkov]

On Mon, Feb 23, 2026 at 08:50:50AM +0100, Luca Weiss wrote:
> On Sat Feb 21, 2026 at 3:49 AM CET, Dmitry Baryshkov wrote:
> > On Fri, Feb 20, 2026 at 12:26:48PM +0100, Luca Weiss wrote:
> >> On Fri Feb 20, 2026 at 11:51 AM CET, Konrad Dybcio wrote:
> >> > On 2/20/26 11:40 AM, Luca Weiss wrote:
> >> >> On Fri Feb 20, 2026 at 11:00 AM CET, Konrad Dybcio wrote:
> >> >>> On 2/20/26 10:19 AM, Luca Weiss wrote:
> >> >>>> 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 b697051a0aaa..7857003099a6 100644
> >> >>>> --- a/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
> >> >>>> +++ b/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
> >> >>>> @@ -108,6 +108,89 @@ rear_cam_sensor: thermal-sensor-rear-cam {
> >> >>>>  		io-channel-names = "sensor-channel";
> >> >>>>  	};
> >> >>>>  
> >> >>>> +	bat_therm_sensor: thermal-sensor-bat-therm {
> >> >>>
> >> >>> nit: this should be a little higher
> >> >> 
> >> >> meh, it's surprisingly easy to miss this sorting stuff. Will fix in v3.
> >> >> 
> >> >>>
> >> >>>> +		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.
> >> >>>> +		 */
> >> >>>
> >> >>> I think this looks good. Is this data going to be correct for all/most
> >> >>> devices (i.e. is there a single battery sku)?
> >> >> 
> >> >> Yes, from my info there's just a single battery SKU, so that makes it
> >> >> easy here.
> >> >> 
> >> >> For Fairphone 3 there's two battery SKUs:
> >> >> 
> >> >> * (Fuji) F3AC with NTC 100kOhm B=4100, ID resistor 10kOhm
> >> >> * (Kayo) F3AC1 with NTC 100kOhm B=4050, ID resistor 49.9kOhm
> >> >> 
> >> >> In reality, one can probably ignore the difference between the LUT for
> >> >> either B value since it only differs by a marginal amount, but
> >> >> conceptually I'm not sure how this should really be resolved.
> >> >> 
> >> >> We could have both battery definitions in the dtb, and then the charging
> >> >> driver could determine the battery that's actually present in the
> >> >> system (based on the BATT_ID measurement), but given the design here
> >> >> now, I'm not sure how this temperature lookup table would be propagated
> >> >> to the rest of the system...
> >> >
> >> > The path of least resistance (pun intended) would probably be to make
> >> > generic-adc-thermal consume an ID channel and accept a number of LUTs..
> >> 
> >> Not the worst idea ;)
> >> 
> >> >
> >> > That sounds sensible since most battery ID mechanisms are probably also
> >> > ADC-based and one would hope (tm) that the values output by these ADC channels
> >> > would then be distinct enough for the driver to have an easy time confidently
> >> > selecting one of the options (or a fallback)
> >> 
> >> Charger / fuel guage and everything else battery-related would also need
> >> to get the correct battery properties for the actual one present, not
> >> just this generic-adc-thermal driver.
> >> 
> >> But I feel like soon DT maintainers will say that Linux shouldn't
> >> dynamically detect hardware that's present and the DT should be the
> >> absolute source of truth. That works fine in simple cases, but in case
> >> of interchangeable batteries, display panels, camera sensors, this won't
> >> work. *Something* needs to determine what's actually there.
> >
> > How is it handled for the Android boots? I assume there are (at least)
> > two DTBOs and the correct one is being selected somehow (via the msm-id
> > / board-id?). Or does ABL pass some kind of battery identifier to the
> > kernel?
> 
> On downstream the Linux driver will do the selection, there you have two
> batterydata nodes in the dtb with each their qcom,batt-id-kohm property
> and the driver will choose the correct one at runtime.
> 
> Similar with multiple display panels, but I think there usually the
> 'detection' happens via what's passed on cmdline from the bootloader.
> But not with two dtbs, the driver is selecting the correct panel from
> one dtb.

I remembered that all panels are a part of a single DTB, I didn't
remember about the batteries. If there is a bootparam, in theory we can
use it to identify the battery. Or we can find how it is being
identified in the first place and use the same logic in the kernel /
userspace.

> 
> For cameras, the camera stack is 95% in user space, so it's not quite
> comparable but also there usually I think there it's trying probe camera
> #1, if it fails try probing camera #2.
> 
> Regards
> Luca
> 
> >
> >> 
> >> And for most of the ways to detect which of those are present in the
> >> device that is booting, you need half a kernel to power up the various
> >> hardware and do some basic communication to figure out what's there. Of
> >> course you could say that's U-Boot's job for example but not sure you
> >> want to add a CCI (I2C), ADC driver and much more...
> 

-- 
With best wishes
Dmitry

Re: [PATCH v2 0/5] Battery temperature ADC plumbing on Qualcomm platforms

[Hans de Goede]

Hi All,

On 20-Feb-26 10:19, Luca Weiss wrote:
> This implements a 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. Patching a kernel
> per-device is obviously nothing we can put upstream.
> 
> 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

Nice, I agree that this seems the best way forward, especially
taking into account that the generic-adc-thermal driver now
already supports the IIO -> IIO path case.

Regards,

Hans