simple_strto*() are obsolete; use kstrto*() instead. Add proper error
checking.
Signed-off-by: NChristoph Jaeger <christophjaeger@linux.com>
Acked-by: NDavid Rientjes <rientjes@google.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

On Acer Aspire V5-573G battery notifications are sometimes
triggered too early. For example, when AC is unplugged and
notification is triggered, battery state is still reported as
"Full", and changes to "Discharging" only after short delay,
without any notification.

This patch solves the problem by adding 1 second sleep.
Similar quirk is already implemented in AC driver for other laptop.
Signed-off-by: NAlexander Mezin <mezin.alexander@gmail.com>
Acked-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Use callback for setting up quirk instead of checking return code
of dmi_check_system(). This change will allow using bat_dmi_table
for other quirks.
Signed-off-by: NAlexander Mezin <mezin.alexander@gmail.com>
Acked-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI Battery device receives notifications from firmware frequently,
and most of these notifications are some general events, like battery
remaining capacity change, etc, which should not wake the system up
if the system is in suspend/hibernate state.

This causes a problem that the system wakes up from suspend to freeze
shortly, because there is an ACPI battery notification every 10 seconds.

Fix the problem in this patch by registering ACPI battery device'
own wakeup source, and waking up the system only when the battery remaining
capacity is critical low, or lower than the alarm capacity set via _BTP.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=76221Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI battery device receives notifications when
1. the remaining battery capacity becomes critical low
2. the trip point set by the _BTP (Design capacity of Warning by default)
   is reached or crossed.

So it is able to support POWER_SUPPLY_PROP_CAPACITY_LEVEL to report
        POWER_SUPPLY_CAPACITY_LEVEL_CRITICAL,
        POWER_SUPPLY_CAPACITY_LEVEL_LOW,
        POWER_SUPPLY_CAPACITY_LEVEL_NORMAL,
        POWER_SUPPLY_CAPACITY_LEVEL_FULL,
capacity levels to power supply core and user space.

Introduce support for POWER_SUPPLY_PROP_CAPACITY_LEVEL in this patch.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Most time of battery resume callback is spent on executing AML code
_BTP, _BIF and _BIF to get battery info, status and set alarm. These
AML methods may access EC operation regions several times and consumes
time.

These operations are not necessary during devices resume and can run
during POST_SUSPEND/HIBERNATION event when all processes are thawed.

This also can avoid removing and adding battery sysfs nodes every system
resume even if the battery unit is not actually changed. The original code
updates sysfs nodes without check and this seems not reasonable.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The commit 1e2d9cdf and 7d7ee958 remove ACPI Proc Battery
directory and breaks some old userspace tools. This patch
is to revert commit 1e2d9cdf.

Fixes: 1e2d9cdf (ACPI / Battery: Remove battery's proc directory)
Cc: 3.13+ <stable@vger.kernel.org> # 3.13+
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Allow other drivers to subscribe to battery status notifications.
Just like AC driver does.
Signed-off-by: NAlexander Mezin <mezin.alexander@gmail.com>
Acked-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI_BATTERY_CLASS is used in multiple places.
Also, I'll use ACPI_BATTERY_NOTIFY_STATUS inside AC driver in
one of following patches.

So, create a header file and move ACPI_BATTERY_CLASS and
ACPI_BATTERY_NOTIFY_* definitions into it.
Also, remove copy of ACPI_BATTERY_CLASS from sbs.c
Signed-off-by: NAlexander Mezin <mezin.alexander@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The ACPI battery driver defines acpi_battery_resume() when
CONFIG_PM_SLEEP is defined. This results in the following compile
error when CONFIG_PM_SLEEP is undefined:

drivers/acpi/battery.c:847:8: error: ‘acpi_battery_resume’ undeclared here (not in a function)
Signed-off-by: NShuah Khan <shuah.kh@samsung.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Fix incorrect sscanf() string in acpi_battery_init_alarm().
Change from %ld to %lu, because 'x' is unsigned long.
Signed-off-by: NLuis G.F <luisgf@luisgf.es>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The AML method _BIX of NEC LZ750/LS returns a broken package which
skips the first member "Revision" (ACPI 5.0, Table 10-234).

Add a quirk for this machine to skip member "Revision" during parsing
the package returned by _BIX.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=67351Reported-and-tested-by: NFrancisco Castro <fcr@adinet.com.uy>
Cc: 3.8+ <stable@vger.kernel.org> " 3.8+
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and
<acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h>
inclusions and remove some inclusions of those files that aren't
necessary.

First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>
should not be included directly from any files that are built for
CONFIG_ACPI unset, because that generally leads to build warnings about
undefined symbols in !CONFIG_ACPI builds.  For CONFIG_ACPI set,
<linux/acpi.h> includes those files and for CONFIG_ACPI unset it
provides stub ACPI symbols to be used in that case.

Second, there are ordering dependencies between those files that always
have to be met.  Namely, it is required that <acpi/acpi_bus.h> be included
prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the
latter depends on are always there.  And <acpi/acpi.h> which provides
basic ACPICA type declarations should always be included prior to any other
ACPI headers in CONFIG_ACPI builds.  That also is taken care of including
<linux/acpi.h> as appropriate.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff)
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff)
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The battery's proc directory isn't useded and remove it.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: NJan Hoffmann <jan.christian.hoffmann@gmail.com>
References: http://bugzilla.kernel.org/show_bug.cgi?id=60519Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Cc: 2.6.34+ <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

It is quite some time that this one has been deprecated.
Get rid of it.

Should some really important user be overseen, it may be reverted and
the userspace program worked on first, but it is time to do something
to get rid of this old stuff...
Signed-off-by: NThomas Renninger <trenn@suse.de>
Acked-by: NMatthew Garrett <matthew.garrett@nebula.com>
Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Introduce helper function acpi_execute_simple_method() and use it in
a number of places to simplify code.

[rjw: Changelog]
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Introduce helper function acpi_has_method() and use it in a number
of places to simplify code.

[rjw: Changelog]
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add or remove spaces that give errors or warnings from checkpatch.pl.
Signed-off-by: NNicholas Mazzuca <nicholas@mazzucastuff.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The only part of proc_dir_entry the code outside of fs/proc
really cares about is PDE(inode)->data.  Provide a helper
for that; static inline for now, eventually will be moved
to fs/proc, along with the knowledge of struct proc_dir_entry
layout.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

This patch fixes following compiler warning when build via make W=1:

drivers/acpi/battery.c:149:52: warning: no previous prototype for ‘acpi_battery_present’ [-Wmissing-prototypes]
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The second argument of ACPI driver .remove() operation is only used
by the ACPI processor driver and the value passed to that driver
through it is always available from the given struct acpi_device
object's removal_type field.  For this reason, the second ACPI driver
.remove() argument is in fact useless, so drop it.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NJiang Liu <jiang.liu@huawei.com>
Acked-by: NToshi Kani <toshi.kani@hp.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>

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=41062Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

According to compiler warnings, several suspend/resume functions
in ACPI drivers are not used for CONFIG_PM_SLEEP unset, so add
#ifdefs to prevent them from being built in that case.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Make the ACPI battery driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Added Capacity field, which is a pre-defined power_supply
property. Calculating capacity using current charge/energy and
full charge/energy.
Some user mode implementations are relying on capacity field to
show battery strength and power down decision.
Signed-off-by: Nsrinivas pandruvada <srinivas.pandruvada@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

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:
da8aeb92
(ACPI / Battery: Update information on info notification and resume)

cc: <stable@vger.kernel.org>
Signed-off-by: NAndy Whitcroft <apw@canonical.com>
Tested-by: NRalf Jung <post@ralfj.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

both proc_dir_entry ->mode and populating functions
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Commit 9c921c22
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: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
Tested-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NPhil Carmody <ext-phil.2.carmody@nokia.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Make sure the error return from sysfs_add_battery() is checked and
propagated out from acpi_battery_add().
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NVasiliy Kulikov <segoon@openwall.com>
Acked-by: NJeff Garzik <jgarzik@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

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=35642Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

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=35642Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The Commit 25be5821 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: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

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 bc76f90b
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: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This patch is cosmetic only, and makes no functional change.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NKyle McMartin <kyle@redhat.com>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>