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

Dmitry Baryshkov
2026-02-23T19:05:10Z

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