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