Commit Graph

115 Commits

Author SHA1 Message Date
Al Viro d161a13f97 switch procfs to umode_t use
both proc_dir_entry ->mode and populating functions

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2012-01-03 22:54:56 -05:00
Len Brown 5389102e23 Merge branch 'battery' into release 2011-08-05 22:16:42 -04:00
Sergey Senozhatsky 69d94ec6d8 Battery: sysfs_remove_battery(): possible circular locking
Commit 9c921c22a7
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-05 22:15:18 -04:00
Linus Torvalds c299eba3c5 Merge branch 'release' of 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-02 21:17:02 -10:00
Len Brown 4a8f5058bd Merge branches 'acpica', 'battery', 'boot-irqs', 'bz-24492', 'bz-9528', 'from-akpm', 'kexec-param' and 'misc' into release
Conflicts:
	Documentation/kernel-parameters.txt

Signed-off-by: Len Brown <len.brown@intel.com>
2011-08-02 17:22:09 -04:00
Phil Carmody 497888cf69 treewide: fix potentially dangerous trailing ';' in #defined values/expressions
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-21 14:10:00 +02:00
Stefan Hajnoczi eb03cb02b7 ACPI / Battery: propagate sysfs error in acpi_battery_add()
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-16 18:57:24 -04:00
Stefan Hajnoczi e80bba4b51 ACPI / Battery: avoid acpi_battery_add() use-after-free
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-16 18:54:59 -04:00
Vasiliy Kulikov 9c8b04be44 ACPI: constify ops structs
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-16 18:36:17 -04:00
Lan Tianyu 9c921c22a7 ACPI / Battery: Resolve the race condition in the sysfs_remove_battery()
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-14 00:06:19 -04:00
Lan Tianyu 6e17fb6aa1 ACPI / Battery: Add the check before refresh sysfs in the battery_notify()
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-14 00:05:45 -04:00
Lan Tianyu d5a5911b32 ACPI / Battery: Add the hibernation process in the battery_notify()
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-14 00:05:27 -04:00
Lan Tianyu 7b78622d0f ACPI / Battery: Rename acpi_battery_quirks2 with acpi_battery_quirks
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-14 00:04:57 -04:00
Lan Tianyu 55003b2105 ACPI / Battery: Change 16-bit signed negative battery current into correct value
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 bc76f90b8a
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-14 00:04:41 -04:00
Lan Tianyu ae6f618704 ACPI / Battery: Add the power unit macro
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-07-14 00:04:12 -04:00
Kyle McMartin 25be582152 ACPI battery: fribble sysfs files from a resume notifier
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-03-22 23:30:31 -04:00
Linus Torvalds b23fffd778 ACPI / Battery: remove battery refresh on resume
This partially reverts commit da8aeb92d4
("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-20 13:14:10 -08:00
Rafael J. Wysocki da8aeb92d4 ACPI / Battery: Update information on info notification and resume
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-12 05:06:10 -05:00
Zhang Rui 6d855fcdd2 ACPI: delete CONFIG_ACPI_PROCFS_POWER and power procfs I/F in 2.6.39
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>
2011-01-12 00:36:17 -05:00
Len Brown 880308089d Merge branch 'battery' into release 2010-10-25 02:12:57 -04:00
Rafael J. Wysocki a1b4bd694a ACPI / Battery: Return -ENODEV for unknown values in get_property()
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-23 14:05:03 -04:00
Zhang Rui 557d58687d ACPI battery: support percentage battery remaining capacity
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-22 01:28:07 -04:00
Zhang Rui 1b3d4c3b9a ACPI ac/battery/sbs: sysfs I/F always built in, procfs I/F disabled by default
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-10-15 22:02:38 -04:00
Matthew Garrett b137b9942a ACPI: Don't report current_now if battery reports in mWh
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-08-31 00:00:47 -04:00
Zhang Rui 153e500f51 ACPI battery: don't invoke power_supply_changed twice when battery is hot-added
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-07-06 22:22:46 -04:00
Len Brown c25f7cf203 Merge branches 'battery', 'bugzilla-14667', 'bugzilla-15096', 'bugzilla-15480', 'bugzilla-15521', 'bugzilla-15605', 'gpe-reference-counters', 'misc', 'pxm-fix' and 'video-random-key' into release 2010-04-06 17:06:22 -04:00
Alan Jenkins f79e1cec8c ACPI: battery drivers should call power_supply_changed()
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-04 19:53:23 -04:00
Alan Jenkins e363a755e8 ACPI: battery: Fix CONFIG_ACPI_SYSFS_POWER=n
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-04-04 19:53:04 -04:00
Tejun Heo 5a0e3ad6af 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-30 22:02:32 +09:00
Len Brown ec28dcc6b4 Merge branches 'battery-2.6.34', 'bugzilla-10805', 'bugzilla-14668', '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-03-14 21:30:17 -04:00
Lin Ming 439913fffd ACPI: replace acpi_integer by u64
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-28 01:47:33 -05:00
Alexey Starikovskiy c67fcd670b ACPI: Battery: Add support for _BIX extended info method
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-15 17:03:33 -05:00
Alexey Starikovskiy 7b3bcc4a1a ACPI: Battery: Add bit flags
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-01-15 16:55:51 -05:00
Justin P. Mattock 2345baf4a8 battery: fix typo in comment
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-16 00:07:21 -05:00
Len Brown 7a92d80322 Merge branch 'battery' into release 2009-09-19 01:56:17 -04:00
Hector Martin bc76f90b8a ACPI battery: work around negative s16 battery current on Acer
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-29 21:39:54 -04:00
Len Brown a192a9580b ACPI: Move definition of PREFIX from acpi_bus.h to internal..h
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-08-28 19:57:27 -04:00
Len Brown 586caae36c ACPI: battery: fix CONFIG_ACPI_PROCFS_POWER=n build warning
drivers/acpi/battery.c:841: warning: label ‘end’ defined but not used

Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-18 00:38:27 -04:00
Bjorn Helgaas d940669109 ACPI: battery: use .notify method instead of installing handler directly
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-06-18 00:13:14 -04:00
Linus Torvalds b0cbc861a3 Revert "ACPI battery: fix async boot oops"
This reverts commit 5d38258ec0, 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-11 12:45:20 -07:00
Vegard Nossum 5d38258ec0 ACPI battery: fix async boot oops
> 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-07 16:24:54 -04:00
Len Brown 478c6a43fc Merge branch 'linus' into release
Conflicts:
	arch/x86/kernel/cpu/cpufreq/longhaul.c

Signed-off-by: Len Brown <len.brown@intel.com>
2009-04-05 02:14:15 -04:00
Len Brown e2fae0abf6 Merge branch 'constify' into release 2009-04-05 01:51:16 -04:00
Len Brown 59b17bf6ea Merge branch 'async-battery' into release
Conflicts:
	drivers/acpi/Makefile

Signed-off-by: Len Brown <len.brown@intel.com>
2009-04-05 01:48:46 -04:00
Arjan van de Ven 0f66af5301 ACPI: battery: asynchronous init
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-04 12:51:17 -04:00
Jan Engelhardt 070d8eb1f6 ACPI: constify VFTs (1/2)
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-04-03 23:14:40 -04:00
Alexey Dobriyan 99b7623380 proc 2/2: remove struct proc_dir_entry::owner
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-31 01:14:44 +04:00
Alexey Starikovskiy 7faa144a51 ACPI: battery: add power_{now,avg} properties to power_class
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-03-27 22:23:52 -04:00
Richard Hughes 56f382a087 battery: don't assume we are fully charged when not charging or discharging
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>
2009-02-21 12:36:19 -05:00
Alexey Starikovskiy 50b178512b Newly inserted battery might differ from one just removed, so
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>
2008-12-22 19:32:55 -05:00