linux-kernel - Re: [PATCH v3 2/3] power: supply: Add bd718(15/28/78) charger driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250829131542.4f46ebf4@akair>
Date: Fri, 29 Aug 2025 13:15:42 +0200
From: Andreas Kemnade <andreas@...nade.info>
To: Matti Vaittinen <mazziesaccount@...il.com>
Cc: Linus Walleij <linus.walleij@...aro.org>, Lee Jones <lee@...nel.org>,
 Sebastian Reichel <sre@...nel.org>, linux-kernel@...r.kernel.org,
 linux-pm@...r.kernel.org, Krzysztof Kozlowski <krzk@...nel.org>
Subject: Re: [PATCH v3 2/3] power: supply: Add bd718(15/28/78) charger
 driver

Am Fri, 29 Aug 2025 09:35:00 +0300
schrieb Matti Vaittinen <mazziesaccount@...il.com>:

> > to indicate that a measurement of the open circuit voltage
> > is available in some register, which enables you do do more
> > precise capacity estimation, right?  
> 
> AFAIR, the ROHM fuel-gauge algorithm used OCV tables when battery was 
> not really open, but 'relaxed', to adjust the coulomb counter based on 
> the SOC estimated from the OCV. The 'relaxed' condition was met when the 
> current consumption had been 'small', and battery had not been charged 
> 'recently'. I have a vague memory the BD71828 had some hardware support 
> for knowing battery was 'relaxed', the BD71815 and BD71827 might have 
> used coulomb counter 'history' for this. I can try to remember all this 
> a bit better if Andreas continues to upstream also the fuel-gauging 
> logic from the original RFC. But yeah, these interrupts were for over 
> current.

78 at least has. But then the question is how often the relaxed state
really is reached. Current limit is around 3mA per default
(REX_CURCD_TH). So if your
power management is suboptimal, you will not reach that state on
discharing. So, regarding charging, at least when I am on vacation,
the limit on available energy is also my protection against spending
too much time with my electronics (esp. on the smartphone). But that
also means that I will not always charge the device fully. Lowering
current may also mis-indicated that the battery is full.
So the scene is set for any mess with fuel gauges, not limited to the
BD71878.

Regards,
Andreas