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 <[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?
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...
