summaryrefslogtreecommitdiffstats
path: root/drivers/acpi/battery.c
AgeCommit message (Collapse)AuthorFilesLines
2012-01-03switch procfs to umode_t useAl Viro1-1/+1
both proc_dir_entry ->mode and populating functions Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2011-08-05Merge branch 'battery' into releaseLen Brown1-3/+7
2011-08-05Battery: sysfs_remove_battery(): possible circular lockingSergey Senozhatsky1-3/+7
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-02Merge branch 'release' of ↵Linus Torvalds1-32/+50
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 * '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 ...
2011-08-02Merge branches 'acpica', 'battery', 'boot-irqs', 'bz-24492', 'bz-9528', ↵Len Brown1-32/+50
'from-akpm', 'kexec-param' and 'misc' into release Conflicts: Documentation/kernel-parameters.txt Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-21treewide: fix potentially dangerous trailing ';' in #defined values/expressionsPhil Carmody1-1/+1
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: <ab0d55fe-25e5-482b-811e-c475aa6065c3@c29g2000yqd.googlegroups.com> 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 <ext-phil.2.carmody@nokia.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-07-16ACPI / Battery: propagate sysfs error in acpi_battery_add()Stefan Hajnoczi1-3/+8
Make sure the error return from sysfs_add_battery() is checked and propagated out from acpi_battery_add(). Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-16ACPI / Battery: avoid acpi_battery_add() use-after-freeStefan Hajnoczi1-6/+12
When acpi_battery_add_fs() fails the error handling code does not clean up completely. Moreover, it does not return resulting in a use-after-free. Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-16ACPI: constify ops structsVasiliy Kulikov1-1/+1
Structs battery_file, acpi_dock_ops, file_operations, thermal_cooling_device_ops, thermal_zone_device_ops, kernel_param_ops are not changed in runtime. It is safe to make them const. register_hotplug_dock_device() was altered to take const "ops" argument to respect acpi_dock_ops' const notion. Signed-off-by: Vasiliy Kulikov <segoon@openwall.com> Acked-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-14ACPI / Battery: Resolve the race condition in the sysfs_remove_battery()Lan Tianyu1-1/+6
Use battery->lock in sysfs_remove_battery() to make checking, removing, and clearing bat.dev atomic. This is necessary because sysfs_remove_battery() may be invoked concurrently from different paths. https://bugzilla.kernel.org/show_bug.cgi?id=35642 Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-14ACPI / Battery: Add the check before refresh sysfs in the battery_notify()Lan Tianyu1-2/+4
In the commit 25be5821, add the refresh sysfs when system resumes from suspending. But it didn't check that the battery exists. This will cause battery sysfs files added when the battery doesn't exist. This patch add the check before refreshing. https://bugzilla.kernel.org/show_bug.cgi?id=35642 Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-14ACPI / Battery: Add the hibernation process in the battery_notify()Lan Tianyu1-0/+1
The Commit 25be58215 has added a PM notifier to refresh the sys in order to deal with the unit change of the Battery Present Rate. But it just consided the suspend situation. The problem also will happen during the hibernation according the bug 28192. https://bugzilla.kernel.org/show_bug.cgi?id=28192 This patch adds the hibernation process and fix the bug. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-14ACPI / Battery: Rename acpi_battery_quirks2 with acpi_battery_quirksLan Tianyu1-2/+2
This patch is cosmetic only, and makes no functional change. Since the acpi_battery_quirks has been deleted, rename acpi_battery_quirks2 with acpi_battery_quirks to clean the code. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-14ACPI / Battery: Change 16-bit signed negative battery current into correct valueLan Tianyu1-16/+10
This patch is for some machines which report the battery current as a 16-bit signed negative when it is charging. This is caused by DSDT bug. The commit bc76f90b8a5cf4aceedf210d08d5e8292f820cec has resolved the problem for Acer laptops. But some other machines also have such problem. https://bugzilla.kernel.org/show_bug.cgi?id=33722 Since it is improper that the current is above 32A on laptops whether on AC or on battery, this patch is to check the current and take its absolute value as current and producing a message when it is negative in s16. Remove Acer quirk, as this workaround handles Acer too. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-14ACPI / Battery: Add the power unit macroLan Tianyu1-3/+8
This patch is cosmetic only, and makes no functional change. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-03-22ACPI battery: fribble sysfs files from a resume notifierKyle McMartin1-0/+22
Commit da8aeb92 re-poked the battery on resume, but Linus reports that it broke his eee and partially reverted it in b23fffd7. Unfortunately this also results in my x201s giving crack values until the sysfs files are poked again. In the revert message, it was suggested that we poke it from a PM notifier, so let's do that. With this in place, I haven't noticed the units going nutty on my gnome-power-manager across a dozen suspends or so... Signed-off-by: Kyle McMartin <kyle@redhat.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-20ACPI / Battery: remove battery refresh on resumeLinus Torvalds1-1/+0
This partially reverts commit da8aeb92d4853f37e281f11fddf61f9c7d84c3cd ("ACPI / Battery: Update information on info notification and resume"), which causes a hang on resume on at least some machines. This bug was bisected on an ASUS EeePC 901, which hangs at resume time if we do that "acpi_battery_refresh(battery)" in the battery resume function. Rafael suspects we'll still need to refresh the sysfs files upon resume, but that that can be done from a PM notifier (that will run after thawing user space). Bisected-and-tested-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matthew Garrett <mjg@redhat.com> Cc: Len Brown <len.brown@intel.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-01-12ACPI / Battery: Update information on info notification and resumeRafael J. Wysocki1-0/+14
A notification event 0x81 from an ACPI battery device requires us to re-read the battery information structure. Follow this requirement and remove and re-create the battery's attibutes in sysfs so that they reflect the reporting units used by the battery at the moment (those units may actually change sometimes at run time, which happens on some Thinkpads). The approach used in this patch was suggested by Matthew Garrett. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Reported-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12ACPI: delete CONFIG_ACPI_PROCFS_POWER and power procfs I/F in 2.6.39Zhang Rui1-0/+2
sysfs I/F for ACPI power devices, including AC and Battery, has been working in upstream kenrel since 2.6.24, Sep 2007. In 2.6.37, we made the sysfs I/F always built in and this option disabled by default. Now, we plan to remove this option and the ACPI power procfs interface in 2.6.39. First, update the feature-removal-schedule to announce this change. Second, add runtime warnings in ACPI AC/Battery/SBS driver, so that users will notice this change even if "make oldconfig" is used. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-10-25Merge branch 'battery' into releaseLen Brown1-8/+27
2010-10-23ACPI / Battery: Return -ENODEV for unknown values in get_property()Rafael J. Wysocki1-8/+27
The function acpi_battery_get_property() is called by the power supply framework's function power_supply_show_property() implementing the sysfs interface for power supply devices as the ACPI battery driver's ->get_property() callback. Thus it is supposed to return error code if the value of the given property is unknown. Unfortunately, however, it returns 0 in those cases and puts a wrong (negative) value into the intval field of the union power_supply_propval object provided by power_supply_show_property(). In consequence, wrong negative values are read by user space from the battery's sysfs files. Fix this by making acpi_battery_get_property() return -ENODEV for properties with unknown values (-ENODEV is returned, because power_supply_uevent() returns with error for any other error code returned by power_supply_show_property()). Reported-and-tested-by: Sitsofe Wheeler <sitsofe@yahoo.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2010-10-22ACPI battery: support percentage battery remaining capacityZhang Rui1-1/+37
According to the ACPI spec, some kinds of primary battery can report percentage battery remaining capacity directly to OS. In this case, it reports the LastFullChargedCapacity == 100, BatteryPresentRate = 0xFFFFFFFF, and BatteryRemaingCapacity a percentage value, which actually means RemainingBatteryPercentage. Now we found some battery follows this rule even if it's a rechargeable. https://bugzilla.kernel.org/show_bug.cgi?id=15979 Handle these batteries correctly in ACPI battery driver so that they won't break userspace. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Sitsofe Wheeler <sitsofe@yahoo.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-10-15ACPI ac/battery/sbs: sysfs I/F always built in, procfs I/F disabled by defaultZhang Rui1-21/+0
ACPI AC/Battery/SBS driver has different kernel option for procfs and sysfs I/F. This patch, 1. Change CONFIG_ACPI_PROCFS_POWER to 'n' by default so that we can remove it in the next release or two. 2. Remove CONFIG_ACPI_SYSFS_POWER and always build in the sysfs I/F of these drivers. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-08-31ACPI: Don't report current_now if battery reports in mWhMatthew Garrett1-1/+0
ACPI batteries can report in units of either current or energy. Right now we expose the current_now file even if the battery is reporting energy units, resulting in a file that should contain mA instead containing mW. Don't expose this value unless the battery is reporting current. Signed-off-by: Matthew Garrett <mjg@redhat.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-07-06ACPI battery: don't invoke power_supply_changed twice when battery is hot-addedZhang Rui1-1/+7
When battery is hot-added, we should not invoke power_supply_changed in acpi_battery_notify, because it has been invoked in acpi_battery_update, and battery->bat.changed_work is queued in keventd already. https://bugzilla.kernel.org/show_bug.cgi?id=16244 Signed-off-by: Zhang Rui <rui.zhang@intel.com> Acked-by: Alexey Starikovskiy <astarikovskiy@sude.de> Signed-off-by: Len Brown <len.brown@intel.com>
2010-04-06Merge branches 'battery', 'bugzilla-14667', 'bugzilla-15096', ↵Len Brown1-0/+1
'bugzilla-15480', 'bugzilla-15521', 'bugzilla-15605', 'gpe-reference-counters', 'misc', 'pxm-fix' and 'video-random-key' into release
2010-04-04ACPI: battery drivers should call power_supply_changed()Alan Jenkins1-1/+1
Calling kobject_uevent() directly is a layering violation. In particular, it means we'll miss updating the generic LED trigger. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2010-04-04ACPI: battery: Fix CONFIG_ACPI_SYSFS_POWER=nAlan Jenkins1-2/+2
Disabling CONFIG_ACPI_SYSFS_POWER changes the behaviour of acpi_battery_update(). It will call acpi_battery_get_info() even if the battery is not present. I haven't noticed this causing any problem, but it does look like a bad idea. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2010-03-30include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo1-0/+1
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-14Merge branches 'battery-2.6.34', 'bugzilla-10805', 'bugzilla-14668', ↵Len Brown1-2/+2
'bugzilla-531916-power-state', 'ht-warn-2.6.34', 'pnp', 'processor-rename', 'sony-2.6.34', 'suse-bugzilla-531547', 'tz-check', 'video' and 'misc-2.6.34' into release
2010-01-28ACPI: replace acpi_integer by u64Lin Ming1-2/+2
acpi_integer is now obsolete and removed from the ACPICA code base, replaced by u64. Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-15ACPI: Battery: Add support for _BIX extended info methodAlexey Starikovskiy1-10/+58
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-15ACPI: Battery: Add bit flagsAlexey Starikovskiy1-12/+14
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-16battery: fix typo in commentJustin P. Mattock1-1/+1
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-09-19Merge branch 'battery' into releaseLen Brown1-0/+20
2009-08-29ACPI battery: work around negative s16 battery current on AcerHector Martin1-0/+20
Acer Aspire 8930G laptops (and possibly others) report the battery current as a 16-bit signed negative when it is charging. It also reports it as 0x10000 when the current is 0. This patch adds a quirk for this which takes the absolute value of the reported current cast to an s16. This is a DSDT bug present in the latest BIOS revision (the EC register is 16 bits signed and the DSDT attempts to take the 16-bit two's complement of this, which works for discharge but not charge. It also breaks zero values because a 32-bit register is used and the high bits aren't thrown away). I've enabled this for all Acer systems which report in mA units. This should be safe since it won't break compliant systems unless they report a current above 32A, which is insane. The patch also detects the valid 32-bit value -1, which indicates unknown status, and does not attempt the fix in that case (note that this does not conflict with 16-bit -1, which is 65535 as read normally and gets translated to 1mA). Signed-off-by: Hector Martin <hector@marcansoft.com> Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
2009-08-28ACPI: Move definition of PREFIX from acpi_bus.h to internal..hLen Brown1-0/+2
Linux/ACPI core files using internal.h all PREFIX "ACPI: ", however, not all ACPI drivers use/want it -- and they should not have to #undef PREFIX to define their own. Add GPL commment to internal.h while we are there. This does not change any actual console output, asside from a whitespace fix. Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-18ACPI: battery: fix CONFIG_ACPI_PROCFS_POWER=n build warningLen Brown1-7/+5
drivers/acpi/battery.c:841: warning: label ‘end’ defined but not used Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-18ACPI: battery: use .notify method instead of installing handler directlyBjorn Helgaas1-17/+5
This patch adds a .notify() method. The presence of .notify() causes Linux/ACPI to manage event handlers and notify handlers on our behalf, so we don't have to install and remove them ourselves. This driver apparently relies on seeing ALL notify events, not just device-specific ones (because it used ACPI_ALL_NOTIFY). We use the ACPI_DRIVER_ALL_NOTIFY_EVENTS driver flag to request all events. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> CC: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-04-11Revert "ACPI battery: fix async boot oops"Linus Torvalds1-1/+1
This reverts commit 5d38258ec026921a7b266f4047ebeaa75db358e5, since the underlying problem got fixed properly in the previous commit ("async: Fix module loading async-work regression"). Cc: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com> Cc: Vegard Nossum <vegard.nossum@gmail.com> Cc: Len Brown <len.brown@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-04-07ACPI battery: fix async boot oopsVegard Nossum1-1/+1
> BUG: unable to handle kernel NULL pointer dereference at (null) What happens is that the battery module's init sections are being freed before the async callback (which was marked __init) has run. This theory is supported by the fact that the bad RIP value is a vmalloc address. The immediate fix is to make this a non-init call. (A better long-term fix is of course to wait with init-section unloading until a module's async initcalls have been run, which would allow us to discard this function which is still only run once, after all. Perhaps a new async_initcall() function for the async/module API, if this is needed for other modules in the future?) Reported-by: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com> Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com> Tested-by: Alessandro Suardi <alessandro.suardi@gmail.com> Tested-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2009-04-05Merge branch 'linus' into releaseLen Brown1-1/+0
Conflicts: arch/x86/kernel/cpu/cpufreq/longhaul.c Signed-off-by: Len Brown <len.brown@intel.com>
2009-04-05Merge branch 'constify' into releaseLen Brown1-1/+1
2009-04-05Merge branch 'async-battery' into releaseLen Brown1-4/+11
Conflicts: drivers/acpi/Makefile Signed-off-by: Len Brown <len.brown@intel.com>
2009-04-04ACPI: battery: asynchronous initArjan van de Ven1-4/+11
The battery driver tends to take quite some time to initialize (100ms-300ms is quite typical). This patch initializes the batter driver asynchronously, so that other things in the kernel can initialize in parallel to this 300 msec. As part of this, the battery driver had to move to the back of the ACPI init order (hence the Makefile change). Without this move, the next ACPI driver would just block on the ACPI/devicee layer semaphores until the battery driver was done anyway, not gaining any boot time. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2009-04-03ACPI: constify VFTs (1/2)Jan Engelhardt1-1/+1
Signed-off-by: Jan Engelhardt <jengelh@medozas.de> Signed-off-by: Len Brown <len.brown@intel.com>
2009-03-31proc 2/2: remove struct proc_dir_entry::ownerAlexey Dobriyan1-1/+0
Setting ->owner as done currently (pde->owner = THIS_MODULE) is racy as correctly noted at bug #12454. Someone can lookup entry with NULL ->owner, thus not pinning enything, and release it later resulting in module refcount underflow. We can keep ->owner and supply it at registration time like ->proc_fops and ->data. But this leaves ->owner as easy-manipulative field (just one C assignment) and somebody will forget to unpin previous/pin current module when switching ->owner. ->proc_fops is declared as "const" which should give some thoughts. ->read_proc/->write_proc were just fixed to not require ->owner for protection. rmmod'ed directories will be empty and return "." and ".." -- no harm. And directories with tricky enough readdir and lookup shouldn't be modular. We definitely don't want such modular code. Removing ->owner will also make PDE smaller. So, let's nuke it. Kudos to Jeff Layton for reminding about this, let's say, oversight. http://bugzilla.kernel.org/show_bug.cgi?id=12454 Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
2009-03-27ACPI: battery: add power_{now,avg} properties to power_classAlexey Starikovskiy1-5/+7
ACPI has smart batteries, which work in units of energy and measure rate of (dis)charge as power, thus it is not appropriate to export it as a current_now. Current_now will still be exported to allow for userland applications to match. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-21battery: don't assume we are fully charged when not charging or dischargingRichard Hughes1-1/+24
On hardware like the T61 it can take a couple of seconds for the battery to start charging after the power is connected, and we incorrectly tell userspace that we are fully charged, and then go back to charging. Only mark a battery as fully charged when the preset charge matches either the last full charge, or the design charge. http://bugzilla.kernel.org/show_bug.cgi?id=12632 Signed-off-by: Richard Hughes <hughsient@gmail.com> Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Len Brown <len.brown@intel.com>
2008-12-22Newly inserted battery might differ from one just removed, soAlexey Starikovskiy1-2/+3
update of battery info fields is required. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Acked-by: Andy Neitzke <neitzke@ias.edu> Signed-off-by: Alexey Starikovskiy <astarikovskiy <at> suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-29 11:44:41 +0000