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