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

Dmitry Baryshkov
2026-02-21T02:49:40Z

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