linux_dsm_epyc7002/drivers/acpi/battery.c

885 lines
26 KiB
C
Raw Normal View History

/*
* battery.c - ACPI Battery Driver (Revision: 2.0)
*
* Copyright (C) 2007 Alexey Starikovskiy <astarikovskiy@suse.de>
* Copyright (C) 2004-2007 Vladimir Lebedev <vladimir.p.lebedev@intel.com>
* Copyright (C) 2001, 2002 Andy Grover <andrew.grover@intel.com>
* Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
*
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or (at
* your option) any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
*
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*/
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/types.h>
#include <linux/jiffies.h>
#include <linux/async.h>
#include <linux/dmi.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 15:04:11 +07:00
#include <linux/slab.h>
#include <linux/suspend.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 04:28:58 +07:00
#include <asm/unaligned.h>
ACPI: Clean up inclusions of ACPI header files Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h> inclusions and remove some inclusions of those files that aren't necessary. First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h> should not be included directly from any files that are built for CONFIG_ACPI unset, because that generally leads to build warnings about undefined symbols in !CONFIG_ACPI builds. For CONFIG_ACPI set, <linux/acpi.h> includes those files and for CONFIG_ACPI unset it provides stub ACPI symbols to be used in that case. Second, there are ordering dependencies between those files that always have to be met. Namely, it is required that <acpi/acpi_bus.h> be included prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the latter depends on are always there. And <acpi/acpi.h> which provides basic ACPICA type declarations should always be included prior to any other ACPI headers in CONFIG_ACPI builds. That also is taken care of including <linux/acpi.h> as appropriate. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Tony Luck <tony.luck@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff) Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-12-03 07:49:16 +07:00
#include <linux/acpi.h>
#include <linux/power_supply.h>
#include "battery.h"
#define PREFIX "ACPI: "
#define ACPI_BATTERY_VALUE_UNKNOWN 0xFFFFFFFF
#define ACPI_BATTERY_DEVICE_NAME "Battery"
/* Battery power unit: 0 means mW, 1 means mA */
#define ACPI_BATTERY_POWER_UNIT_MA 1
#define _COMPONENT ACPI_BATTERY_COMPONENT
ACPI_MODULE_NAME("battery");
MODULE_AUTHOR("Paul Diefenbaugh");
MODULE_AUTHOR("Alexey Starikovskiy <astarikovskiy@suse.de>");
MODULE_DESCRIPTION("ACPI Battery Driver");
MODULE_LICENSE("GPL");
static int battery_bix_broken_package;
static unsigned int cache_time = 1000;
module_param(cache_time, uint, 0644);
MODULE_PARM_DESC(cache_time, "cache time in milliseconds");
static const struct acpi_device_id battery_device_ids[] = {
{"PNP0C0A", 0},
{"", 0},
};
MODULE_DEVICE_TABLE(acpi, battery_device_ids);
enum {
ACPI_BATTERY_ALARM_PRESENT,
ACPI_BATTERY_XINFO_PRESENT,
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 04:28:58 +07:00
/* On Lenovo Thinkpad models from 2010 and 2011, the power unit
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_QUIRK_THINKPAD_MAH,
};
struct acpi_battery {
struct mutex lock;
Battery: sysfs_remove_battery(): possible circular locking Commit 9c921c22a7f33397a6774d7fa076db9b6a0fd669 Author: Lan Tianyu <tianyu.lan@intel.com> ACPI / Battery: Resolve the race condition in the sysfs_remove_battery() fixed BUG https://bugzilla.kernel.org/show_bug.cgi?id=35642 , but as a side effect made lockdep unhappy with sysfs_remove_battery(): [14818.477168] [14818.477170] ======================================================= [14818.477200] [ INFO: possible circular locking dependency detected ] [14818.477221] 3.1.0-dbg-07865-g1280ea8-dirty #668 [14818.477236] ------------------------------------------------------- [14818.477257] s2ram/1599 is trying to acquire lock: [14818.477276] (s_active#8){++++.+}, at: [<ffffffff81169147>] sysfs_addrm_finish+0x31/0x5a [14818.477323] [14818.477325] but task is already holding lock: [14818.477350] (&battery->lock){+.+.+.}, at: [<ffffffffa0047278>] sysfs_remove_battery+0x10/0x4b [battery] [14818.477395] [14818.477397] which lock already depends on the new lock. [14818.477399] [..] [14818.479121] stack backtrace: [14818.479148] Pid: 1599, comm: s2ram Not tainted 3.1.0-dbg-07865-g1280ea8-dirty #668 [14818.479175] Call Trace: [14818.479198] [<ffffffff814828c3>] print_circular_bug+0x293/0x2a4 [14818.479228] [<ffffffff81070cb5>] __lock_acquire+0xfe4/0x164b [14818.479260] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479288] [<ffffffff810718d2>] lock_acquire+0x138/0x1ac [14818.479316] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479345] [<ffffffff81168a79>] sysfs_deactivate+0x9b/0xec [14818.479373] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479405] [<ffffffff81169147>] sysfs_addrm_finish+0x31/0x5a [14818.479433] [<ffffffff81167bc5>] sysfs_hash_and_remove+0x54/0x77 [14818.479461] [<ffffffff811681b9>] sysfs_remove_file+0x12/0x14 [14818.479488] [<ffffffff81385bf8>] device_remove_file+0x12/0x14 [14818.479516] [<ffffffff81386504>] device_del+0x119/0x17c [14818.479542] [<ffffffff81386575>] device_unregister+0xe/0x1a [14818.479570] [<ffffffff813c6ef9>] power_supply_unregister+0x23/0x27 [14818.479601] [<ffffffffa004729c>] sysfs_remove_battery+0x34/0x4b [battery] [14818.479632] [<ffffffffa004778f>] battery_notify+0x2c/0x3a [battery] [14818.479662] [<ffffffff8148fe82>] notifier_call_chain+0x74/0xa1 [14818.479692] [<ffffffff810624b4>] __blocking_notifier_call_chain+0x6c/0x89 [14818.479722] [<ffffffff810624e0>] blocking_notifier_call_chain+0xf/0x11 [14818.479751] [<ffffffff8107e40e>] pm_notifier_call_chain+0x15/0x27 [14818.479770] [<ffffffff8107ee1a>] enter_state+0xa7/0xd5 [14818.479782] [<ffffffff8107e341>] state_store+0xaa/0xc0 [14818.479795] [<ffffffff8107e297>] ? pm_async_store+0x45/0x45 [14818.479807] [<ffffffff81248837>] kobj_attr_store+0x17/0x19 [14818.479820] [<ffffffff81167e27>] sysfs_write_file+0x103/0x13f [14818.479834] [<ffffffff81109037>] vfs_write+0xad/0x13d [14818.479847] [<ffffffff811092b2>] sys_write+0x45/0x6c [14818.479860] [<ffffffff81492f92>] system_call_fastpath+0x16/0x1b This patch introduces separate lock to struct acpi_battery to grab in sysfs_remove_battery() instead of battery->lock. So fix by Lan Tianyu is still there, we just grab independent lock. Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Tested-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-08-06 05:34:08 +07:00
struct mutex sysfs_lock;
struct power_supply bat;
struct acpi_device *device;
struct notifier_block pm_nb;
unsigned long update_time;
int revision;
int rate_now;
int capacity_now;
int voltage_now;
int design_capacity;
int full_charge_capacity;
int technology;
int design_voltage;
int design_capacity_warning;
int design_capacity_low;
int cycle_count;
int measurement_accuracy;
int max_sampling_time;
int min_sampling_time;
int max_averaging_interval;
int min_averaging_interval;
int capacity_granularity_1;
int capacity_granularity_2;
int alarm;
char model_number[32];
char serial_number[32];
char type[32];
char oem_info[32];
int state;
int power_unit;
unsigned long flags;
};
#define to_acpi_battery(x) container_of(x, struct acpi_battery, bat)
static inline int acpi_battery_present(struct acpi_battery *battery)
{
return battery->device->status.battery_present;
}
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;
if (!strncasecmp("LI-ION", battery->type, 6))
return POWER_SUPPLY_TECHNOLOGY_LION;
if (!strcasecmp("LiP", battery->type))
return POWER_SUPPLY_TECHNOLOGY_LIPO;
return POWER_SUPPLY_TECHNOLOGY_UNKNOWN;
}
static int acpi_battery_get_state(struct acpi_battery *battery);
static int acpi_battery_is_charged(struct acpi_battery *battery)
{
/* either charging or discharging */
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;
}
static int acpi_battery_get_property(struct power_supply *psy,
enum power_supply_property psp,
union power_supply_propval *val)
{
int ret = 0;
struct acpi_battery *battery = to_acpi_battery(psy);
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)
return -ENODEV;
switch (psp) {
case POWER_SUPPLY_PROP_STATUS:
if (battery->state & 0x01)
val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
else if (battery->state & 0x02)
val->intval = POWER_SUPPLY_STATUS_CHARGING;
else if (acpi_battery_is_charged(battery))
val->intval = POWER_SUPPLY_STATUS_FULL;
else
val->intval = POWER_SUPPLY_STATUS_UNKNOWN;
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;
case POWER_SUPPLY_PROP_CYCLE_COUNT:
val->intval = battery->cycle_count;
break;
case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN:
if (battery->design_voltage == ACPI_BATTERY_VALUE_UNKNOWN)
ret = -ENODEV;
else
val->intval = battery->design_voltage * 1000;
break;
case POWER_SUPPLY_PROP_VOLTAGE_NOW:
if (battery->voltage_now == ACPI_BATTERY_VALUE_UNKNOWN)
ret = -ENODEV;
else
val->intval = battery->voltage_now * 1000;
break;
case POWER_SUPPLY_PROP_CURRENT_NOW:
case POWER_SUPPLY_PROP_POWER_NOW:
if (battery->rate_now == ACPI_BATTERY_VALUE_UNKNOWN)
ret = -ENODEV;
else
val->intval = battery->rate_now * 1000;
break;
case POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN:
case POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN:
if (battery->design_capacity == ACPI_BATTERY_VALUE_UNKNOWN)
ret = -ENODEV;
else
val->intval = battery->design_capacity * 1000;
break;
case POWER_SUPPLY_PROP_CHARGE_FULL:
case POWER_SUPPLY_PROP_ENERGY_FULL:
if (battery->full_charge_capacity == ACPI_BATTERY_VALUE_UNKNOWN)
ret = -ENODEV;
else
val->intval = battery->full_charge_capacity * 1000;
break;
case POWER_SUPPLY_PROP_CHARGE_NOW:
case POWER_SUPPLY_PROP_ENERGY_NOW:
if (battery->capacity_now == ACPI_BATTERY_VALUE_UNKNOWN)
ret = -ENODEV;
else
val->intval = battery->capacity_now * 1000;
break;
case POWER_SUPPLY_PROP_CAPACITY:
if (battery->capacity_now && battery->full_charge_capacity)
val->intval = battery->capacity_now * 100/
battery->full_charge_capacity;
else
val->intval = 0;
break;
case POWER_SUPPLY_PROP_MODEL_NAME:
val->strval = battery->model_number;
break;
case POWER_SUPPLY_PROP_MANUFACTURER:
val->strval = battery->oem_info;
break;
case POWER_SUPPLY_PROP_SERIAL_NUMBER:
val->strval = battery->serial_number;
break;
default:
ret = -EINVAL;
}
return ret;
}
static enum power_supply_property charge_battery_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_FULL_DESIGN,
POWER_SUPPLY_PROP_CHARGE_FULL,
POWER_SUPPLY_PROP_CHARGE_NOW,
POWER_SUPPLY_PROP_CAPACITY,
POWER_SUPPLY_PROP_MODEL_NAME,
POWER_SUPPLY_PROP_MANUFACTURER,
POWER_SUPPLY_PROP_SERIAL_NUMBER,
};
static enum power_supply_property energy_battery_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_FULL_DESIGN,
POWER_SUPPLY_PROP_ENERGY_FULL,
POWER_SUPPLY_PROP_ENERGY_NOW,
POWER_SUPPLY_PROP_CAPACITY,
POWER_SUPPLY_PROP_MODEL_NAME,
POWER_SUPPLY_PROP_MANUFACTURER,
POWER_SUPPLY_PROP_SERIAL_NUMBER,
};
/* --------------------------------------------------------------------------
Battery Management
-------------------------------------------------------------------------- */
struct acpi_offsets {
size_t offset; /* offset inside struct acpi_sbs_battery */
u8 mode; /* int or string? */
};
static struct acpi_offsets state_offsets[] = {
{offsetof(struct acpi_battery, state), 0},
{offsetof(struct acpi_battery, rate_now), 0},
{offsetof(struct acpi_battery, capacity_now), 0},
{offsetof(struct acpi_battery, voltage_now), 0},
};
static struct acpi_offsets info_offsets[] = {
{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, 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},
};
static struct acpi_offsets extended_info_offsets[] = {
{offsetof(struct acpi_battery, revision), 0},
{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},
};
static int extract_package(struct acpi_battery *battery,
union acpi_object *package,
struct acpi_offsets *offsets, int num)
{
int i;
union acpi_object *element;
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) {
u8 *ptr = (u8 *)battery + offsets[i].offset;
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,
sizeof(u64));
ptr[sizeof(u64)] = 0;
} else
*ptr = 0; /* don't have value */
} else {
int *x = (int *)((u8 *)battery + offsets[i].offset);
*x = (element->type == ACPI_TYPE_INTEGER) ?
element->integer.value : -1;
}
}
return 0;
}
static int acpi_battery_get_status(struct acpi_battery *battery)
{
if (acpi_bus_get_status(battery->device)) {
ACPI_EXCEPTION((AE_INFO, AE_ERROR, "Evaluating _STA"));
return -ENODEV;
}
return 0;
}
static int acpi_battery_get_info(struct acpi_battery *battery)
{
int result = -EFAULT;
acpi_status status = 0;
char *name = test_bit(ACPI_BATTERY_XINFO_PRESENT, &battery->flags) ?
"_BIX" : "_BIF";
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
if (!acpi_battery_present(battery))
return 0;
mutex_lock(&battery->lock);
status = acpi_evaluate_object(battery->device->handle, name,
NULL, &buffer);
mutex_unlock(&battery->lock);
if (ACPI_FAILURE(status)) {
ACPI_EXCEPTION((AE_INFO, status, "Evaluating %s", name));
return -ENODEV;
}
if (battery_bix_broken_package)
result = extract_package(battery, buffer.pointer,
extended_info_offsets + 1,
ARRAY_SIZE(extended_info_offsets) - 1);
else if (test_bit(ACPI_BATTERY_XINFO_PRESENT, &battery->flags))
result = extract_package(battery, buffer.pointer,
extended_info_offsets,
ARRAY_SIZE(extended_info_offsets));
else
result = extract_package(battery, buffer.pointer,
info_offsets, ARRAY_SIZE(info_offsets));
kfree(buffer.pointer);
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 04:28:58 +07: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,
is correct. */
/* capacity_granularity_* equal 1 on the systems tested, so
it's impossible to tell if they would need an adjustment
or not if their values were higher. */
}
return result;
}
static int acpi_battery_get_state(struct acpi_battery *battery)
{
int result = 0;
acpi_status status = 0;
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
if (!acpi_battery_present(battery))
return 0;
if (battery->update_time &&
time_before(jiffies, battery->update_time +
msecs_to_jiffies(cache_time)))
return 0;
mutex_lock(&battery->lock);
status = acpi_evaluate_object(battery->device->handle, "_BST",
NULL, &buffer);
mutex_unlock(&battery->lock);
if (ACPI_FAILURE(status)) {
ACPI_EXCEPTION((AE_INFO, status, "Evaluating _BST"));
return -ENODEV;
}
result = extract_package(battery, buffer.pointer,
state_offsets, ARRAY_SIZE(state_offsets));
battery->update_time = jiffies;
kfree(buffer.pointer);
/* 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) {
battery->rate_now = abs((s16)battery->rate_now);
printk_once(KERN_WARNING FW_BUG "battery: (dis)charge rate"
" invalid.\n");
}
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 04:28:58 +07: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;
}
return result;
}
static int acpi_battery_set_alarm(struct acpi_battery *battery)
{
acpi_status status = 0;
if (!acpi_battery_present(battery) ||
!test_bit(ACPI_BATTERY_ALARM_PRESENT, &battery->flags))
return -ENODEV;
mutex_lock(&battery->lock);
status = acpi_execute_simple_method(battery->device->handle, "_BTP",
battery->alarm);
mutex_unlock(&battery->lock);
if (ACPI_FAILURE(status))
return -ENODEV;
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Alarm set to %d\n", battery->alarm));
return 0;
}
static int acpi_battery_init_alarm(struct acpi_battery *battery)
{
/* See if alarms are supported, and if so, set default */
if (!acpi_has_method(battery->device->handle, "_BTP")) {
clear_bit(ACPI_BATTERY_ALARM_PRESENT, &battery->flags);
return 0;
}
set_bit(ACPI_BATTERY_ALARM_PRESENT, &battery->flags);
if (!battery->alarm)
battery->alarm = battery->design_capacity_warning;
return acpi_battery_set_alarm(battery);
}
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));
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));
if (sscanf(buf, "%lu\n", &x) == 1)
battery->alarm = x/1000;
if (acpi_battery_present(battery))
acpi_battery_set_alarm(battery);
return count;
}
static struct device_attribute alarm_attr = {
.attr = {.name = "alarm", .mode = 0644},
.show = acpi_battery_alarm_show,
.store = acpi_battery_alarm_store,
};
static int sysfs_add_battery(struct acpi_battery *battery)
{
int result;
if (battery->power_unit == ACPI_BATTERY_POWER_UNIT_MA) {
battery->bat.properties = charge_battery_props;
battery->bat.num_properties =
ARRAY_SIZE(charge_battery_props);
} else {
battery->bat.properties = energy_battery_props;
battery->bat.num_properties =
ARRAY_SIZE(energy_battery_props);
}
battery->bat.name = acpi_device_bid(battery->device);
battery->bat.type = POWER_SUPPLY_TYPE_BATTERY;
battery->bat.get_property = acpi_battery_get_property;
result = power_supply_register(&battery->device->dev, &battery->bat);
if (result)
return result;
return device_create_file(battery->bat.dev, &alarm_attr);
}
static void sysfs_remove_battery(struct acpi_battery *battery)
{
Battery: sysfs_remove_battery(): possible circular locking Commit 9c921c22a7f33397a6774d7fa076db9b6a0fd669 Author: Lan Tianyu <tianyu.lan@intel.com> ACPI / Battery: Resolve the race condition in the sysfs_remove_battery() fixed BUG https://bugzilla.kernel.org/show_bug.cgi?id=35642 , but as a side effect made lockdep unhappy with sysfs_remove_battery(): [14818.477168] [14818.477170] ======================================================= [14818.477200] [ INFO: possible circular locking dependency detected ] [14818.477221] 3.1.0-dbg-07865-g1280ea8-dirty #668 [14818.477236] ------------------------------------------------------- [14818.477257] s2ram/1599 is trying to acquire lock: [14818.477276] (s_active#8){++++.+}, at: [<ffffffff81169147>] sysfs_addrm_finish+0x31/0x5a [14818.477323] [14818.477325] but task is already holding lock: [14818.477350] (&battery->lock){+.+.+.}, at: [<ffffffffa0047278>] sysfs_remove_battery+0x10/0x4b [battery] [14818.477395] [14818.477397] which lock already depends on the new lock. [14818.477399] [..] [14818.479121] stack backtrace: [14818.479148] Pid: 1599, comm: s2ram Not tainted 3.1.0-dbg-07865-g1280ea8-dirty #668 [14818.479175] Call Trace: [14818.479198] [<ffffffff814828c3>] print_circular_bug+0x293/0x2a4 [14818.479228] [<ffffffff81070cb5>] __lock_acquire+0xfe4/0x164b [14818.479260] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479288] [<ffffffff810718d2>] lock_acquire+0x138/0x1ac [14818.479316] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479345] [<ffffffff81168a79>] sysfs_deactivate+0x9b/0xec [14818.479373] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479405] [<ffffffff81169147>] sysfs_addrm_finish+0x31/0x5a [14818.479433] [<ffffffff81167bc5>] sysfs_hash_and_remove+0x54/0x77 [14818.479461] [<ffffffff811681b9>] sysfs_remove_file+0x12/0x14 [14818.479488] [<ffffffff81385bf8>] device_remove_file+0x12/0x14 [14818.479516] [<ffffffff81386504>] device_del+0x119/0x17c [14818.479542] [<ffffffff81386575>] device_unregister+0xe/0x1a [14818.479570] [<ffffffff813c6ef9>] power_supply_unregister+0x23/0x27 [14818.479601] [<ffffffffa004729c>] sysfs_remove_battery+0x34/0x4b [battery] [14818.479632] [<ffffffffa004778f>] battery_notify+0x2c/0x3a [battery] [14818.479662] [<ffffffff8148fe82>] notifier_call_chain+0x74/0xa1 [14818.479692] [<ffffffff810624b4>] __blocking_notifier_call_chain+0x6c/0x89 [14818.479722] [<ffffffff810624e0>] blocking_notifier_call_chain+0xf/0x11 [14818.479751] [<ffffffff8107e40e>] pm_notifier_call_chain+0x15/0x27 [14818.479770] [<ffffffff8107ee1a>] enter_state+0xa7/0xd5 [14818.479782] [<ffffffff8107e341>] state_store+0xaa/0xc0 [14818.479795] [<ffffffff8107e297>] ? pm_async_store+0x45/0x45 [14818.479807] [<ffffffff81248837>] kobj_attr_store+0x17/0x19 [14818.479820] [<ffffffff81167e27>] sysfs_write_file+0x103/0x13f [14818.479834] [<ffffffff81109037>] vfs_write+0xad/0x13d [14818.479847] [<ffffffff811092b2>] sys_write+0x45/0x6c [14818.479860] [<ffffffff81492f92>] system_call_fastpath+0x16/0x1b This patch introduces separate lock to struct acpi_battery to grab in sysfs_remove_battery() instead of battery->lock. So fix by Lan Tianyu is still there, we just grab independent lock. Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Tested-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-08-06 05:34:08 +07:00
mutex_lock(&battery->sysfs_lock);
if (!battery->bat.dev) {
Battery: sysfs_remove_battery(): possible circular locking Commit 9c921c22a7f33397a6774d7fa076db9b6a0fd669 Author: Lan Tianyu <tianyu.lan@intel.com> ACPI / Battery: Resolve the race condition in the sysfs_remove_battery() fixed BUG https://bugzilla.kernel.org/show_bug.cgi?id=35642 , but as a side effect made lockdep unhappy with sysfs_remove_battery(): [14818.477168] [14818.477170] ======================================================= [14818.477200] [ INFO: possible circular locking dependency detected ] [14818.477221] 3.1.0-dbg-07865-g1280ea8-dirty #668 [14818.477236] ------------------------------------------------------- [14818.477257] s2ram/1599 is trying to acquire lock: [14818.477276] (s_active#8){++++.+}, at: [<ffffffff81169147>] sysfs_addrm_finish+0x31/0x5a [14818.477323] [14818.477325] but task is already holding lock: [14818.477350] (&battery->lock){+.+.+.}, at: [<ffffffffa0047278>] sysfs_remove_battery+0x10/0x4b [battery] [14818.477395] [14818.477397] which lock already depends on the new lock. [14818.477399] [..] [14818.479121] stack backtrace: [14818.479148] Pid: 1599, comm: s2ram Not tainted 3.1.0-dbg-07865-g1280ea8-dirty #668 [14818.479175] Call Trace: [14818.479198] [<ffffffff814828c3>] print_circular_bug+0x293/0x2a4 [14818.479228] [<ffffffff81070cb5>] __lock_acquire+0xfe4/0x164b [14818.479260] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479288] [<ffffffff810718d2>] lock_acquire+0x138/0x1ac [14818.479316] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479345] [<ffffffff81168a79>] sysfs_deactivate+0x9b/0xec [14818.479373] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479405] [<ffffffff81169147>] sysfs_addrm_finish+0x31/0x5a [14818.479433] [<ffffffff81167bc5>] sysfs_hash_and_remove+0x54/0x77 [14818.479461] [<ffffffff811681b9>] sysfs_remove_file+0x12/0x14 [14818.479488] [<ffffffff81385bf8>] device_remove_file+0x12/0x14 [14818.479516] [<ffffffff81386504>] device_del+0x119/0x17c [14818.479542] [<ffffffff81386575>] device_unregister+0xe/0x1a [14818.479570] [<ffffffff813c6ef9>] power_supply_unregister+0x23/0x27 [14818.479601] [<ffffffffa004729c>] sysfs_remove_battery+0x34/0x4b [battery] [14818.479632] [<ffffffffa004778f>] battery_notify+0x2c/0x3a [battery] [14818.479662] [<ffffffff8148fe82>] notifier_call_chain+0x74/0xa1 [14818.479692] [<ffffffff810624b4>] __blocking_notifier_call_chain+0x6c/0x89 [14818.479722] [<ffffffff810624e0>] blocking_notifier_call_chain+0xf/0x11 [14818.479751] [<ffffffff8107e40e>] pm_notifier_call_chain+0x15/0x27 [14818.479770] [<ffffffff8107ee1a>] enter_state+0xa7/0xd5 [14818.479782] [<ffffffff8107e341>] state_store+0xaa/0xc0 [14818.479795] [<ffffffff8107e297>] ? pm_async_store+0x45/0x45 [14818.479807] [<ffffffff81248837>] kobj_attr_store+0x17/0x19 [14818.479820] [<ffffffff81167e27>] sysfs_write_file+0x103/0x13f [14818.479834] [<ffffffff81109037>] vfs_write+0xad/0x13d [14818.479847] [<ffffffff811092b2>] sys_write+0x45/0x6c [14818.479860] [<ffffffff81492f92>] system_call_fastpath+0x16/0x1b This patch introduces separate lock to struct acpi_battery to grab in sysfs_remove_battery() instead of battery->lock. So fix by Lan Tianyu is still there, we just grab independent lock. Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Tested-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-08-06 05:34:08 +07:00
mutex_unlock(&battery->sysfs_lock);
return;
}
device_remove_file(battery->bat.dev, &alarm_attr);
power_supply_unregister(&battery->bat);
battery->bat.dev = NULL;
Battery: sysfs_remove_battery(): possible circular locking Commit 9c921c22a7f33397a6774d7fa076db9b6a0fd669 Author: Lan Tianyu <tianyu.lan@intel.com> ACPI / Battery: Resolve the race condition in the sysfs_remove_battery() fixed BUG https://bugzilla.kernel.org/show_bug.cgi?id=35642 , but as a side effect made lockdep unhappy with sysfs_remove_battery(): [14818.477168] [14818.477170] ======================================================= [14818.477200] [ INFO: possible circular locking dependency detected ] [14818.477221] 3.1.0-dbg-07865-g1280ea8-dirty #668 [14818.477236] ------------------------------------------------------- [14818.477257] s2ram/1599 is trying to acquire lock: [14818.477276] (s_active#8){++++.+}, at: [<ffffffff81169147>] sysfs_addrm_finish+0x31/0x5a [14818.477323] [14818.477325] but task is already holding lock: [14818.477350] (&battery->lock){+.+.+.}, at: [<ffffffffa0047278>] sysfs_remove_battery+0x10/0x4b [battery] [14818.477395] [14818.477397] which lock already depends on the new lock. [14818.477399] [..] [14818.479121] stack backtrace: [14818.479148] Pid: 1599, comm: s2ram Not tainted 3.1.0-dbg-07865-g1280ea8-dirty #668 [14818.479175] Call Trace: [14818.479198] [<ffffffff814828c3>] print_circular_bug+0x293/0x2a4 [14818.479228] [<ffffffff81070cb5>] __lock_acquire+0xfe4/0x164b [14818.479260] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479288] [<ffffffff810718d2>] lock_acquire+0x138/0x1ac [14818.479316] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479345] [<ffffffff81168a79>] sysfs_deactivate+0x9b/0xec [14818.479373] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479405] [<ffffffff81169147>] sysfs_addrm_finish+0x31/0x5a [14818.479433] [<ffffffff81167bc5>] sysfs_hash_and_remove+0x54/0x77 [14818.479461] [<ffffffff811681b9>] sysfs_remove_file+0x12/0x14 [14818.479488] [<ffffffff81385bf8>] device_remove_file+0x12/0x14 [14818.479516] [<ffffffff81386504>] device_del+0x119/0x17c [14818.479542] [<ffffffff81386575>] device_unregister+0xe/0x1a [14818.479570] [<ffffffff813c6ef9>] power_supply_unregister+0x23/0x27 [14818.479601] [<ffffffffa004729c>] sysfs_remove_battery+0x34/0x4b [battery] [14818.479632] [<ffffffffa004778f>] battery_notify+0x2c/0x3a [battery] [14818.479662] [<ffffffff8148fe82>] notifier_call_chain+0x74/0xa1 [14818.479692] [<ffffffff810624b4>] __blocking_notifier_call_chain+0x6c/0x89 [14818.479722] [<ffffffff810624e0>] blocking_notifier_call_chain+0xf/0x11 [14818.479751] [<ffffffff8107e40e>] pm_notifier_call_chain+0x15/0x27 [14818.479770] [<ffffffff8107ee1a>] enter_state+0xa7/0xd5 [14818.479782] [<ffffffff8107e341>] state_store+0xaa/0xc0 [14818.479795] [<ffffffff8107e297>] ? pm_async_store+0x45/0x45 [14818.479807] [<ffffffff81248837>] kobj_attr_store+0x17/0x19 [14818.479820] [<ffffffff81167e27>] sysfs_write_file+0x103/0x13f [14818.479834] [<ffffffff81109037>] vfs_write+0xad/0x13d [14818.479847] [<ffffffff811092b2>] sys_write+0x45/0x6c [14818.479860] [<ffffffff81492f92>] system_call_fastpath+0x16/0x1b This patch introduces separate lock to struct acpi_battery to grab in sysfs_remove_battery() instead of battery->lock. So fix by Lan Tianyu is still there, we just grab independent lock. Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Tested-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-08-06 05:34:08 +07:00
mutex_unlock(&battery->sysfs_lock);
}
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 04:28:58 +07: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
the source code of dmidecode. */
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));
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);
}
}
/*
* 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.
*/
static void acpi_battery_quirks(struct acpi_battery *battery)
{
if (test_bit(ACPI_BATTERY_QUIRK_PERCENTAGE_CAPACITY, &battery->flags))
return;
if (battery->full_charge_capacity == 100 &&
battery->rate_now == ACPI_BATTERY_VALUE_UNKNOWN &&
battery->capacity_now >= 0 && battery->capacity_now <= 100) {
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 04:28:58 +07:00
if (test_bit(ACPI_BATTERY_QUIRK_THINKPAD_MAH, &battery->flags))
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 04:28:58 +07:00
if (battery->power_unit && dmi_name_in_vendors("LENOVO")) {
const char *s;
s = dmi_get_system_info(DMI_PRODUCT_VERSION);
if (s && !strnicmp(s, "ThinkPad", 8)) {
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;
}
}
}
}
static int acpi_battery_update(struct acpi_battery *battery)
{
int result, old_present = acpi_battery_present(battery);
result = acpi_battery_get_status(battery);
if (result)
return result;
if (!acpi_battery_present(battery)) {
sysfs_remove_battery(battery);
battery->update_time = 0;
return 0;
}
if (!battery->update_time ||
old_present != acpi_battery_present(battery)) {
result = acpi_battery_get_info(battery);
if (result)
return result;
acpi_battery_init_alarm(battery);
}
if (!battery->bat.dev) {
result = sysfs_add_battery(battery);
if (result)
return result;
}
result = acpi_battery_get_state(battery);
acpi_battery_quirks(battery);
return result;
}
static void acpi_battery_refresh(struct acpi_battery *battery)
{
int power_unit;
if (!battery->bat.dev)
return;
power_unit = battery->power_unit;
acpi_battery_get_info(battery);
if (power_unit == battery->power_unit)
return;
/* The battery has changed its reporting units. */
sysfs_remove_battery(battery);
sysfs_add_battery(battery);
}
/* --------------------------------------------------------------------------
Driver Interface
-------------------------------------------------------------------------- */
static void acpi_battery_notify(struct acpi_device *device, u32 event)
{
struct acpi_battery *battery = acpi_driver_data(device);
struct device *old;
if (!battery)
return;
old = battery->bat.dev;
if (event == ACPI_BATTERY_NOTIFY_INFO)
acpi_battery_refresh(battery);
acpi_battery_update(battery);
acpi_bus_generate_netlink_event(device->pnp.device_class,
dev_name(&device->dev), event,
acpi_battery_present(battery));
acpi_notifier_call_chain(device, event, acpi_battery_present(battery));
/* acpi_battery_update could remove power_supply object */
if (old && battery->bat.dev)
power_supply_changed(&battery->bat);
}
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);
switch (mode) {
case PM_POST_HIBERNATION:
case PM_POST_SUSPEND:
if (battery->bat.dev) {
sysfs_remove_battery(battery);
sysfs_add_battery(battery);
}
break;
}
return 0;
}
static struct dmi_system_id bat_dmi_table[] = {
{
.ident = "NEC LZ750/LS",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "NEC"),
DMI_MATCH(DMI_PRODUCT_NAME, "PC-LZ750LS"),
},
},
{},
};
static int acpi_battery_add(struct acpi_device *device)
{
int result = 0;
struct acpi_battery *battery = NULL;
if (!device)
return -EINVAL;
battery = kzalloc(sizeof(struct acpi_battery), GFP_KERNEL);
if (!battery)
return -ENOMEM;
battery->device = device;
strcpy(acpi_device_name(device), ACPI_BATTERY_DEVICE_NAME);
strcpy(acpi_device_class(device), ACPI_BATTERY_CLASS);
device->driver_data = battery;
mutex_init(&battery->lock);
Battery: sysfs_remove_battery(): possible circular locking Commit 9c921c22a7f33397a6774d7fa076db9b6a0fd669 Author: Lan Tianyu <tianyu.lan@intel.com> ACPI / Battery: Resolve the race condition in the sysfs_remove_battery() fixed BUG https://bugzilla.kernel.org/show_bug.cgi?id=35642 , but as a side effect made lockdep unhappy with sysfs_remove_battery(): [14818.477168] [14818.477170] ======================================================= [14818.477200] [ INFO: possible circular locking dependency detected ] [14818.477221] 3.1.0-dbg-07865-g1280ea8-dirty #668 [14818.477236] ------------------------------------------------------- [14818.477257] s2ram/1599 is trying to acquire lock: [14818.477276] (s_active#8){++++.+}, at: [<ffffffff81169147>] sysfs_addrm_finish+0x31/0x5a [14818.477323] [14818.477325] but task is already holding lock: [14818.477350] (&battery->lock){+.+.+.}, at: [<ffffffffa0047278>] sysfs_remove_battery+0x10/0x4b [battery] [14818.477395] [14818.477397] which lock already depends on the new lock. [14818.477399] [..] [14818.479121] stack backtrace: [14818.479148] Pid: 1599, comm: s2ram Not tainted 3.1.0-dbg-07865-g1280ea8-dirty #668 [14818.479175] Call Trace: [14818.479198] [<ffffffff814828c3>] print_circular_bug+0x293/0x2a4 [14818.479228] [<ffffffff81070cb5>] __lock_acquire+0xfe4/0x164b [14818.479260] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479288] [<ffffffff810718d2>] lock_acquire+0x138/0x1ac [14818.479316] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479345] [<ffffffff81168a79>] sysfs_deactivate+0x9b/0xec [14818.479373] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479405] [<ffffffff81169147>] sysfs_addrm_finish+0x31/0x5a [14818.479433] [<ffffffff81167bc5>] sysfs_hash_and_remove+0x54/0x77 [14818.479461] [<ffffffff811681b9>] sysfs_remove_file+0x12/0x14 [14818.479488] [<ffffffff81385bf8>] device_remove_file+0x12/0x14 [14818.479516] [<ffffffff81386504>] device_del+0x119/0x17c [14818.479542] [<ffffffff81386575>] device_unregister+0xe/0x1a [14818.479570] [<ffffffff813c6ef9>] power_supply_unregister+0x23/0x27 [14818.479601] [<ffffffffa004729c>] sysfs_remove_battery+0x34/0x4b [battery] [14818.479632] [<ffffffffa004778f>] battery_notify+0x2c/0x3a [battery] [14818.479662] [<ffffffff8148fe82>] notifier_call_chain+0x74/0xa1 [14818.479692] [<ffffffff810624b4>] __blocking_notifier_call_chain+0x6c/0x89 [14818.479722] [<ffffffff810624e0>] blocking_notifier_call_chain+0xf/0x11 [14818.479751] [<ffffffff8107e40e>] pm_notifier_call_chain+0x15/0x27 [14818.479770] [<ffffffff8107ee1a>] enter_state+0xa7/0xd5 [14818.479782] [<ffffffff8107e341>] state_store+0xaa/0xc0 [14818.479795] [<ffffffff8107e297>] ? pm_async_store+0x45/0x45 [14818.479807] [<ffffffff81248837>] kobj_attr_store+0x17/0x19 [14818.479820] [<ffffffff81167e27>] sysfs_write_file+0x103/0x13f [14818.479834] [<ffffffff81109037>] vfs_write+0xad/0x13d [14818.479847] [<ffffffff811092b2>] sys_write+0x45/0x6c [14818.479860] [<ffffffff81492f92>] system_call_fastpath+0x16/0x1b This patch introduces separate lock to struct acpi_battery to grab in sysfs_remove_battery() instead of battery->lock. So fix by Lan Tianyu is still there, we just grab independent lock. Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Tested-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-08-06 05:34:08 +07:00
mutex_init(&battery->sysfs_lock);
if (acpi_has_method(battery->device->handle, "_BIX"))
set_bit(ACPI_BATTERY_XINFO_PRESENT, &battery->flags);
result = acpi_battery_update(battery);
if (result)
goto fail;
printk(KERN_INFO PREFIX "%s Slot [%s] (battery %s)\n",
ACPI_BATTERY_DEVICE_NAME, acpi_device_bid(device),
device->status.battery_present ? "present" : "absent");
battery->pm_nb.notifier_call = battery_notify;
register_pm_notifier(&battery->pm_nb);
return result;
fail:
sysfs_remove_battery(battery);
mutex_destroy(&battery->lock);
Battery: sysfs_remove_battery(): possible circular locking Commit 9c921c22a7f33397a6774d7fa076db9b6a0fd669 Author: Lan Tianyu <tianyu.lan@intel.com> ACPI / Battery: Resolve the race condition in the sysfs_remove_battery() fixed BUG https://bugzilla.kernel.org/show_bug.cgi?id=35642 , but as a side effect made lockdep unhappy with sysfs_remove_battery(): [14818.477168] [14818.477170] ======================================================= [14818.477200] [ INFO: possible circular locking dependency detected ] [14818.477221] 3.1.0-dbg-07865-g1280ea8-dirty #668 [14818.477236] ------------------------------------------------------- [14818.477257] s2ram/1599 is trying to acquire lock: [14818.477276] (s_active#8){++++.+}, at: [<ffffffff81169147>] sysfs_addrm_finish+0x31/0x5a [14818.477323] [14818.477325] but task is already holding lock: [14818.477350] (&battery->lock){+.+.+.}, at: [<ffffffffa0047278>] sysfs_remove_battery+0x10/0x4b [battery] [14818.477395] [14818.477397] which lock already depends on the new lock. [14818.477399] [..] [14818.479121] stack backtrace: [14818.479148] Pid: 1599, comm: s2ram Not tainted 3.1.0-dbg-07865-g1280ea8-dirty #668 [14818.479175] Call Trace: [14818.479198] [<ffffffff814828c3>] print_circular_bug+0x293/0x2a4 [14818.479228] [<ffffffff81070cb5>] __lock_acquire+0xfe4/0x164b [14818.479260] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479288] [<ffffffff810718d2>] lock_acquire+0x138/0x1ac [14818.479316] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479345] [<ffffffff81168a79>] sysfs_deactivate+0x9b/0xec [14818.479373] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479405] [<ffffffff81169147>] sysfs_addrm_finish+0x31/0x5a [14818.479433] [<ffffffff81167bc5>] sysfs_hash_and_remove+0x54/0x77 [14818.479461] [<ffffffff811681b9>] sysfs_remove_file+0x12/0x14 [14818.479488] [<ffffffff81385bf8>] device_remove_file+0x12/0x14 [14818.479516] [<ffffffff81386504>] device_del+0x119/0x17c [14818.479542] [<ffffffff81386575>] device_unregister+0xe/0x1a [14818.479570] [<ffffffff813c6ef9>] power_supply_unregister+0x23/0x27 [14818.479601] [<ffffffffa004729c>] sysfs_remove_battery+0x34/0x4b [battery] [14818.479632] [<ffffffffa004778f>] battery_notify+0x2c/0x3a [battery] [14818.479662] [<ffffffff8148fe82>] notifier_call_chain+0x74/0xa1 [14818.479692] [<ffffffff810624b4>] __blocking_notifier_call_chain+0x6c/0x89 [14818.479722] [<ffffffff810624e0>] blocking_notifier_call_chain+0xf/0x11 [14818.479751] [<ffffffff8107e40e>] pm_notifier_call_chain+0x15/0x27 [14818.479770] [<ffffffff8107ee1a>] enter_state+0xa7/0xd5 [14818.479782] [<ffffffff8107e341>] state_store+0xaa/0xc0 [14818.479795] [<ffffffff8107e297>] ? pm_async_store+0x45/0x45 [14818.479807] [<ffffffff81248837>] kobj_attr_store+0x17/0x19 [14818.479820] [<ffffffff81167e27>] sysfs_write_file+0x103/0x13f [14818.479834] [<ffffffff81109037>] vfs_write+0xad/0x13d [14818.479847] [<ffffffff811092b2>] sys_write+0x45/0x6c [14818.479860] [<ffffffff81492f92>] system_call_fastpath+0x16/0x1b This patch introduces separate lock to struct acpi_battery to grab in sysfs_remove_battery() instead of battery->lock. So fix by Lan Tianyu is still there, we just grab independent lock. Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Tested-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-08-06 05:34:08 +07:00
mutex_destroy(&battery->sysfs_lock);
kfree(battery);
return result;
}
static int acpi_battery_remove(struct acpi_device *device)
{
struct acpi_battery *battery = NULL;
if (!device || !acpi_driver_data(device))
return -EINVAL;
battery = acpi_driver_data(device);
unregister_pm_notifier(&battery->pm_nb);
sysfs_remove_battery(battery);
mutex_destroy(&battery->lock);
Battery: sysfs_remove_battery(): possible circular locking Commit 9c921c22a7f33397a6774d7fa076db9b6a0fd669 Author: Lan Tianyu <tianyu.lan@intel.com> ACPI / Battery: Resolve the race condition in the sysfs_remove_battery() fixed BUG https://bugzilla.kernel.org/show_bug.cgi?id=35642 , but as a side effect made lockdep unhappy with sysfs_remove_battery(): [14818.477168] [14818.477170] ======================================================= [14818.477200] [ INFO: possible circular locking dependency detected ] [14818.477221] 3.1.0-dbg-07865-g1280ea8-dirty #668 [14818.477236] ------------------------------------------------------- [14818.477257] s2ram/1599 is trying to acquire lock: [14818.477276] (s_active#8){++++.+}, at: [<ffffffff81169147>] sysfs_addrm_finish+0x31/0x5a [14818.477323] [14818.477325] but task is already holding lock: [14818.477350] (&battery->lock){+.+.+.}, at: [<ffffffffa0047278>] sysfs_remove_battery+0x10/0x4b [battery] [14818.477395] [14818.477397] which lock already depends on the new lock. [14818.477399] [..] [14818.479121] stack backtrace: [14818.479148] Pid: 1599, comm: s2ram Not tainted 3.1.0-dbg-07865-g1280ea8-dirty #668 [14818.479175] Call Trace: [14818.479198] [<ffffffff814828c3>] print_circular_bug+0x293/0x2a4 [14818.479228] [<ffffffff81070cb5>] __lock_acquire+0xfe4/0x164b [14818.479260] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479288] [<ffffffff810718d2>] lock_acquire+0x138/0x1ac [14818.479316] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479345] [<ffffffff81168a79>] sysfs_deactivate+0x9b/0xec [14818.479373] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479405] [<ffffffff81169147>] sysfs_addrm_finish+0x31/0x5a [14818.479433] [<ffffffff81167bc5>] sysfs_hash_and_remove+0x54/0x77 [14818.479461] [<ffffffff811681b9>] sysfs_remove_file+0x12/0x14 [14818.479488] [<ffffffff81385bf8>] device_remove_file+0x12/0x14 [14818.479516] [<ffffffff81386504>] device_del+0x119/0x17c [14818.479542] [<ffffffff81386575>] device_unregister+0xe/0x1a [14818.479570] [<ffffffff813c6ef9>] power_supply_unregister+0x23/0x27 [14818.479601] [<ffffffffa004729c>] sysfs_remove_battery+0x34/0x4b [battery] [14818.479632] [<ffffffffa004778f>] battery_notify+0x2c/0x3a [battery] [14818.479662] [<ffffffff8148fe82>] notifier_call_chain+0x74/0xa1 [14818.479692] [<ffffffff810624b4>] __blocking_notifier_call_chain+0x6c/0x89 [14818.479722] [<ffffffff810624e0>] blocking_notifier_call_chain+0xf/0x11 [14818.479751] [<ffffffff8107e40e>] pm_notifier_call_chain+0x15/0x27 [14818.479770] [<ffffffff8107ee1a>] enter_state+0xa7/0xd5 [14818.479782] [<ffffffff8107e341>] state_store+0xaa/0xc0 [14818.479795] [<ffffffff8107e297>] ? pm_async_store+0x45/0x45 [14818.479807] [<ffffffff81248837>] kobj_attr_store+0x17/0x19 [14818.479820] [<ffffffff81167e27>] sysfs_write_file+0x103/0x13f [14818.479834] [<ffffffff81109037>] vfs_write+0xad/0x13d [14818.479847] [<ffffffff811092b2>] sys_write+0x45/0x6c [14818.479860] [<ffffffff81492f92>] system_call_fastpath+0x16/0x1b This patch introduces separate lock to struct acpi_battery to grab in sysfs_remove_battery() instead of battery->lock. So fix by Lan Tianyu is still there, we just grab independent lock. Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Tested-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-08-06 05:34:08 +07:00
mutex_destroy(&battery->sysfs_lock);
kfree(battery);
return 0;
}
#ifdef CONFIG_PM_SLEEP
/* this is needed to learn about changes made in suspended state */
static int acpi_battery_resume(struct device *dev)
{
struct acpi_battery *battery;
if (!dev)
return -EINVAL;
battery = acpi_driver_data(to_acpi_device(dev));
if (!battery)
return -EINVAL;
battery->update_time = 0;
acpi_battery_update(battery);
return 0;
}
#else
#define acpi_battery_resume NULL
#endif
static SIMPLE_DEV_PM_OPS(acpi_battery_pm, NULL, acpi_battery_resume);
static struct acpi_driver acpi_battery_driver = {
.name = "battery",
.class = ACPI_BATTERY_CLASS,
.ids = battery_device_ids,
.flags = ACPI_DRIVER_ALL_NOTIFY_EVENTS,
.ops = {
.add = acpi_battery_add,
.remove = acpi_battery_remove,
.notify = acpi_battery_notify,
},
.drv.pm = &acpi_battery_pm,
};
static void __init acpi_battery_init_async(void *unused, async_cookie_t cookie)
{
if (acpi_disabled)
return;
if (dmi_check_system(bat_dmi_table))
battery_bix_broken_package = 1;
acpi_bus_register_driver(&acpi_battery_driver);
}
static int __init acpi_battery_init(void)
{
async_schedule(acpi_battery_init_async, NULL);
return 0;
}
static void __exit acpi_battery_exit(void)
{
acpi_bus_unregister_driver(&acpi_battery_driver);
}
module_init(acpi_battery_init);
module_exit(acpi_battery_exit);