linux-kernel - Re: [PATCH 2/3] power: supply: cpcap-battery: Fix battery identification

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: <Y3W+M3/7zOutygEZ@atomide.com>
Date:   Thu, 17 Nov 2022 06:53:07 +0200
From:   Tony Lindgren <tony@...mide.com>
To:     Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>
Cc:     Sebastian Reichel <sebastian.reichel@...labora.com>,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        philipp@...s.xyz, Pavel Machek <pavel@....cz>
Subject: Re: [PATCH 2/3] power: supply: cpcap-battery: Fix battery
 identification

* Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com> [221115 15:31]:
> Hi,
> 
> On 15.11.22 г. 15:49 ч., Tony Lindgren wrote:
> > Hi,
> > 
> > * Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com> [221110 16:40]:
> > > On 10.11.22 г. 18:05 ч., Sebastian Reichel wrote:
> > > > Why do we care?
> > > > 
> > > Because if we know the battery is genuine (or at least pretends to be :) ),
> > > then we can read battery parameters from nvram, see patch 3/3. This will
> > > allow us to charge HV LiPo batteries to 4.35V, using the full capacity.
> > 
> > Let's not enable charge voltages above 4.2V automatically at all unless
> > the user chooses to set a higher charge voltage via sysfs manually.
> > 
> > We have had reports of bloated batteries if left connected to the charger
> > at higher voltage than 4.2V. This seems to happen after connected for some
> > weeks or months. AFAIK this happens both with Android and mainline kernel
> > at higher voltages.
> > 
> 
> Not that I sent such patch yet, but still, thinking about it, we should be
> able to easily prevent such damage by not restarting the charging after
> battery is full and voltage has dropped by 50mV or so. There can be a
> threshold (lets say 4.25 or 4.2) above which charging shall not be
> re-enabled unless the user reconnects the charger. Even if default stays 4.2
> and it is the user that has enabled 4.35. Just an idea.

Sure the logic to handle max charge voltage and maintenance charge voltage
could be there. With commit d4ee021c410f we now just wait for the charge
to come down to 4.2V if charged at 4.35V with Android.

We still should not enable higher charge voltages by default though. It
still needs to be enabled by the user via sysfs. It's possible that also
shorter peaks of higher charge voltage accelerate the battery degration.
It just may happen slower than what we've seen earlier. To test this,
multiple devices would need to be left connected to a charger for several
months :)

Regards,

Tony