Re: [PATCH RFC 2/8] power: supply: Add driver for Qualcomm PMI8998 fuel gauge

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

On 12/12/25 4:22 PM, David Heidelberg wrote:
> On 27/11/2025 16:28, Konrad Dybcio wrote:
>> On 11/24/25 10:53 PM, David Heidelberg via B4 Relay wrote:
>>> From: Joel Selvaraj <foss@joelselvaraj.com>
>>>
>>> Ths driver supports the fuel gauge hardware available on PMICs known as
>>> 3rd generation fuel gauge hardware available on PMI8998.
>>>
> [...]
> 
>> Downstream checks if the address is > 0xBA which is what you want
>> at least for pmi8998
> 
> My downstream [1] checks this value.

https://github.com/LineageOS/android_kernel_xiaomi_sdm845/blob/lineage-22.2/drivers/power/supply/qcom/fg-util.c#L434

I can quite surely tell you "> 0xBA" is the correct condition to check
for.. both my work laptop and a downstream clone on my SSD concur that

> 
> [1] https://github.com/LineageOS/android_kernel_xiaomi_sdm845/blob/lineage-22.2/drivers/power/supply/qcom/qpnp-fg.c#L760>
>> You can de-abbreviate this to 'secure_access' (not to be confused
>> with 'secondary' or so). There's a locking mechanism which needs a
>> 0xa5 byte written to the base+0xd0 register (applies to all FG
>> peripherals with the 'last non-secure register' value possibly
>> varying).
>>
>> [...]
>>
>>> +    u8 sec_addr_val = 0xa5;
>>> +    int ret;
>>> +
>>> +    if (((chip->base + addr) & 0xff00) == 0)
>>
>> The 'fuel gauge' consists of:
>>
>> FG_BATT_SOC @ 0x4000 (state of charge monitor)
>> FG_BATT_INFO @ 0x4100 ("general fg minus SoC")
>> FG_BCL @ 0x4200 (battery current limiter)
>> FG_LMH @ 0x4300 (limits management hardware)
>> FG_MEM_IF @ 0x4400 (DMA engine)
>> RRADC @ 0x4500 (today handled by its own driver)
>>
>> and a couple other peripherals that Linux doesn't need to worry about
>>
>> Each one of them should have its own 'reg' entry (which is assumed
>> to be 0x100-long), which will let you skip such interesting checks
>> and rely on the regmap framework disallowing address spillover (or
>> you can just then make the addr argument a u8)
> 
> Sounds good.
> 
>>
>> It would be good to keep in mind their relationship and think about how
>> to model them together. I don't think they must all necessarily be part
>> of a single big "fg" dt node, particularly the LMH/BCL part seems to be
>> rather self-contained
> 
> Would you recommend some readings to prepare for this task?
> 
> I see the FG_BATT* + FG_MEM_IF seems to be pretty relying on each other, so I assume I need to take good care of that relation, when spliting pieces up.

It may be that a single "fuel-gauge@" device node may make the most
sense to represent all three of batt_soc, batt_info and mem_if.

You'll unfortunately find out whether this is a good idea as you
write/port the drivers. Downstream has some hacks around plumbing
various PMIC peripherals with just function exports between drivers,
so don't read too hard into that, just try to understand what each
piece/function is doing and how that fits into the power_supply
framework.

I'm a little unsure about bcl and lmh.. but downstream keeps them in
a single node and it doesn't seem to be that bad of an idea. There's some
LMH support today in the kernel.. but not for the PMIC peripheral. That
said, the downstream driver seems to just make the same secure calls
anyway (which may be incomplete for some platforms, I don't remember the
details: <20230113031401.2336157-3-konrad.dybcio@linaro.org>)

Konrad