summaryrefslogtreecommitdiff
path: root/drivers/acpi/battery.c
AgeCommit message (Collapse)AuthorFilesLines
2018-02-04ACPI / battery: Add quirk for Asus UX360UA and UX410UAKKai Heng Feng1-0/+16
Same issue as other Asus laptops, ACPI incorrectly reports discharging when battery is full and AC is plugged. Use the same battery quirk can workaround the issue. Link: https://bugs.launchpad.net/bugs/1661876 Link: https://bugs.launchpad.net/bugs/1745032 Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-18ACPI / battery: Add quirk for Asus GL502VSK and UX305LAKai-Heng Feng1-3/+29
On Asus GL502VSK and UX305LA, ACPI incorrectly reports discharging when battery is full and AC is plugged. However rate_now is correct under this circumstance, hence we can use "rate_now == 0" as a predicate to report battery full status correctly. Link: https://bugs.launchpad.net/bugs/1482390 Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-13ACPI: battery: Drop redundant test for failureBjørn Mork1-3/+1
Merging the two adjacent conditionally built blocks makes the code a lot more readable. And as a bonus, we drop a duplicate test when CONFIG_ACPI_PROCFS_POWER is undefined. Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-24ACPI: make device_attribute constBhumika Goyal1-1/+1
Make these const as they are only passed as an argument to the function device_create_file and device_remove_file and the corresponding arguments are of type const. Done using Coccinelle Signed-off-by: Bhumika Goyal <bhumirks@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-15ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idleRafael J. Wysocki1-1/+1
The ACPI SCI (System Control Interrupt) is set up as a wakeup IRQ during suspend-to-idle transitions and, consequently, any events signaled through it wake up the system from that state. However, on some systems some of the events signaled via the ACPI SCI while suspended to idle should not cause the system to wake up. In fact, quite often they should just be discarded. Arguably, systems should not resume entirely on such events, but in order to decide which events really should cause the system to resume and which are spurious, it is necessary to resume up to the point when ACPI SCIs are actually handled and processed, which is after executing dpm_resume_noirq() in the system resume path. For this reasons, add a loop around freeze_enter() in which the platforms can process events signaled via multiplexed IRQ lines like the ACPI SCI and add suspend-to-idle hooks that can be used for this purpose to struct platform_freeze_ops. In the ACPI case, the ->wake hook is used for checking if the SCI has triggered while suspended and deferring the interrupt-induced system wakeup until the events signaled through it are actually processed sufficiently to decide whether or not the system should resume. In turn, the ->sync hook allows all of the relevant event queues to be flushed so as to prevent events from being missed due to race conditions. In addition to that, some ACPI code processing wakeup events needs to be modified to use the "hard" version of wakeup triggers, so that it will cause a system resume to happen on device-induced wakeup events even if the "soft" mechanism to prevent the system from suspending is not enabled. However, to preserve the existing behavior with respect to suspend-to-RAM, this only is done in the suspend-to-idle case and only if an SCI has occurred while suspended. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-09Merge branches 'intel_pstate' and 'pm-sleep'Rafael J. Wysocki1-1/+1
* intel_pstate: cpufreq: intel_pstate: Avoid division by 0 in min_perf_pct_min() * pm-sleep: Revert "ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle"
2017-06-07Revert "ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle"Rafael J. Wysocki1-1/+1
Revert commit eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle) as it turned out to be premature and triggered a number of different issues on various systems. That includes, but is not limited to, premature suspend-to-RAM aborts on Dell XPS 13 (9343) reported by Dominik. The issue the commit in question attempted to address is real and will need to be taken care of going forward, but evidently more work is needed for this purpose. Reported-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-05-09Merge branches 'pm-domains', 'pm-cpuidle', 'pm-sleep' and 'powercap'Rafael J. Wysocki1-1/+1
* pm-domains: PM / Domains: Add DT file to MAINTAINERS PM / Domains: Fix DT example * pm-cpuidle: x86/intel_idle: add Gemini Lake support cpuidle: check dev before usage in cpuidle_use_deepest_state() * pm-sleep: ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle PM / wakeup: Integrate mechanism to abort transitions in progress * powercap: powercap: intel_rapl: Add support for Gemini Lake
2017-05-05ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idleRafael J. Wysocki1-1/+1
The ACPI SCI (System Control Interrupt) is set up as a wakeup IRQ during suspend-to-idle transitions and, consequently, any events signaled through it wake up the system from that state. However, on some systems some of the events signaled via the ACPI SCI while suspended to idle should not cause the system to wake up. In fact, quite often they should just be discarded. Arguably, systems should not resume entirely on such events, but in order to decide which events really should cause the system to resume and which are spurious, it is necessary to resume up to the point when ACPI SCIs are actually handled and processed, which is after executing dpm_resume_noirq() in the system resume path. For this reasons, add a loop around freeze_enter() in which the platforms can process events signaled via multiplexed IRQ lines like the ACPI SCI and add suspend-to-idle hooks that can be used for this purpose to struct platform_freeze_ops. In the ACPI case, the ->wake hook is used for checking if the SCI has triggered while suspended and deferring the interrupt-induced system wakeup until the events signaled through it are actually processed sufficiently to decide whether or not the system should resume. In turn, the ->sync hook allows all of the relevant event queues to be flushed so as to prevent events from being missed due to race conditions. In addition to that, some ACPI code processing wakeup events needs to be modified to use the "hard" version of wakeup triggers, so that it will cause a system resume to happen on device-induced wakeup events even if the "soft" mechanism to prevent the system from suspending is not enabled (that also helps to catch device-induced wakeup events occurring during suspend transitions in progress). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-04-19ACPI / battery: Add a blacklist with PMIC ACPI HIDs with a native battery driverHans de Goede1-0/+14
On some systems we have a native PMIC driver which provides battery monitoring, while the ACPI battery driver is broken on these systems due to bad DSDTs or because we do not support the proprietary and undocumented ACPI opregions these ACPI battery devices rely on (e.g. BMOP opregion). This leads to there being 2 battery power_supply-s registed like this: ~$ acpi Battery 0: Charging, 84%, 00:49:39 until charged Battery 1: Unknown, 0%, rate information unavailable Even if the ACPI battery where to function fine (which on systems where we have a native PMIC driver it often doesn't) we still do not want to export the same battery to userspace twice. This commit adds a blacklist with PMIC ACPI HIDs for which we've a native battery driver and makes the ACPI battery driver not register itself when a PMIC on this list is present. Link: https://bugzilla.kernel.org/show_bug.cgi?id=194811 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-04-19ACPI / battery: Fix acpi_battery_exit on acpi_battery_init_async errorsHans de Goede1-2/+6
The acpi_lock_battery_dir() / acpi_bus_register_driver() calls in acpi_battery_init_async() may fail. Check that they succeeded before undoing them. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-24Replace <asm/uaccess.h> with <linux/uaccess.h> globallyLinus Torvalds1-1/+1
This was entirely automated, using the script by Al: PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*<asm/uaccess.h>' sed -i -e "s!$PATT!#include <linux/uaccess.h>!" \ $(git grep -l "$PATT"|grep -v ^include/linux/uaccess.h) to do the replacement at the end of the merge window. Requested-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-11-16ACPI / battery: If _BIX fails, retry with _BIFDave Lambley1-24/+48
The Lenovo Yoga 300 laptop's firmware advertises that it provides the _BIX the method to retrieve battery information. Unfortunately (some versions of?) the implementation return with an error. [ 21.712228] ACPI Exception: AE_AML_PACKAGE_LIMIT, Index (0x000000010) is beyond end of object (length 0xD) (20160422/exoparg2-427) [ 21.712244] ACPI Error: Method parse/execution failed [\_SB.PCI0.LPCB.H_EC.BAT1._BIX] (Node ffff95f8ff0b20f0), AE_AML_PACKAGE_LIMIT (20160422/psparse-542) The _BIF method does succeed and returns convincing data. We detect _BIX failing and automatically retry with _BIF. Signed-off-by: Dave Lambley <linux@davel.me.uk> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-31ACPI / battery: Add sysfs representation after checking _BSTCarlos Garnacho1-4/+6
Thus move sysfs_add_battery() after acpi_battery_get_state(), which doesn't require the power_supply. Prevents possible hanged tasks if acpi_battery_get_state() fails consistently (and takes a long time in doing so) when called inside acpi_battery_add(). In this situation the battery module first calls sysfs_add_battery(), which creates a power_supply, which spawns an async power_supply_deferred_register_work() task, which shall try to hold the parent battery device mutex (being already held) so this register work is set up after device initialization. If initialization takes long enough the thread will be eventually run and try to hold the mutex before acpi_battery_add() had the chance to finish. Eventually the 5 retries in acpi_battery_update_retry() fail, the error state is propagated, and results in sysfs_remove_battery() being called within the error handling paths of acpi_battery_add(), and the power_supply tear down too. This triggers a cancel_delayed_work_sync() of the deferred_register_work task, which ends up in schedule(). The end result is that the deferred task is blocked trying to acquire the parent device mutex, which is not released because the thread doing initialization (and failure handling) went to sleep awaiting for the deferred task to be cancelled. The hanged tasks look like this: INFO: task kworker/u8:0:6 blocked for more than 120 seconds. ... Call Trace: [<ffffffff815daec5>] schedule+0x35/0x80 [<ffffffff815dda3c>] schedule_timeout+0x1ec/0x250 [<ffffffff810a0572>] ? check_preempt_curr+0x52/0x90 [<ffffffff810a05c9>] ? ttwu_do_wakeup+0x19/0xe0 [<ffffffff815db915>] wait_for_common+0xc5/0x190 [<ffffffff810a1500>] ? wake_up_q+0x70/0x70 [<ffffffff815db9fd>] wait_for_completion+0x1d/0x20 [<ffffffff8108ffb1>] flush_work+0x111/0x1c0 [<ffffffff8108dfe0>] ? flush_workqueue_prep_pwqs+0x1a0/0x1a0 [<ffffffff810909af>] __cancel_work_timer+0x9f/0x1d0 [<ffffffff81090b13>] cancel_delayed_work_sync+0x13/0x20 [<ffffffff8147ac67>] power_supply_unregister+0x37/0xc0 [<ffffffffa058b03d>] sysfs_remove_battery+0x3d/0x52 [battery] [<ffffffffa058bf3a>] acpi_battery_add+0x112/0x181 [battery] [<ffffffff81366db6>] acpi_device_probe+0x54/0x19b [<ffffffff81427e9c>] driver_probe_device+0x22c/0x440 [<ffffffff81428181>] __driver_attach+0xd1/0xf0 [<ffffffff814280b0>] ? driver_probe_device+0x440/0x440 [<ffffffff8142591c>] bus_for_each_dev+0x6c/0xc0 [<ffffffff8142758e>] driver_attach+0x1e/0x20 [<ffffffff81426fc3>] bus_add_driver+0x1c3/0x280 [<ffffffff81428b00>] driver_register+0x60/0xe0 [<ffffffff81366c80>] acpi_bus_register_driver+0x3b/0x43 [<ffffffffa0591040>] acpi_battery_init_async+0x1c/0x1e [battery] [<ffffffff81099268>] async_run_entry_fn+0x48/0x150 [<ffffffff81090d09>] process_one_work+0x1e9/0x440 [<ffffffff81090fab>] worker_thread+0x4b/0x4f0 [<ffffffff81090f60>] ? process_one_work+0x440/0x440 [<ffffffff81096b58>] kthread+0xd8/0xf0 [<ffffffff815de97f>] ret_from_fork+0x1f/0x40 [<ffffffff81096a80>] ? kthread_worker_fn+0x180/0x180 INFO: task kworker/u8:4:282 blocked for more than 120 seconds. ... Call Trace: [<ffffffff810ad745>] ? put_prev_entity+0x35/0x8b0 [<ffffffff815daec5>] schedule+0x35/0x80 [<ffffffff815db14e>] schedule_preempt_disabled+0xe/0x10 [<ffffffff815dc533>] __mutex_lock_slowpath+0xb3/0x120 [<ffffffff815dc5bf>] mutex_lock+0x1f/0x30 [<ffffffff8147a59b>] power_supply_deferred_register_work+0x2b/0x50 [<ffffffff81090d09>] process_one_work+0x1e9/0x440 [<ffffffff81090fab>] worker_thread+0x4b/0x4f0 [<ffffffff81090f60>] ? process_one_work+0x440/0x440 [<ffffffff81090f60>] ? process_one_work+0x440/0x440 [<ffffffff81096b58>] kthread+0xd8/0xf0 [<ffffffff815de97f>] ret_from_fork+0x1f/0x40 [<ffffffff81096a80>] ? kthread_worker_fn+0x180/0x180 Making sysfs_add_battery() the last operation here means that the power_supply won't be created yet when the acpi_add_battery() failure handling happens, the deferred task won't even spawn, and sysfs_remove_battery will just skip over the NULL battery->bat. Signed-off-by: Carlos Garnacho <carlosg@gnome.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-21ACPI / battery: Correctly serialise with the pending async probeChris Wilson1-1/+1
async_synchronize_cookie() only serialises all tasks up to the specified cookie, and importantly does not wait for the task corresponding with the cookie. [This is so that it can be trivially used from inside the async_func_t in order to serialise with all preceding tasks.] In order to serialise with acpi_battery_init_async() we need to compensate and pass in the next cookie instead. The impact today is zero since performing an async_schedule() from inside a module init function will trigger an async_synchronize_full() prior to the module loader's completion. However, if the probe was moved to its own unregistered async_domain, then the async_synchronize_cookie would be replaced with an async_synchronize_full_domain. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-08ACPI: Remove FSF mailing addressesJarkko Nikula1-4/+0
There is no need to carry potentially outdated Free Software Foundation mailing address in file headers since the COPYING file includes it. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-15ACPI / battery: mark DMI table as __initconstMathias Krause1-3/+5
The bat_dmi_table[] DMI table is referenced from the __init function acpi_battery_init_async() only. It and its referenced functions can therefore be marked __initconst to free up ~1kB of runtime memory after initialization is done. Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-15ACPI / battery: minor tweaks to acpi_battery_units()Mathias Krause1-8/+6
Make the acpi_battery_units() function take a const argument and return a const char*, too. Also make it static. It probably doesn't matter, as gcc will be clever enough to optimize and inline the code even without these hints. However, we also get rid of a #ifdef block by moving the function closer to its usage location, so it's at least a small gain in code readability. Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-15ACPI / battery: constify the offset tablesMathias Krause1-4/+4
The offset tables are only read, not modified. Make them const. Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-05-14ACPI / battery: ensure acpi_battery_init() has finishLuis Henriques1-1/+3
Make sure that async function scheduled with async_schedule() has already been executed. Signed-off-by: Luis Henriques <luis.henriques@canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-05-14ACPI / battery: drop useless return statementsLuis Henriques1-5/+5
Signed-off-by: Luis Henriques <luis.henriques@canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-05-14ACPI / battery: abort initialization earlier if acpi_disabledLuis Henriques1-3/+3
If ACPI is disabled there's no need to schedule an async function call, the driver initialization can be aborted earlier in acpi_battery_init(). Signed-off-by: Luis Henriques <luis.henriques@canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-04-14Merge tag 'pm+acpi-4.1-rc1' of ↵Linus Torvalds1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management and ACPI updates from Rafael Wysocki: "These are mostly fixes and cleanups all over, although there are a few items that sort of fall into the new feature category. First off, we have new callbacks for PM domains that should help us to handle some issues related to device initialization in a better way. There also is some consolidation in the unified device properties API area allowing us to use that inferface for accessing data coming from platform initialization code in addition to firmware-provided data. We have some new device/CPU IDs in a few drivers, support for new chips and a new cpufreq driver too. Specifics: - Generic PM domains support update including new PM domain callbacks to handle device initialization better (Russell King, Rafael J Wysocki, Kevin Hilman) - Unified device properties API update including a new mechanism for accessing data provided by platform initialization code (Rafael J Wysocki, Adrian Hunter) - ARM cpuidle update including ARM32/ARM64 handling consolidation (Daniel Lezcano) - intel_idle update including support for the Silvermont Core in the Baytrail SOC and for the Airmont Core in the Cherrytrail and Braswell SOCs (Len Brown, Mathias Krause) - New cpufreq driver for Hisilicon ACPU (Leo Yan) - intel_pstate update including support for the Knights Landing chip (Dasaratharaman Chandramouli, Kristen Carlson Accardi) - QorIQ cpufreq driver update (Tang Yuantian, Arnd Bergmann) - powernv cpufreq driver update (Shilpasri G Bhat) - devfreq update including Tegra support changes (Tomeu Vizoso, MyungJoo Ham, Chanwoo Choi) - powercap RAPL (Running-Average Power Limit) driver update including support for Intel Broadwell server chips (Jacob Pan, Mathias Krause) - ACPI device enumeration update related to the handling of the special PRP0001 device ID allowing DT-style 'compatible' property to be used for ACPI device identification (Rafael J Wysocki) - ACPI EC driver update including limited _DEP support (Lan Tianyu, Lv Zheng) - ACPI backlight driver update including a new mechanism to allow native backlight handling to be forced on non-Windows 8 systems and a new quirk for Lenovo Ideapad Z570 (Aaron Lu, Hans de Goede) - New Windows Vista compatibility quirk for Sony VGN-SR19XN (Chen Yu) - Assorted ACPI fixes and cleanups (Aaron Lu, Martin Kepplinger, Masanari Iida, Mika Westerberg, Nan Li, Rafael J Wysocki) - Fixes related to suspend-to-idle for the iTCO watchdog driver and the ACPI core system suspend/resume code (Rafael J Wysocki, Chen Yu) - PM tracing support for the suspend phase of system suspend/resume transitions (Zhonghui Fu) - Configurable delay for the system suspend/resume testing facility (Brian Norris) - PNP subsystem cleanups (Peter Huewe, Rafael J Wysocki)" * tag 'pm+acpi-4.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (74 commits) ACPI / scan: Fix NULL pointer dereference in acpi_companion_match() ACPI / scan: Rework modalias creation when "compatible" is present intel_idle: mark cpu id array as __initconst powercap / RAPL: mark rapl_ids array as __initconst powercap / RAPL: add ID for Broadwell server intel_pstate: Knights Landing support intel_pstate: remove MSR test cpufreq: fix qoriq uniprocessor build ACPI / scan: Take the PRP0001 position in the list of IDs into account ACPI / scan: Simplify acpi_match_device() ACPI / scan: Generalize of_compatible matching device property: Introduce firmware node type for platform data device property: Make it possible to use secondary firmware nodes PM / watchdog: iTCO: stop watchdog during system suspend cpufreq: hisilicon: add acpu driver ACPI / EC: Call acpi_walk_dep_device_list() after installing EC opregion handler cpufreq: powernv: Report cpu frequency throttling intel_idle: Add support for the Airmont Core in the Cherrytrail and Braswell SOCs intel_idle: Update support for Silvermont Core in Baytrail SOC PM / devfreq: tegra: Register governor on module init ...
2015-04-14ACPI / battery: Fix doubly added battery on system suspendKrzysztof Kozlowski1-1/+1
Commit 297d716f6260 ("power_supply: Change ownership from driver to core") inverted the logic in battery_notify(). As an effect already present battery was re-added on each system suspend or hibernation. WARNING: CPU: 0 PID: 303 at ../fs/sysfs/dir.c:31 sysfs_warn_dup+0x68/0x80() sysfs: cannot create duplicate filename '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0C0A:00/power_supply/BAT0' CPU: 0 PID: 303 Comm: rtcwake Not tainted 4.0.0-ARCH-02621-g07e6253af953 #48 Call Trace: sysfs_create_dir_ns+0x8d/0xa0 kobject_add_internal+0xb6/0x370 kobject_add+0x6f/0xd0 device_add+0x120/0x6c0 __power_supply_register+0x145/0x290 power_supply_register_no_ws+0x10/0x20 sysfs_add_battery+0x84/0xc5 [battery] battery_notify+0x45/0x6b [battery] notifier_call_chain+0x4f/0x80 __blocking_notifier_call_chain+0x4b/0x70 blocking_notifier_call_chain+0x16/0x20 pm_notifier_call_chain+0x1a/0x40 pm_suspend+0x3ed/0x4e0 Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-By: Sebastian Reichel <sre@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-03-18ACPI / battery: make warning greppableMartin Kepplinger1-2/+2
Signed-off-by: Martin Kepplinger <martink@posteo.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-13power_supply: Change ownership from driver to coreKrzysztof Kozlowski1-25/+30
Change the ownership of power_supply structure from each driver implementing the class to the power supply core. The patch changes power_supply_register() function thus all drivers implementing power supply class are adjusted. Each driver provides the implementation of power supply. However it should not be the owner of power supply class instance because it is exposed by core to other subsystems with power_supply_get_by_name(). These other subsystems have no knowledge when the driver will unregister the power supply. This leads to several issues when driver is unbound - mostly because user of power supply accesses freed memory. Instead let the core own the instance of struct 'power_supply'. Other users of this power supply will still access valid memory because it will be freed when device reference count reaches 0. Currently this means "it will leak" but power_supply_put() call in next patches will solve it. This solves invalid memory references in following race condition scenario: Thread 1: charger manager Thread 2: power supply driver, used by charger manager THREAD 1 (charger manager) THREAD 2 (power supply driver) ========================== ============================== psy = power_supply_get_by_name() Driver unbind, .remove power_supply_unregister() Device fully removed psy->get_property() The 'get_property' call is executed in invalid context because the driver was unbound and struct 'power_supply' memory was freed. This could be observed easily with charger manager driver (here compiled with max17040 fuel gauge): $ cat /sys/devices/virtual/power_supply/cm-battery/capacity & $ echo "1-0036" > /sys/bus/i2c/drivers/max17040/unbind [ 55.725123] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 55.732584] pgd = d98d4000 [ 55.734060] [00000000] *pgd=5afa2831, *pte=00000000, *ppte=00000000 [ 55.740318] Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM [ 55.746210] Modules linked in: [ 55.749259] CPU: 1 PID: 2936 Comm: cat Tainted: G W 3.19.0-rc1-next-20141226-00048-gf79f475f3c44-dirty #1496 [ 55.760190] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 55.766270] task: d9b76f00 ti: daf54000 task.ti: daf54000 [ 55.771647] PC is at 0x0 [ 55.774182] LR is at charger_get_property+0x2f4/0x36c [ 55.779201] pc : [<00000000>] lr : [<c034b0b4>] psr: 60000013 [ 55.779201] sp : daf55e90 ip : 00000003 fp : 00000000 [ 55.790657] r10: 00000000 r9 : c06e2878 r8 : d9b26c68 [ 55.795865] r7 : dad81610 r6 : daec7410 r5 : daf55ebc r4 : 00000000 [ 55.802367] r3 : 00000000 r2 : daf55ebc r1 : 0000002a r0 : d9b26c68 [ 55.808879] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 55.815994] Control: 10c5387d Table: 598d406a DAC: 00000015 [ 55.821723] Process cat (pid: 2936, stack limit = 0xdaf54210) [ 55.827451] Stack: (0xdaf55e90 to 0xdaf56000) [ 55.831795] 5e80: 60000013 c01459c4 0000002a c06f8ef8 [ 55.839956] 5ea0: db651000 c06f8ef8 daebac00 c04cb668 daebac08 c0346864 00000000 c01459c4 [ 55.848115] 5ec0: d99eaa80 c06f8ef8 00000fff 00001000 db651000 c027f25c c027f240 d99eaa80 [ 55.856274] 5ee0: d9a06c00 c0146218 daf55f18 00001000 d99eaa80 db4c18c0 00000001 00000001 [ 55.864468] 5f00: daf55f80 c0144c78 c0144c54 c0107f90 00015000 d99eaab0 00000000 00000000 [ 55.872603] 5f20: 000051c7 00000000 db4c18c0 c04a9370 00015000 00001000 daf55f80 00001000 [ 55.880763] 5f40: daf54000 00015000 00000000 c00e53dc db4c18c0 c00e548c 0000000d 00008124 [ 55.888937] 5f60: 00000001 00000000 00000000 db4c18c0 db4c18c0 00001000 00015000 c00e5550 [ 55.897099] 5f80: 00000000 00000000 00001000 00001000 00015000 00000003 00000003 c000f364 [ 55.905239] 5fa0: 00000000 c000f1a0 00001000 00015000 00000003 00015000 00001000 0001333c [ 55.913399] 5fc0: 00001000 00015000 00000003 00000003 00000002 00000000 00000000 00000000 [ 55.921560] 5fe0: 7fffe000 be999850 0000a225 b6f3c19c 60000010 00000003 00000000 00000000 [ 55.929744] [<c034b0b4>] (charger_get_property) from [<c0346864>] (power_supply_show_property+0x48/0x20c) [ 55.939286] [<c0346864>] (power_supply_show_property) from [<c027f25c>] (dev_attr_show+0x1c/0x48) [ 55.948130] [<c027f25c>] (dev_attr_show) from [<c0146218>] (sysfs_kf_seq_show+0x84/0x104) [ 55.956298] [<c0146218>] (sysfs_kf_seq_show) from [<c0144c78>] (kernfs_seq_show+0x24/0x28) [ 55.964536] [<c0144c78>] (kernfs_seq_show) from [<c0107f90>] (seq_read+0x1b0/0x484) [ 55.972172] [<c0107f90>] (seq_read) from [<c00e53dc>] (__vfs_read+0x18/0x4c) [ 55.979188] [<c00e53dc>] (__vfs_read) from [<c00e548c>] (vfs_read+0x7c/0x100) [ 55.986304] [<c00e548c>] (vfs_read) from [<c00e5550>] (SyS_read+0x40/0x8c) [ 55.993164] [<c00e5550>] (SyS_read) from [<c000f1a0>] (ret_fast_syscall+0x0/0x48) [ 56.000626] Code: bad PC value [ 56.011652] ---[ end trace 7b64343fbdae8ef1 ]--- Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> [for the nvec part] Reviewed-by: Marc Dietrich <marvin24@gmx.de> [for compal-laptop.c] Acked-by: Darren Hart <dvhart@linux.intel.com> [for the mfd part] Acked-by: Lee Jones <lee.jones@linaro.org> [for the hid part] Acked-by: Jiri Kosina <jkosina@suse.cz> [for the acpi part] Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
2015-03-13power_supply: Move run-time configuration to separate structureKrzysztof Kozlowski1-1/+2
Add new structure 'power_supply_config' for holding run-time initialization data like of_node, supplies and private driver data. The power_supply_register() function is changed so all power supply drivers need updating. When registering the power supply this new 'power_supply_config' should be used instead of directly initializing 'struct power_supply'. This allows changing the ownership of power_supply structure from driver to the power supply core in next patches. When a driver does not use of_node or supplies then it should use NULL as config. If driver uses of_node or supplies then it should allocate config on stack and initialize it with proper values. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Pavel Machek <pavel@ucw.cz> [for the nvec part] Reviewed-by: Marc Dietrich <marvin24@gmx.de> [for drivers/platform/x86/compal-laptop.c] Reviewed-by: Darren Hart <dvhart@linux.intel.com> [for drivers/hid/*] Reviewed-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sebastian Reichel <sre@kernel.org>
2014-11-24ACPI: Add _DEP support to fix battery issue on Asus T100TALan Tianyu1-0/+4
ACPI 5.0 introduces _DEP (Operation Region Dependencies) to designate device objects that OSPM should assign a higher priority in start ordering due to future operation region accesses. On Asus T100TA, ACPI battery info are read from a I2C slave device via I2C operation region. Before I2C operation region handler is installed, battery _STA always returns 0. There is a _DEP method of designating start order under battery device node. This patch is to implement _DEP feature to fix battery issue on the Asus T100TA. Introducing acpi_dep_list and adding dep_unmet count in struct acpi_device. During ACPI namespace scan, create struct acpi_dep_data for a valid pair of master (device pointed to by _DEP)/ slave(device with _DEP), record master's and slave's ACPI handle in it and put it into acpi_dep_list. The dep_unmet count will increase by one if there is a device under its _DEP. Driver's probe() should return EPROBE_DEFER when find dep_unmet is larger than 0. When I2C operation region handler is installed, remove all struct acpi_dep_data on the acpi_dep_list whose master is pointed to I2C host controller and decrease slave's dep_unmet. When dep_unmet decreases to 0, all _DEP conditions are met and then do acpi_bus_attach() for the device in order to resolve battery _STA issue on the Asus T100TA. Link: https://bugzilla.kernel.org/show_bug.cgi?id=69011 Tested-by: Jan-Michael Brummer <jan.brummer@tabos.org> Tested-by: Adam Williamson <adamw@happyassassin.net> Tested-by: Michael Shigorin <shigorin@gmail.com> Acked-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-24ACPI / battery: Replace strnicmp with strncasecmpRasmus Villemoes1-1/+1
The kernel used to contain two functions for length-delimited, case-insensitive string comparison, strnicmp with correct semantics and a slightly buggy strncasecmp. The latter is the POSIX name, so strnicmp was renamed to strncasecmp, and strnicmp made into a wrapper for the new strncasecmp to avoid breaking existing users. To allow the compat wrapper strnicmp to be removed at some point in the future, and to avoid the extra indirection cost, do s/strnicmp/strncasecmp/g. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-09Revert "ACPI / battery: fix wrong value of capacity_now reported when fully ↵Bjørn Mork1-14/+0
charged" This reverts commit 232de5143790 ("ACPI / battery: fix wrong value of capacity_now reported when fully charged") There is nothing wrong or unexpected about 'capacity_now' increasing above the last 'full_charge_capacity' value. Different charging cycles will cause 'full_charge_capacity' to vary, both up and down. Good battery firmwares will update 'full_charge_capacity' when the current charging cycle is complete, increasing it if necessary. It might even go above 'design_capacity' on a fresh and healthy battery. Capping 'capacity_now' to 'full_charge_capacity' is plain wrong, and printing a warning if this doesn't happen to match the 'design_capacity' is both annoying and terribly wrong. This results in bogus warnings on perfectly working systems/firmwares: [Firmware Bug]: battery: reported current charge level (39800) is higher than reported maximum charge level (39800). and wrong values being reported for 'capacity_now' and 'full_charge_capacity' after the warning has been triggered. Fixes: 232de5143790 ("ACPI / battery: fix wrong value of capacity_now reported when fully charged") Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-09Revert "ACPI / battery: Fix warning message in acpi_battery_get_state()"Bjørn Mork1-1/+1
This reverts commit d719870b41e0 ("ACPI / battery: Fix warning message in acpi_battery_get_state()") Capping 'capacity_now' to 'full_charge_capacity' is plain wrong. If this is necessary to work around some buggy firmware, then the workaround needs protection against being applied to working firmwares. Good battery firmwares will allow 'capacity_now' to increase above 'full_charge_capacity', and will update the latter when the battery is fully charged. By capping 'capacity_now' we lose accurate capacity reporting until charging is complete whenever 'full_charge_capacity' needs to be increased. Fixes: d719870b41e0 ("ACPI / battery: Fix warning message in acpi_battery_get_state()") Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-08-10ACPI / battery: Fix warning message in acpi_battery_get_state()Mariusz Ceier1-1/+1
capacity_now should be assigned after comparing it to design_capacity. Otherwise warning is printed even when capacity_now before assignment is equal to design_capacity, making the check useless and "current charge level" wrong (it should be higher than, not equal to, "maximum charge level", which is full_charge_capacity): "battery: reported current charge level (56410) is higher than reported maximum charge level (56410)." Fixes: 232de5143790 (ACPI / battery: fix wrong value of capacity_now reported when fully charged) Signed-off-by: Mariusz Ceier <mceier+kernel@gmail.com> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ [rjw: Subject] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-07-30ACPI / battery: remove duplicated include from battery.cWei Yongjun1-1/+0
Remove duplicated include. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-07-07ACPI / battery: fix wrong value of capacity_now reported when fully chargedJosef Gajdusek1-0/+14
It seems that some batteries (noticed on DELL JYPJ136) assume capacity_now = design_capacity when fully charged. This causes reported capacity to suddenly jump to >full_charge_capacity (and that means capacity reported to userspace is >100% and incorrect) values after 99%. This patch detects capacity_now > full_charge_capacity, notifies userspace (unless it is the known bug where capacity_now == design_capacity) and trims the value to full_charge_capacity. Signed-off-by: Josef Gajdusek <atx@atx.name> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-07-07ACPI / battery: Retry to get battery information if failed during probingLan Tianyu1-1/+26
Some machines (eg. Lenovo Z480) ECs are not stable during boot up and causes battery driver fails to be loaded due to failure of getting battery information from EC sometimes. After several retries, the operation will work. This patch is to retry to get battery information 5 times if the first try fails. Link: https://bugzilla.kernel.org/show_bug.cgi?id=75581 Reported-and-tested-by: naszar <naszar@ya.ru> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-19Merge branches 'acpi-general', 'acpi-processor', 'acpi-lpss' and 'acpi-battery'Rafael J. Wysocki1-3/+36
* acpi-general: ACPI: use kstrto*() instead of simple_strto*() * acpi-processor: ACPI / processor replace __attribute__((packed)) by __packed * acpi-lpss: ACPI / LPSS: Take I2C host controllers out of reset * acpi-battery: ACPI / battery: add quirk for Acer Aspire V5-573G ACPI / battery: use callback for setting up quirks
2014-06-17ACPI: use kstrto*() instead of simple_strto*()Christoph Jaeger1-1/+4
simple_strto*() are obsolete; use kstrto*() instead. Add proper error checking. Signed-off-by: Christoph Jaeger <christophjaeger@linux.com> Acked-by: David Rientjes <rientjes@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-17ACPI / battery: add quirk for Acer Aspire V5-573GAlexander Mezin1-0/+24
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: Alexander Mezin <mezin.alexander@gmail.com> Acked-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-17ACPI / battery: use callback for setting up quirksAlexander Mezin1-2/+8
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: Alexander Mezin <mezin.alexander@gmail.com> Acked-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-30ACPI / battery: wakeup the system only when necessaryZhang Rui1-1/+17
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=76221 Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-30ACPI / battery: introduce support for POWER_SUPPLY_PROP_CAPACITY_LEVELZhang Rui1-3/+20
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: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-16ACPI / battery: Accelerate battery resume callbackLan Tianyu1-9/+27
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: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-06ACPI: Revert "ACPI / Battery: Remove battery's proc directory"Lan Tianyu1-1/+328
The commit 1e2d9cd and 7d7ee95 remove ACPI Proc Battery directory and breaks some old userspace tools. This patch is to revert commit 1e2d9cd. Fixes: 1e2d9cdfb449 (ACPI / Battery: Remove battery's proc directory) Cc: 3.13+ <stable@vger.kernel.org> # 3.13+ Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-19ACPI / battery: call ACPI notifier chain in acpi_battery_notifyAlexander Mezin1-0/+1
Allow other drivers to subscribe to battery status notifications. Just like AC driver does. Signed-off-by: Alexander Mezin <mezin.alexander@gmail.com> Acked-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-19ACPI / battery: move some ACPI_BATTERY_* definitions to headerAlexander Mezin1-4/+2
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: Alexander Mezin <mezin.alexander@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-13ACPI / battery: fix battery driver compile error when CONFIG_PM_SLEEP is ↵Shuah Khan1-0/+2
undefined 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: Shuah Khan <shuah.kh@samsung.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-05ACPI / battery: Fix incorrect sscanf() string in acpi_battery_init_alarm()Luis G.F1-1/+1
Fix incorrect sscanf() string in acpi_battery_init_alarm(). Change from %ld to %lu, because 'x' is unsigned long. Signed-off-by: Luis G.F <luisgf@luisgf.es> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-12Merge branch 'acpi-cleanup'Rafael J. Wysocki1-2/+1
* acpi-cleanup: (22 commits) ACPI / tables: Return proper error codes from acpi_table_parse() and fix comment. ACPI / tables: Check if id is NULL in acpi_table_parse() ACPI / proc: Include appropriate header file in proc.c ACPI / EC: Remove unused functions and add prototype declaration in internal.h ACPI / dock: Include appropriate header file in dock.c ACPI / PCI: Include appropriate header file in pci_link.c ACPI / PCI: Include appropriate header file in pci_slot.c ACPI / EC: Mark the function acpi_ec_add_debugfs() as static in ec_sys.c ACPI / NVS: Include appropriate header file in nvs.c ACPI / OSL: Mark the function acpi_table_checksum() as static ACPI / processor: initialize a variable to silence compiler warning ACPI / processor: use ACPI_COMPANION() to get ACPI device ACPI: correct minor typos ACPI / sleep: Drop redundant acpi_disabled check ACPI / dock: Drop redundant acpi_disabled check ACPI / table: Replace '1' with specific error return values ACPI: remove trailing whitespace ACPI / IBFT: Fix incorrect <acpi/acpi.h> inclusion in iSCSI boot firmware module ACPI / i915: Fix incorrect <acpi/acpi.h> inclusions via <linux/acpi_io.h> SFI / ACPI: Fix warnings reported during builds with W=1 ... Conflicts: drivers/acpi/nvs.c drivers/hwmon/asus_atk0110.c
2014-01-06ACPI / Battery: Add a _BIX quirk for NEC LZ750/LSLan Tianyu1-1/+21
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=67351 Reported-and-tested-by: Francisco Castro <fcr@adinet.com.uy> Cc: 3.8+ <stable@vger.kernel.org> " 3.8+ Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-12-07ACPI: Clean up inclusions of ACPI header filesLv Zheng1-2/+1
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: Lv 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-19 23:04:19 +0000