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: NSitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NZhang Rui <rui.zhang@intel.com>
Tested-by: NSitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NMatthew Garrett <mjg@redhat.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

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=16244Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Acked-by: NAlexey Starikovskiy <astarikovskiy@sude.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

Calling kobject_uevent() directly is a layering violation.  In
particular, it means we'll miss updating the generic LED trigger.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Acked-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Acked-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

acpi_integer is now obsolete and removed from the ACPICA code base,
replaced by u64.
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NJustin P. Mattock <justinmattock@gmail.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NHector Martin <hector@marcansoft.com>
Acked-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NLen Brown <len.brown@intel.com>

drivers/acpi/battery.c:841: warning: label ‘end’ defined but not used
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NBjorn Helgaas <bjorn.helgaas@hp.com>
CC: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This reverts commit 5d38258e, 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: NLinus Torvalds <torvalds@linux-foundation.org>

> 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: NArkadiusz Miskiewicz <a.miskiewicz@gmail.com>
Signed-off-by: NVegard Nossum <vegard.nossum@gmail.com>
Tested-by: NAlessandro Suardi <alessandro.suardi@gmail.com>
Tested-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NJan Engelhardt <jengelh@medozas.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

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=12454Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>

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: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

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=12632Signed-off-by: NRichard Hughes <hughsient@gmail.com>
Acked-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

update of battery info fields is required.
Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Acked-by: NAndy Neitzke <neitzke@ias.edu>

Signed-off-by: Alexey Starikovskiy <astarikovskiy <at> suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

This reverts commit 558073dd, along with
the failed try to fix the regression it caused ("ACPI: Fix ACPI battery
regression introduced by commit 558073"), which just made things worse.

Commit aaad0776 (that failed "Fix ACPI
battery regression") got the voltage conversion confused, and fixed the
problem with Rafael's battery monitor apparently just by mistake.

So revert them both, getting us back to the 2.6.27 state in this, and
let's revisit it when people understand what's going on.
Noted-by: NPaul Martin <pm@debian.org>
Requested-by: NRafael J. Wysocki <rjw@sisk.pl>
Cc: Len Brown <len.brown@intel.com>
Cc: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 558073dd ("ACPI: battery: Convert
discharge energy rate to current properly") caused the battery subsystem
to report wrong values of the remaining time on battery power and the
time until fully charged on Toshiba Portege R500 (and presumably on
other boxes too).

Fix the issue by correcting the conversion from mW to mA.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

ACPI battery interface reports its state either in mW or in mA, and
discharge rate in your case is reported in mW. power_supply interface
does not have such a parameter, so current_now parameter is used
for all cases. But in case of mW, reported discharge should
be converted into mA.
Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Tested-by: NFerenc Wagner <wferi@niif.hu>
Signed-off-by: NLen Brown <len.brown@intel.com>

Move all the component definitions for drivers to a single shared place,
include/acpi/acpi_drivers.h.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This patch is part of a larger patch series which will remove
the "char bus_id[20]" name string from struct device. The device
name is managed in the kobject anyway, and without any size
limitation, and just needlessly copied into "struct device".

To set and read the device name dev_name(dev) and dev_set_name(dev)
must be used. If your code uses static kobjects, which it shouldn't
do, "const char *init_name" can be used to statically provide the
name the registered device should have. At registration time, the
init_name field is cleared, to enforce the use of dev_name(dev) to
access the device name at a later time.

We need to get rid of all occurrences of bus_id in the entire tree
to be able to enable the new interface. Please apply this patch,
and possibly convert any remaining remaining occurrences of bus_id.

We want to submit a patch to -next, which will remove bus_id from
"struct device", to find the remaining pieces to convert, and finally
switch over to the new api, which will remove the 20 bytes array
and does no longer have a size limitation.
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-Off-By: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Tejun's commit 7b595756 made sysfs
attribute->owner unnecessary.  But the field was left in the structure to
ease the merge.  It's been over a year since that change and it is now
time to start killing attribute->owner along with its users - one arch at
a time!

This patch is attempt #1 to get rid of attribute->owner only for
CONFIG_X86_64 or CONFIG_X86_32 .  We will deal with other arches later on
as and when possible - avr32 will be the next since that is something I
can test.  Compile (make allyesconfig / make allmodconfig / custom config)
and boot tested.

akpm: the idea is that we put the declaration of sttribute.owner inside
`#ifndef CONFIG_X86'.  But that proved to be too ambitious for now because
new usages kept on turning up in subsystem trees.

[akpm: remove the ifdef for now]
Signed-off-by: NParag Warudkar <parag.lkml@gmail.com>
Cc: Greg KH <greg@kroah.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Tejun Heo <htejun@gmail.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Roland Dreier <rolandd@cisco.com>
Cc: David Brownell <david-b@pacbell.net>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Catch attempts to use of acpi_driver_data on pointers of wrong type.

akpm: rewritten to use proper C typechecking and remove the
"function"-used-as-lvalue thing.
Signed-off-by: NPavel Machek <pavel@suse.cz>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Use proc_create()/proc_create_data() to make sure that ->proc_fops and ->data
be setup before gluing PDE to main tree.

Add correct ->owner to proc_fops to fix reading/module unloading race.
Signed-off-by: NDenis V. Lunev <den@openvz.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Acer BIOS has a bug which is exposed when a dead battery is present.

The package template that is used to describe battery status is
over-written with sane values when the battery is live.
But when the batter is dead, a bogus reference in the template
is used.  In this case, Linux returns a fault, when instead
it should simply return that it doesn't know the missing value.

http://bugzilla.kernel.org/show_bug.cgi?id=8573
http://bugzilla.kernel.org/show_bug.cgi?id=10202Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

egrep serial /proc/acpi/battery/BAT0/info
serial number:           32090

serial number can tell you from the imminent danger
of beeing set on fire.
Signed-off-by: Nmaximilian attems <max@stro.at>
Acked-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

Reference: http://bugzilla.kernel.org/show_bug.cgi?id=9494Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

At least some systems report technology information with trailing spaces:

{pts/1}% cat -E /var/tmp/bat/2.6.23 | grep type
battery type:            Li-ION  $

Use strncasecmp to compare model string to skip trailing part
Signed-off-by: NAndrey Borzenkov <arvidjaar@mail.ru>
Acked-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

Introduce new ACPI_PROCFS_POWER (default Yes) config option and move
procfs code in battery, ac, and sbs drivers under it.
This is done to allow ACPI_PROCFS to be default No.
Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

get_property() should not call battery_update(), it also should call
get_status() only if battery is present to avoid cycle and oops.
Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Tested-by: NRolf Eike Beer <eike-kernel@sf-tec.de>
Acked-by: NJohannes Weiner <hannes@saeurebad.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If a battery is at a critical charge level and not being charged or
discharged, then the ACPI _BST method will return a state of 4, and
the current acpi_battery_get_property() code will not set any property
value for POWER_SUPPLY_PROP_STATUS.  This will cause an oops in
power_supply_show_property() when it reads off the end of the
status_text array.  This actually was causing a 100% reproducible
crash on boot on my laptop with two batteries, when one battery was
completely drained and the laptop was not plugged in.

Fix this by making sure acpi_battery_get_property() returns
POWER_SUPPLY_STATUS_UNKNOWN for any battery state it doesn't already
handle explicitly.  There doesn't seem to be any status enum value
defined that makes more sense than 'unknown' for a battery at a
critical charge level.
Signed-off-by: NRoland Dreier <roland@digitalvampire.org>
Acked-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <lenb@t61.(none)>

Some machines return integer instead of expected string.
Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Tested-by: NAndrey Borzenkov <arvidjaar@mail.ru>
Tested-by: NFrans Pop <elendil@planet.nl>
Signed-off-by: NLen Brown <len.brown@intel.com>