Re: Revert Asus battery_full_discharging_quirk

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 11-04-18 18:28, Daniel Drake wrote:
On Mon, Apr 9, 2018 at 4:03 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
Pardon my French: but this is bullshit, the behavior I'm describing can be
observed every single charge cycle. I've written multiple full-gauge and
charger-ic drivers by now and none actively discharge the battery.

What they do is they do not *start* *charging* the battery when it is above
a certain threshold, so they charge to 100%, and if you then disconnect it
only shortly, so it drops to 99% and then plug in again they do not start
a new charge cycle. That is a very different thing from actively discharging
the battery and reporting this "not charging" state as discharging to the
user will make the user think his adapter/power-brick is broken or not
properly plugged in.

I was going mostly on the communications from Asus here - and
extrapolating since my UPS is also documented to have discharge cycle
behaviour

Ah yes I guess UPS-es do have a discharge cycle, as they are always
on mains. Laptops are expected to get their discharge from not being
plugged in all the time. I know some user do plug them in almost all
of the time, which is where the threshold to start a new charge
cycle comes in.

- but I guess I was wrong about "decent consumer products"
in general. Thanks for sharing your experience.

You're welcome.

So Asus is simply not telling the entire story here and their ACPI
implementation really is buggy.

If you have time to write up your analysis against the AML (and any
suggested AML changes), I will pass it on to Asus BIOS team in hope
that they fix future products.

It is sorta hard to analyze a specific AML for this without
knowing which brand + model charger-IC and fuel-gauge-IC are used.

I think it is best to give them my generic description.

What we want from them is to NOT set the discharge bit in the ACPI
battery's state field when no discharging is happening (as can be
observed by the (dis)charge rate being 0).

Basically the problem is "not charging" != "discharging"...

I agree with the approach you are taking in your patches. Thanks for
working on this!

You're welcome as I mentioned I've had this on my radar for a while
already, so when I first saw Kai-Heng's fix coming in and then you
reverting it, it seemed like time to work on this now rather then
later.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux