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 <[email protected]> > >>>> --- > >>>> 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
