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]
Date:   Sun, 11 Nov 2018 12:57:12 +0100
From:   Hans de Goede <hdegoede@...hat.com>
To:     Daniel Drake <drake@...lessm.com>, pavel@....cz
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Len Brown <lenb@...nel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        sebastian.reichel@...labora.co.uk,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        linux@...lessm.com,
        João Paulo Rechi Vita <jprvita@...lessm.com>,
        João Paulo Rechi Vita <jprvita@...il.com>
Subject: Re: [PATCH] ACPI / battery: Fix reporting "Not charging" when
 capacity is 100%

Hi,

On 11/7/18 5:53 AM, Daniel Drake wrote:
> On Mon, Nov 5, 2018 at 1:19 AM Pavel Machek <pavel@....cz> wrote:
>> Plus, I don't think "100% charge" is right test for "battery full". At
>> least on thinkpads, there's configuration option, and it is common
>> _not_ to charge batterry above 95% or so (to increase its lifetime).
> 
> Hans also touched on this area in his response:
> 
>> As for this kernel-side fix I do not believe that fixing thus in
>> the kernel is the right thing to do. We try to stay away from
>> heuristics using full_charge_capacity in the kernel since that
>> is not really reliable / deterministic.
> 
> I'm not fully convinced by this argument though.
> 
> The ACPI spec is not very clear on what conditions you should apply to
> decide when the battery is full. Instead, ACPI seems to provide a
> pretty decent amount of data, and the decision about whether to
> interpret that as "battery full" is left for consumers.

Right, but in this case the "discharging" status bit is explicitly
set, to me it feels wrong to report "full", when the firmware
is reporting "discharging" IMHO, at best we are "not charging"
(on AC, below the threshold where a new charge cycle starts) and
that is what we are currently reporting.

Anu heurstics to decide that "not charging" is close enough to full
to report it as full to the user belongs in userspace IMHO.

Anyways this ultimately is Rafael's call. If Rafael is ok with this
patch then I would like to see Pavel's comment addressed and otherwise
it is fine with me.

Note that we will still often get the case where a laptop is charged,
reports full, is unplugged for 5 minutes and then replugged and then
reports a capacity of 97% combined with "not charging", so we will
still need to fix userspace to handle this.

Rafael, what is your take on this?

Regards,

Hans

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ