Add newline to printk so that the message is on a line
by itself and not merged with something unrelated to it.
Reported-by: NToralf Förster <toralf.foerster@gmx.de>
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

There is a seemingly useless check in drivers/acpi/osl.c added by
commit bc73675b (ACPI: fixes a false alarm from lockdep), which really
is necessary to avoid false positive lockdep complaints.  Document
this and rearrange the code related to it so that it makes fewer
checks.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>

Added support of CPU hot-remove via an ACPI eject notification.
It calls acpi_bus_hot_remove_device(), which shares the same code
path with the sysfs eject operation.  acpi_os_hotplug_execute()
runs the hot-remove operation in kacpi_hotplug_wq and serializes
it between ACPI hot-remove and sysfs eject requests.
Signed-off-by: NToshi Kani <toshi.kani@hp.com>
Reviewed-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Tested-by: NIgorMammedov <imammedo@redhat.com>
Tested-by: NVijay Mohan Pandarathil <vijaymohan.pandarathil@hp.com>
Tested-by: NPrarit Bhargava <prarit@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Exported acpi_os_hotplug_execute() and acpi_bus_hot_remove_device()
so that they can be called from modules for hot-remove operations.
Signed-off-by: NToshi Kani <toshi.kani@hp.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI devices are glued with physical devices through _ADR object, ACPI
enumerated devices are identified with _UID object.  Currently we can
observe _HID/_CID through sysfs interfaces (hid/modalias), but there's
no way for us to check _ADR/_UID from user space.  This patch closes
this gap for ACPI developers and users.

[rjw: Modified the subject and changelog slightly.]
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The _UID object is optional, but is required when the device has no
other way to report a persistent unique device ID.
This patch is required for ACPI 5.0 ACPI enumerated IP cores.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRui Zhang <rui.zhang@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The ACPI specificiation would like us to save NVS at hibernation time,
but makes no mention of saving NVS over S3.  Not all versions of
Windows do this either, and it is clear that not all machines need NVS
saved/restored over S3.  Allow the user to improve their suspend/resume
time by disabling the NVS save/restore at S3 time, but continue to do
the NVS save/restore for S4 as specified.
Signed-off-by: NKristen Carlson Accardi <kristen@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Removed lockable in struct acpi_device_flags since it is no
longer used by any code. acpi_bus_hot_remove_device() cannot
use this flag because acpi_bus_trim() frees up its acpi_device
object. Furthermore, the dock driver calls _LCK method without
using this lockable flag.
Signed-off-by: NToshi Kani <toshi.kani@hp.com>
Reviewed-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

During hot-remove, acpi_bus_hot_remove_device() calls ACPI _LCK
method when device->flags.lockable is set. However, this device
pointer is stale since the target acpi_device object has been
already kfree'd by acpi_bus_trim().

The flags.lockable indicates whether or not this ACPI object
implements _LCK method. Fix the stable pointer access by replacing
it with acpi_get_handle() to check if _LCK is implemented.
Signed-off-by: NToshi Kani <toshi.kani@hp.com>
Reviewed-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

"ACPI0004","PNP0A05" and "PNP0A06" are all defined in array
container_device_ids[], so use it, but not the hard coding style.

Also, introduce a new API is_container_device() to determine if a
device is a container device.
Signed-off-by: NTang Chen <tangchen@cn.fujitsu.com>
Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Even if acpi_processor_handle_eject() offlines cpu, there is a chance
to online the cpu after that. So the patch closes the window by using
get/put_online_cpus().

Why does the patch change _cpu_up() logic?

The patch cares the race of hot-remove cpu and _cpu_up(). If the patch
does not change it, there is the following race.

hot-remove cpu                         |  _cpu_up()
------------------------------------- ------------------------------------
call acpi_processor_handle_eject()     |
     call cpu_down()                   |
     call get_online_cpus()            |
                                       | call cpu_hotplug_begin() and stop here
     call arch_unregister_cpu()        |
     call acpi_unmap_lsapic()          |
     call put_online_cpus()            |
                                       | start and continue _cpu_up()
     return acpi_processor_remove()    |
continue hot-remove the cpu            |

So _cpu_up() can continue to itself. And hot-remove cpu can also continue
itself. If the patch changes _cpu_up() logic, the race disappears as below:

hot-remove cpu                         | _cpu_up()
-----------------------------------------------------------------------
call acpi_processor_handle_eject()     |
     call cpu_down()                   |
     call get_online_cpus()            |
                                       | call cpu_hotplug_begin() and stop here
     call arch_unregister_cpu()        |
     call acpi_unmap_lsapic()          |
          cpu's cpu_present is set     |
          to false by set_cpu_present()|
     call put_online_cpus()            |
                                       | start _cpu_up()
                                       | check cpu_present() and return -EINVAL
     return acpi_processor_remove()    |
continue hot-remove the cpu            |
Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Reviewed-by: NToshi Kani <toshi.kani@hp.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Replace a few calls to strict_strtoul() in acpi_pad.c with kstrtoul()
and use pr_warn() instead of printk() in the same file.

[rjw: Modified the subject and changelog.]
Signed-off-by: NJosh Taylor <joshua.taylor0@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Combined two ACPI namespace walks, which look for dock stations
and then bays separately, into a single walk.
Signed-off-by: NToshi Kani <toshi.kani@hp.com>
Reviewed-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Currently when advance_transaction() is called in EC interrupt handler,
if there is nothing driver can do with the interrupt, it will be taken
as a false one.

But this is not always true, as there may be a SCI EC interrupt fired
during normal read/write operation, which should not be counted as a
false one. This patch fixes the problem.
Signed-off-by: NFeng Tang <feng.tang@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add more debug info for EC transaction debugging, like the interrupt
status register value, the detail info of a EC transaction.
Signed-off-by: NFeng Tang <feng.tang@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Current member names for mutex/spinlock are a little confusing.

Change the
{
	struct mutex lock;
	spinlock_t curr_lock;
}
to
{
	struct mutex mutex;
	spinlock_t lock;
}

So that the code is cleaner and easier to read.
Signed-off-by: NFeng Tang <feng.tang@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

There are systems where video module known to work fine regardless
of broken _DOD and ignoring returned value here doesn't cause
any issues later. This should fix brightness controls on some laptops.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47861Signed-off-by: NIgor Murzov <e-mail@date.by>
Reviewed-by: NSergey V <sftp.mtuci@gmail.com>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>

We handle NOTIFY_THROTTLING so don't then fall through to unsupported event.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Memory is allocated with kzalloc() and assigned to
'physical_node'. Then 'physical_node->node_id' is initialized with a
call to 'find_first_zero_bit()', if that results in a value greater
than ACPI_MAX_PHYSICAL_NODE we'll end up jumping to the 'err:' label
and there leave the function and let 'physical_node' go out of scope
and leak the memory we allocated.
This patch fixes the leak by simply freeing the unused/unneeded memory
pointed to by 'physical_node' just before we jump to 'err:'.

[rjw: The problem has been introduced by commit 1033f904 (ACPI: Allow
 ACPI binding with USB-3.0 hub), which is new in 3.7-rc.]
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Reviewed-by: NToshi Kani <toshi.kani@hp.com>
Reviewed-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Acked-by: NDavid Rientjes <rientjes@google.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Drivers may make calls that require the ACPI IPMI driver to have been
initialised already, so make sure that it appears earlier in the build
order.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The dereference should be moved below the NULL test.

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NLen Brown <len.brown@intel.com>

Add support to export the device description obtained from the ACPI _STR
method, if one exists for a device, to user-space via a sysfs interface.
This new interface provides a standard and platform neutral way for users
to obtain the description text stored in the ACPI _STR method.  If no
_STR method exists for the device, no sysfs 'description' file will be
created.  The 'description' file will be located in the /sys/devices/
directory using the device's path.

/sys/device/<bus>/<bridge path>/<device path>.../firmware_node/description

Example:

/sys/devices/pci0000:00/0000:00.07.0/0000:0e:00.0/firmware_node/description

It can also be located using the ACPI device path, for example:

/sys/devices/LNXSYSTM:00/device:00/ACPI0004:00/PNP0A08:00/device:13/device:15/description
/sys/devices/LNXSYSTM:00/device:00/ACPI0004:00/ACPI0004:01/ACPI0007:02/description

Execute the 'cat' command on the 'description' file to obtain the
description string for that device.

This patch also includes documentation describing how the new sysfs
interface works

Changes from v1-v2 based on comments by Len Brown and Fengguang Wu
* Removed output "No Description" and leaving a NULL attribute if the
_STR method failed to evaluate.

* In acpi_device_remove_files() removed the redundent check of
dev->pnp.str_obj before calling free.  This check triggered a message
from smatch.
Signed-off-by: NLance Ortiz <lance.ortiz@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Parsing acpi table entries may fall into an infinite loop on a buggy BIOS
which has entry length=0 in acpi table.

Instead of kernel hang with few failure clue which leads to heavy lifting debug
effort, this patch hardens kernel boot by booting into non NUMA mode. The debug
info left in log buffer helps people identify the issue.
Signed-off-by: NFenghua Yu <fenghua.yu@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

By enlarging the GPE storm threshold back to 20, that laptop's
EC works fine with interrupt mode instead of polling mode.

https://bugzilla.kernel.org/show_bug.cgi?id=45151Reported-and-Tested-by: NFrancesco <trentini@dei.unipd.it>
Signed-off-by: NFeng Tang <feng.tang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>
cc: stable@vger.kernel.org

The Linux EC driver includes a mechanism to detect GPE storms,
and switch from interrupt-mode to polling mode.  However, polling
mode sometimes doesn't work, so the workaround is problematic.
Also, different systems seem to need the threshold for detecting
the GPE storm at different levels.

ACPI_EC_STORM_THRESHOLD was initially 20 when it's created, and
was changed to 8 in 2.6.28 commit 06cf7d3c "ACPI: EC: lower interrupt storm
threshold" to fix kernel bug 11892 by forcing the laptop in that bug to
work in polling mode. However in bug 45151, it works fine in interrupt
mode if we lift the threshold back to 20.

This patch makes the threshold a module parameter so that user has a
flexible option to debug/workaround this issue.

The default is unchanged.

This is also a preparation patch to fix specific systems:
	https://bugzilla.kernel.org/show_bug.cgi?id=45151Signed-off-by: NFeng Tang <feng.tang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>
cc: stable@vger.kernel.org

The ACPI BGRT driver accesses the BIOS logo image when it initializes.
However, ACPI 5.0 (which introduces the BGRT) recommends putting the
logo image in EFI boot services memory, so that the OS can reclaim that
memory.  Production systems follow this recommendation, breaking the
ACPI BGRT driver.

Move the bulk of the BGRT code to run during a new EFI late
initialization phase, which occurs after switching EFI to virtual mode,
and after initializing ACPI, but before freeing boot services memory.
Copy the BIOS logo image to kernel memory at that point, and make it
accessible to the BGRT driver.  Rework the existing ACPI BGRT driver to
act as a simple wrapper exposing that image (and the properties from the
BGRT) via sysfs.
Signed-off-by: NJosh Triplett <josh@joshtriplett.org>
Link: http://lkml.kernel.org/r/93ce9f823f1c1f3bb88bdd662cce08eee7a17f5d.1348876882.git.josh@joshtriplett.orgSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>

The _OSC method may exist in module level code,
so it must be called after ACPI_FULL_INITIALIZATION

On some new platforms with Zero-Power-Optical-Disk-Drive (ZPODD)
support, this fix is necessary to save power.
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Tested-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>
Cc: stable@vger.kernel.org

This patch changes the implementation of acpi_pci_find_root().

We can access acpi_pci_root without scanning acpi_pci_roots list.
If hostbridge hotplug is supported, acpi_pci_roots list will be
protected by mutex.  We should not access acpi_pci_roots list
if preventable to lessen deadlock risk.
Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Use mutex to protect acpi_pci_roots list against PCI host bridge
hotplug operations.

[bhelgaas: s/struct acpi_handle *handle/acpi_handle handle/]
Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

This patch changes the function signature of walk_root_bridge().

We can omit _STA, _SEG, and _BBN evaluation by passing not acpi_handle
but acpi_pci_root.  Now that acpi_pci_slot_add() which is the only
caller of walk_root_bridge() gets acpi_pci_root structure, changing
signature of walk_root_bridge() is reasonable.

[bhelgaas: changelog]
Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

This patch changes .add/.remove interfaces of acpi_pci_driver.
In the current implementation acpi_handle is passed as a parameter
of .add/.remove interface.  However, the acpi_pci_root structure
contains more useful information than just the acpi_handle.  This
enables us to avoid some useless lookups in each acpi_pci_driver.

Note: This changes interfaces used by acpi_pci_register_driver(), an
exported symbol.  This patch updates all the in-kernel users, but any
out-of-kernel acpi_pci_register_driver() users will need updates.

[bhelgaas: changelog]
Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Use mutex to protect global acpi_pci_drivers list against PCI
host bridge hotplug operations.
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

When hot-plugging PCI root bridge, acpi_pci_drivers' add()/remove()
methods should be invoked to notify registered drivers.
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Use normal list for struct acpi_pci_driver to simplify code.
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

This function is used to update the cooling state of
all the cooling devices that are bound to an active trip point.

This will be used for passive cooling as well, in the future patches.
as both active and passive cooling can share the same algorithm,
which is

1. if the temperature is higher than a trip point,
   a. if the trend is THERMAL_TREND_RAISING, use higher cooling
      state for this trip point
   b. if the trend is THERMAL_TREND_DROPPING, use lower cooling
      state for this trip point

2. if the temperature is lower than a trip point, use lower
   cooling state for this trip point.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Reviewed-by: NRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: NEduardo Valentin <eduardo.valentin@ti.com>

Remove tc1/tc2 in generic thermal layer.
.get_trend() callback starts to take effect from this patch.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Reviewed-by: NRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: NValentin, Eduardo <eduardo.valentin@ti.com>

According to ACPI spec, tc1 and tc2 are used by OSPM
to anticipate the temperature trends.
We introduced the same concept to the generic thermal layer
for passive cooling, but now it seems that these values
are hard to be used on other platforms.

So We introduce .get_trend() as a more general solution.

For the platform thermal drivers that have their own way to
anticipate the temperature trends, they should provide
their own .get_trend() callback.
Or else, we will calculate the temperature trends by simply
comparing the current temperature and the cached previous
temperature reading.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Reviewed-by: NRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: NValentin, Eduardo <eduardo.valentin@ti.com>

set upper and lower limits when binding
a thermal cooling device to a thermal zone device.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Reviewed-by: NRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: NEduardo Valentin <eduardo.valentin@ti.com>

Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>