kernel.git/drivers/acpi/battery.c, branch linux-3.2.y

ACPI / battery: Retry to get battery information if failed during probing

2014-08-06T17:07:36Z

commit 75646e758a0ecbed5024454507d5be5b9ea9dcbf upstream. Some machines (eg. Lenovo Z480) ECs are not stable during boot up and causes battery driver fails to be loaded due to failure of getting battery information from EC sometimes. After several retries, the operation will work. This patch is to retry to get battery information 5 times if the first try fails. Link: https://bugzilla.kernel.org/show_bug.cgi?id=75581 Reported-and-tested-by: naszar Signed-off-by: Lan Tianyu Signed-off-by: Rafael J. Wysocki [bwh: Backported to 3.2: acpi_battery_update() doesn't take a second parameter] Signed-off-by: Ben Hutchings

ACPI / battery: Fix parsing _BIX return value

2013-09-10T00:57:18Z

commit 016d5baad04269e8559332df05f89bd95b52d6ad upstream. The _BIX method returns extended battery info as a package. According the ACPI spec (ACPI 5, Section 10.2.2.2), the first member of that package should be "Revision". However, the current ACPI battery driver treats the first member as "Power Unit" which should be the second member. This causes the result of _BIX return data parsing to be incorrect. Fix this by adding a new member called 'revision' to struct acpi_battery and adding the offsetof() information on it to extended_info_offsets[] as the first row. [rjw: Changelog] Reported-and-tested-by: Jan Hoffmann References: http://bugzilla.kernel.org/show_bug.cgi?id=60519 Signed-off-by: Lan Tianyu Signed-off-by: Rafael J. Wysocki Signed-off-by: Ben Hutchings

ACPI / battery: Correct battery capacity values on Thinkpads

2013-01-03T03:33:10Z

commit 4000e626156935dfb626321ce09cae2c833eabbb upstream. 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 Signed-off-by: Rafael J. Wysocki Signed-off-by: Ben Hutchings

ACPI battery: only refresh the sysfs files when pertinent information changes

2012-06-10T13:42:07Z

commit c5971456964290da7e98222892797b71ef793e62 upstream. We only need to regenerate the sysfs files when the capacity units change, avoid the update otherwise. The origin of this issue is dates way back to 2.6.38: da8aeb92d4853f37e281f11fddf61f9c7d84c3cd (ACPI / Battery: Update information on info notification and resume) Signed-off-by: Andy Whitcroft Tested-by: Ralf Jung Signed-off-by: Len Brown Signed-off-by: Ben Hutchings

Merge branch 'battery' into release

2011-08-06T02:16:42Z

Battery: sysfs_remove_battery(): possible circular locking

2011-08-06T02:15:18Z

Commit 9c921c22a7f33397a6774d7fa076db9b6a0fd669 Author: Lan Tianyu 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: [] sysfs_addrm_finish+0x31/0x5a [14818.477323] [14818.477325] but task is already holding lock: [14818.477350] (&battery->lock){+.+.+.}, at: [] 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] [] print_circular_bug+0x293/0x2a4 [14818.479228] [] __lock_acquire+0xfe4/0x164b [14818.479260] [] ? sysfs_addrm_finish+0x31/0x5a [14818.479288] [] lock_acquire+0x138/0x1ac [14818.479316] [] ? sysfs_addrm_finish+0x31/0x5a [14818.479345] [] sysfs_deactivate+0x9b/0xec [14818.479373] [] ? sysfs_addrm_finish+0x31/0x5a [14818.479405] [] sysfs_addrm_finish+0x31/0x5a [14818.479433] [] sysfs_hash_and_remove+0x54/0x77 [14818.479461] [] sysfs_remove_file+0x12/0x14 [14818.479488] [] device_remove_file+0x12/0x14 [14818.479516] [] device_del+0x119/0x17c [14818.479542] [] device_unregister+0xe/0x1a [14818.479570] [] power_supply_unregister+0x23/0x27 [14818.479601] [] sysfs_remove_battery+0x34/0x4b [battery] [14818.479632] [] battery_notify+0x2c/0x3a [battery] [14818.479662] [] notifier_call_chain+0x74/0xa1 [14818.479692] [] __blocking_notifier_call_chain+0x6c/0x89 [14818.479722] [] blocking_notifier_call_chain+0xf/0x11 [14818.479751] [] pm_notifier_call_chain+0x15/0x27 [14818.479770] [] enter_state+0xa7/0xd5 [14818.479782] [] state_store+0xaa/0xc0 [14818.479795] [] ? pm_async_store+0x45/0x45 [14818.479807] [] kobj_attr_store+0x17/0x19 [14818.479820] [] sysfs_write_file+0x103/0x13f [14818.479834] [] vfs_write+0xad/0x13d [14818.479847] [] sys_write+0x45/0x6c [14818.479860] [] 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 Tested-by: Lan Tianyu Signed-off-by: Len Brown

Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6

2011-08-03T07:17:02Z

* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (28 commits) ACPI: delete stale reference in kernel-parameters.txt ACPI: add missing _OSI strings ACPI: remove NID_INVAL thermal: make THERMAL_HWMON implementation fully internal thermal: split hwmon lookup to a separate function thermal: hide CONFIG_THERMAL_HWMON ACPI print OSI(Linux) warning only once ACPI: DMI workaround for Asus A8N-SLI Premium and Asus A8N-SLI DELUX ACPI / Battery: propagate sysfs error in acpi_battery_add() ACPI / Battery: avoid acpi_battery_add() use-after-free ACPI: introduce "acpi_rsdp=" parameter for kdump ACPI: constify ops structs ACPI: fix CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS ACPI: fix 80 char overflow ACPI / Battery: Resolve the race condition in the sysfs_remove_battery() ACPI / Battery: Add the check before refresh sysfs in the battery_notify() ACPI / Battery: Add the hibernation process in the battery_notify() ACPI / Battery: Rename acpi_battery_quirks2 with acpi_battery_quirks ACPI / Battery: Change 16-bit signed negative battery current into correct value ACPI / Battery: Add the power unit macro ...

Merge branches 'acpica', 'battery', 'boot-irqs', 'bz-24492', 'bz-9528', 'from-akpm', 'kexec-param' and 'misc' into release

2011-08-02T21:22:09Z

Conflicts: Documentation/kernel-parameters.txt Signed-off-by: Len Brown

treewide: fix potentially dangerous trailing ';' in #defined values/expressions

2011-07-21T12:10:00Z

All these are instances of #define NAME value; or #define NAME(params_opt) value; These of course fail to build when used in contexts like if(foo $OP NAME) while(bar $OP NAME) and may silently generate the wrong code in contexts such as foo = NAME + 1; /* foo = value; + 1; */ bar = NAME - 1; /* bar = value; - 1; */ baz = NAME & quux; /* baz = value; & quux; */ Reported on comp.lang.c, Message-ID: Initial analysis of the dangers provided by Keith Thompson in that thread. There are many more instances of more complicated macros having unnecessary trailing semicolons, but this pile seems to be all of the cases of simple values suffering from the problem. (Thus things that are likely to be found in one of the contexts above, more complicated ones aren't.) Signed-off-by: Phil Carmody Signed-off-by: Jiri Kosina

ACPI / Battery: propagate sysfs error in acpi_battery_add()

2011-07-16T22:57:24Z

Make sure the error return from sysfs_add_battery() is checked and propagated out from acpi_battery_add(). Signed-off-by: Stefan Hajnoczi Signed-off-by: Len Brown