Re: [PATCH] arm64: dts: qcom: sdm845-oneplus: fix fuel gauge compatible

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 8/29/26 11:03 PM, Rinat Muhamedgaliev wrote:
> On 29/08/2026, Konrad Dybcio wrote:
>> If I'm reading that thread right, this IC is on the battery itself (?)
>> and it seems to differ across different units / suppliers, would that
>> be a good interpretation?
> 
> That matches what I found while looking into this. Both the bq27411-G1
> and bq27541-G1 datasheets describe them as pack-side fuel gauges meant
> for integration into the battery pack itself, alongside the protection
> IC, rather than being placed on the phone's mainboard. So it's
> plausible that different battery packs (different suppliers or
> production batches) could carry a different chip variant, and DT
> can't detect that at boot time - the bq27xxx driver picks its register
> map purely from the compatible string, with no runtime DeviceType
> probing.
> 
> I want to be upfront: I only tested this on my own OnePlus 6T
> (fajita), by reading DeviceType directly over I2C on that one unit. I
> haven't verified whether other fajita/enchilada units report the same
> value, so I can't rule out that some devices out there actually do
> have a bq27411 and would regress with this patch.
> 
> I'm not sure what the right way to handle this is and would appreciate
> guidance. A few options I can think of, roughly in order of effort:
> 
> - Ask other sdm845-mainline users to report their DeviceType (a quick
>   i2cget on 0x55) to get a sense of how common each variant is.
> - Leave the fix as-is for now, since it's still strictly correct for
>   the tested unit and the previous binding was wrong for it, but note
>   the pack-side/per-battery caveat explicitly in the commit message.
> - Longer term, add DeviceType autodetection to bq27xxx_battery.c
>   itself so the driver picks the right register map at probe time
>   instead of relying on a static DT compatible - though that's a
>   separate, larger change to the driver, not this DT patch.
> 
> Happy to go whichever direction you and the other reviewers think is
> right; just didn't want to claim more certainty than I actually have.

If the driver can do autodetection, then that's a good idea

Otherwise, since based on David's reply there's strong reasons to
believe both variants are out in the wild, no autodetection would
suggest we need 2 DT variants (I'm really a fan of the other option)

Konrad