On 15.07.2020 07.33, Andy Shevchenko wrote:
+Cc: PDx86 mailing list
On Wed, Jul 15, 2020 at 5:40 AM Mark Enriquez <bugmenot.oss@xxxxxxxxx> wrote:
TL;DR; On some "newer" asus laptops, the first battery is listed as BAT1 as if using the 1-index of counting, rather than "BATT", which prevents having a "charge_control_end_threshold" file present.
It was also reported here:
https://gist.github.com/klausenbusk/643f15320ae8997427155c38be13e445#gistcomment-3307147
I believe we have a fix for this
http://git.infradead.org/linux-platform-drivers-x86.git/commit/a6146ab8a57b6a84e3643398605ec6f897a69365
I did consider sending a patch, but adding every battery name isn't
scalable. Maybe we should just remove the check? The purpose of the
logic is to ensure "charge_control_end_threshold" is only added for the
primary battery, but assuming a laptop have two batteries they are
probably named BAT0 and BAT1 (+ I've never heard of ASUS laptops with
more than one battery).
Another option, would be changing the logic so the knob is only added
the first time the add_battery hook is called (a global boolean?)
Good day,
From this commit
/6b3586d45bba14f6912f37488090c37a3710e7b4 "platform/x86: asus-wmi: Support laptops where the first battery is named BATT"
I also have seen that on a "newer" asus laptop (vivobook x571gt) the first battery is "BAT1" rather than "BATT".
Yet, the "charge_control_end_threshold" file does also work on the system ... well, after recompiling the kernel with this additional case in.
Writing to this file does limit the RSOC of the battery and stops charging at the set threshold, albeit with the status "Unknown" instead of "Not Charging" but that's for another case.
The corresponding bugzilla report is in https://bugzilla.kernel.org/show_bug.cgi?id=208385.
Thank you.
