linux-kernel - Re: [PATCH 00/10] Add RT5033 charger device 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20230325160819.GA1820@bug>
Date:   Sat, 25 Mar 2023 17:08:20 +0100
From:   Pavel Machek <pavel@....cz>
To:     Jakob Hauser <jahau@...ketmail.com>
Cc:     Sebastian Reichel <sre@...nel.org>, Lee Jones <lee@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Beomho Seo <beomho.seo@...sung.com>,
        Chanwoo Choi <cw00.choi@...sung.com>,
        Stephan Gerhold <stephan@...hold.net>,
        Raymond Hackley <raymondhackley@...tonmail.com>,
        linux-pm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, ~postmarketos/upstreaming@...ts.sr.ht
Subject: Re: [PATCH 00/10] Add RT5033 charger device driver

Hi!

> Some comments on the end-of-charge behavior. The rt5033 chip offers three
> options. In the Android driver, a forth option was implemented.

Hmm. I'm working on that on motorola-cpcap driver, and I guess this is going
to be common problem for many drivers.

> - By default, the rt5033 chip charges indefinitely. The current goes down but
>   there is always a charge voltage to the battery, which might not be too good
>   for the battery lifetime.
> - There is the possibility to enable a fast charge timer. The timer can be
>   set to 4, 6, 8... 16 hours. After that time has elapsed, charging stops
>   and the battery gets discharged. This option with a timer of 4 hours was
>   chosen by Beomho Seo in the patchset of March 2015. However, that option
>   is confusing to the user. It doesn't initiate a re-charge cycle. So when
>   keeping plugged in the device over night, I find it discharging on the
>   next morning.
> - The third option of the rt5033 chip is enabling charging termination. This
>   also enables a re-charge cycle. When the charging current sinks below the
>   end-of-charge current, the chip stops charging. The sysfs state changes to
>   "not charging". When the voltage gets 0.1 V below the end-of-charge constant
>   voltage, re-charging starts. Then again, when charging current sinks below
>   the end-of-charge current, the chip stops charging. And so on, going up and
>   down in re-charge cycles. In case the power consumption is high (e.g. tuning
>   on the display of the mobile device), the current goes into an equilibrium.
>   The downside of this charging termination option: When reaching the end-of-
>   charge current, the capacity might not have reached 100 % yet. The capacity
>   to reach probably depends on power consumption and battery wear. On my mobile
>   device, capacity reaches 98 %, drops to 96 % until re-charging kicks in,
>   climbs to 98 %, drops to 96 %, and so on. Not reaching 100 % is a bit
>   confusing to the user, too.

Is the system powered from the battery in the not-charging case?

Anyway, we should teach userspace that "full battery" does not neccessary mean 100%,
as keeping battery at 4.3V wears it down quickly.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html