2019-05-27 14:55:06 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2007-09-26 23:42:58 +08:00
|
|
|
* battery.c - ACPI Battery Driver (Revision: 2.0)
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
2007-09-26 23:42:58 +08:00
|
|
|
* Copyright (C) 2007 Alexey Starikovskiy <astarikovskiy@suse.de>
|
|
|
|
|
* Copyright (C) 2004-2007 Vladimir Lebedev <vladimir.p.lebedev@intel.com>
|
2005-04-17 06:20:36 +08:00
|
|
|
* Copyright (C) 2001, 2002 Andy Grover <andrew.grover@intel.com>
|
|
|
|
|
* Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
|
|
|
|
|
*/
|
|
|
|
|
|
2021-02-04 02:44:57 +08:00
|
|
|
#define pr_fmt(fmt) "ACPI: battery: " fmt
|
2018-02-07 22:58:13 +08:00
|
|
|
|
2018-07-24 19:27:32 +08:00
|
|
|
#include <linux/async.h>
|
|
|
|
|
#include <linux/delay.h>
|
|
|
|
|
#include <linux/dmi.h>
|
|
|
|
|
#include <linux/jiffies.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/kernel.h>
|
2018-02-07 22:58:13 +08:00
|
|
|
#include <linux/list.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/module.h>
|
2018-02-07 22:58:13 +08:00
|
|
|
#include <linux/mutex.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
|
|
|
#include <linux/slab.h>
|
2011-03-23 04:19:50 +08:00
|
|
|
#include <linux/suspend.h>
|
2018-07-24 19:27:32 +08:00
|
|
|
#include <linux/types.h>
|
|
|
|
|
|
ACPI / battery: Correct battery capacity values on Thinkpads
Add a quirk to correctly report battery capacity on 2010 and 2011
Lenovo Thinkpad models.
The affected models that I tested (x201, t410, t410s, and x220)
exhibit a problem where, when battery capacity reporting unit is mAh,
the values being reported are wrong. Pre-2010 and 2012 models appear
to always report in mWh and are thus unaffected. Also, in mid-2012
Lenovo issued a BIOS update for the 2011 models that fixes the issue
(tested on x220 with a post-1.29 BIOS). No such update is available
for the 2010 models, so those still need this patch.
Problem description: for some reason, the affected Thinkpads switch
the reporting unit between mAh and mWh; generally, mAh is used when a
laptop is plugged in and mWh when it's unplugged, although a
suspend/resume or rmmod/modprobe is needed for the switch to take
effect. The values reported in mAh are *always* wrong. This does
not appear to be a kernel regression; I believe that the values were
never reported correctly. I tested back to kernel 2.6.34, with
multiple machines and BIOS versions.
Simply plugging a laptop into mains before turning it on is enough to
reproduce the problem. Here's a sample /proc/acpi/battery/BAT0/info
from Thinkpad x220 (before a BIOS update) with a 4-cell battery:
present: yes
design capacity: 2886 mAh
last full capacity: 2909 mAh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 145 mAh
design capacity low: 13 mAh
cycle count: 0
capacity granularity 1: 1 mAh
capacity granularity 2: 1 mAh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Once the laptop switches the unit to mWh (unplug from mains, suspend,
resume), the output changes to:
present: yes
design capacity: 28860 mWh
last full capacity: 29090 mWh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 1454 mWh
design capacity low: 200 mWh
cycle count: 0
capacity granularity 1: 1 mWh
capacity granularity 2: 1 mWh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Can you see how the values for "design capacity", etc., differ by a
factor of 10 instead of 14.8 (the design voltage of this battery)?
On the battery itself it says: 14.8V, 1.95Ah, 29Wh, so clearly the
values reported in mWh are correct and the ones in mAh are not.
My guess is that this problem has been around ever since those
machines were released, but because the most common Thinkpad
batteries are rated at 10.8V, the error (8%) is small enough that it
simply hasn't been noticed or at least nobody could be bothered to
look into it.
My patch works around the problem by adjusting the incorrectly
reported mAh values by "10000 / design_voltage". The patch also has
code to figure out if it should be activated or not. It only
activates on Lenovo Thinkpads, only when the unit is mAh, and, as an
extra precaution, only when the battery capacity reported through
ACPI does not match what is reported through DMI (I've never
encountered a machine where the first two conditions would be true
but the last would not, but better safe than sorry).
I've been using this patch for close to a year on several systems
without any problems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=41062
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-17 05:28:58 +08:00
|
|
|
#include <asm/unaligned.h>
|
2007-09-26 23:43:04 +08:00
|
|
|
|
2013-12-03 08:49:16 +08:00
|
|
|
#include <linux/acpi.h>
|
2007-09-26 23:43:04 +08:00
|
|
|
#include <linux/power_supply.h>
|
|
|
|
|
|
2018-02-07 22:58:13 +08:00
|
|
|
#include <acpi/battery.h>
|
2014-03-12 01:58:46 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#define ACPI_BATTERY_VALUE_UNKNOWN 0xFFFFFFFF
|
2019-12-10 17:57:50 +08:00
|
|
|
#define ACPI_BATTERY_CAPACITY_VALID(capacity) \
|
|
|
|
|
((capacity) != 0 && (capacity) != ACPI_BATTERY_VALUE_UNKNOWN)
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
#define ACPI_BATTERY_DEVICE_NAME "Battery"
|
|
|
|
|
|
2011-06-30 11:32:40 +08:00
|
|
|
/* Battery power unit: 0 means mW, 1 means mA */
|
|
|
|
|
#define ACPI_BATTERY_POWER_UNIT_MA 1
|
|
|
|
|
|
2014-05-28 15:23:36 +08:00
|
|
|
#define ACPI_BATTERY_STATE_DISCHARGING 0x1
|
|
|
|
|
#define ACPI_BATTERY_STATE_CHARGING 0x2
|
|
|
|
|
#define ACPI_BATTERY_STATE_CRITICAL 0x4
|
|
|
|
|
|
2007-02-13 11:42:12 +08:00
|
|
|
MODULE_AUTHOR("Paul Diefenbaugh");
|
2007-09-26 23:42:58 +08:00
|
|
|
MODULE_AUTHOR("Alexey Starikovskiy <astarikovskiy@suse.de>");
|
2007-02-13 12:50:02 +08:00
|
|
|
MODULE_DESCRIPTION("ACPI Battery Driver");
|
2005-04-17 06:20:36 +08:00
|
|
|
MODULE_LICENSE("GPL");
|
|
|
|
|
|
2015-05-12 05:49:05 +08:00
|
|
|
static async_cookie_t async_cookie;
|
2017-04-19 20:02:09 +08:00
|
|
|
static bool battery_driver_registered;
|
2014-01-06 22:50:37 +08:00
|
|
|
static int battery_bix_broken_package;
|
2014-06-04 03:01:23 +08:00
|
|
|
static int battery_notification_delay_ms;
|
2018-04-12 18:02:00 +08:00
|
|
|
static int battery_ac_is_broken;
|
2018-04-18 20:04:39 +08:00
|
|
|
static int battery_check_pmic = 1;
|
2007-09-26 23:42:52 +08:00
|
|
|
static unsigned int cache_time = 1000;
|
|
|
|
|
module_param(cache_time, uint, 0644);
|
|
|
|
|
MODULE_PARM_DESC(cache_time, "cache time in milliseconds");
|
2007-02-20 20:48:06 +08:00
|
|
|
|
2007-07-23 20:44:41 +08:00
|
|
|
static const struct acpi_device_id battery_device_ids[] = {
|
|
|
|
|
{"PNP0C0A", 0},
|
|
|
|
|
{"", 0},
|
|
|
|
|
};
|
|
|
|
|
|
2007-09-26 23:42:58 +08:00
|
|
|
MODULE_DEVICE_TABLE(acpi, battery_device_ids);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2017-04-19 20:02:10 +08:00
|
|
|
/* Lists of PMIC ACPI HIDs with an (often better) native battery driver */
|
|
|
|
|
static const char * const acpi_battery_blacklist[] = {
|
|
|
|
|
"INT33F4", /* X-Powers AXP288 PMIC */
|
|
|
|
|
};
|
|
|
|
|
|
2009-10-15 18:31:24 +08:00
|
|
|
enum {
|
|
|
|
|
ACPI_BATTERY_ALARM_PRESENT,
|
2009-10-15 18:31:44 +08:00
|
|
|
ACPI_BATTERY_XINFO_PRESENT,
|
2010-10-22 10:02:06 +08:00
|
|
|
ACPI_BATTERY_QUIRK_PERCENTAGE_CAPACITY,
|
ACPI / battery: Correct battery capacity values on Thinkpads
Add a quirk to correctly report battery capacity on 2010 and 2011
Lenovo Thinkpad models.
The affected models that I tested (x201, t410, t410s, and x220)
exhibit a problem where, when battery capacity reporting unit is mAh,
the values being reported are wrong. Pre-2010 and 2012 models appear
to always report in mWh and are thus unaffected. Also, in mid-2012
Lenovo issued a BIOS update for the 2011 models that fixes the issue
(tested on x220 with a post-1.29 BIOS). No such update is available
for the 2010 models, so those still need this patch.
Problem description: for some reason, the affected Thinkpads switch
the reporting unit between mAh and mWh; generally, mAh is used when a
laptop is plugged in and mWh when it's unplugged, although a
suspend/resume or rmmod/modprobe is needed for the switch to take
effect. The values reported in mAh are *always* wrong. This does
not appear to be a kernel regression; I believe that the values were
never reported correctly. I tested back to kernel 2.6.34, with
multiple machines and BIOS versions.
Simply plugging a laptop into mains before turning it on is enough to
reproduce the problem. Here's a sample /proc/acpi/battery/BAT0/info
from Thinkpad x220 (before a BIOS update) with a 4-cell battery:
present: yes
design capacity: 2886 mAh
last full capacity: 2909 mAh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 145 mAh
design capacity low: 13 mAh
cycle count: 0
capacity granularity 1: 1 mAh
capacity granularity 2: 1 mAh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Once the laptop switches the unit to mWh (unplug from mains, suspend,
resume), the output changes to:
present: yes
design capacity: 28860 mWh
last full capacity: 29090 mWh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 1454 mWh
design capacity low: 200 mWh
cycle count: 0
capacity granularity 1: 1 mWh
capacity granularity 2: 1 mWh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Can you see how the values for "design capacity", etc., differ by a
factor of 10 instead of 14.8 (the design voltage of this battery)?
On the battery itself it says: 14.8V, 1.95Ah, 29Wh, so clearly the
values reported in mWh are correct and the ones in mAh are not.
My guess is that this problem has been around ever since those
machines were released, but because the most common Thinkpad
batteries are rated at 10.8V, the error (8%) is small enough that it
simply hasn't been noticed or at least nobody could be bothered to
look into it.
My patch works around the problem by adjusting the incorrectly
reported mAh values by "10000 / design_voltage". The patch also has
code to figure out if it should be activated or not. It only
activates on Lenovo Thinkpads, only when the unit is mAh, and, as an
extra precaution, only when the battery capacity reported through
ACPI does not match what is reported through DMI (I've never
encountered a machine where the first two conditions would be true
but the last would not, but better safe than sorry).
I've been using this patch for close to a year on several systems
without any problems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=41062
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-17 05:28:58 +08:00
|
|
|
/* On Lenovo Thinkpad models from 2010 and 2011, the power unit
|
2021-03-27 20:08:18 +08:00
|
|
|
* switches between mWh and mAh depending on whether the system
|
|
|
|
|
* is running on battery or not. When mAh is the unit, most
|
|
|
|
|
* reported values are incorrect and need to be adjusted by
|
|
|
|
|
* 10000/design_voltage. Verified on x201, t410, t410s, and x220.
|
|
|
|
|
* Pre-2010 and 2012 models appear to always report in mWh and
|
|
|
|
|
* are thus unaffected (tested with t42, t61, t500, x200, x300,
|
|
|
|
|
* and x230). Also, in mid-2012 Lenovo issued a BIOS update for
|
|
|
|
|
* the 2011 models that fixes the issue (tested on x220 with a
|
|
|
|
|
* post-1.29 BIOS), but as of Nov. 2012, no such update is
|
|
|
|
|
* available for the 2010 models.
|
|
|
|
|
*/
|
ACPI / battery: Correct battery capacity values on Thinkpads
Add a quirk to correctly report battery capacity on 2010 and 2011
Lenovo Thinkpad models.
The affected models that I tested (x201, t410, t410s, and x220)
exhibit a problem where, when battery capacity reporting unit is mAh,
the values being reported are wrong. Pre-2010 and 2012 models appear
to always report in mWh and are thus unaffected. Also, in mid-2012
Lenovo issued a BIOS update for the 2011 models that fixes the issue
(tested on x220 with a post-1.29 BIOS). No such update is available
for the 2010 models, so those still need this patch.
Problem description: for some reason, the affected Thinkpads switch
the reporting unit between mAh and mWh; generally, mAh is used when a
laptop is plugged in and mWh when it's unplugged, although a
suspend/resume or rmmod/modprobe is needed for the switch to take
effect. The values reported in mAh are *always* wrong. This does
not appear to be a kernel regression; I believe that the values were
never reported correctly. I tested back to kernel 2.6.34, with
multiple machines and BIOS versions.
Simply plugging a laptop into mains before turning it on is enough to
reproduce the problem. Here's a sample /proc/acpi/battery/BAT0/info
from Thinkpad x220 (before a BIOS update) with a 4-cell battery:
present: yes
design capacity: 2886 mAh
last full capacity: 2909 mAh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 145 mAh
design capacity low: 13 mAh
cycle count: 0
capacity granularity 1: 1 mAh
capacity granularity 2: 1 mAh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Once the laptop switches the unit to mWh (unplug from mains, suspend,
resume), the output changes to:
present: yes
design capacity: 28860 mWh
last full capacity: 29090 mWh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 1454 mWh
design capacity low: 200 mWh
cycle count: 0
capacity granularity 1: 1 mWh
capacity granularity 2: 1 mWh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Can you see how the values for "design capacity", etc., differ by a
factor of 10 instead of 14.8 (the design voltage of this battery)?
On the battery itself it says: 14.8V, 1.95Ah, 29Wh, so clearly the
values reported in mWh are correct and the ones in mAh are not.
My guess is that this problem has been around ever since those
machines were released, but because the most common Thinkpad
batteries are rated at 10.8V, the error (8%) is small enough that it
simply hasn't been noticed or at least nobody could be bothered to
look into it.
My patch works around the problem by adjusting the incorrectly
reported mAh values by "10000 / design_voltage". The patch also has
code to figure out if it should be activated or not. It only
activates on Lenovo Thinkpads, only when the unit is mAh, and, as an
extra precaution, only when the battery capacity reported through
ACPI does not match what is reported through DMI (I've never
encountered a machine where the first two conditions would be true
but the last would not, but better safe than sorry).
I've been using this patch for close to a year on several systems
without any problems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=41062
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-17 05:28:58 +08:00
|
|
|
ACPI_BATTERY_QUIRK_THINKPAD_MAH,
|
2018-02-24 17:20:15 +08:00
|
|
|
/* for batteries reporting current capacity with design capacity
|
|
|
|
|
* on a full charge, but showing degradation in full charge cap.
|
|
|
|
|
*/
|
|
|
|
|
ACPI_BATTERY_QUIRK_DEGRADED_FULL_CHARGE,
|
2009-10-15 18:31:24 +08:00
|
|
|
};
|
2007-05-12 01:18:55 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
struct acpi_battery {
|
2007-09-26 23:42:46 +08:00
|
|
|
struct mutex lock;
|
2011-08-06 06:34:08 +08:00
|
|
|
struct mutex sysfs_lock;
|
2015-03-12 15:44:11 +08:00
|
|
|
struct power_supply *bat;
|
|
|
|
|
struct power_supply_desc bat_desc;
|
2007-09-26 23:42:52 +08:00
|
|
|
struct acpi_device *device;
|
2011-03-23 04:19:50 +08:00
|
|
|
struct notifier_block pm_nb;
|
2018-02-07 22:58:13 +08:00
|
|
|
struct list_head list;
|
2007-09-26 23:42:52 +08:00
|
|
|
unsigned long update_time;
|
2013-07-30 20:00:42 +08:00
|
|
|
int revision;
|
2009-03-28 10:23:52 +08:00
|
|
|
int rate_now;
|
2007-09-26 23:43:04 +08:00
|
|
|
int capacity_now;
|
|
|
|
|
int voltage_now;
|
2007-09-26 23:42:46 +08:00
|
|
|
int design_capacity;
|
2007-09-26 23:43:04 +08:00
|
|
|
int full_charge_capacity;
|
2007-09-26 23:42:46 +08:00
|
|
|
int technology;
|
|
|
|
|
int design_voltage;
|
|
|
|
|
int design_capacity_warning;
|
|
|
|
|
int design_capacity_low;
|
2009-10-15 18:31:44 +08:00
|
|
|
int cycle_count;
|
|
|
|
|
int measurement_accuracy;
|
|
|
|
|
int max_sampling_time;
|
|
|
|
|
int min_sampling_time;
|
|
|
|
|
int max_averaging_interval;
|
|
|
|
|
int min_averaging_interval;
|
2007-09-26 23:42:46 +08:00
|
|
|
int capacity_granularity_1;
|
|
|
|
|
int capacity_granularity_2;
|
2007-09-26 23:42:52 +08:00
|
|
|
int alarm;
|
2007-09-26 23:42:46 +08:00
|
|
|
char model_number[32];
|
|
|
|
|
char serial_number[32];
|
|
|
|
|
char type[32];
|
|
|
|
|
char oem_info[32];
|
2007-09-26 23:42:52 +08:00
|
|
|
int state;
|
|
|
|
|
int power_unit;
|
2009-10-15 18:31:24 +08:00
|
|
|
unsigned long flags;
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
|
2015-03-12 15:44:11 +08:00
|
|
|
#define to_acpi_battery(x) power_supply_get_drvdata(x)
|
2007-09-26 23:43:04 +08:00
|
|
|
|
2013-03-11 17:17:06 +08:00
|
|
|
static inline int acpi_battery_present(struct acpi_battery *battery)
|
2007-02-20 20:48:06 +08:00
|
|
|
{
|
2007-05-12 01:18:55 +08:00
|
|
|
return battery->device->status.battery_present;
|
|
|
|
|
}
|
2007-09-26 23:42:46 +08:00
|
|
|
|
2007-09-26 23:43:04 +08:00
|
|
|
static int acpi_battery_technology(struct acpi_battery *battery)
|
|
|
|
|
{
|
|
|
|
|
if (!strcasecmp("NiCd", battery->type))
|
|
|
|
|
return POWER_SUPPLY_TECHNOLOGY_NiCd;
|
|
|
|
|
if (!strcasecmp("NiMH", battery->type))
|
|
|
|
|
return POWER_SUPPLY_TECHNOLOGY_NiMH;
|
|
|
|
|
if (!strcasecmp("LION", battery->type))
|
|
|
|
|
return POWER_SUPPLY_TECHNOLOGY_LION;
|
2007-11-11 01:02:49 +08:00
|
|
|
if (!strncasecmp("LI-ION", battery->type, 6))
|
2007-10-28 20:33:10 +08:00
|
|
|
return POWER_SUPPLY_TECHNOLOGY_LION;
|
2007-09-26 23:43:04 +08:00
|
|
|
if (!strcasecmp("LiP", battery->type))
|
|
|
|
|
return POWER_SUPPLY_TECHNOLOGY_LIPO;
|
|
|
|
|
return POWER_SUPPLY_TECHNOLOGY_UNKNOWN;
|
|
|
|
|
}
|
|
|
|
|
|
2007-11-13 17:23:06 +08:00
|
|
|
static int acpi_battery_get_state(struct acpi_battery *battery);
|
2007-10-26 05:10:47 +08:00
|
|
|
|
2009-01-25 23:05:50 +08:00
|
|
|
static int acpi_battery_is_charged(struct acpi_battery *battery)
|
|
|
|
|
{
|
2014-05-28 15:23:36 +08:00
|
|
|
/* charging, discharging or critical low */
|
2009-01-25 23:05:50 +08:00
|
|
|
if (battery->state != 0)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
/* battery not reporting charge */
|
|
|
|
|
if (battery->capacity_now == ACPI_BATTERY_VALUE_UNKNOWN ||
|
|
|
|
|
battery->capacity_now == 0)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
/* good batteries update full_charge as the batteries degrade */
|
|
|
|
|
if (battery->full_charge_capacity == battery->capacity_now)
|
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
|
|
/* fallback to using design values for broken batteries */
|
|
|
|
|
if (battery->design_capacity == battery->capacity_now)
|
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
|
|
/* we don't do any sort of metric based on percentages */
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2018-02-24 17:20:15 +08:00
|
|
|
static bool acpi_battery_is_degraded(struct acpi_battery *battery)
|
|
|
|
|
{
|
2019-12-10 17:57:50 +08:00
|
|
|
return ACPI_BATTERY_CAPACITY_VALID(battery->full_charge_capacity) &&
|
|
|
|
|
ACPI_BATTERY_CAPACITY_VALID(battery->design_capacity) &&
|
2018-02-24 17:20:15 +08:00
|
|
|
battery->full_charge_capacity < battery->design_capacity;
|
|
|
|
|
}
|
|
|
|
|
|
ACPI / battery: Add handling for devices which wrongly report discharging state
On quite a few devices the battery code in the ACPI tables is buggy and
first checks the charging status bits of the charger-IC, and if those
report not charging it will report discharging, without looking at the
presence of AC power or at the battery dis(charge) current from the
fuel-gauge.
This causes the wrong status to be reported for the battery in the
following quite common scenario:
1) Plug in charger while battery is say half full, battery starts
charging, charging state bits indicate: pre-charge or fast-charge,
ACPI reported battery status is ok
2) When fully charged charging state bits indicate: end-of-charge,
ACPI reported battery status is ok
3) unplug the charger, wait 1 minute, replug. Now the battery voltage is
still above the start-charging threshold, so the charger will not start
charging to avoid wrecking the battery by repeatedly recharging the last 1%
capacity. The charger IC charging state bits now are all 0 (not-charging)
and the broken ACPI code wrongly translate this to "discharging" and ends
up setting the ACPI_BATTERY_STATE_DISCHARGING bit in its state field.
Reporting this "not charging" state as discharging is confusing for users,
making the user think his adapter/power-brick is broken or not properly
plugged in.
This commit adds a helper for handling the ACPI_BATTERY_STATE_DISCHARGING
state. This helper checks if we're an AC and the current going out of the
battery is 0 and in that case reports a status of "not charging" to
userspace rather then "discharging".
This replaces commit c68f0676ef7d ("ACPI / battery: Add quirk for Asus
GL502VSK and UX305LA"), a previous fix for this which was reverted.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Daniel Drake <drake@endlessm.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-04-12 18:01:59 +08:00
|
|
|
static int acpi_battery_handle_discharging(struct acpi_battery *battery)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* Some devices wrongly report discharging if the battery's charge level
|
|
|
|
|
* was above the device's start charging threshold atm the AC adapter
|
|
|
|
|
* was plugged in and the device thus did not start a new charge cycle.
|
|
|
|
|
*/
|
2018-04-12 18:02:00 +08:00
|
|
|
if ((battery_ac_is_broken || power_supply_is_system_supplied()) &&
|
|
|
|
|
battery->rate_now == 0)
|
ACPI / battery: Add handling for devices which wrongly report discharging state
On quite a few devices the battery code in the ACPI tables is buggy and
first checks the charging status bits of the charger-IC, and if those
report not charging it will report discharging, without looking at the
presence of AC power or at the battery dis(charge) current from the
fuel-gauge.
This causes the wrong status to be reported for the battery in the
following quite common scenario:
1) Plug in charger while battery is say half full, battery starts
charging, charging state bits indicate: pre-charge or fast-charge,
ACPI reported battery status is ok
2) When fully charged charging state bits indicate: end-of-charge,
ACPI reported battery status is ok
3) unplug the charger, wait 1 minute, replug. Now the battery voltage is
still above the start-charging threshold, so the charger will not start
charging to avoid wrecking the battery by repeatedly recharging the last 1%
capacity. The charger IC charging state bits now are all 0 (not-charging)
and the broken ACPI code wrongly translate this to "discharging" and ends
up setting the ACPI_BATTERY_STATE_DISCHARGING bit in its state field.
Reporting this "not charging" state as discharging is confusing for users,
making the user think his adapter/power-brick is broken or not properly
plugged in.
This commit adds a helper for handling the ACPI_BATTERY_STATE_DISCHARGING
state. This helper checks if we're an AC and the current going out of the
battery is 0 and in that case reports a status of "not charging" to
userspace rather then "discharging".
This replaces commit c68f0676ef7d ("ACPI / battery: Add quirk for Asus
GL502VSK and UX305LA"), a previous fix for this which was reverted.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Daniel Drake <drake@endlessm.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-04-12 18:01:59 +08:00
|
|
|
return POWER_SUPPLY_STATUS_NOT_CHARGING;
|
|
|
|
|
|
|
|
|
|
return POWER_SUPPLY_STATUS_DISCHARGING;
|
|
|
|
|
}
|
|
|
|
|
|
2007-09-26 23:43:04 +08:00
|
|
|
static int acpi_battery_get_property(struct power_supply *psy,
|
|
|
|
|
enum power_supply_property psp,
|
|
|
|
|
union power_supply_propval *val)
|
|
|
|
|
{
|
2019-12-10 17:57:51 +08:00
|
|
|
int full_capacity = ACPI_BATTERY_VALUE_UNKNOWN, ret = 0;
|
2007-09-26 23:43:04 +08:00
|
|
|
struct acpi_battery *battery = to_acpi_battery(psy);
|
|
|
|
|
|
2007-11-13 17:23:06 +08:00
|
|
|
if (acpi_battery_present(battery)) {
|
|
|
|
|
/* run battery update only if it is present */
|
|
|
|
|
acpi_battery_get_state(battery);
|
|
|
|
|
} else if (psp != POWER_SUPPLY_PROP_PRESENT)
|
2007-09-26 23:43:04 +08:00
|
|
|
return -ENODEV;
|
|
|
|
|
switch (psp) {
|
|
|
|
|
case POWER_SUPPLY_PROP_STATUS:
|
Revert "ACPI / battery: Add quirk for Asus GL502VSK and UX305LA"
Revert commit c68f0676ef7d ("ACPI / battery: Add quirk for Asus
GL502VSK and UX305LA") and commit 4446823e2573 ("ACPI / battery: Add
quirk for Asus UX360UA and UX410UAK").
On many many Asus products, the battery is sometimes reported as
charging or discharging even when it is full and you are on AC power.
This change quirked the kernel to avoid advertising the discharging
state when this happens on 4 laptop models, under the belief that
this was incorrect information. I presume it originates from user
reports who are confused that their battery status icon says that it
is discharging.
However, the reported information is indeed correct, and the quirk
approach taken is inadequate and more thought is needed first.
Specifically:
1. It only quirks discharging state, not charging
2. There are so many different Asus products and DMI naming variants
within those product families that behave this way; Linux could
grow to quirk hundreds of products and still not even be close at
"winning" this battle.
3. Asus previously clarified that this behaviour is intentional. The
platform will periodically do a partial discharge/charge cycle
when the battery is full, because this is one way to extend the
lifetime of the battery (leaving a battery at 100% charge and
unused will decrease its usable capacity over time).
My understanding is that any decent consumer product will have
this behaviour, but it appears that Asus is different in that
they expose this info through ACPI.
However, the behaviour seems correct. The ACPI spec does not
suggest in that the platform should hide the truth. It lets you
report that the battery is full of charge, and discharging, and
with external power connected; and Asus does this.
4. In terms of not confusing the user, this seems like something that
could/should be handled by userspace, which can also detect these
same (accurate) conditions in the general case.
Revert this quirk before it gets included in a release, while we look
for better approaches.
Signed-off-by: Daniel Drake <drake@endlessm.com>
Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-14 16:42:17 +08:00
|
|
|
if (battery->state & ACPI_BATTERY_STATE_DISCHARGING)
|
ACPI / battery: Add handling for devices which wrongly report discharging state
On quite a few devices the battery code in the ACPI tables is buggy and
first checks the charging status bits of the charger-IC, and if those
report not charging it will report discharging, without looking at the
presence of AC power or at the battery dis(charge) current from the
fuel-gauge.
This causes the wrong status to be reported for the battery in the
following quite common scenario:
1) Plug in charger while battery is say half full, battery starts
charging, charging state bits indicate: pre-charge or fast-charge,
ACPI reported battery status is ok
2) When fully charged charging state bits indicate: end-of-charge,
ACPI reported battery status is ok
3) unplug the charger, wait 1 minute, replug. Now the battery voltage is
still above the start-charging threshold, so the charger will not start
charging to avoid wrecking the battery by repeatedly recharging the last 1%
capacity. The charger IC charging state bits now are all 0 (not-charging)
and the broken ACPI code wrongly translate this to "discharging" and ends
up setting the ACPI_BATTERY_STATE_DISCHARGING bit in its state field.
Reporting this "not charging" state as discharging is confusing for users,
making the user think his adapter/power-brick is broken or not properly
plugged in.
This commit adds a helper for handling the ACPI_BATTERY_STATE_DISCHARGING
state. This helper checks if we're an AC and the current going out of the
battery is 0 and in that case reports a status of "not charging" to
userspace rather then "discharging".
This replaces commit c68f0676ef7d ("ACPI / battery: Add quirk for Asus
GL502VSK and UX305LA"), a previous fix for this which was reverted.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Daniel Drake <drake@endlessm.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-04-12 18:01:59 +08:00
|
|
|
val->intval = acpi_battery_handle_discharging(battery);
|
Revert "ACPI / battery: Add quirk for Asus GL502VSK and UX305LA"
Revert commit c68f0676ef7d ("ACPI / battery: Add quirk for Asus
GL502VSK and UX305LA") and commit 4446823e2573 ("ACPI / battery: Add
quirk for Asus UX360UA and UX410UAK").
On many many Asus products, the battery is sometimes reported as
charging or discharging even when it is full and you are on AC power.
This change quirked the kernel to avoid advertising the discharging
state when this happens on 4 laptop models, under the belief that
this was incorrect information. I presume it originates from user
reports who are confused that their battery status icon says that it
is discharging.
However, the reported information is indeed correct, and the quirk
approach taken is inadequate and more thought is needed first.
Specifically:
1. It only quirks discharging state, not charging
2. There are so many different Asus products and DMI naming variants
within those product families that behave this way; Linux could
grow to quirk hundreds of products and still not even be close at
"winning" this battle.
3. Asus previously clarified that this behaviour is intentional. The
platform will periodically do a partial discharge/charge cycle
when the battery is full, because this is one way to extend the
lifetime of the battery (leaving a battery at 100% charge and
unused will decrease its usable capacity over time).
My understanding is that any decent consumer product will have
this behaviour, but it appears that Asus is different in that
they expose this info through ACPI.
However, the behaviour seems correct. The ACPI spec does not
suggest in that the platform should hide the truth. It lets you
report that the battery is full of charge, and discharging, and
with external power connected; and Asus does this.
4. In terms of not confusing the user, this seems like something that
could/should be handled by userspace, which can also detect these
same (accurate) conditions in the general case.
Revert this quirk before it gets included in a release, while we look
for better approaches.
Signed-off-by: Daniel Drake <drake@endlessm.com>
Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-14 16:42:17 +08:00
|
|
|
else if (battery->state & ACPI_BATTERY_STATE_CHARGING)
|
2007-09-26 23:43:04 +08:00
|
|
|
val->intval = POWER_SUPPLY_STATUS_CHARGING;
|
2009-01-25 23:05:50 +08:00
|
|
|
else if (acpi_battery_is_charged(battery))
|
2007-09-26 23:43:04 +08:00
|
|
|
val->intval = POWER_SUPPLY_STATUS_FULL;
|
2007-11-08 07:09:09 +08:00
|
|
|
else
|
|
|
|
|
val->intval = POWER_SUPPLY_STATUS_UNKNOWN;
|
2007-09-26 23:43:04 +08:00
|
|
|
break;
|
|
|
|
|
case POWER_SUPPLY_PROP_PRESENT:
|
|
|
|
|
val->intval = acpi_battery_present(battery);
|
|
|
|
|
break;
|
|
|
|
|
case POWER_SUPPLY_PROP_TECHNOLOGY:
|
|
|
|
|
val->intval = acpi_battery_technology(battery);
|
|
|
|
|
break;
|
2009-10-15 18:31:44 +08:00
|
|
|
case POWER_SUPPLY_PROP_CYCLE_COUNT:
|
|
|
|
|
val->intval = battery->cycle_count;
|
|
|
|
|
break;
|
2007-09-26 23:43:04 +08:00
|
|
|
case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN:
|
2010-10-24 01:35:15 +08:00
|
|
|
if (battery->design_voltage == ACPI_BATTERY_VALUE_UNKNOWN)
|
|
|
|
|
ret = -ENODEV;
|
|
|
|
|
else
|
|
|
|
|
val->intval = battery->design_voltage * 1000;
|
2007-09-26 23:43:04 +08:00
|
|
|
break;
|
|
|
|
|
case POWER_SUPPLY_PROP_VOLTAGE_NOW:
|
2010-10-24 01:35:15 +08:00
|
|
|
if (battery->voltage_now == ACPI_BATTERY_VALUE_UNKNOWN)
|
|
|
|
|
ret = -ENODEV;
|
|
|
|
|
else
|
|
|
|
|
val->intval = battery->voltage_now * 1000;
|
2007-09-26 23:43:04 +08:00
|
|
|
break;
|
|
|
|
|
case POWER_SUPPLY_PROP_CURRENT_NOW:
|
2009-03-28 10:23:52 +08:00
|
|
|
case POWER_SUPPLY_PROP_POWER_NOW:
|
2010-10-24 01:35:15 +08:00
|
|
|
if (battery->rate_now == ACPI_BATTERY_VALUE_UNKNOWN)
|
|
|
|
|
ret = -ENODEV;
|
|
|
|
|
else
|
|
|
|
|
val->intval = battery->rate_now * 1000;
|
2007-09-26 23:43:04 +08:00
|
|
|
break;
|
|
|
|
|
case POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN:
|
|
|
|
|
case POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN:
|
2019-12-10 17:57:50 +08:00
|
|
|
if (!ACPI_BATTERY_CAPACITY_VALID(battery->design_capacity))
|
2010-10-24 01:35:15 +08:00
|
|
|
ret = -ENODEV;
|
|
|
|
|
else
|
|
|
|
|
val->intval = battery->design_capacity * 1000;
|
2007-09-26 23:43:04 +08:00
|
|
|
break;
|
|
|
|
|
case POWER_SUPPLY_PROP_CHARGE_FULL:
|
|
|
|
|
case POWER_SUPPLY_PROP_ENERGY_FULL:
|
2019-12-10 17:57:50 +08:00
|
|
|
if (!ACPI_BATTERY_CAPACITY_VALID(battery->full_charge_capacity))
|
2010-10-24 01:35:15 +08:00
|
|
|
ret = -ENODEV;
|
|
|
|
|
else
|
|
|
|
|
val->intval = battery->full_charge_capacity * 1000;
|
2007-09-26 23:43:04 +08:00
|
|
|
break;
|
|
|
|
|
case POWER_SUPPLY_PROP_CHARGE_NOW:
|
|
|
|
|
case POWER_SUPPLY_PROP_ENERGY_NOW:
|
2010-10-24 01:35:15 +08:00
|
|
|
if (battery->capacity_now == ACPI_BATTERY_VALUE_UNKNOWN)
|
|
|
|
|
ret = -ENODEV;
|
|
|
|
|
else
|
|
|
|
|
val->intval = battery->capacity_now * 1000;
|
2007-09-26 23:43:04 +08:00
|
|
|
break;
|
2012-04-06 08:38:54 +08:00
|
|
|
case POWER_SUPPLY_PROP_CAPACITY:
|
2019-12-10 17:57:51 +08:00
|
|
|
if (ACPI_BATTERY_CAPACITY_VALID(battery->full_charge_capacity))
|
|
|
|
|
full_capacity = battery->full_charge_capacity;
|
|
|
|
|
else if (ACPI_BATTERY_CAPACITY_VALID(battery->design_capacity))
|
|
|
|
|
full_capacity = battery->design_capacity;
|
|
|
|
|
|
2019-12-10 17:57:50 +08:00
|
|
|
if (battery->capacity_now == ACPI_BATTERY_VALUE_UNKNOWN ||
|
2019-12-10 17:57:51 +08:00
|
|
|
full_capacity == ACPI_BATTERY_VALUE_UNKNOWN)
|
2019-12-10 17:57:50 +08:00
|
|
|
ret = -ENODEV;
|
|
|
|
|
else
|
2012-04-06 08:38:54 +08:00
|
|
|
val->intval = battery->capacity_now * 100/
|
2019-12-10 17:57:51 +08:00
|
|
|
full_capacity;
|
2012-04-06 08:38:54 +08:00
|
|
|
break;
|
2014-05-28 15:23:36 +08:00
|
|
|
case POWER_SUPPLY_PROP_CAPACITY_LEVEL:
|
|
|
|
|
if (battery->state & ACPI_BATTERY_STATE_CRITICAL)
|
|
|
|
|
val->intval = POWER_SUPPLY_CAPACITY_LEVEL_CRITICAL;
|
|
|
|
|
else if (test_bit(ACPI_BATTERY_ALARM_PRESENT, &battery->flags) &&
|
|
|
|
|
(battery->capacity_now <= battery->alarm))
|
|
|
|
|
val->intval = POWER_SUPPLY_CAPACITY_LEVEL_LOW;
|
|
|
|
|
else if (acpi_battery_is_charged(battery))
|
|
|
|
|
val->intval = POWER_SUPPLY_CAPACITY_LEVEL_FULL;
|
|
|
|
|
else
|
|
|
|
|
val->intval = POWER_SUPPLY_CAPACITY_LEVEL_NORMAL;
|
|
|
|
|
break;
|
2007-09-26 23:43:04 +08:00
|
|
|
case POWER_SUPPLY_PROP_MODEL_NAME:
|
|
|
|
|
val->strval = battery->model_number;
|
|
|
|
|
break;
|
|
|
|
|
case POWER_SUPPLY_PROP_MANUFACTURER:
|
|
|
|
|
val->strval = battery->oem_info;
|
|
|
|
|
break;
|
2008-01-23 01:46:50 +08:00
|
|
|
case POWER_SUPPLY_PROP_SERIAL_NUMBER:
|
|
|
|
|
val->strval = battery->serial_number;
|
|
|
|
|
break;
|
2007-09-26 23:43:04 +08:00
|
|
|
default:
|
2010-10-24 01:35:15 +08:00
|
|
|
ret = -EINVAL;
|
2007-09-26 23:43:04 +08:00
|
|
|
}
|
2010-10-24 01:35:15 +08:00
|
|
|
return ret;
|
2007-09-26 23:43:04 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static enum power_supply_property charge_battery_props[] = {
|
|
|
|
|
POWER_SUPPLY_PROP_STATUS,
|
|
|
|
|
POWER_SUPPLY_PROP_PRESENT,
|
|
|
|
|
POWER_SUPPLY_PROP_TECHNOLOGY,
|
2009-10-15 18:31:44 +08:00
|
|
|
POWER_SUPPLY_PROP_CYCLE_COUNT,
|
2007-09-26 23:43:04 +08:00
|
|
|
POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN,
|
|
|
|
|
POWER_SUPPLY_PROP_VOLTAGE_NOW,
|
|
|
|
|
POWER_SUPPLY_PROP_CURRENT_NOW,
|
|
|
|
|
POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
|
|
|
|
|
POWER_SUPPLY_PROP_CHARGE_FULL,
|
|
|
|
|
POWER_SUPPLY_PROP_CHARGE_NOW,
|
2012-04-06 08:38:54 +08:00
|
|
|
POWER_SUPPLY_PROP_CAPACITY,
|
2014-05-28 15:23:36 +08:00
|
|
|
POWER_SUPPLY_PROP_CAPACITY_LEVEL,
|
2007-09-26 23:43:04 +08:00
|
|
|
POWER_SUPPLY_PROP_MODEL_NAME,
|
|
|
|
|
POWER_SUPPLY_PROP_MANUFACTURER,
|
2008-01-23 01:46:50 +08:00
|
|
|
POWER_SUPPLY_PROP_SERIAL_NUMBER,
|
2007-09-26 23:43:04 +08:00
|
|
|
};
|
|
|
|
|
|
2019-12-10 17:57:52 +08:00
|
|
|
static enum power_supply_property charge_battery_full_cap_broken_props[] = {
|
|
|
|
|
POWER_SUPPLY_PROP_STATUS,
|
|
|
|
|
POWER_SUPPLY_PROP_PRESENT,
|
|
|
|
|
POWER_SUPPLY_PROP_TECHNOLOGY,
|
|
|
|
|
POWER_SUPPLY_PROP_CYCLE_COUNT,
|
|
|
|
|
POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN,
|
|
|
|
|
POWER_SUPPLY_PROP_VOLTAGE_NOW,
|
|
|
|
|
POWER_SUPPLY_PROP_CURRENT_NOW,
|
|
|
|
|
POWER_SUPPLY_PROP_CHARGE_NOW,
|
|
|
|
|
POWER_SUPPLY_PROP_MODEL_NAME,
|
|
|
|
|
POWER_SUPPLY_PROP_MANUFACTURER,
|
|
|
|
|
POWER_SUPPLY_PROP_SERIAL_NUMBER,
|
|
|
|
|
};
|
|
|
|
|
|
2007-09-26 23:43:04 +08:00
|
|
|
static enum power_supply_property energy_battery_props[] = {
|
|
|
|
|
POWER_SUPPLY_PROP_STATUS,
|
|
|
|
|
POWER_SUPPLY_PROP_PRESENT,
|
|
|
|
|
POWER_SUPPLY_PROP_TECHNOLOGY,
|
2009-10-15 18:31:44 +08:00
|
|
|
POWER_SUPPLY_PROP_CYCLE_COUNT,
|
2007-09-26 23:43:04 +08:00
|
|
|
POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN,
|
|
|
|
|
POWER_SUPPLY_PROP_VOLTAGE_NOW,
|
2009-03-28 10:23:52 +08:00
|
|
|
POWER_SUPPLY_PROP_POWER_NOW,
|
2007-09-26 23:43:04 +08:00
|
|
|
POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN,
|
|
|
|
|
POWER_SUPPLY_PROP_ENERGY_FULL,
|
|
|
|
|
POWER_SUPPLY_PROP_ENERGY_NOW,
|
2012-04-06 08:38:54 +08:00
|
|
|
POWER_SUPPLY_PROP_CAPACITY,
|
2014-05-28 15:23:36 +08:00
|
|
|
POWER_SUPPLY_PROP_CAPACITY_LEVEL,
|
2007-09-26 23:43:04 +08:00
|
|
|
POWER_SUPPLY_PROP_MODEL_NAME,
|
|
|
|
|
POWER_SUPPLY_PROP_MANUFACTURER,
|
2008-01-23 01:46:50 +08:00
|
|
|
POWER_SUPPLY_PROP_SERIAL_NUMBER,
|
2007-09-26 23:43:04 +08:00
|
|
|
};
|
|
|
|
|
|
2018-08-07 15:36:30 +08:00
|
|
|
static enum power_supply_property energy_battery_full_cap_broken_props[] = {
|
|
|
|
|
POWER_SUPPLY_PROP_STATUS,
|
|
|
|
|
POWER_SUPPLY_PROP_PRESENT,
|
|
|
|
|
POWER_SUPPLY_PROP_TECHNOLOGY,
|
|
|
|
|
POWER_SUPPLY_PROP_CYCLE_COUNT,
|
|
|
|
|
POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN,
|
|
|
|
|
POWER_SUPPLY_PROP_VOLTAGE_NOW,
|
|
|
|
|
POWER_SUPPLY_PROP_POWER_NOW,
|
|
|
|
|
POWER_SUPPLY_PROP_ENERGY_NOW,
|
|
|
|
|
POWER_SUPPLY_PROP_MODEL_NAME,
|
|
|
|
|
POWER_SUPPLY_PROP_MANUFACTURER,
|
|
|
|
|
POWER_SUPPLY_PROP_SERIAL_NUMBER,
|
|
|
|
|
};
|
|
|
|
|
|
2021-03-27 20:08:18 +08:00
|
|
|
/* Battery Management */
|
2007-09-26 23:42:46 +08:00
|
|
|
struct acpi_offsets {
|
|
|
|
|
size_t offset; /* offset inside struct acpi_sbs_battery */
|
|
|
|
|
u8 mode; /* int or string? */
|
|
|
|
|
};
|
2007-02-20 20:48:06 +08:00
|
|
|
|
2015-06-13 20:26:53 +08:00
|
|
|
static const struct acpi_offsets state_offsets[] = {
|
2007-09-26 23:42:46 +08:00
|
|
|
{offsetof(struct acpi_battery, state), 0},
|
2009-03-28 10:23:52 +08:00
|
|
|
{offsetof(struct acpi_battery, rate_now), 0},
|
2007-09-26 23:43:04 +08:00
|
|
|
{offsetof(struct acpi_battery, capacity_now), 0},
|
|
|
|
|
{offsetof(struct acpi_battery, voltage_now), 0},
|
2007-09-26 23:42:46 +08:00
|
|
|
};
|
2007-02-20 20:48:06 +08:00
|
|
|
|
2015-06-13 20:26:53 +08:00
|
|
|
static const struct acpi_offsets info_offsets[] = {
|
2007-09-26 23:42:46 +08:00
|
|
|
{offsetof(struct acpi_battery, power_unit), 0},
|
|
|
|
|
{offsetof(struct acpi_battery, design_capacity), 0},
|
2007-09-26 23:43:04 +08:00
|
|
|
{offsetof(struct acpi_battery, full_charge_capacity), 0},
|
2007-09-26 23:42:46 +08:00
|
|
|
{offsetof(struct acpi_battery, technology), 0},
|
|
|
|
|
{offsetof(struct acpi_battery, design_voltage), 0},
|
|
|
|
|
{offsetof(struct acpi_battery, design_capacity_warning), 0},
|
|
|
|
|
{offsetof(struct acpi_battery, design_capacity_low), 0},
|
|
|
|
|
{offsetof(struct acpi_battery, capacity_granularity_1), 0},
|
|
|
|
|
{offsetof(struct acpi_battery, capacity_granularity_2), 0},
|
|
|
|
|
{offsetof(struct acpi_battery, model_number), 1},
|
|
|
|
|
{offsetof(struct acpi_battery, serial_number), 1},
|
|
|
|
|
{offsetof(struct acpi_battery, type), 1},
|
|
|
|
|
{offsetof(struct acpi_battery, oem_info), 1},
|
|
|
|
|
};
|
2007-02-20 20:48:06 +08:00
|
|
|
|
2015-06-13 20:26:53 +08:00
|
|
|
static const struct acpi_offsets extended_info_offsets[] = {
|
2013-07-30 20:00:42 +08:00
|
|
|
{offsetof(struct acpi_battery, revision), 0},
|
2009-10-15 18:31:44 +08:00
|
|
|
{offsetof(struct acpi_battery, power_unit), 0},
|
|
|
|
|
{offsetof(struct acpi_battery, design_capacity), 0},
|
|
|
|
|
{offsetof(struct acpi_battery, full_charge_capacity), 0},
|
|
|
|
|
{offsetof(struct acpi_battery, technology), 0},
|
|
|
|
|
{offsetof(struct acpi_battery, design_voltage), 0},
|
|
|
|
|
{offsetof(struct acpi_battery, design_capacity_warning), 0},
|
|
|
|
|
{offsetof(struct acpi_battery, design_capacity_low), 0},
|
|
|
|
|
{offsetof(struct acpi_battery, cycle_count), 0},
|
|
|
|
|
{offsetof(struct acpi_battery, measurement_accuracy), 0},
|
|
|
|
|
{offsetof(struct acpi_battery, max_sampling_time), 0},
|
|
|
|
|
{offsetof(struct acpi_battery, min_sampling_time), 0},
|
|
|
|
|
{offsetof(struct acpi_battery, max_averaging_interval), 0},
|
|
|
|
|
{offsetof(struct acpi_battery, min_averaging_interval), 0},
|
|
|
|
|
{offsetof(struct acpi_battery, capacity_granularity_1), 0},
|
|
|
|
|
{offsetof(struct acpi_battery, capacity_granularity_2), 0},
|
|
|
|
|
{offsetof(struct acpi_battery, model_number), 1},
|
|
|
|
|
{offsetof(struct acpi_battery, serial_number), 1},
|
|
|
|
|
{offsetof(struct acpi_battery, type), 1},
|
|
|
|
|
{offsetof(struct acpi_battery, oem_info), 1},
|
|
|
|
|
};
|
|
|
|
|
|
2007-09-26 23:42:46 +08:00
|
|
|
static int extract_package(struct acpi_battery *battery,
|
|
|
|
|
union acpi_object *package,
|
2015-06-13 20:26:53 +08:00
|
|
|
const struct acpi_offsets *offsets, int num)
|
2007-09-26 23:42:46 +08:00
|
|
|
{
|
2007-10-30 04:29:40 +08:00
|
|
|
int i;
|
2007-09-26 23:42:46 +08:00
|
|
|
union acpi_object *element;
|
2021-03-27 20:08:18 +08:00
|
|
|
|
2007-09-26 23:42:46 +08:00
|
|
|
if (package->type != ACPI_TYPE_PACKAGE)
|
|
|
|
|
return -EFAULT;
|
|
|
|
|
for (i = 0; i < num; ++i) {
|
|
|
|
|
if (package->package.count <= i)
|
|
|
|
|
return -EFAULT;
|
|
|
|
|
element = &package->package.elements[i];
|
|
|
|
|
if (offsets[i].mode) {
|
2007-10-30 04:29:40 +08:00
|
|
|
u8 *ptr = (u8 *)battery + offsets[i].offset;
|
2021-03-27 20:08:18 +08:00
|
|
|
|
2007-10-30 04:29:40 +08:00
|
|
|
if (element->type == ACPI_TYPE_STRING ||
|
|
|
|
|
element->type == ACPI_TYPE_BUFFER)
|
|
|
|
|
strncpy(ptr, element->string.pointer, 32);
|
|
|
|
|
else if (element->type == ACPI_TYPE_INTEGER) {
|
|
|
|
|
strncpy(ptr, (u8 *)&element->integer.value,
|
2010-01-28 10:53:19 +08:00
|
|
|
sizeof(u64));
|
|
|
|
|
ptr[sizeof(u64)] = 0;
|
2008-03-18 10:37:42 +08:00
|
|
|
} else
|
|
|
|
|
*ptr = 0; /* don't have value */
|
2007-09-26 23:42:46 +08:00
|
|
|
} else {
|
2008-03-18 10:37:42 +08:00
|
|
|
int *x = (int *)((u8 *)battery + offsets[i].offset);
|
|
|
|
|
*x = (element->type == ACPI_TYPE_INTEGER) ?
|
|
|
|
|
element->integer.value : -1;
|
2007-09-26 23:42:46 +08:00
|
|
|
}
|
2007-02-20 20:48:06 +08:00
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int acpi_battery_get_status(struct acpi_battery *battery)
|
|
|
|
|
{
|
2007-09-26 23:42:58 +08:00
|
|
|
if (acpi_bus_get_status(battery->device)) {
|
2021-02-04 02:44:57 +08:00
|
|
|
acpi_handle_info(battery->device->handle,
|
|
|
|
|
"_STA evaluation failed\n");
|
2007-02-20 20:48:06 +08:00
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
2007-09-26 23:42:58 +08:00
|
|
|
return 0;
|
2007-02-20 20:48:06 +08:00
|
|
|
}
|
|
|
|
|
|
2016-11-04 09:05:40 +08:00
|
|
|
|
|
|
|
|
static int extract_battery_info(const int use_bix,
|
|
|
|
|
struct acpi_battery *battery,
|
|
|
|
|
const struct acpi_buffer *buffer)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2007-09-26 23:42:58 +08:00
|
|
|
int result = -EFAULT;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2016-11-04 09:05:40 +08:00
|
|
|
if (use_bix && battery_bix_broken_package)
|
|
|
|
|
result = extract_package(battery, buffer->pointer,
|
2014-01-06 22:50:37 +08:00
|
|
|
extended_info_offsets + 1,
|
|
|
|
|
ARRAY_SIZE(extended_info_offsets) - 1);
|
2016-11-04 09:05:40 +08:00
|
|
|
else if (use_bix)
|
|
|
|
|
result = extract_package(battery, buffer->pointer,
|
2009-10-15 18:31:44 +08:00
|
|
|
extended_info_offsets,
|
|
|
|
|
ARRAY_SIZE(extended_info_offsets));
|
|
|
|
|
else
|
2016-11-04 09:05:40 +08:00
|
|
|
result = extract_package(battery, buffer->pointer,
|
2009-10-15 18:31:44 +08:00
|
|
|
info_offsets, ARRAY_SIZE(info_offsets));
|
2010-10-22 10:02:06 +08:00
|
|
|
if (test_bit(ACPI_BATTERY_QUIRK_PERCENTAGE_CAPACITY, &battery->flags))
|
|
|
|
|
battery->full_charge_capacity = battery->design_capacity;
|
ACPI / battery: Correct battery capacity values on Thinkpads
Add a quirk to correctly report battery capacity on 2010 and 2011
Lenovo Thinkpad models.
The affected models that I tested (x201, t410, t410s, and x220)
exhibit a problem where, when battery capacity reporting unit is mAh,
the values being reported are wrong. Pre-2010 and 2012 models appear
to always report in mWh and are thus unaffected. Also, in mid-2012
Lenovo issued a BIOS update for the 2011 models that fixes the issue
(tested on x220 with a post-1.29 BIOS). No such update is available
for the 2010 models, so those still need this patch.
Problem description: for some reason, the affected Thinkpads switch
the reporting unit between mAh and mWh; generally, mAh is used when a
laptop is plugged in and mWh when it's unplugged, although a
suspend/resume or rmmod/modprobe is needed for the switch to take
effect. The values reported in mAh are *always* wrong. This does
not appear to be a kernel regression; I believe that the values were
never reported correctly. I tested back to kernel 2.6.34, with
multiple machines and BIOS versions.
Simply plugging a laptop into mains before turning it on is enough to
reproduce the problem. Here's a sample /proc/acpi/battery/BAT0/info
from Thinkpad x220 (before a BIOS update) with a 4-cell battery:
present: yes
design capacity: 2886 mAh
last full capacity: 2909 mAh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 145 mAh
design capacity low: 13 mAh
cycle count: 0
capacity granularity 1: 1 mAh
capacity granularity 2: 1 mAh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Once the laptop switches the unit to mWh (unplug from mains, suspend,
resume), the output changes to:
present: yes
design capacity: 28860 mWh
last full capacity: 29090 mWh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 1454 mWh
design capacity low: 200 mWh
cycle count: 0
capacity granularity 1: 1 mWh
capacity granularity 2: 1 mWh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Can you see how the values for "design capacity", etc., differ by a
factor of 10 instead of 14.8 (the design voltage of this battery)?
On the battery itself it says: 14.8V, 1.95Ah, 29Wh, so clearly the
values reported in mWh are correct and the ones in mAh are not.
My guess is that this problem has been around ever since those
machines were released, but because the most common Thinkpad
batteries are rated at 10.8V, the error (8%) is small enough that it
simply hasn't been noticed or at least nobody could be bothered to
look into it.
My patch works around the problem by adjusting the incorrectly
reported mAh values by "10000 / design_voltage". The patch also has
code to figure out if it should be activated or not. It only
activates on Lenovo Thinkpads, only when the unit is mAh, and, as an
extra precaution, only when the battery capacity reported through
ACPI does not match what is reported through DMI (I've never
encountered a machine where the first two conditions would be true
but the last would not, but better safe than sorry).
I've been using this patch for close to a year on several systems
without any problems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=41062
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-17 05:28:58 +08:00
|
|
|
if (test_bit(ACPI_BATTERY_QUIRK_THINKPAD_MAH, &battery->flags) &&
|
|
|
|
|
battery->power_unit && battery->design_voltage) {
|
|
|
|
|
battery->design_capacity = battery->design_capacity *
|
|
|
|
|
10000 / battery->design_voltage;
|
|
|
|
|
battery->full_charge_capacity = battery->full_charge_capacity *
|
|
|
|
|
10000 / battery->design_voltage;
|
|
|
|
|
battery->design_capacity_warning =
|
|
|
|
|
battery->design_capacity_warning *
|
|
|
|
|
10000 / battery->design_voltage;
|
|
|
|
|
/* Curiously, design_capacity_low, unlike the rest of them,
|
2021-03-27 20:08:18 +08:00
|
|
|
* is correct.
|
|
|
|
|
*/
|
ACPI / battery: Correct battery capacity values on Thinkpads
Add a quirk to correctly report battery capacity on 2010 and 2011
Lenovo Thinkpad models.
The affected models that I tested (x201, t410, t410s, and x220)
exhibit a problem where, when battery capacity reporting unit is mAh,
the values being reported are wrong. Pre-2010 and 2012 models appear
to always report in mWh and are thus unaffected. Also, in mid-2012
Lenovo issued a BIOS update for the 2011 models that fixes the issue
(tested on x220 with a post-1.29 BIOS). No such update is available
for the 2010 models, so those still need this patch.
Problem description: for some reason, the affected Thinkpads switch
the reporting unit between mAh and mWh; generally, mAh is used when a
laptop is plugged in and mWh when it's unplugged, although a
suspend/resume or rmmod/modprobe is needed for the switch to take
effect. The values reported in mAh are *always* wrong. This does
not appear to be a kernel regression; I believe that the values were
never reported correctly. I tested back to kernel 2.6.34, with
multiple machines and BIOS versions.
Simply plugging a laptop into mains before turning it on is enough to
reproduce the problem. Here's a sample /proc/acpi/battery/BAT0/info
from Thinkpad x220 (before a BIOS update) with a 4-cell battery:
present: yes
design capacity: 2886 mAh
last full capacity: 2909 mAh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 145 mAh
design capacity low: 13 mAh
cycle count: 0
capacity granularity 1: 1 mAh
capacity granularity 2: 1 mAh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Once the laptop switches the unit to mWh (unplug from mains, suspend,
resume), the output changes to:
present: yes
design capacity: 28860 mWh
last full capacity: 29090 mWh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 1454 mWh
design capacity low: 200 mWh
cycle count: 0
capacity granularity 1: 1 mWh
capacity granularity 2: 1 mWh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Can you see how the values for "design capacity", etc., differ by a
factor of 10 instead of 14.8 (the design voltage of this battery)?
On the battery itself it says: 14.8V, 1.95Ah, 29Wh, so clearly the
values reported in mWh are correct and the ones in mAh are not.
My guess is that this problem has been around ever since those
machines were released, but because the most common Thinkpad
batteries are rated at 10.8V, the error (8%) is small enough that it
simply hasn't been noticed or at least nobody could be bothered to
look into it.
My patch works around the problem by adjusting the incorrectly
reported mAh values by "10000 / design_voltage". The patch also has
code to figure out if it should be activated or not. It only
activates on Lenovo Thinkpads, only when the unit is mAh, and, as an
extra precaution, only when the battery capacity reported through
ACPI does not match what is reported through DMI (I've never
encountered a machine where the first two conditions would be true
but the last would not, but better safe than sorry).
I've been using this patch for close to a year on several systems
without any problems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=41062
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-17 05:28:58 +08:00
|
|
|
/* capacity_granularity_* equal 1 on the systems tested, so
|
2021-03-27 20:08:18 +08:00
|
|
|
* it's impossible to tell if they would need an adjustment
|
|
|
|
|
* or not if their values were higher.
|
|
|
|
|
*/
|
ACPI / battery: Correct battery capacity values on Thinkpads
Add a quirk to correctly report battery capacity on 2010 and 2011
Lenovo Thinkpad models.
The affected models that I tested (x201, t410, t410s, and x220)
exhibit a problem where, when battery capacity reporting unit is mAh,
the values being reported are wrong. Pre-2010 and 2012 models appear
to always report in mWh and are thus unaffected. Also, in mid-2012
Lenovo issued a BIOS update for the 2011 models that fixes the issue
(tested on x220 with a post-1.29 BIOS). No such update is available
for the 2010 models, so those still need this patch.
Problem description: for some reason, the affected Thinkpads switch
the reporting unit between mAh and mWh; generally, mAh is used when a
laptop is plugged in and mWh when it's unplugged, although a
suspend/resume or rmmod/modprobe is needed for the switch to take
effect. The values reported in mAh are *always* wrong. This does
not appear to be a kernel regression; I believe that the values were
never reported correctly. I tested back to kernel 2.6.34, with
multiple machines and BIOS versions.
Simply plugging a laptop into mains before turning it on is enough to
reproduce the problem. Here's a sample /proc/acpi/battery/BAT0/info
from Thinkpad x220 (before a BIOS update) with a 4-cell battery:
present: yes
design capacity: 2886 mAh
last full capacity: 2909 mAh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 145 mAh
design capacity low: 13 mAh
cycle count: 0
capacity granularity 1: 1 mAh
capacity granularity 2: 1 mAh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Once the laptop switches the unit to mWh (unplug from mains, suspend,
resume), the output changes to:
present: yes
design capacity: 28860 mWh
last full capacity: 29090 mWh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 1454 mWh
design capacity low: 200 mWh
cycle count: 0
capacity granularity 1: 1 mWh
capacity granularity 2: 1 mWh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Can you see how the values for "design capacity", etc., differ by a
factor of 10 instead of 14.8 (the design voltage of this battery)?
On the battery itself it says: 14.8V, 1.95Ah, 29Wh, so clearly the
values reported in mWh are correct and the ones in mAh are not.
My guess is that this problem has been around ever since those
machines were released, but because the most common Thinkpad
batteries are rated at 10.8V, the error (8%) is small enough that it
simply hasn't been noticed or at least nobody could be bothered to
look into it.
My patch works around the problem by adjusting the incorrectly
reported mAh values by "10000 / design_voltage". The patch also has
code to figure out if it should be activated or not. It only
activates on Lenovo Thinkpads, only when the unit is mAh, and, as an
extra precaution, only when the battery capacity reported through
ACPI does not match what is reported through DMI (I've never
encountered a machine where the first two conditions would be true
but the last would not, but better safe than sorry).
I've been using this patch for close to a year on several systems
without any problems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=41062
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-17 05:28:58 +08:00
|
|
|
}
|
2018-02-24 17:20:15 +08:00
|
|
|
if (test_bit(ACPI_BATTERY_QUIRK_DEGRADED_FULL_CHARGE, &battery->flags) &&
|
|
|
|
|
battery->capacity_now > battery->full_charge_capacity)
|
|
|
|
|
battery->capacity_now = battery->full_charge_capacity;
|
|
|
|
|
|
2006-06-27 12:41:40 +08:00
|
|
|
return result;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2016-11-04 09:05:40 +08:00
|
|
|
static int acpi_battery_get_info(struct acpi_battery *battery)
|
|
|
|
|
{
|
|
|
|
|
const int xinfo = test_bit(ACPI_BATTERY_XINFO_PRESENT, &battery->flags);
|
|
|
|
|
int use_bix;
|
|
|
|
|
int result = -ENODEV;
|
|
|
|
|
|
|
|
|
|
if (!acpi_battery_present(battery))
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
for (use_bix = xinfo ? 1 : 0; use_bix >= 0; use_bix--) {
|
|
|
|
|
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
|
|
|
|
|
acpi_status status = AE_ERROR;
|
|
|
|
|
|
|
|
|
|
mutex_lock(&battery->lock);
|
|
|
|
|
status = acpi_evaluate_object(battery->device->handle,
|
|
|
|
|
use_bix ? "_BIX":"_BIF",
|
|
|
|
|
NULL, &buffer);
|
|
|
|
|
mutex_unlock(&battery->lock);
|
|
|
|
|
|
|
|
|
|
if (ACPI_FAILURE(status)) {
|
2021-02-04 02:44:57 +08:00
|
|
|
acpi_handle_info(battery->device->handle,
|
|
|
|
|
"%s evaluation failed: %s\n",
|
2021-03-27 20:08:18 +08:00
|
|
|
use_bix ? "_BIX":"_BIF",
|
|
|
|
|
acpi_format_exception(status));
|
2016-11-04 09:05:40 +08:00
|
|
|
} else {
|
|
|
|
|
result = extract_battery_info(use_bix,
|
|
|
|
|
battery,
|
|
|
|
|
&buffer);
|
|
|
|
|
|
|
|
|
|
kfree(buffer.pointer);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!result && !use_bix && xinfo)
|
|
|
|
|
pr_warn(FW_BUG "The _BIX method is broken, using _BIF.\n");
|
|
|
|
|
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
2007-02-20 20:48:06 +08:00
|
|
|
static int acpi_battery_get_state(struct acpi_battery *battery)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2005-08-05 12:44:28 +08:00
|
|
|
int result = 0;
|
|
|
|
|
acpi_status status = 0;
|
|
|
|
|
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-02-20 20:48:06 +08:00
|
|
|
if (!acpi_battery_present(battery))
|
|
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-09-26 23:42:52 +08:00
|
|
|
if (battery->update_time &&
|
|
|
|
|
time_before(jiffies, battery->update_time +
|
|
|
|
|
msecs_to_jiffies(cache_time)))
|
|
|
|
|
return 0;
|
|
|
|
|
|
2007-09-26 23:42:46 +08:00
|
|
|
mutex_lock(&battery->lock);
|
2007-09-26 23:42:52 +08:00
|
|
|
status = acpi_evaluate_object(battery->device->handle, "_BST",
|
2007-09-26 23:42:46 +08:00
|
|
|
NULL, &buffer);
|
|
|
|
|
mutex_unlock(&battery->lock);
|
2007-08-15 12:19:26 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
if (ACPI_FAILURE(status)) {
|
2021-02-04 02:44:57 +08:00
|
|
|
acpi_handle_info(battery->device->handle,
|
|
|
|
|
"_BST evaluation failed: %s",
|
|
|
|
|
acpi_format_exception(status));
|
2006-06-27 12:41:40 +08:00
|
|
|
return -ENODEV;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2007-09-26 23:42:58 +08:00
|
|
|
|
2007-09-26 23:42:46 +08:00
|
|
|
result = extract_package(battery, buffer.pointer,
|
|
|
|
|
state_offsets, ARRAY_SIZE(state_offsets));
|
2007-09-26 23:42:52 +08:00
|
|
|
battery->update_time = jiffies;
|
2007-05-12 01:18:55 +08:00
|
|
|
kfree(buffer.pointer);
|
2009-08-07 06:57:48 +08:00
|
|
|
|
2011-06-30 11:33:12 +08:00
|
|
|
/* For buggy DSDTs that report negative 16-bit values for either
|
|
|
|
|
* charging or discharging current and/or report 0 as 65536
|
|
|
|
|
* due to bad math.
|
|
|
|
|
*/
|
|
|
|
|
if (battery->power_unit == ACPI_BATTERY_POWER_UNIT_MA &&
|
|
|
|
|
battery->rate_now != ACPI_BATTERY_VALUE_UNKNOWN &&
|
|
|
|
|
(s16)(battery->rate_now) < 0) {
|
2009-08-07 06:57:48 +08:00
|
|
|
battery->rate_now = abs((s16)battery->rate_now);
|
2021-02-04 02:44:57 +08:00
|
|
|
pr_warn_once(FW_BUG "(dis)charge rate invalid.\n");
|
2011-06-30 11:33:12 +08:00
|
|
|
}
|
2009-08-07 06:57:48 +08:00
|
|
|
|
2010-10-22 10:02:06 +08:00
|
|
|
if (test_bit(ACPI_BATTERY_QUIRK_PERCENTAGE_CAPACITY, &battery->flags)
|
|
|
|
|
&& battery->capacity_now >= 0 && battery->capacity_now <= 100)
|
|
|
|
|
battery->capacity_now = (battery->capacity_now *
|
|
|
|
|
battery->full_charge_capacity) / 100;
|
ACPI / battery: Correct battery capacity values on Thinkpads
Add a quirk to correctly report battery capacity on 2010 and 2011
Lenovo Thinkpad models.
The affected models that I tested (x201, t410, t410s, and x220)
exhibit a problem where, when battery capacity reporting unit is mAh,
the values being reported are wrong. Pre-2010 and 2012 models appear
to always report in mWh and are thus unaffected. Also, in mid-2012
Lenovo issued a BIOS update for the 2011 models that fixes the issue
(tested on x220 with a post-1.29 BIOS). No such update is available
for the 2010 models, so those still need this patch.
Problem description: for some reason, the affected Thinkpads switch
the reporting unit between mAh and mWh; generally, mAh is used when a
laptop is plugged in and mWh when it's unplugged, although a
suspend/resume or rmmod/modprobe is needed for the switch to take
effect. The values reported in mAh are *always* wrong. This does
not appear to be a kernel regression; I believe that the values were
never reported correctly. I tested back to kernel 2.6.34, with
multiple machines and BIOS versions.
Simply plugging a laptop into mains before turning it on is enough to
reproduce the problem. Here's a sample /proc/acpi/battery/BAT0/info
from Thinkpad x220 (before a BIOS update) with a 4-cell battery:
present: yes
design capacity: 2886 mAh
last full capacity: 2909 mAh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 145 mAh
design capacity low: 13 mAh
cycle count: 0
capacity granularity 1: 1 mAh
capacity granularity 2: 1 mAh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Once the laptop switches the unit to mWh (unplug from mains, suspend,
resume), the output changes to:
present: yes
design capacity: 28860 mWh
last full capacity: 29090 mWh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 1454 mWh
design capacity low: 200 mWh
cycle count: 0
capacity granularity 1: 1 mWh
capacity granularity 2: 1 mWh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Can you see how the values for "design capacity", etc., differ by a
factor of 10 instead of 14.8 (the design voltage of this battery)?
On the battery itself it says: 14.8V, 1.95Ah, 29Wh, so clearly the
values reported in mWh are correct and the ones in mAh are not.
My guess is that this problem has been around ever since those
machines were released, but because the most common Thinkpad
batteries are rated at 10.8V, the error (8%) is small enough that it
simply hasn't been noticed or at least nobody could be bothered to
look into it.
My patch works around the problem by adjusting the incorrectly
reported mAh values by "10000 / design_voltage". The patch also has
code to figure out if it should be activated or not. It only
activates on Lenovo Thinkpads, only when the unit is mAh, and, as an
extra precaution, only when the battery capacity reported through
ACPI does not match what is reported through DMI (I've never
encountered a machine where the first two conditions would be true
but the last would not, but better safe than sorry).
I've been using this patch for close to a year on several systems
without any problems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=41062
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-17 05:28:58 +08:00
|
|
|
if (test_bit(ACPI_BATTERY_QUIRK_THINKPAD_MAH, &battery->flags) &&
|
|
|
|
|
battery->power_unit && battery->design_voltage) {
|
|
|
|
|
battery->capacity_now = battery->capacity_now *
|
|
|
|
|
10000 / battery->design_voltage;
|
|
|
|
|
}
|
2018-02-24 17:20:15 +08:00
|
|
|
if (test_bit(ACPI_BATTERY_QUIRK_DEGRADED_FULL_CHARGE, &battery->flags) &&
|
|
|
|
|
battery->capacity_now > battery->full_charge_capacity)
|
|
|
|
|
battery->capacity_now = battery->full_charge_capacity;
|
|
|
|
|
|
2007-02-20 20:48:06 +08:00
|
|
|
return result;
|
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-09-26 23:42:58 +08:00
|
|
|
static int acpi_battery_set_alarm(struct acpi_battery *battery)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2005-08-05 12:44:28 +08:00
|
|
|
acpi_status status = 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2009-10-15 18:31:44 +08:00
|
|
|
if (!acpi_battery_present(battery) ||
|
2009-10-15 18:31:24 +08:00
|
|
|
!test_bit(ACPI_BATTERY_ALARM_PRESENT, &battery->flags))
|
2006-06-27 12:41:40 +08:00
|
|
|
return -ENODEV;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-09-26 23:42:46 +08:00
|
|
|
mutex_lock(&battery->lock);
|
2013-06-29 00:24:39 +08:00
|
|
|
status = acpi_execute_simple_method(battery->device->handle, "_BTP",
|
|
|
|
|
battery->alarm);
|
2007-09-26 23:42:46 +08:00
|
|
|
mutex_unlock(&battery->lock);
|
2007-09-26 23:42:58 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
if (ACPI_FAILURE(status))
|
2006-06-27 12:41:40 +08:00
|
|
|
return -ENODEV;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2021-02-04 02:44:57 +08:00
|
|
|
acpi_handle_debug(battery->device->handle, "Alarm set to %d\n",
|
|
|
|
|
battery->alarm);
|
|
|
|
|
|
2006-06-27 12:41:40 +08:00
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2007-02-20 20:48:06 +08:00
|
|
|
static int acpi_battery_init_alarm(struct acpi_battery *battery)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2007-02-20 20:48:06 +08:00
|
|
|
/* See if alarms are supported, and if so, set default */
|
2013-06-29 00:24:38 +08:00
|
|
|
if (!acpi_has_method(battery->device->handle, "_BTP")) {
|
2009-10-15 18:31:24 +08:00
|
|
|
clear_bit(ACPI_BATTERY_ALARM_PRESENT, &battery->flags);
|
2007-09-26 23:42:52 +08:00
|
|
|
return 0;
|
2007-02-20 20:48:06 +08:00
|
|
|
}
|
2009-10-15 18:31:24 +08:00
|
|
|
set_bit(ACPI_BATTERY_ALARM_PRESENT, &battery->flags);
|
2007-09-26 23:42:52 +08:00
|
|
|
if (!battery->alarm)
|
|
|
|
|
battery->alarm = battery->design_capacity_warning;
|
2007-09-26 23:42:58 +08:00
|
|
|
return acpi_battery_set_alarm(battery);
|
2007-02-20 20:48:06 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-10-28 17:50:09 +08:00
|
|
|
static ssize_t acpi_battery_alarm_show(struct device *dev,
|
|
|
|
|
struct device_attribute *attr,
|
|
|
|
|
char *buf)
|
|
|
|
|
{
|
|
|
|
|
struct acpi_battery *battery = to_acpi_battery(dev_get_drvdata(dev));
|
2021-03-27 20:08:18 +08:00
|
|
|
|
2007-10-28 17:50:09 +08:00
|
|
|
return sprintf(buf, "%d\n", battery->alarm * 1000);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static ssize_t acpi_battery_alarm_store(struct device *dev,
|
|
|
|
|
struct device_attribute *attr,
|
|
|
|
|
const char *buf, size_t count)
|
|
|
|
|
{
|
|
|
|
|
unsigned long x;
|
|
|
|
|
struct acpi_battery *battery = to_acpi_battery(dev_get_drvdata(dev));
|
2021-03-27 20:08:18 +08:00
|
|
|
|
2014-01-21 22:40:43 +08:00
|
|
|
if (sscanf(buf, "%lu\n", &x) == 1)
|
2007-10-28 17:50:09 +08:00
|
|
|
battery->alarm = x/1000;
|
|
|
|
|
if (acpi_battery_present(battery))
|
|
|
|
|
acpi_battery_set_alarm(battery);
|
|
|
|
|
return count;
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-21 19:43:07 +08:00
|
|
|
static const struct device_attribute alarm_attr = {
|
2008-10-19 11:28:50 +08:00
|
|
|
.attr = {.name = "alarm", .mode = 0644},
|
2007-10-28 17:50:09 +08:00
|
|
|
.show = acpi_battery_alarm_show,
|
|
|
|
|
.store = acpi_battery_alarm_store,
|
|
|
|
|
};
|
|
|
|
|
|
2018-02-07 22:58:13 +08:00
|
|
|
/*
|
|
|
|
|
* The Battery Hooking API
|
|
|
|
|
*
|
|
|
|
|
* This API is used inside other drivers that need to expose
|
|
|
|
|
* platform-specific behaviour within the generic driver in a
|
|
|
|
|
* generic way.
|
|
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
static LIST_HEAD(acpi_battery_list);
|
|
|
|
|
static LIST_HEAD(battery_hook_list);
|
|
|
|
|
static DEFINE_MUTEX(hook_mutex);
|
|
|
|
|
|
2018-02-24 00:32:55 +08:00
|
|
|
static void __battery_hook_unregister(struct acpi_battery_hook *hook, int lock)
|
2018-02-07 22:58:13 +08:00
|
|
|
{
|
|
|
|
|
struct acpi_battery *battery;
|
|
|
|
|
/*
|
|
|
|
|
* In order to remove a hook, we first need to
|
|
|
|
|
* de-register all the batteries that are registered.
|
|
|
|
|
*/
|
|
|
|
|
if (lock)
|
|
|
|
|
mutex_lock(&hook_mutex);
|
|
|
|
|
list_for_each_entry(battery, &acpi_battery_list, list) {
|
|
|
|
|
hook->remove_battery(battery->bat);
|
|
|
|
|
}
|
|
|
|
|
list_del(&hook->list);
|
|
|
|
|
if (lock)
|
|
|
|
|
mutex_unlock(&hook_mutex);
|
|
|
|
|
pr_info("extension unregistered: %s\n", hook->name);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void battery_hook_unregister(struct acpi_battery_hook *hook)
|
|
|
|
|
{
|
|
|
|
|
__battery_hook_unregister(hook, 1);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(battery_hook_unregister);
|
|
|
|
|
|
|
|
|
|
void battery_hook_register(struct acpi_battery_hook *hook)
|
|
|
|
|
{
|
|
|
|
|
struct acpi_battery *battery;
|
|
|
|
|
|
|
|
|
|
mutex_lock(&hook_mutex);
|
|
|
|
|
INIT_LIST_HEAD(&hook->list);
|
|
|
|
|
list_add(&hook->list, &battery_hook_list);
|
|
|
|
|
/*
|
|
|
|
|
* Now that the driver is registered, we need
|
|
|
|
|
* to notify the hook that a battery is available
|
|
|
|
|
* for each battery, so that the driver may add
|
|
|
|
|
* its attributes.
|
|
|
|
|
*/
|
|
|
|
|
list_for_each_entry(battery, &acpi_battery_list, list) {
|
|
|
|
|
if (hook->add_battery(battery->bat)) {
|
|
|
|
|
/*
|
|
|
|
|
* If a add-battery returns non-zero,
|
|
|
|
|
* the registration of the extension has failed,
|
|
|
|
|
* and we will not add it to the list of loaded
|
|
|
|
|
* hooks.
|
|
|
|
|
*/
|
|
|
|
|
pr_err("extension failed to load: %s", hook->name);
|
|
|
|
|
__battery_hook_unregister(hook, 0);
|
2018-07-04 18:27:15 +08:00
|
|
|
goto end;
|
2018-02-07 22:58:13 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
pr_info("new extension: %s\n", hook->name);
|
2018-07-04 18:27:15 +08:00
|
|
|
end:
|
2018-02-07 22:58:13 +08:00
|
|
|
mutex_unlock(&hook_mutex);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(battery_hook_register);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* This function gets called right after the battery sysfs
|
|
|
|
|
* attributes have been added, so that the drivers that
|
|
|
|
|
* define custom sysfs attributes can add their own.
|
2021-03-27 20:08:18 +08:00
|
|
|
*/
|
2018-02-07 22:58:13 +08:00
|
|
|
static void battery_hook_add_battery(struct acpi_battery *battery)
|
|
|
|
|
{
|
2018-07-04 18:27:15 +08:00
|
|
|
struct acpi_battery_hook *hook_node, *tmp;
|
2018-02-07 22:58:13 +08:00
|
|
|
|
|
|
|
|
mutex_lock(&hook_mutex);
|
|
|
|
|
INIT_LIST_HEAD(&battery->list);
|
|
|
|
|
list_add(&battery->list, &acpi_battery_list);
|
|
|
|
|
/*
|
|
|
|
|
* Since we added a new battery to the list, we need to
|
|
|
|
|
* iterate over the hooks and call add_battery for each
|
|
|
|
|
* hook that was registered. This usually happens
|
|
|
|
|
* when a battery gets hotplugged or initialized
|
|
|
|
|
* during the battery module initialization.
|
|
|
|
|
*/
|
2018-07-04 18:27:15 +08:00
|
|
|
list_for_each_entry_safe(hook_node, tmp, &battery_hook_list, list) {
|
2018-02-07 22:58:13 +08:00
|
|
|
if (hook_node->add_battery(battery->bat)) {
|
|
|
|
|
/*
|
|
|
|
|
* The notification of the extensions has failed, to
|
|
|
|
|
* prevent further errors we will unload the extension.
|
|
|
|
|
*/
|
|
|
|
|
pr_err("error in extension, unloading: %s",
|
|
|
|
|
hook_node->name);
|
2018-07-04 18:27:15 +08:00
|
|
|
__battery_hook_unregister(hook_node, 0);
|
2018-02-07 22:58:13 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
mutex_unlock(&hook_mutex);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void battery_hook_remove_battery(struct acpi_battery *battery)
|
|
|
|
|
{
|
|
|
|
|
struct acpi_battery_hook *hook;
|
|
|
|
|
|
|
|
|
|
mutex_lock(&hook_mutex);
|
|
|
|
|
/*
|
|
|
|
|
* Before removing the hook, we need to remove all
|
|
|
|
|
* custom attributes from the battery.
|
|
|
|
|
*/
|
|
|
|
|
list_for_each_entry(hook, &battery_hook_list, list) {
|
|
|
|
|
hook->remove_battery(battery->bat);
|
|
|
|
|
}
|
|
|
|
|
/* Then, just remove the battery from the list */
|
|
|
|
|
list_del(&battery->list);
|
|
|
|
|
mutex_unlock(&hook_mutex);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void __exit battery_hook_exit(void)
|
|
|
|
|
{
|
|
|
|
|
struct acpi_battery_hook *hook;
|
|
|
|
|
struct acpi_battery_hook *ptr;
|
|
|
|
|
/*
|
|
|
|
|
* At this point, the acpi_bus_unregister_driver()
|
|
|
|
|
* has called remove for all batteries. We just
|
|
|
|
|
* need to remove the hooks.
|
|
|
|
|
*/
|
|
|
|
|
list_for_each_entry_safe(hook, ptr, &battery_hook_list, list) {
|
|
|
|
|
__battery_hook_unregister(hook, 1);
|
|
|
|
|
}
|
|
|
|
|
mutex_destroy(&hook_mutex);
|
|
|
|
|
}
|
|
|
|
|
|
2007-10-28 17:50:09 +08:00
|
|
|
static int sysfs_add_battery(struct acpi_battery *battery)
|
|
|
|
|
{
|
2015-03-12 15:44:11 +08:00
|
|
|
struct power_supply_config psy_cfg = { .drv_data = battery, };
|
2019-12-10 17:57:52 +08:00
|
|
|
bool full_cap_broken = false;
|
|
|
|
|
|
|
|
|
|
if (!ACPI_BATTERY_CAPACITY_VALID(battery->full_charge_capacity) &&
|
|
|
|
|
!ACPI_BATTERY_CAPACITY_VALID(battery->design_capacity))
|
|
|
|
|
full_cap_broken = true;
|
2007-10-28 17:50:09 +08:00
|
|
|
|
2011-06-30 11:32:40 +08:00
|
|
|
if (battery->power_unit == ACPI_BATTERY_POWER_UNIT_MA) {
|
2019-12-10 17:57:52 +08:00
|
|
|
if (full_cap_broken) {
|
|
|
|
|
battery->bat_desc.properties =
|
|
|
|
|
charge_battery_full_cap_broken_props;
|
|
|
|
|
battery->bat_desc.num_properties =
|
|
|
|
|
ARRAY_SIZE(charge_battery_full_cap_broken_props);
|
|
|
|
|
} else {
|
|
|
|
|
battery->bat_desc.properties = charge_battery_props;
|
|
|
|
|
battery->bat_desc.num_properties =
|
|
|
|
|
ARRAY_SIZE(charge_battery_props);
|
|
|
|
|
}
|
2007-10-28 17:50:09 +08:00
|
|
|
} else {
|
2019-12-10 17:57:52 +08:00
|
|
|
if (full_cap_broken) {
|
|
|
|
|
battery->bat_desc.properties =
|
|
|
|
|
energy_battery_full_cap_broken_props;
|
|
|
|
|
battery->bat_desc.num_properties =
|
|
|
|
|
ARRAY_SIZE(energy_battery_full_cap_broken_props);
|
|
|
|
|
} else {
|
|
|
|
|
battery->bat_desc.properties = energy_battery_props;
|
|
|
|
|
battery->bat_desc.num_properties =
|
|
|
|
|
ARRAY_SIZE(energy_battery_props);
|
|
|
|
|
}
|
2007-10-28 17:50:09 +08:00
|
|
|
}
|
|
|
|
|
|
2015-03-12 15:44:11 +08:00
|
|
|
battery->bat_desc.name = acpi_device_bid(battery->device);
|
|
|
|
|
battery->bat_desc.type = POWER_SUPPLY_TYPE_BATTERY;
|
|
|
|
|
battery->bat_desc.get_property = acpi_battery_get_property;
|
2007-10-28 17:50:09 +08:00
|
|
|
|
2015-03-12 15:44:11 +08:00
|
|
|
battery->bat = power_supply_register_no_ws(&battery->device->dev,
|
|
|
|
|
&battery->bat_desc, &psy_cfg);
|
2014-05-28 15:23:38 +08:00
|
|
|
|
2015-03-12 15:44:11 +08:00
|
|
|
if (IS_ERR(battery->bat)) {
|
|
|
|
|
int result = PTR_ERR(battery->bat);
|
|
|
|
|
|
|
|
|
|
battery->bat = NULL;
|
2007-10-28 17:50:09 +08:00
|
|
|
return result;
|
2015-03-12 15:44:11 +08:00
|
|
|
}
|
2018-02-07 22:58:13 +08:00
|
|
|
battery_hook_add_battery(battery);
|
2015-03-12 15:44:11 +08:00
|
|
|
return device_create_file(&battery->bat->dev, &alarm_attr);
|
2007-10-28 17:50:09 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void sysfs_remove_battery(struct acpi_battery *battery)
|
|
|
|
|
{
|
2011-08-06 06:34:08 +08:00
|
|
|
mutex_lock(&battery->sysfs_lock);
|
2015-03-12 15:44:11 +08:00
|
|
|
if (!battery->bat) {
|
2011-08-06 06:34:08 +08:00
|
|
|
mutex_unlock(&battery->sysfs_lock);
|
2007-10-28 17:50:09 +08:00
|
|
|
return;
|
2011-06-30 11:34:12 +08:00
|
|
|
}
|
2018-02-07 22:58:13 +08:00
|
|
|
battery_hook_remove_battery(battery);
|
2015-03-12 15:44:11 +08:00
|
|
|
device_remove_file(&battery->bat->dev, &alarm_attr);
|
|
|
|
|
power_supply_unregister(battery->bat);
|
|
|
|
|
battery->bat = NULL;
|
2011-08-06 06:34:08 +08:00
|
|
|
mutex_unlock(&battery->sysfs_lock);
|
2009-08-07 06:57:48 +08:00
|
|
|
}
|
|
|
|
|
|
ACPI / battery: Correct battery capacity values on Thinkpads
Add a quirk to correctly report battery capacity on 2010 and 2011
Lenovo Thinkpad models.
The affected models that I tested (x201, t410, t410s, and x220)
exhibit a problem where, when battery capacity reporting unit is mAh,
the values being reported are wrong. Pre-2010 and 2012 models appear
to always report in mWh and are thus unaffected. Also, in mid-2012
Lenovo issued a BIOS update for the 2011 models that fixes the issue
(tested on x220 with a post-1.29 BIOS). No such update is available
for the 2010 models, so those still need this patch.
Problem description: for some reason, the affected Thinkpads switch
the reporting unit between mAh and mWh; generally, mAh is used when a
laptop is plugged in and mWh when it's unplugged, although a
suspend/resume or rmmod/modprobe is needed for the switch to take
effect. The values reported in mAh are *always* wrong. This does
not appear to be a kernel regression; I believe that the values were
never reported correctly. I tested back to kernel 2.6.34, with
multiple machines and BIOS versions.
Simply plugging a laptop into mains before turning it on is enough to
reproduce the problem. Here's a sample /proc/acpi/battery/BAT0/info
from Thinkpad x220 (before a BIOS update) with a 4-cell battery:
present: yes
design capacity: 2886 mAh
last full capacity: 2909 mAh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 145 mAh
design capacity low: 13 mAh
cycle count: 0
capacity granularity 1: 1 mAh
capacity granularity 2: 1 mAh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Once the laptop switches the unit to mWh (unplug from mains, suspend,
resume), the output changes to:
present: yes
design capacity: 28860 mWh
last full capacity: 29090 mWh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 1454 mWh
design capacity low: 200 mWh
cycle count: 0
capacity granularity 1: 1 mWh
capacity granularity 2: 1 mWh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Can you see how the values for "design capacity", etc., differ by a
factor of 10 instead of 14.8 (the design voltage of this battery)?
On the battery itself it says: 14.8V, 1.95Ah, 29Wh, so clearly the
values reported in mWh are correct and the ones in mAh are not.
My guess is that this problem has been around ever since those
machines were released, but because the most common Thinkpad
batteries are rated at 10.8V, the error (8%) is small enough that it
simply hasn't been noticed or at least nobody could be bothered to
look into it.
My patch works around the problem by adjusting the incorrectly
reported mAh values by "10000 / design_voltage". The patch also has
code to figure out if it should be activated or not. It only
activates on Lenovo Thinkpads, only when the unit is mAh, and, as an
extra precaution, only when the battery capacity reported through
ACPI does not match what is reported through DMI (I've never
encountered a machine where the first two conditions would be true
but the last would not, but better safe than sorry).
I've been using this patch for close to a year on several systems
without any problems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=41062
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-17 05:28:58 +08:00
|
|
|
static void find_battery(const struct dmi_header *dm, void *private)
|
|
|
|
|
{
|
|
|
|
|
struct acpi_battery *battery = (struct acpi_battery *)private;
|
|
|
|
|
/* Note: the hardcoded offsets below have been extracted from
|
2021-03-27 20:08:18 +08:00
|
|
|
* the source code of dmidecode.
|
|
|
|
|
*/
|
ACPI / battery: Correct battery capacity values on Thinkpads
Add a quirk to correctly report battery capacity on 2010 and 2011
Lenovo Thinkpad models.
The affected models that I tested (x201, t410, t410s, and x220)
exhibit a problem where, when battery capacity reporting unit is mAh,
the values being reported are wrong. Pre-2010 and 2012 models appear
to always report in mWh and are thus unaffected. Also, in mid-2012
Lenovo issued a BIOS update for the 2011 models that fixes the issue
(tested on x220 with a post-1.29 BIOS). No such update is available
for the 2010 models, so those still need this patch.
Problem description: for some reason, the affected Thinkpads switch
the reporting unit between mAh and mWh; generally, mAh is used when a
laptop is plugged in and mWh when it's unplugged, although a
suspend/resume or rmmod/modprobe is needed for the switch to take
effect. The values reported in mAh are *always* wrong. This does
not appear to be a kernel regression; I believe that the values were
never reported correctly. I tested back to kernel 2.6.34, with
multiple machines and BIOS versions.
Simply plugging a laptop into mains before turning it on is enough to
reproduce the problem. Here's a sample /proc/acpi/battery/BAT0/info
from Thinkpad x220 (before a BIOS update) with a 4-cell battery:
present: yes
design capacity: 2886 mAh
last full capacity: 2909 mAh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 145 mAh
design capacity low: 13 mAh
cycle count: 0
capacity granularity 1: 1 mAh
capacity granularity 2: 1 mAh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Once the laptop switches the unit to mWh (unplug from mains, suspend,
resume), the output changes to:
present: yes
design capacity: 28860 mWh
last full capacity: 29090 mWh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 1454 mWh
design capacity low: 200 mWh
cycle count: 0
capacity granularity 1: 1 mWh
capacity granularity 2: 1 mWh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Can you see how the values for "design capacity", etc., differ by a
factor of 10 instead of 14.8 (the design voltage of this battery)?
On the battery itself it says: 14.8V, 1.95Ah, 29Wh, so clearly the
values reported in mWh are correct and the ones in mAh are not.
My guess is that this problem has been around ever since those
machines were released, but because the most common Thinkpad
batteries are rated at 10.8V, the error (8%) is small enough that it
simply hasn't been noticed or at least nobody could be bothered to
look into it.
My patch works around the problem by adjusting the incorrectly
reported mAh values by "10000 / design_voltage". The patch also has
code to figure out if it should be activated or not. It only
activates on Lenovo Thinkpads, only when the unit is mAh, and, as an
extra precaution, only when the battery capacity reported through
ACPI does not match what is reported through DMI (I've never
encountered a machine where the first two conditions would be true
but the last would not, but better safe than sorry).
I've been using this patch for close to a year on several systems
without any problems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=41062
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-17 05:28:58 +08:00
|
|
|
if (dm->type == DMI_ENTRY_PORTABLE_BATTERY && dm->length >= 8) {
|
|
|
|
|
const u8 *dmi_data = (const u8 *)(dm + 1);
|
|
|
|
|
int dmi_capacity = get_unaligned((const u16 *)(dmi_data + 6));
|
2021-03-27 20:08:18 +08:00
|
|
|
|
ACPI / battery: Correct battery capacity values on Thinkpads
Add a quirk to correctly report battery capacity on 2010 and 2011
Lenovo Thinkpad models.
The affected models that I tested (x201, t410, t410s, and x220)
exhibit a problem where, when battery capacity reporting unit is mAh,
the values being reported are wrong. Pre-2010 and 2012 models appear
to always report in mWh and are thus unaffected. Also, in mid-2012
Lenovo issued a BIOS update for the 2011 models that fixes the issue
(tested on x220 with a post-1.29 BIOS). No such update is available
for the 2010 models, so those still need this patch.
Problem description: for some reason, the affected Thinkpads switch
the reporting unit between mAh and mWh; generally, mAh is used when a
laptop is plugged in and mWh when it's unplugged, although a
suspend/resume or rmmod/modprobe is needed for the switch to take
effect. The values reported in mAh are *always* wrong. This does
not appear to be a kernel regression; I believe that the values were
never reported correctly. I tested back to kernel 2.6.34, with
multiple machines and BIOS versions.
Simply plugging a laptop into mains before turning it on is enough to
reproduce the problem. Here's a sample /proc/acpi/battery/BAT0/info
from Thinkpad x220 (before a BIOS update) with a 4-cell battery:
present: yes
design capacity: 2886 mAh
last full capacity: 2909 mAh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 145 mAh
design capacity low: 13 mAh
cycle count: 0
capacity granularity 1: 1 mAh
capacity granularity 2: 1 mAh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Once the laptop switches the unit to mWh (unplug from mains, suspend,
resume), the output changes to:
present: yes
design capacity: 28860 mWh
last full capacity: 29090 mWh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 1454 mWh
design capacity low: 200 mWh
cycle count: 0
capacity granularity 1: 1 mWh
capacity granularity 2: 1 mWh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Can you see how the values for "design capacity", etc., differ by a
factor of 10 instead of 14.8 (the design voltage of this battery)?
On the battery itself it says: 14.8V, 1.95Ah, 29Wh, so clearly the
values reported in mWh are correct and the ones in mAh are not.
My guess is that this problem has been around ever since those
machines were released, but because the most common Thinkpad
batteries are rated at 10.8V, the error (8%) is small enough that it
simply hasn't been noticed or at least nobody could be bothered to
look into it.
My patch works around the problem by adjusting the incorrectly
reported mAh values by "10000 / design_voltage". The patch also has
code to figure out if it should be activated or not. It only
activates on Lenovo Thinkpads, only when the unit is mAh, and, as an
extra precaution, only when the battery capacity reported through
ACPI does not match what is reported through DMI (I've never
encountered a machine where the first two conditions would be true
but the last would not, but better safe than sorry).
I've been using this patch for close to a year on several systems
without any problems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=41062
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-17 05:28:58 +08:00
|
|
|
if (dm->length >= 18)
|
|
|
|
|
dmi_capacity *= dmi_data[17];
|
|
|
|
|
if (battery->design_capacity * battery->design_voltage / 1000
|
|
|
|
|
!= dmi_capacity &&
|
|
|
|
|
battery->design_capacity * 10 == dmi_capacity)
|
|
|
|
|
set_bit(ACPI_BATTERY_QUIRK_THINKPAD_MAH,
|
|
|
|
|
&battery->flags);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2010-10-22 10:02:06 +08:00
|
|
|
/*
|
|
|
|
|
* According to the ACPI spec, some kinds of primary batteries can
|
|
|
|
|
* report percentage battery remaining capacity directly to OS.
|
|
|
|
|
* In this case, it reports the Last Full Charged Capacity == 100
|
|
|
|
|
* and BatteryPresentRate == 0xFFFFFFFF.
|
|
|
|
|
*
|
|
|
|
|
* Now we found some battery reports percentage remaining capacity
|
|
|
|
|
* even if it's rechargeable.
|
|
|
|
|
* https://bugzilla.kernel.org/show_bug.cgi?id=15979
|
|
|
|
|
*
|
|
|
|
|
* Handle this correctly so that they won't break userspace.
|
|
|
|
|
*/
|
2011-06-30 11:33:27 +08:00
|
|
|
static void acpi_battery_quirks(struct acpi_battery *battery)
|
2010-10-22 10:02:06 +08:00
|
|
|
{
|
|
|
|
|
if (test_bit(ACPI_BATTERY_QUIRK_PERCENTAGE_CAPACITY, &battery->flags))
|
2013-05-09 07:11:15 +08:00
|
|
|
return;
|
2010-10-22 10:02:06 +08:00
|
|
|
|
2013-05-09 07:11:15 +08:00
|
|
|
if (battery->full_charge_capacity == 100 &&
|
|
|
|
|
battery->rate_now == ACPI_BATTERY_VALUE_UNKNOWN &&
|
|
|
|
|
battery->capacity_now >= 0 && battery->capacity_now <= 100) {
|
2010-10-22 10:02:06 +08:00
|
|
|
set_bit(ACPI_BATTERY_QUIRK_PERCENTAGE_CAPACITY, &battery->flags);
|
|
|
|
|
battery->full_charge_capacity = battery->design_capacity;
|
|
|
|
|
battery->capacity_now = (battery->capacity_now *
|
|
|
|
|
battery->full_charge_capacity) / 100;
|
|
|
|
|
}
|
ACPI / battery: Correct battery capacity values on Thinkpads
Add a quirk to correctly report battery capacity on 2010 and 2011
Lenovo Thinkpad models.
The affected models that I tested (x201, t410, t410s, and x220)
exhibit a problem where, when battery capacity reporting unit is mAh,
the values being reported are wrong. Pre-2010 and 2012 models appear
to always report in mWh and are thus unaffected. Also, in mid-2012
Lenovo issued a BIOS update for the 2011 models that fixes the issue
(tested on x220 with a post-1.29 BIOS). No such update is available
for the 2010 models, so those still need this patch.
Problem description: for some reason, the affected Thinkpads switch
the reporting unit between mAh and mWh; generally, mAh is used when a
laptop is plugged in and mWh when it's unplugged, although a
suspend/resume or rmmod/modprobe is needed for the switch to take
effect. The values reported in mAh are *always* wrong. This does
not appear to be a kernel regression; I believe that the values were
never reported correctly. I tested back to kernel 2.6.34, with
multiple machines and BIOS versions.
Simply plugging a laptop into mains before turning it on is enough to
reproduce the problem. Here's a sample /proc/acpi/battery/BAT0/info
from Thinkpad x220 (before a BIOS update) with a 4-cell battery:
present: yes
design capacity: 2886 mAh
last full capacity: 2909 mAh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 145 mAh
design capacity low: 13 mAh
cycle count: 0
capacity granularity 1: 1 mAh
capacity granularity 2: 1 mAh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Once the laptop switches the unit to mWh (unplug from mains, suspend,
resume), the output changes to:
present: yes
design capacity: 28860 mWh
last full capacity: 29090 mWh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 1454 mWh
design capacity low: 200 mWh
cycle count: 0
capacity granularity 1: 1 mWh
capacity granularity 2: 1 mWh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Can you see how the values for "design capacity", etc., differ by a
factor of 10 instead of 14.8 (the design voltage of this battery)?
On the battery itself it says: 14.8V, 1.95Ah, 29Wh, so clearly the
values reported in mWh are correct and the ones in mAh are not.
My guess is that this problem has been around ever since those
machines were released, but because the most common Thinkpad
batteries are rated at 10.8V, the error (8%) is small enough that it
simply hasn't been noticed or at least nobody could be bothered to
look into it.
My patch works around the problem by adjusting the incorrectly
reported mAh values by "10000 / design_voltage". The patch also has
code to figure out if it should be activated or not. It only
activates on Lenovo Thinkpads, only when the unit is mAh, and, as an
extra precaution, only when the battery capacity reported through
ACPI does not match what is reported through DMI (I've never
encountered a machine where the first two conditions would be true
but the last would not, but better safe than sorry).
I've been using this patch for close to a year on several systems
without any problems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=41062
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-17 05:28:58 +08:00
|
|
|
|
|
|
|
|
if (test_bit(ACPI_BATTERY_QUIRK_THINKPAD_MAH, &battery->flags))
|
2013-05-09 07:11:15 +08:00
|
|
|
return;
|
ACPI / battery: Correct battery capacity values on Thinkpads
Add a quirk to correctly report battery capacity on 2010 and 2011
Lenovo Thinkpad models.
The affected models that I tested (x201, t410, t410s, and x220)
exhibit a problem where, when battery capacity reporting unit is mAh,
the values being reported are wrong. Pre-2010 and 2012 models appear
to always report in mWh and are thus unaffected. Also, in mid-2012
Lenovo issued a BIOS update for the 2011 models that fixes the issue
(tested on x220 with a post-1.29 BIOS). No such update is available
for the 2010 models, so those still need this patch.
Problem description: for some reason, the affected Thinkpads switch
the reporting unit between mAh and mWh; generally, mAh is used when a
laptop is plugged in and mWh when it's unplugged, although a
suspend/resume or rmmod/modprobe is needed for the switch to take
effect. The values reported in mAh are *always* wrong. This does
not appear to be a kernel regression; I believe that the values were
never reported correctly. I tested back to kernel 2.6.34, with
multiple machines and BIOS versions.
Simply plugging a laptop into mains before turning it on is enough to
reproduce the problem. Here's a sample /proc/acpi/battery/BAT0/info
from Thinkpad x220 (before a BIOS update) with a 4-cell battery:
present: yes
design capacity: 2886 mAh
last full capacity: 2909 mAh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 145 mAh
design capacity low: 13 mAh
cycle count: 0
capacity granularity 1: 1 mAh
capacity granularity 2: 1 mAh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Once the laptop switches the unit to mWh (unplug from mains, suspend,
resume), the output changes to:
present: yes
design capacity: 28860 mWh
last full capacity: 29090 mWh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 1454 mWh
design capacity low: 200 mWh
cycle count: 0
capacity granularity 1: 1 mWh
capacity granularity 2: 1 mWh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Can you see how the values for "design capacity", etc., differ by a
factor of 10 instead of 14.8 (the design voltage of this battery)?
On the battery itself it says: 14.8V, 1.95Ah, 29Wh, so clearly the
values reported in mWh are correct and the ones in mAh are not.
My guess is that this problem has been around ever since those
machines were released, but because the most common Thinkpad
batteries are rated at 10.8V, the error (8%) is small enough that it
simply hasn't been noticed or at least nobody could be bothered to
look into it.
My patch works around the problem by adjusting the incorrectly
reported mAh values by "10000 / design_voltage". The patch also has
code to figure out if it should be activated or not. It only
activates on Lenovo Thinkpads, only when the unit is mAh, and, as an
extra precaution, only when the battery capacity reported through
ACPI does not match what is reported through DMI (I've never
encountered a machine where the first two conditions would be true
but the last would not, but better safe than sorry).
I've been using this patch for close to a year on several systems
without any problems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=41062
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-17 05:28:58 +08:00
|
|
|
|
|
|
|
|
if (battery->power_unit && dmi_name_in_vendors("LENOVO")) {
|
|
|
|
|
const char *s;
|
2021-03-27 20:08:18 +08:00
|
|
|
|
ACPI / battery: Correct battery capacity values on Thinkpads
Add a quirk to correctly report battery capacity on 2010 and 2011
Lenovo Thinkpad models.
The affected models that I tested (x201, t410, t410s, and x220)
exhibit a problem where, when battery capacity reporting unit is mAh,
the values being reported are wrong. Pre-2010 and 2012 models appear
to always report in mWh and are thus unaffected. Also, in mid-2012
Lenovo issued a BIOS update for the 2011 models that fixes the issue
(tested on x220 with a post-1.29 BIOS). No such update is available
for the 2010 models, so those still need this patch.
Problem description: for some reason, the affected Thinkpads switch
the reporting unit between mAh and mWh; generally, mAh is used when a
laptop is plugged in and mWh when it's unplugged, although a
suspend/resume or rmmod/modprobe is needed for the switch to take
effect. The values reported in mAh are *always* wrong. This does
not appear to be a kernel regression; I believe that the values were
never reported correctly. I tested back to kernel 2.6.34, with
multiple machines and BIOS versions.
Simply plugging a laptop into mains before turning it on is enough to
reproduce the problem. Here's a sample /proc/acpi/battery/BAT0/info
from Thinkpad x220 (before a BIOS update) with a 4-cell battery:
present: yes
design capacity: 2886 mAh
last full capacity: 2909 mAh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 145 mAh
design capacity low: 13 mAh
cycle count: 0
capacity granularity 1: 1 mAh
capacity granularity 2: 1 mAh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Once the laptop switches the unit to mWh (unplug from mains, suspend,
resume), the output changes to:
present: yes
design capacity: 28860 mWh
last full capacity: 29090 mWh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 1454 mWh
design capacity low: 200 mWh
cycle count: 0
capacity granularity 1: 1 mWh
capacity granularity 2: 1 mWh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Can you see how the values for "design capacity", etc., differ by a
factor of 10 instead of 14.8 (the design voltage of this battery)?
On the battery itself it says: 14.8V, 1.95Ah, 29Wh, so clearly the
values reported in mWh are correct and the ones in mAh are not.
My guess is that this problem has been around ever since those
machines were released, but because the most common Thinkpad
batteries are rated at 10.8V, the error (8%) is small enough that it
simply hasn't been noticed or at least nobody could be bothered to
look into it.
My patch works around the problem by adjusting the incorrectly
reported mAh values by "10000 / design_voltage". The patch also has
code to figure out if it should be activated or not. It only
activates on Lenovo Thinkpads, only when the unit is mAh, and, as an
extra precaution, only when the battery capacity reported through
ACPI does not match what is reported through DMI (I've never
encountered a machine where the first two conditions would be true
but the last would not, but better safe than sorry).
I've been using this patch for close to a year on several systems
without any problems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=41062
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-17 05:28:58 +08:00
|
|
|
s = dmi_get_system_info(DMI_PRODUCT_VERSION);
|
2014-09-17 04:51:24 +08:00
|
|
|
if (s && !strncasecmp(s, "ThinkPad", 8)) {
|
ACPI / battery: Correct battery capacity values on Thinkpads
Add a quirk to correctly report battery capacity on 2010 and 2011
Lenovo Thinkpad models.
The affected models that I tested (x201, t410, t410s, and x220)
exhibit a problem where, when battery capacity reporting unit is mAh,
the values being reported are wrong. Pre-2010 and 2012 models appear
to always report in mWh and are thus unaffected. Also, in mid-2012
Lenovo issued a BIOS update for the 2011 models that fixes the issue
(tested on x220 with a post-1.29 BIOS). No such update is available
for the 2010 models, so those still need this patch.
Problem description: for some reason, the affected Thinkpads switch
the reporting unit between mAh and mWh; generally, mAh is used when a
laptop is plugged in and mWh when it's unplugged, although a
suspend/resume or rmmod/modprobe is needed for the switch to take
effect. The values reported in mAh are *always* wrong. This does
not appear to be a kernel regression; I believe that the values were
never reported correctly. I tested back to kernel 2.6.34, with
multiple machines and BIOS versions.
Simply plugging a laptop into mains before turning it on is enough to
reproduce the problem. Here's a sample /proc/acpi/battery/BAT0/info
from Thinkpad x220 (before a BIOS update) with a 4-cell battery:
present: yes
design capacity: 2886 mAh
last full capacity: 2909 mAh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 145 mAh
design capacity low: 13 mAh
cycle count: 0
capacity granularity 1: 1 mAh
capacity granularity 2: 1 mAh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Once the laptop switches the unit to mWh (unplug from mains, suspend,
resume), the output changes to:
present: yes
design capacity: 28860 mWh
last full capacity: 29090 mWh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 1454 mWh
design capacity low: 200 mWh
cycle count: 0
capacity granularity 1: 1 mWh
capacity granularity 2: 1 mWh
model number: 42T4899
serial number: 21064
battery type: LION
OEM info: SANYO
Can you see how the values for "design capacity", etc., differ by a
factor of 10 instead of 14.8 (the design voltage of this battery)?
On the battery itself it says: 14.8V, 1.95Ah, 29Wh, so clearly the
values reported in mWh are correct and the ones in mAh are not.
My guess is that this problem has been around ever since those
machines were released, but because the most common Thinkpad
batteries are rated at 10.8V, the error (8%) is small enough that it
simply hasn't been noticed or at least nobody could be bothered to
look into it.
My patch works around the problem by adjusting the incorrectly
reported mAh values by "10000 / design_voltage". The patch also has
code to figure out if it should be activated or not. It only
activates on Lenovo Thinkpads, only when the unit is mAh, and, as an
extra precaution, only when the battery capacity reported through
ACPI does not match what is reported through DMI (I've never
encountered a machine where the first two conditions would be true
but the last would not, but better safe than sorry).
I've been using this patch for close to a year on several systems
without any problems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=41062
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-17 05:28:58 +08:00
|
|
|
dmi_walk(find_battery, battery);
|
|
|
|
|
if (test_bit(ACPI_BATTERY_QUIRK_THINKPAD_MAH,
|
|
|
|
|
&battery->flags) &&
|
|
|
|
|
battery->design_voltage) {
|
|
|
|
|
battery->design_capacity =
|
|
|
|
|
battery->design_capacity *
|
|
|
|
|
10000 / battery->design_voltage;
|
|
|
|
|
battery->full_charge_capacity =
|
|
|
|
|
battery->full_charge_capacity *
|
|
|
|
|
10000 / battery->design_voltage;
|
|
|
|
|
battery->design_capacity_warning =
|
|
|
|
|
battery->design_capacity_warning *
|
|
|
|
|
10000 / battery->design_voltage;
|
|
|
|
|
battery->capacity_now = battery->capacity_now *
|
|
|
|
|
10000 / battery->design_voltage;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-02-24 17:20:15 +08:00
|
|
|
|
|
|
|
|
if (test_bit(ACPI_BATTERY_QUIRK_DEGRADED_FULL_CHARGE, &battery->flags))
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
if (acpi_battery_is_degraded(battery) &&
|
|
|
|
|
battery->capacity_now > battery->full_charge_capacity) {
|
|
|
|
|
set_bit(ACPI_BATTERY_QUIRK_DEGRADED_FULL_CHARGE, &battery->flags);
|
|
|
|
|
battery->capacity_now = battery->full_charge_capacity;
|
|
|
|
|
}
|
2010-10-22 10:02:06 +08:00
|
|
|
}
|
|
|
|
|
|
2014-05-04 14:07:06 +08:00
|
|
|
static int acpi_battery_update(struct acpi_battery *battery, bool resume)
|
2007-02-20 20:48:06 +08:00
|
|
|
{
|
2018-07-15 06:40:18 +08:00
|
|
|
int result = acpi_battery_get_status(battery);
|
|
|
|
|
|
2007-10-28 17:50:09 +08:00
|
|
|
if (result)
|
2007-02-20 20:48:06 +08:00
|
|
|
return result;
|
2018-07-15 06:40:18 +08:00
|
|
|
|
2007-10-28 17:50:09 +08:00
|
|
|
if (!acpi_battery_present(battery)) {
|
|
|
|
|
sysfs_remove_battery(battery);
|
2008-01-02 03:27:24 +08:00
|
|
|
battery->update_time = 0;
|
2007-10-28 17:50:09 +08:00
|
|
|
return 0;
|
2007-02-20 20:48:06 +08:00
|
|
|
}
|
2014-05-04 14:07:06 +08:00
|
|
|
|
|
|
|
|
if (resume)
|
|
|
|
|
return 0;
|
|
|
|
|
|
2018-07-15 06:40:18 +08:00
|
|
|
if (!battery->update_time) {
|
2008-01-02 03:27:24 +08:00
|
|
|
result = acpi_battery_get_info(battery);
|
|
|
|
|
if (result)
|
|
|
|
|
return result;
|
|
|
|
|
acpi_battery_init_alarm(battery);
|
|
|
|
|
}
|
ACPI / battery: Add sysfs representation after checking _BST
Thus move sysfs_add_battery() after acpi_battery_get_state(), which doesn't
require the power_supply. Prevents possible hanged tasks if
acpi_battery_get_state() fails consistently (and takes a long time in doing
so) when called inside acpi_battery_add().
In this situation the battery module first calls sysfs_add_battery(),
which creates a power_supply, which spawns an async
power_supply_deferred_register_work() task, which shall try to hold the
parent battery device mutex (being already held) so this register work
is set up after device initialization. If initialization takes long enough
the thread will be eventually run and try to hold the mutex before
acpi_battery_add() had the chance to finish.
Eventually the 5 retries in acpi_battery_update_retry() fail, the error
state is propagated, and results in sysfs_remove_battery() being called
within the error handling paths of acpi_battery_add(), and the power_supply
tear down too.
This triggers a cancel_delayed_work_sync() of the deferred_register_work
task, which ends up in schedule(). The end result is that the deferred
task is blocked trying to acquire the parent device mutex, which is not
released because the thread doing initialization (and failure handling)
went to sleep awaiting for the deferred task to be cancelled.
The hanged tasks look like this:
INFO: task kworker/u8:0:6 blocked for more than 120 seconds.
...
Call Trace:
[<ffffffff815daec5>] schedule+0x35/0x80
[<ffffffff815dda3c>] schedule_timeout+0x1ec/0x250
[<ffffffff810a0572>] ? check_preempt_curr+0x52/0x90
[<ffffffff810a05c9>] ? ttwu_do_wakeup+0x19/0xe0
[<ffffffff815db915>] wait_for_common+0xc5/0x190
[<ffffffff810a1500>] ? wake_up_q+0x70/0x70
[<ffffffff815db9fd>] wait_for_completion+0x1d/0x20
[<ffffffff8108ffb1>] flush_work+0x111/0x1c0
[<ffffffff8108dfe0>] ? flush_workqueue_prep_pwqs+0x1a0/0x1a0
[<ffffffff810909af>] __cancel_work_timer+0x9f/0x1d0
[<ffffffff81090b13>] cancel_delayed_work_sync+0x13/0x20
[<ffffffff8147ac67>] power_supply_unregister+0x37/0xc0
[<ffffffffa058b03d>] sysfs_remove_battery+0x3d/0x52 [battery]
[<ffffffffa058bf3a>] acpi_battery_add+0x112/0x181 [battery]
[<ffffffff81366db6>] acpi_device_probe+0x54/0x19b
[<ffffffff81427e9c>] driver_probe_device+0x22c/0x440
[<ffffffff81428181>] __driver_attach+0xd1/0xf0
[<ffffffff814280b0>] ? driver_probe_device+0x440/0x440
[<ffffffff8142591c>] bus_for_each_dev+0x6c/0xc0
[<ffffffff8142758e>] driver_attach+0x1e/0x20
[<ffffffff81426fc3>] bus_add_driver+0x1c3/0x280
[<ffffffff81428b00>] driver_register+0x60/0xe0
[<ffffffff81366c80>] acpi_bus_register_driver+0x3b/0x43
[<ffffffffa0591040>] acpi_battery_init_async+0x1c/0x1e [battery]
[<ffffffff81099268>] async_run_entry_fn+0x48/0x150
[<ffffffff81090d09>] process_one_work+0x1e9/0x440
[<ffffffff81090fab>] worker_thread+0x4b/0x4f0
[<ffffffff81090f60>] ? process_one_work+0x440/0x440
[<ffffffff81096b58>] kthread+0xd8/0xf0
[<ffffffff815de97f>] ret_from_fork+0x1f/0x40
[<ffffffff81096a80>] ? kthread_worker_fn+0x180/0x180
INFO: task kworker/u8:4:282 blocked for more than 120 seconds.
...
Call Trace:
[<ffffffff810ad745>] ? put_prev_entity+0x35/0x8b0
[<ffffffff815daec5>] schedule+0x35/0x80
[<ffffffff815db14e>] schedule_preempt_disabled+0xe/0x10
[<ffffffff815dc533>] __mutex_lock_slowpath+0xb3/0x120
[<ffffffff815dc5bf>] mutex_lock+0x1f/0x30
[<ffffffff8147a59b>] power_supply_deferred_register_work+0x2b/0x50
[<ffffffff81090d09>] process_one_work+0x1e9/0x440
[<ffffffff81090fab>] worker_thread+0x4b/0x4f0
[<ffffffff81090f60>] ? process_one_work+0x440/0x440
[<ffffffff81090f60>] ? process_one_work+0x440/0x440
[<ffffffff81096b58>] kthread+0xd8/0xf0
[<ffffffff815de97f>] ret_from_fork+0x1f/0x40
[<ffffffff81096a80>] ? kthread_worker_fn+0x180/0x180
Making sysfs_add_battery() the last operation here means that the
power_supply won't be created yet when the acpi_add_battery() failure
handling happens, the deferred task won't even spawn, and
sysfs_remove_battery will just skip over the NULL battery->bat.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-10 23:24:15 +08:00
|
|
|
|
|
|
|
|
result = acpi_battery_get_state(battery);
|
|
|
|
|
if (result)
|
|
|
|
|
return result;
|
|
|
|
|
acpi_battery_quirks(battery);
|
|
|
|
|
|
2015-03-12 15:44:11 +08:00
|
|
|
if (!battery->bat) {
|
2011-07-12 16:03:29 +08:00
|
|
|
result = sysfs_add_battery(battery);
|
|
|
|
|
if (result)
|
|
|
|
|
return result;
|
|
|
|
|
}
|
2014-05-28 15:23:38 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Wakeup the system if battery is critical low
|
|
|
|
|
* or lower than the alarm level
|
|
|
|
|
*/
|
|
|
|
|
if ((battery->state & ACPI_BATTERY_STATE_CRITICAL) ||
|
|
|
|
|
(test_bit(ACPI_BATTERY_ALARM_PRESENT, &battery->flags) &&
|
2020-11-05 10:06:00 +08:00
|
|
|
(battery->capacity_now <= battery->alarm)))
|
ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle
The ACPI SCI (System Control Interrupt) is set up as a wakeup IRQ
during suspend-to-idle transitions and, consequently, any events
signaled through it wake up the system from that state. However,
on some systems some of the events signaled via the ACPI SCI while
suspended to idle should not cause the system to wake up. In fact,
quite often they should just be discarded.
Arguably, systems should not resume entirely on such events, but in
order to decide which events really should cause the system to resume
and which are spurious, it is necessary to resume up to the point
when ACPI SCIs are actually handled and processed, which is after
executing dpm_resume_noirq() in the system resume path.
For this reasons, add a loop around freeze_enter() in which the
platforms can process events signaled via multiplexed IRQ lines
like the ACPI SCI and add suspend-to-idle hooks that can be
used for this purpose to struct platform_freeze_ops.
In the ACPI case, the ->wake hook is used for checking if the SCI
has triggered while suspended and deferring the interrupt-induced
system wakeup until the events signaled through it are actually
processed sufficiently to decide whether or not the system should
resume. In turn, the ->sync hook allows all of the relevant event
queues to be flushed so as to prevent events from being missed due
to race conditions.
In addition to that, some ACPI code processing wakeup events needs
to be modified to use the "hard" version of wakeup triggers, so that
it will cause a system resume to happen on device-induced wakeup
events even if the "soft" mechanism to prevent the system from
suspending is not enabled. However, to preserve the existing
behavior with respect to suspend-to-RAM, this only is done in
the suspend-to-idle case and only if an SCI has occurred while
suspended.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-13 04:56:34 +08:00
|
|
|
acpi_pm_wakeup_event(&battery->device->dev);
|
2014-05-28 15:23:38 +08:00
|
|
|
|
2010-10-22 10:02:06 +08:00
|
|
|
return result;
|
2007-02-10 14:43:48 +08:00
|
|
|
}
|
|
|
|
|
|
2011-01-07 06:42:27 +08:00
|
|
|
static void acpi_battery_refresh(struct acpi_battery *battery)
|
|
|
|
|
{
|
2012-05-03 21:48:26 +08:00
|
|
|
int power_unit;
|
|
|
|
|
|
2015-03-12 15:44:11 +08:00
|
|
|
if (!battery->bat)
|
2011-01-07 06:42:27 +08:00
|
|
|
return;
|
|
|
|
|
|
2012-05-03 21:48:26 +08:00
|
|
|
power_unit = battery->power_unit;
|
|
|
|
|
|
2011-01-07 06:42:27 +08:00
|
|
|
acpi_battery_get_info(battery);
|
2012-05-03 21:48:26 +08:00
|
|
|
|
|
|
|
|
if (power_unit == battery->power_unit)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
/* The battery has changed its reporting units. */
|
2011-01-07 06:42:27 +08:00
|
|
|
sysfs_remove_battery(battery);
|
|
|
|
|
sysfs_add_battery(battery);
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-27 20:08:18 +08:00
|
|
|
/* Driver Interface */
|
2009-04-30 23:35:47 +08:00
|
|
|
static void acpi_battery_notify(struct acpi_device *device, u32 event)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2009-04-30 23:35:47 +08:00
|
|
|
struct acpi_battery *battery = acpi_driver_data(device);
|
2015-03-12 15:44:11 +08:00
|
|
|
struct power_supply *old;
|
2009-04-30 23:35:47 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
if (!battery)
|
2006-06-27 12:41:40 +08:00
|
|
|
return;
|
2015-03-12 15:44:11 +08:00
|
|
|
old = battery->bat;
|
2014-06-04 03:01:23 +08:00
|
|
|
/*
|
2021-03-27 20:08:18 +08:00
|
|
|
* On Acer Aspire V5-573G notifications are sometimes triggered too
|
|
|
|
|
* early. For example, when AC is unplugged and notification is
|
|
|
|
|
* triggered, battery state is still reported as "Full", and changes to
|
|
|
|
|
* "Discharging" only after short delay, without any notification.
|
|
|
|
|
*/
|
2014-06-04 03:01:23 +08:00
|
|
|
if (battery_notification_delay_ms > 0)
|
|
|
|
|
msleep(battery_notification_delay_ms);
|
2011-01-07 06:42:27 +08:00
|
|
|
if (event == ACPI_BATTERY_NOTIFY_INFO)
|
|
|
|
|
acpi_battery_refresh(battery);
|
2014-05-04 14:07:06 +08:00
|
|
|
acpi_battery_update(battery, false);
|
2007-09-26 23:42:52 +08:00
|
|
|
acpi_bus_generate_netlink_event(device->pnp.device_class,
|
ACPI: struct device - replace bus_id with dev_name(), dev_set_name()
This patch is part of a larger patch series which will remove
the "char bus_id[20]" name string from struct device. The device
name is managed in the kobject anyway, and without any size
limitation, and just needlessly copied into "struct device".
To set and read the device name dev_name(dev) and dev_set_name(dev)
must be used. If your code uses static kobjects, which it shouldn't
do, "const char *init_name" can be used to statically provide the
name the registered device should have. At registration time, the
init_name field is cleared, to enforce the use of dev_name(dev) to
access the device name at a later time.
We need to get rid of all occurrences of bus_id in the entire tree
to be able to enable the new interface. Please apply this patch,
and possibly convert any remaining remaining occurrences of bus_id.
We want to submit a patch to -next, which will remove bus_id from
"struct device", to find the remaining pieces to convert, and finally
switch over to the new api, which will remove the 20 bytes array
and does no longer have a size limitation.
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-Off-By: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Len Brown <len.brown@intel.com>
2008-10-30 08:18:59 +08:00
|
|
|
dev_name(&device->dev), event,
|
2007-02-20 20:48:06 +08:00
|
|
|
acpi_battery_present(battery));
|
2014-03-12 01:58:47 +08:00
|
|
|
acpi_notifier_call_chain(device, event, acpi_battery_present(battery));
|
2009-12-14 06:42:36 +08:00
|
|
|
/* acpi_battery_update could remove power_supply object */
|
2015-03-12 15:44:11 +08:00
|
|
|
if (old && battery->bat)
|
|
|
|
|
power_supply_changed(battery->bat);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2011-03-23 04:19:50 +08:00
|
|
|
static int battery_notify(struct notifier_block *nb,
|
|
|
|
|
unsigned long mode, void *_unused)
|
|
|
|
|
{
|
|
|
|
|
struct acpi_battery *battery = container_of(nb, struct acpi_battery,
|
|
|
|
|
pm_nb);
|
2014-05-04 14:07:06 +08:00
|
|
|
int result;
|
|
|
|
|
|
2011-03-23 04:19:50 +08:00
|
|
|
switch (mode) {
|
2011-06-30 11:33:40 +08:00
|
|
|
case PM_POST_HIBERNATION:
|
2011-03-23 04:19:50 +08:00
|
|
|
case PM_POST_SUSPEND:
|
2014-05-04 14:07:06 +08:00
|
|
|
if (!acpi_battery_present(battery))
|
|
|
|
|
return 0;
|
|
|
|
|
|
2018-07-24 19:27:34 +08:00
|
|
|
if (battery->bat) {
|
|
|
|
|
acpi_battery_refresh(battery);
|
|
|
|
|
} else {
|
2014-05-04 14:07:06 +08:00
|
|
|
result = acpi_battery_get_info(battery);
|
|
|
|
|
if (result)
|
|
|
|
|
return result;
|
|
|
|
|
|
|
|
|
|
result = sysfs_add_battery(battery);
|
|
|
|
|
if (result)
|
|
|
|
|
return result;
|
2018-07-24 19:27:34 +08:00
|
|
|
}
|
2014-05-04 14:07:06 +08:00
|
|
|
|
|
|
|
|
acpi_battery_init_alarm(battery);
|
|
|
|
|
acpi_battery_get_state(battery);
|
2011-03-23 04:19:50 +08:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2015-06-13 20:26:55 +08:00
|
|
|
static int __init
|
|
|
|
|
battery_bix_broken_package_quirk(const struct dmi_system_id *d)
|
2014-06-04 03:01:22 +08:00
|
|
|
{
|
|
|
|
|
battery_bix_broken_package = 1;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2015-06-13 20:26:55 +08:00
|
|
|
static int __init
|
|
|
|
|
battery_notification_delay_quirk(const struct dmi_system_id *d)
|
2014-06-04 03:01:23 +08:00
|
|
|
{
|
|
|
|
|
battery_notification_delay_ms = 1000;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-12 18:02:00 +08:00
|
|
|
static int __init
|
|
|
|
|
battery_ac_is_broken_quirk(const struct dmi_system_id *d)
|
|
|
|
|
{
|
|
|
|
|
battery_ac_is_broken = 1;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-18 20:04:39 +08:00
|
|
|
static int __init
|
|
|
|
|
battery_do_not_check_pmic_quirk(const struct dmi_system_id *d)
|
|
|
|
|
{
|
|
|
|
|
battery_check_pmic = 0;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2015-06-13 20:26:55 +08:00
|
|
|
static const struct dmi_system_id bat_dmi_table[] __initconst = {
|
2014-01-06 22:50:37 +08:00
|
|
|
{
|
2018-04-12 18:01:58 +08:00
|
|
|
/* NEC LZ750/LS */
|
2014-06-04 03:01:22 +08:00
|
|
|
.callback = battery_bix_broken_package_quirk,
|
2014-01-06 22:50:37 +08:00
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "NEC"),
|
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "PC-LZ750LS"),
|
|
|
|
|
},
|
|
|
|
|
},
|
2014-06-04 03:01:23 +08:00
|
|
|
{
|
2018-04-12 18:01:58 +08:00
|
|
|
/* Acer Aspire V5-573G */
|
2014-06-04 03:01:23 +08:00
|
|
|
.callback = battery_notification_delay_quirk,
|
|
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
|
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "Aspire V5-573G"),
|
|
|
|
|
},
|
|
|
|
|
},
|
2018-04-12 18:02:00 +08:00
|
|
|
{
|
|
|
|
|
/* Point of View mobii wintab p800w */
|
|
|
|
|
.callback = battery_ac_is_broken_quirk,
|
|
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
|
|
|
|
|
DMI_MATCH(DMI_BOARD_NAME, "Aptio CRB"),
|
|
|
|
|
DMI_MATCH(DMI_BIOS_VERSION, "3BAIR1013"),
|
|
|
|
|
/* Above matches are too generic, add bios-date match */
|
|
|
|
|
DMI_MATCH(DMI_BIOS_DATE, "08/22/2014"),
|
|
|
|
|
},
|
|
|
|
|
},
|
2018-04-18 20:04:39 +08:00
|
|
|
{
|
2020-02-23 22:29:41 +08:00
|
|
|
/* ECS EF20EA, AXP288 PMIC but uses separate fuel-gauge */
|
2018-04-18 20:04:39 +08:00
|
|
|
.callback = battery_do_not_check_pmic_quirk,
|
|
|
|
|
.matches = {
|
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
{
|
2020-02-23 22:29:41 +08:00
|
|
|
/* Lenovo Ideapad Miix 320, AXP288 PMIC, separate fuel-gauge */
|
2018-04-18 20:04:39 +08:00
|
|
|
.callback = battery_do_not_check_pmic_quirk,
|
|
|
|
|
.matches = {
|
2020-02-23 22:29:41 +08:00
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
|
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "80XF"),
|
|
|
|
|
DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo MIIX 320-10ICR"),
|
2018-04-18 20:04:39 +08:00
|
|
|
},
|
|
|
|
|
},
|
2014-01-06 22:50:37 +08:00
|
|
|
{},
|
|
|
|
|
};
|
|
|
|
|
|
2014-07-07 15:47:12 +08:00
|
|
|
/*
|
|
|
|
|
* Some machines'(E,G Lenovo Z480) ECs are not stable
|
|
|
|
|
* during boot up and this causes battery driver fails to be
|
|
|
|
|
* probed due to failure of getting battery information
|
|
|
|
|
* from EC sometimes. After several retries, the operation
|
|
|
|
|
* may work. So add retry code here and 20ms sleep between
|
|
|
|
|
* every retries.
|
|
|
|
|
*/
|
|
|
|
|
static int acpi_battery_update_retry(struct acpi_battery *battery)
|
|
|
|
|
{
|
|
|
|
|
int retry, ret;
|
|
|
|
|
|
|
|
|
|
for (retry = 5; retry; retry--) {
|
|
|
|
|
ret = acpi_battery_update(battery, false);
|
|
|
|
|
if (!ret)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
msleep(20);
|
|
|
|
|
}
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2005-08-05 12:44:28 +08:00
|
|
|
static int acpi_battery_add(struct acpi_device *device)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2005-08-05 12:44:28 +08:00
|
|
|
int result = 0;
|
|
|
|
|
struct acpi_battery *battery = NULL;
|
2013-06-29 00:24:38 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
if (!device)
|
2006-06-27 12:41:40 +08:00
|
|
|
return -EINVAL;
|
2014-11-23 21:22:54 +08:00
|
|
|
|
|
|
|
|
if (device->dep_unmet)
|
|
|
|
|
return -EPROBE_DEFER;
|
|
|
|
|
|
2006-12-20 04:56:11 +08:00
|
|
|
battery = kzalloc(sizeof(struct acpi_battery), GFP_KERNEL);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (!battery)
|
2006-06-27 12:41:40 +08:00
|
|
|
return -ENOMEM;
|
2006-05-20 04:54:39 +08:00
|
|
|
battery->device = device;
|
2005-04-17 06:20:36 +08:00
|
|
|
strcpy(acpi_device_name(device), ACPI_BATTERY_DEVICE_NAME);
|
|
|
|
|
strcpy(acpi_device_class(device), ACPI_BATTERY_CLASS);
|
2008-09-23 05:37:34 +08:00
|
|
|
device->driver_data = battery;
|
2007-09-26 23:42:46 +08:00
|
|
|
mutex_init(&battery->lock);
|
2011-08-06 06:34:08 +08:00
|
|
|
mutex_init(&battery->sysfs_lock);
|
2013-06-29 00:24:38 +08:00
|
|
|
if (acpi_has_method(battery->device->handle, "_BIX"))
|
2009-10-15 18:31:44 +08:00
|
|
|
set_bit(ACPI_BATTERY_XINFO_PRESENT, &battery->flags);
|
2014-07-07 15:47:12 +08:00
|
|
|
|
|
|
|
|
result = acpi_battery_update_retry(battery);
|
2011-07-12 16:03:29 +08:00
|
|
|
if (result)
|
|
|
|
|
goto fail;
|
2014-07-07 15:47:12 +08:00
|
|
|
|
2021-02-04 02:44:57 +08:00
|
|
|
pr_info("Slot [%s] (battery %s)\n", acpi_device_bid(device),
|
2011-07-12 16:03:28 +08:00
|
|
|
device->status.battery_present ? "present" : "absent");
|
|
|
|
|
|
2011-03-23 04:19:50 +08:00
|
|
|
battery->pm_nb.notifier_call = battery_notify;
|
|
|
|
|
register_pm_notifier(&battery->pm_nb);
|
|
|
|
|
|
2014-05-28 15:23:38 +08:00
|
|
|
device_init_wakeup(&device->dev, 1);
|
|
|
|
|
|
2006-06-27 12:41:40 +08:00
|
|
|
return result;
|
2011-07-12 16:03:28 +08:00
|
|
|
|
|
|
|
|
fail:
|
|
|
|
|
sysfs_remove_battery(battery);
|
|
|
|
|
mutex_destroy(&battery->lock);
|
2011-08-06 06:34:08 +08:00
|
|
|
mutex_destroy(&battery->sysfs_lock);
|
2011-07-12 16:03:28 +08:00
|
|
|
kfree(battery);
|
|
|
|
|
return result;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2013-01-24 07:24:48 +08:00
|
|
|
static int acpi_battery_remove(struct acpi_device *device)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2005-08-05 12:44:28 +08:00
|
|
|
struct acpi_battery *battery = NULL;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
if (!device || !acpi_driver_data(device))
|
2006-06-27 12:41:40 +08:00
|
|
|
return -EINVAL;
|
2014-05-28 15:23:38 +08:00
|
|
|
device_init_wakeup(&device->dev, 0);
|
2006-10-01 06:28:50 +08:00
|
|
|
battery = acpi_driver_data(device);
|
2011-03-23 04:19:50 +08:00
|
|
|
unregister_pm_notifier(&battery->pm_nb);
|
2007-10-28 17:50:09 +08:00
|
|
|
sysfs_remove_battery(battery);
|
2007-09-26 23:42:46 +08:00
|
|
|
mutex_destroy(&battery->lock);
|
2011-08-06 06:34:08 +08:00
|
|
|
mutex_destroy(&battery->sysfs_lock);
|
2005-04-17 06:20:36 +08:00
|
|
|
kfree(battery);
|
2006-06-27 12:41:40 +08:00
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2012-08-10 05:00:02 +08:00
|
|
|
#ifdef CONFIG_PM_SLEEP
|
2006-10-11 05:20:41 +08:00
|
|
|
/* this is needed to learn about changes made in suspended state */
|
2012-06-28 05:26:43 +08:00
|
|
|
static int acpi_battery_resume(struct device *dev)
|
2006-10-11 05:20:41 +08:00
|
|
|
{
|
|
|
|
|
struct acpi_battery *battery;
|
2012-06-28 05:26:43 +08:00
|
|
|
|
|
|
|
|
if (!dev)
|
2006-10-11 05:20:41 +08:00
|
|
|
return -EINVAL;
|
2012-06-28 05:26:43 +08:00
|
|
|
|
|
|
|
|
battery = acpi_driver_data(to_acpi_device(dev));
|
|
|
|
|
if (!battery)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
2007-09-26 23:42:52 +08:00
|
|
|
battery->update_time = 0;
|
2014-05-04 14:07:06 +08:00
|
|
|
acpi_battery_update(battery, true);
|
2007-02-20 20:48:06 +08:00
|
|
|
return 0;
|
2006-10-11 05:20:41 +08:00
|
|
|
}
|
2014-02-13 11:19:06 +08:00
|
|
|
#else
|
|
|
|
|
#define acpi_battery_resume NULL
|
2012-08-10 05:00:02 +08:00
|
|
|
#endif
|
2006-10-11 05:20:41 +08:00
|
|
|
|
2012-06-28 05:26:43 +08:00
|
|
|
static SIMPLE_DEV_PM_OPS(acpi_battery_pm, NULL, acpi_battery_resume);
|
|
|
|
|
|
2007-09-26 23:42:58 +08:00
|
|
|
static struct acpi_driver acpi_battery_driver = {
|
|
|
|
|
.name = "battery",
|
|
|
|
|
.class = ACPI_BATTERY_CLASS,
|
|
|
|
|
.ids = battery_device_ids,
|
2009-04-30 23:35:47 +08:00
|
|
|
.flags = ACPI_DRIVER_ALL_NOTIFY_EVENTS,
|
2007-09-26 23:42:58 +08:00
|
|
|
.ops = {
|
|
|
|
|
.add = acpi_battery_add,
|
|
|
|
|
.remove = acpi_battery_remove,
|
2009-04-30 23:35:47 +08:00
|
|
|
.notify = acpi_battery_notify,
|
2007-09-26 23:42:58 +08:00
|
|
|
},
|
2012-06-28 05:26:43 +08:00
|
|
|
.drv.pm = &acpi_battery_pm,
|
2007-09-26 23:42:58 +08:00
|
|
|
};
|
|
|
|
|
|
2009-04-12 03:45:20 +08:00
|
|
|
static void __init acpi_battery_init_async(void *unused, async_cookie_t cookie)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2017-04-19 20:02:10 +08:00
|
|
|
unsigned int i;
|
2015-05-12 05:48:46 +08:00
|
|
|
int result;
|
|
|
|
|
|
2014-06-04 03:01:22 +08:00
|
|
|
dmi_check_system(bat_dmi_table);
|
2015-05-12 05:48:46 +08:00
|
|
|
|
2018-04-18 20:04:39 +08:00
|
|
|
if (battery_check_pmic) {
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(acpi_battery_blacklist); i++)
|
|
|
|
|
if (acpi_dev_present(acpi_battery_blacklist[i], "1", -1)) {
|
2021-02-04 02:44:57 +08:00
|
|
|
pr_info("found native %s PMIC, not loading\n",
|
2018-04-18 20:04:39 +08:00
|
|
|
acpi_battery_blacklist[i]);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-05-12 05:48:46 +08:00
|
|
|
result = acpi_bus_register_driver(&acpi_battery_driver);
|
2017-04-19 20:02:09 +08:00
|
|
|
battery_driver_registered = (result == 0);
|
2009-01-11 03:19:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int __init acpi_battery_init(void)
|
|
|
|
|
{
|
2015-05-12 05:48:38 +08:00
|
|
|
if (acpi_disabled)
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
2015-05-12 05:49:05 +08:00
|
|
|
async_cookie = async_schedule(acpi_battery_init_async, NULL);
|
2006-06-27 12:41:40 +08:00
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2005-08-05 12:44:28 +08:00
|
|
|
static void __exit acpi_battery_exit(void)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2016-05-19 16:11:52 +08:00
|
|
|
async_synchronize_cookie(async_cookie + 1);
|
2018-02-07 22:58:13 +08:00
|
|
|
if (battery_driver_registered) {
|
2017-04-19 20:02:09 +08:00
|
|
|
acpi_bus_unregister_driver(&acpi_battery_driver);
|
2018-02-07 22:58:13 +08:00
|
|
|
battery_hook_exit();
|
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
module_init(acpi_battery_init);
|
|
|
|
|
module_exit(acpi_battery_exit);
|