Commit Graph

198 Commits

Author SHA1 Message Date
Jouke Witteveen 673b427166 ACPI / battery: Safe unregistering of hooks
A hooking API was implemented for 4.17 in fa93854f7a followed
by hooks for Thinkpad laptops in 2801b9683f. The Thinkpad
drivers did not support the Thinkpad 13 and the hooking API crashes
on unsupported batteries by altering a list of hooks during unsafe
iteration. Thus, Thinkpad 13 laptops could no longer boot.

Additionally, a lock was kept in place and debugging information was
printed out of order.

Fixes: fa93854f7a (battery: Add the battery hooking API)
Cc: 4.17+ <stable@vger.kernel.org> # 4.17+
Signed-off-by: Jouke Witteveen <j.witteveen@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-07-04 12:36:29 +02:00
Linus Torvalds f4fe74cc90 ACPI updates for 4.18-rc1
These update the ACPICA code in the kernel to the 20180508 upstream
 revision and make it support the RT patch, add CPPC v3 support to the
 ACPI CPPC library, add a WDAT-based watchdog quirk to prevent clashes
 with the RTC, add quirks to the ACPI AC and battery drivers, and
 update the ACPI SoC drivers.
 
 Specifics:
 
  - Update the ACPICA code in the kernel to the 20180508 upstream
    revision including:
    * iASL -tc option enhancement (Bob Moore).
    * Debugger improvements (Bob Moore).
    * Support for tables larger than 1 MB in acpidump/acpixtract
      (Bob Moore).
    * Minor fixes and cleanups (Colin Ian King, Toomas Soome).
 
  - Make the ACPICA code in the kernel support the RT patch (Sebastian
    Andrzej Siewior, Steven Rostedt).
 
  - Add a kmemleak annotation to the ACPICA code (Larry Finger).
 
  - Add CPPC v3 support to the ACPI CPPC library and fix two issues
    related to CPPC (Prashanth Prakash, Al Stone).
 
  - Add an ACPI WDAT-based watchdog quirk to prefer iTCO_wdt on
    systems where WDAT clashes with the RTC SRAM (Mika Westerberg).
 
  - Add some quirks to the ACPI AC and battery drivers (Carlo Caione,
    Hans de Goede).
 
  - Update the ACPI SoC drivers for Intel (LPSS) and AMD (APD)
    platforms (Akshu Agrawal, Hans de Goede).
 
  - Fix up some assorted minor issues (Al Stone, Laszlo Toth,
    Mathieu Malaterre).
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQIcBAABCAAGBQJbFR2IAAoJEILEb/54YlRxsEcP/0vxyGvTXUnHH13h1ayhbcEL
 qKA//1Zvw55mFb86nlnIVWUfpVx5pN4sOd2MZL2bDmNP8+ZX1QFbwtkpP8MtnRyX
 0pmPb2QpmHz/ZHutVg3rGxFOV4Sk0IPevQW7d4eu/Gc6K/UkfREMj10PWu9EoNWm
 6UCKuONxeoUAtE/OTfvU33ghpYgBH506Kg6/EwLLRX0tA10NBa11L9ijUEkVfa0s
 RDn5Z9ndjGGed4XtlSNkfabEJpc6uX9JvbAw77DKZgyqEZgQyNa4CZ2C1ZtH66lZ
 HCS62eJ6ePGUvzW/KTn825+MOGni5YisGlfonHuF9xHpPNSp7Doxmyny3lMYHL7S
 l0XdI2G7UIOFO5eaRM/zYQPQyF05lna28MVvTWJWBA3bcUz4rav9fzPKYp5l+To0
 xK1Ol84sowlkOKoi/RIcOx5nsh05SufGqNu9RuXjRZ4iK0bJPCD3YNt+tH95b94M
 0YOuoDkIylieVET4xgHB5vBOj8EgMOLtSaGSpEbh816i+BdZMx7YnS4xSmQ+JFjd
 rVCJMnXcLZ82j3pkvPpR0W3VLVbEJPjLftENjSVJ+vA9lR567byBFrvzTEmsEQoi
 KlNWh5qDmoR96dPheLdhD1HtsL070xLhyqYOUDvtqTiVH8uNxoWfQzcSfvXPvLqc
 XGCcG/oPP9FFpNZfLzAB
 =FAIF
 -----END PGP SIGNATURE-----

Merge tag 'acpi-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

Pull ACPI updates from Rafael Wysocki:
 "These update the ACPICA code in the kernel to the 20180508 upstream
  revision and make it support the RT patch, add CPPC v3 support to the
  ACPI CPPC library, add a WDAT-based watchdog quirk to prevent clashes
  with the RTC, add quirks to the ACPI AC and battery drivers, and
  update the ACPI SoC drivers.

  Specifics:

   - Update the ACPICA code in the kernel to the 20180508 upstream
     revision including:
       * iASL -tc option enhancement (Bob Moore).
       * Debugger improvements (Bob Moore).
       * Support for tables larger than 1 MB in acpidump/acpixtract (Bob
         Moore).
       * Minor fixes and cleanups (Colin Ian King, Toomas Soome).

   - Make the ACPICA code in the kernel support the RT patch (Sebastian
     Andrzej Siewior, Steven Rostedt).

   - Add a kmemleak annotation to the ACPICA code (Larry Finger).

   - Add CPPC v3 support to the ACPI CPPC library and fix two issues
     related to CPPC (Prashanth Prakash, Al Stone).

   - Add an ACPI WDAT-based watchdog quirk to prefer iTCO_wdt on systems
     where WDAT clashes with the RTC SRAM (Mika Westerberg).

   - Add some quirks to the ACPI AC and battery drivers (Carlo Caione,
     Hans de Goede).

   - Update the ACPI SoC drivers for Intel (LPSS) and AMD (APD)
     platforms (Akshu Agrawal, Hans de Goede).

   - Fix up some assorted minor issues (Al Stone, Laszlo Toth, Mathieu
     Malaterre)"

* tag 'acpi-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (32 commits)
  ACPICA: Mark acpi_ut_create_internal_object_dbg() memory allocations as non-leaks
  ACPI / watchdog: Prefer iTCO_wdt always when WDAT table uses RTC SRAM
  mailbox: PCC: erroneous error message when parsing ACPI PCCT
  ACPICA: Update version to 20180508
  ACPICA: acpidump/acpixtract: Support for tables larger than 1MB
  ACPI: APD: Add AMD misc clock handler support
  clk: x86: Add ST oscout platform clock
  ACPICA: Update version to 20180427
  ACPICA: Debugger: Removed direct support for EC address space in "Test Objects"
  ACPICA: Debugger: Add Package support for "test objects" command
  ACPICA: Improve error messages for the namespace root node
  ACPICA: Fix potential infinite loop in acpi_rs_dump_byte_list
  ACPICA: vsnprintf: this statement may fall through
  ACPICA: Tables: Fix spelling mistake in comment
  ACPICA: iASL: Enhance the -tc option (create AML hex file in C)
  ACPI: Add missing prototype_for arch_post_acpi_subsys_init()
  ACPI / tables: improve comments regarding acpi_parse_entries_array()
  ACPICA: Convert acpi_gbl_hardware lock back to an acpi_raw_spinlock
  ACPICA: provide abstraction for raw_spinlock_t
  ACPI / CPPC: Fix invalid PCC channel status errors
  ...
2018-06-05 10:08:27 -07:00
Christoph Hellwig e7b087fc6b acpi/battery: simplify procfs code
Use remove_proc_subtree to remove the whole subtree on cleanup, and
unwind the registration loop into individual calls.  Switch to use
proc_create_seq where applicable.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-16 07:24:30 +02:00
Carlo Caione ec625a37c1 ACPI / battery: Add quirk to avoid checking for PMIC with native driver
With commit dccfae6d4f (ACPI / battery: Add a blacklist with PMIC ACPI
HIDs with a native battery driver) a blacklist was introduced to avoid
using the ACPI drivers for the battery when a native PMIC driver was
already present. While this is in general a good idea (because of broken
DSDT or proprietary and undocumented ACPI opregions for the ACPI battery
devices) there are some Cherry Trail devices which use a separate FG
controller despite the AXP288 having a builtin FG.

The net effect of blacklisting the ACPI drivers is that on these devices
the battery reporting is broken since the AXP288 PMIC FG bits are not
actually used on this hardware.

This commit adds a battery_do_not_check_pmic quirk for this and sets
this on the 2 devices currently known to use a separate FG controller,
the ECS EF20EA and the Lenovo Ideapad Miix 320.

[hdegoede@redhat.com: Merge the quirk handling and the adding of the DMI
 table entry into 1 commit, add a second DMI entry for the Miix 320.]

Signed-off-by: Carlo Caione <carlo@endlessm.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-10 16:59:48 +02:00
Hans de Goede 1b799c5cf0 ACPI / battery: Ignore AC state in handle_discharging on systems where it is broken
On some devices the "AC" interface ACPI AML code uses the exact same broken
logic which is causing the battery code to wrongly report discharging to
determine the "AC" state. Specifically the ACPI AML code is checking the
charging status bits of the charger-IC rather then the vbus present or
power-good status bits.

This makes our workaround for devices which wrongly report discharging when
plugged into AC while the charge is above the start charging threshold not
work on these devices.

This commit adds a battery_ac_is_broken flag and when that is set it skips
the power_supply_is_system_supplied() check in the workaround fixing this.

This flag gets set by a DMI quirk selected by systems where we know the AC
AML code is broken in this way *and* the rate_now value can be trusted.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-02 13:06:59 +02:00
Hans de Goede 19fffc8450 ACPI / battery: Add handling for devices which wrongly report discharging state
On quite a few devices the battery code in the ACPI tables is buggy and
first checks the charging status bits of the charger-IC, and if those
report not charging it will report discharging, without looking at the
presence of AC power or at the battery dis(charge) current from the
fuel-gauge.

This causes the wrong status to be reported for the battery in the
following quite common scenario:

1) Plug in charger while battery is say half full, battery starts
charging, charging state bits indicate: pre-charge or fast-charge,
ACPI reported battery status is ok

2) When fully charged charging state bits indicate: end-of-charge,
ACPI reported battery status is ok

3) unplug the charger, wait 1 minute, replug. Now the battery voltage is
still above the start-charging threshold, so the charger will not start
charging to avoid wrecking the battery by repeatedly recharging the last 1%
capacity. The charger IC charging state bits now are all 0 (not-charging)
and the broken ACPI code wrongly translate this to "discharging" and ends
up setting the ACPI_BATTERY_STATE_DISCHARGING bit in its state field.

Reporting this "not charging" state as discharging is confusing for users,
making the user think his adapter/power-brick is broken or not properly
plugged in.

This commit adds a helper for handling the ACPI_BATTERY_STATE_DISCHARGING
state. This helper checks if we're an AC and the current going out of the
battery is 0 and in that case reports a status of "not charging" to
userspace rather then "discharging".

This replaces commit c68f0676ef ("ACPI / battery: Add quirk for Asus
GL502VSK and UX305LA"), a previous fix for this which was reverted.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Daniel Drake <drake@endlessm.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-02 13:06:59 +02:00
Hans de Goede 91afa07664 ACPI / battery: Remove initializer for unused ident dmi_system_id
The battery code does not use the dmi_system_id ident member, so there is
no need to initialize it. This saves us storing the unused strings as
as const data.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-02 13:06:59 +02:00
Rafael J. Wysocki 0c9ed61bdd Merge branches 'acpi-battery', 'acpi-doc' and 'acpi-pmic'
* acpi-battery:
  Revert "ACPI: battery: Add the ThinkPad "Not Charging" quirk"
  ACPI: battery: do not export degraded capacity values over 100
  ACPI: battery: make function __battery_hook_unregister() static
  ACPI: battery: Add the ThinkPad "Not Charging" quirk
  thinkpad_acpi: Add support for battery thresholds
  power: add to_power_supply macro to the API
  battery: Add the battery hooking API

* acpi-doc:
  ACPI: sysfs: Update device object sysfs documentation

* acpi-pmic:
  ACPI / PMIC: Replace license boilerplate with SPDX license identifier
2018-04-02 10:58:13 +02:00
Daniel Drake 82bf43b291 Revert "ACPI / battery: Add quirk for Asus GL502VSK and UX305LA"
Revert commit c68f0676ef ("ACPI / battery: Add quirk for Asus
GL502VSK and UX305LA") and commit 4446823e25 ("ACPI / battery: Add
quirk for Asus UX360UA and UX410UAK").

On many many Asus products, the battery is sometimes reported as
charging or discharging even when it is full and you are on AC power.
This change quirked the kernel to avoid advertising the discharging
state when this happens on 4 laptop models, under the belief that
this was incorrect information.  I presume it originates from user
reports who are confused that their battery status icon says that it
is discharging.

However, the reported information is indeed correct, and the quirk
approach taken is inadequate and more thought is needed first.
Specifically:

 1. It only quirks discharging state, not charging

 2. There are so many different Asus products and DMI naming variants
    within those product families that behave this way; Linux could
    grow to quirk hundreds of products and still not even be close at
    "winning" this battle.

 3. Asus previously clarified that this behaviour is intentional. The
    platform will periodically do a partial discharge/charge cycle
    when the battery is full, because this is one way to extend the
    lifetime of the battery (leaving a battery at 100% charge and
    unused will decrease its usable capacity over time).

    My understanding is that any decent consumer product will have
    this behaviour, but it appears that Asus is different in that
    they expose this info through ACPI.

    However, the behaviour seems correct. The ACPI spec does not
    suggest in that the platform should hide the truth.  It lets you
    report that the battery is full of charge, and discharging, and
    with external power connected; and Asus does this.

 4. In terms of not confusing the user, this seems like something that
    could/should be handled by userspace, which can also detect these
    same (accurate) conditions in the general case.

Revert this quirk before it gets included in a release, while we look
for better approaches.

Signed-off-by: Daniel Drake <drake@endlessm.com>
Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-19 10:08:39 +01:00
Rafael J. Wysocki 7a4ea10c01 Revert "ACPI: battery: Add the ThinkPad "Not Charging" quirk"
Revert commit 91eea70e5e (ACPI: battery: Add the ThinkPad "Not
Charging" quirk) as it is reported to cause user space to misbehave.

That appears to be due to bugs in user space, so this commit will go
in again after the bugs have been fixed and the fixes have been
delivered to users.

Link: https://marc.info/?l=linux-acpi&m=152089585129589&w=2
Reported-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-13 10:07:49 +01:00
Laszlo Toth a20136a67a ACPI: battery: do not export degraded capacity values over 100
With a degraded battery, full_charge_capacity can be less
than design_capacity, however it's not sure that capacity_now's
max will follow.

Example from an affected machine:
/sys/class/power_supply/BAT0/charge_full        -> 4290000
/sys/class/power_supply/BAT0/charge_full_design -> 5900000
/sys/class/power_supply/BAT0/charge_now         -> 5900000
/sys/class/power_supply/BAT0/capacity           -> 137

The battery is a degraded one with a full charge, and
charge_now is the value of charge_full_design instead of
charge_full.

Added a new quirk to test and correct this, and
a new function to check if the battery is a degraded one
or not. This keeps the possibility to be over 100 if
it's really the case.

Signed-off-by: Laszlo Toth <laszlth@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-02-27 17:17:11 +01:00
Colin Ian King 514bcc5dfa ACPI: battery: make function __battery_hook_unregister() static
The function __battery_hook_unregister is local to the source and does
not need to be in global scope, so make it static.

Cleans up sparse warning:
drivers/acpi/battery.c:654:6: warning: symbol '__battery_hook_unregister'
was not declared. Should it be static?

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-02-27 17:09:20 +01:00
Ognjen Galic 91eea70e5e ACPI: battery: Add the ThinkPad "Not Charging" quirk
The EC/ACPI firmware on Lenovo ThinkPads used to report a status
of "Unknown" when the battery is between the charge start and
charge stop thresholds. On Windows, it reports "Not Charging"
so the quirk has been added to also report correctly.

Now the "status" attribute returns "Not Charging" when the
battery on ThinkPads is not physicaly charging.

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Ognjen Galic <smclt30p@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-02-21 23:27:14 +01:00
Ognjen Galic fa93854f7a battery: Add the battery hooking API
This is a patch that implements a generic hooking API for the
generic ACPI battery driver.

With this new generic API, drivers can expose platform specific
behaviour via sysfs attributes in /sys/class/power_supply/BATn/
in a generic way.

A perfect example of the need for this API are Lenovo ThinkPads.

Lenovo ThinkPads have a ACPI extension that allows the setting of
start and stop charge thresholds in the EC and battery firmware
via ACPI. The thinkpad_acpi module can use this API to expose
sysfs attributes that it controls inside the ACPI battery driver
sysfs tree, under /sys/class/power_supply/BATN/.

The file drivers/acpi/battery.h has been moved to
include/acpi/battery.h and the includes inside ac.c, sbs.c, and
battery.c have been adjusted to reflect that.

When drivers hooks into the API, the API calls add_battery() for
each battery in the system that passes it a acpi_battery
struct. Then, the drivers can use device_create_file() to create
new sysfs attributes with that struct and identify the batteries
for per-battery attributes.

Signed-off-by: Ognjen Galic <smclt30p@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-02-21 23:27:13 +01:00
Kai Heng Feng 4446823e25 ACPI / battery: Add quirk for Asus UX360UA and UX410UAK
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>
2018-02-04 09:17:47 +01:00
Kai-Heng Feng c68f0676ef ACPI / battery: Add quirk for Asus GL502VSK and UX305LA
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-18 12:25:51 +01:00
Bjørn Mork 6993ce46c9 ACPI: battery: Drop redundant test for failure
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-12-13 01:14:54 +01:00
Bhumika Goyal 82d2b61058 ACPI: make device_attribute const
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-08-24 03:38:25 +02:00
Rafael J. Wysocki 33e4f80ee6 ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle
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-15 00:55:44 +02:00
Rafael J. Wysocki fbd78afe34 Merge branches 'intel_pstate' and 'pm-sleep'
* 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-09 01:25:16 +02:00
Rafael J. Wysocki f3b7eaae1b Revert "ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle"
Revert commit eed4d47efe (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-06-07 00:57:37 +02:00
Rafael J. Wysocki 80449d89d4 Merge branches 'pm-domains', 'pm-cpuidle', 'pm-sleep' and 'powercap'
* 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-09 23:21:46 +02:00
Rafael J. Wysocki eed4d47efe ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle
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-05-05 22:54:28 +02:00
Hans de Goede dccfae6d4f ACPI / battery: Add a blacklist with PMIC ACPI HIDs with a native battery driver
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-19 22:53:35 +02:00
Hans de Goede bc39fbcf9c ACPI / battery: Fix acpi_battery_exit on acpi_battery_init_async errors
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>
2017-04-19 22:53:35 +02:00
Linus Torvalds 7c0f6ba682 Replace <asm/uaccess.h> with <linux/uaccess.h> globally
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-12-24 11:46:01 -08:00
Dave Lambley 2d09af4a88 ACPI / battery: If _BIX fails, retry with _BIF
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-11-16 23:09:45 +01:00
Carlos Garnacho 12c78ca2ab ACPI / battery: Add sysfs representation after checking _BST
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-08-31 00:35:16 +02:00
Chris Wilson 5dfa0c7395 ACPI / battery: Correctly serialise with the pending async probe
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>
2016-05-21 01:25:07 +02:00
Jarkko Nikula 4c62dbbce9 ACPI: Remove FSF mailing addresses
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-07-08 02:27:32 +02:00
Mathias Krause 048d16da75 ACPI / battery: mark DMI table as __initconst
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-15 14:23:44 +02:00
Mathias Krause 27059b9132 ACPI / battery: minor tweaks to acpi_battery_units()
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-15 14:23:06 +02:00
Mathias Krause a465878455 ACPI / battery: constify the offset tables
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-06-15 14:21:22 +02:00
Luis Henriques eca21d9167 ACPI / battery: ensure acpi_battery_init() has finish
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-14 00:58:40 +02:00
Luis Henriques 479faaf00f ACPI / battery: drop useless return statements
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-05-14 00:58:40 +02:00
Luis Henriques e234b074c8 ACPI / battery: abort initialization earlier if acpi_disabled
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-05-14 00:58:39 +02:00
Linus Torvalds 2481bc7528 Power management and ACPI updates for v4.1-rc1
- 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).
 
 /
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.22 (GNU/Linux)
 
 iQIcBAABCAAGBQJVLbO+AAoJEILEb/54YlRx5N4QAJXsmEW1FL2l6mMAyTQkEsVj
 nbqjF9I6aJgYM9+i8GKaZJxpN17SAZ7Ii7aCAXjPwX8AvjT70+gcZr+KDWtPir61
 B75VNVEcUYOR4vOF5Z6rQcQMlhGPkfMOJYXFMahpOG6DdPbVh1x2/tuawfc6IC0V
 a6S/fln6WqHrXQ+8swDSv1KuZsav6+8AQaTlNUQkkuXdY9b3k/3xiy5C2K26APP8
 x1B39iAF810qX6ipnK0gEOC3Vs29dl7hvNmgOVmmkBGVS7+pqTuy5n1/9M12cDRz
 78IQ7DXB0NcSwr5tdrmGVUyH0Q6H9lnD3vO7MJkYwKDh5a/2MiBr2GZc4KHDKDWn
 E1sS27f1Pdn9qnpWLzTcY+yYNV3EEyre56L2fc+sh+Xq9sNOjUah+Y/eAej/IxYD
 XYRf+GAj768yCJgNP+Y3PJES/PRh+0IZ/dn5k0Qq2iYvc8mcObyG6zdQIvCucv/i
 70uV1Z2GWEb31cI9TUV8o5GrMW3D0KI9EsCEEpiFFUnhjNog3AWcerGgFQMHxu7X
 ZnNSzudvek+XJ3NtpbPgTiJAmnMz8bDvBQm3G1LUO2TQdjYTU6YMUHsfzXs8DL6c
 aIMWO4stkVuDtWrlT/hfzIXepliccyXmSP6sbH+zNNCepulXe5C4M2SftaDi4l/B
 uIctXWznvHoGys+EFL+v
 =erd3
 -----END PGP SIGNATURE-----

Merge tag 'pm+acpi-4.1-rc1' of 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-14 20:21:54 -07:00
Krzysztof Kozlowski 31f7dc7969 ACPI / battery: Fix doubly added battery on system suspend
Commit 297d716f62 ("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-04-14 09:03:33 -07:00
Martin Kepplinger 9237516c1b ACPI / battery: make warning greppable
Signed-off-by: Martin Kepplinger <martink@posteo.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-18 02:08:56 +01:00
Krzysztof Kozlowski 297d716f62 power_supply: Change ownership from driver to core
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-13 23:15:51 +01:00
Krzysztof Kozlowski 2dc9215d7c power_supply: Move run-time configuration to separate structure
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>
2015-03-13 23:15:12 +01:00
Lan Tianyu 40e7fcb192 ACPI: Add _DEP support to fix battery issue on Asus T100TA
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-11-24 01:04:55 +01:00
Rasmus Villemoes ffd8a731d9 ACPI / battery: Replace strnicmp with strncasecmp
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-24 23:26:32 +02:00
Bjørn Mork 508b3c6776 Revert "ACPI / battery: fix wrong value of capacity_now reported when fully charged"
This reverts commit 232de51437 ("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: 232de51437 ("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-09 16:20:12 +02:00
Bjørn Mork 583ee394ac Revert "ACPI / battery: Fix warning message in acpi_battery_get_state()"
This reverts commit d719870b41 ("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: d719870b41 ("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-09-09 16:19:03 +02:00
Mariusz Ceier d719870b41 ACPI / battery: Fix warning message in acpi_battery_get_state()
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: 232de51437 (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-08-10 16:19:31 +02:00
Wei Yongjun 3a54a57dce ACPI / battery: remove duplicated include from battery.c
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-30 02:02:12 +02:00
Josef Gajdusek 232de51437 ACPI / battery: fix wrong value of capacity_now reported when fully charged
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-07 23:37:06 +02:00
Lan Tianyu 75646e758a ACPI / battery: Retry to get battery information if failed during probing
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-07-07 13:39:00 +02:00
Rafael J. Wysocki cf8116c491 Merge branches 'acpi-general', 'acpi-processor', 'acpi-lpss' and 'acpi-battery'
* 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-19 14:40:48 +02:00