The ECDT of ASUSTEK L4R doesn't provide correct command and data
I/O ports.  The DSDT provides the correct information instead.

For this reason, add this machine to quirk list for ECDT validation
and use the EC information from the DSDT.

[rjw: Changelog]
References: https://bugzilla.kernel.org/show_bug.cgi?id=60765Reported-and-tested-by: NDaniele Esposti <expo@expobrain.net>
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Cc: All <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Some machines don't provide _TZD, so check the availability of it
before carrying out futher operations.

If _TZD is present, also check the result of its evaluation.

[rjw: Changelog]
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The macro INVALID_TABLE() is defined like this:

 #define INVALID_TABLE(x, path, name)                                    \
         { pr_err("ACPI OVERRIDE: " x " [%s%s]\n", path, name); continue; }

And it is used like this:

	for (...) {
		...
		if (...)
			INVALID_TABLE()
		...
	}

The "continue" in the macro makes the code hard to understand.

And also, this macro is only used several times in a single file.
As suggested by Joe Perches <joe@perches.com>, we can remote it and
use pr_err directly.

So after this patch, this macro is removed, and pr_err() is used
like this:

	for (...) {
		...
		if (...) {
			pr_err("ACPI OVERRIDE: ......");
			continue;
		}
		...
	}
Signed-off-by: NTang Chen <tangchen@cn.fujitsu.com>
Suggested-by: NJoe Perches <joe@perches.com>
Acked-by: NTejun Heo <tj@kernel.org>
Acked-by: NToshi Kani <toshi.kani@hp.com>
Reviewed-by: NZhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

It's unreadable to pass "-1" as trip parameter directly to
thermal_zone_bind_cooling_device().  Use THERMAL_TRIPS_NONE instead.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Acked-by: NZhang Rui <rui.zhang@intel.com>
Acked-by: NDurgadoss R <durgadoss.r@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The ACPI_THERMAL_FILE* macros are not used now, so remove them.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Acked-by: NZhang Rui <rui.zhang@intel.com>
Acked-by: NDurgadoss R <durgadoss.r@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The acpi_thermal->lock now just is initialized when a thermal zone
device is added and destroyed when the thermal zone is removed.
It is never used in any other places, so remove it.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Acked-by: NZhang Rui <rui.zhang@intel.com>
Acked-by: NDurgadoss R <durgadoss.r@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

__initdata should come after the variable name being declared and
nowhere else, in this way the variable will be placed in the
intended section.
Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

__init belongs after the return type on functions, not before it.
Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

__init belongs after the return type on functions, not before it.
Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

__initdata should be placed between the variable name and equal
sign for the variable to be placed in the intended section.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

__initdata should be placed between the variable name and equal
sign for the variable to be placed in the intended section.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

__initdata should be placed between the variable name and equal
sign for the variable to be placed in the intended section.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

In theory, under a given ACPI namespace node there should be only
one child device object with _ADR whose value matches a given bus
address exactly.  In practice, however, there are systems in which
multiple child device objects under a given parent have _ADR matching
exactly the same address.  In those cases we use _STA to determine
which of the multiple matching devices is enabled, since some systems
are known to indicate which ACPI device object to associate with the
given physical (usually PCI) device this way.

Unfortunately, as it turns out, there are systems in which many
device objects under the same parent have _ADR matching exactly the
same bus address and none of them has _STA, in which case they all
should be regarded as enabled according to the spec.  Still, if
those device objects are supposed to represent bridges (e.g. this
is the case for device objects corresponding to PCIe ports), we can
try harder and skip the ones that have no child device objects in the
ACPI namespace.  With luck, we can avoid using device objects that we
are not expected to use this way.

Although this only works for bridges whose children also have ACPI
namespace representation, it is sufficient to address graphics
adapter detection issues on some systems, so rework the code finding
a matching device ACPI handle for a given bus address to implement
this idea.

Introduce a new function, acpi_find_child(), taking three arguments:
the ACPI handle of the device's parent, a bus address suitable for
the device's bus type and a bool indicating if the device is a
bridge and make it work as outlined above.  Reimplement the function
currently used for this purpose, acpi_get_child(), as a call to
acpi_find_child() with the last argument set to 'false' and make
the PCI subsystem use acpi_find_child() with the bridge information
passed as the last argument to it.  [Lan Tianyu notices that it is
not sufficient to use pci_is_bridge() for that, because the device's
subordinate pointer hasn't been set yet at this point, so use
hdr_type instead.]

This change fixes a regression introduced inadvertently by commit
33f767d7 (ACPI: Rework acpi_get_child() to be more efficient) which
overlooked the fact that for acpi_walk_namespace() "post-order" means
"after all children have been visited" rather than "on the way back",
so for device objects without children and for namespace walks of
depth 1, as in the acpi_get_child() case, the "post-order" callbacks
ordering is actually the same as the ordering of "pre-order" ones.
Since that commit changed the namespace walk in acpi_get_child() to
terminate after finding the first matching object instead of going
through all of them and returning the last one, it effectively
changed the result returned by that function in some rare cases and
that led to problems (the switch from a "pre-order" to a "post-order"
callback was supposed to prevent that from happening, but it was
ineffective).

As it turns out, the systems where the change made by commit
33f767d7 actually matters are those where there are multiple ACPI
device objects representing the same PCIe port (which effectively
is a bridge).  Moreover, only one of them, and the one we are
expected to use, has child device objects in the ACPI namespace,
so the regression can be addressed as described above.

References: https://bugzilla.kernel.org/show_bug.cgi?id=60561Reported-by: NPeter Wu <lekensteyn@gmail.com>
Tested-by: NVladimir Lalov <mail@vlalov.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: 3.9+ <stable@vger.kernel.org> # 3.9+

try_offline_node() checks that all CPUs associated with the given
node have been removed by using cpu_present_bits.  If all cpus
related to that node have been removed, try_offline_node() clears
the node information.

However, try_offline_node() called from acpi_processor_remove() never
clears the node information.  For disabling cpu_present_bits,
acpi_unmap_lsapic() needs be called.  Yet, acpi_unmap_lsapic() is
called after try_offline_node() has run.  So when try_offline_node()
runs, the CPU's cpu_present_bits is always set.

Fix the issue by moving try_offline_node() after acpi_unmap_lsapic().

The problem fixed here was uncovered by commit cecdb193 "ACPI / scan:
Change the implementation of acpi_bus_trim()".

[rjw: Changelog]
Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Acked-by: NToshi Kani <toshi.kani@hp.com>
Cc: 3.9+ <stable@vger.kernel.org> # 3.9+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The create_dev label in acpi_create_platform_device() is not
necessary, because the if statement causing the jump to it to
happen may be rearranged to avoid that jump.

Rework the code accordingly (no functional changes should result
drom that).
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The physical_node_id_bitmap in struct acpi_device is only used for
looking up the first currently unused dependent phyiscal node ID
by acpi_bind_one().  It is not really necessary, however, because
acpi_bind_one() walks the entire physical_node_list of the given
device object for sanity checking anyway and if that list is always
sorted by node_id, it is straightforward to find the first gap
between the currently used node IDs and use that number as the ID
of the new list node.

This also removes the artificial limit of the maximum number of
dependent physical devices per ACPI device object, which now depends
only on the capacity of unsigend int.  As a result, it fixes a
regression introduced by commit e2ff3940 (ACPI / memhotplug: Bind
removable memory blocks to ACPI device nodes) that caused
acpi_memory_enable_device() to fail when the number of 128 MB blocks
within one removable memory module was greater than 32.
Reported-and-tested-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NToshi Kani <toshi.kani@hp.com>
Reviewed-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>

Move acpi_bus_get_device() from bus.c to scan.c which allows
acpi_bus_data_handler() to become static and clean up the latter.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Currently, ACPI platform device creation is aborted when there
are no valid IO resources for the device.  This approach will not
work if the device has only GPIO as its resource or some custom
resources.

Remove zero resource check and allow platform device creation even
without any valid IO resources.

[rjw: Changelog]
Signed-off-by: NKuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The list of physical devices corresponding to an ACPI device
object is walked by acpi_system_wakeup_device_seq_show() and
physical_device_enable_wakeup() without taking that object's
physical_node_lock mutex.  Since each of those functions may be
run at any time as a result of a user space action, the lack of
appropriate locking in them may lead to a kernel crash if that
happens during device hot-add or hot-remove involving the device
object in question.

Fix the issue by modifying acpi_system_wakeup_device_seq_show() and
physical_device_enable_wakeup() to use physical_node_lock as
appropriate.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: All <stable@vger.kernel.org>

If the _BCL package ordering is descending, the first level
(br->levels[2]) is likely to be 0, and if the number of levels
matches the number of steps, we might confuse a returned level to
mean the index.

For example:

  current_level = max_level = 100
  test_level = 0
  returned level = 100

In this case 100 means the level, not the index, and _BCM failed.
Still, if the _BCL package ordering is descending, the index of
level 0 is also 100, so we assume _BQC is indexed, when it's not.

This causes all _BQC calls to return bogus values causing weird
behavior from the user's perspective.  For example:

xbacklight -set 10; xbacklight -set 20;

would flash to 90% and then slowly down to the desired level (20).

The solution is simple; test anything other than the first level
(e.g. 1).

[rjw: Changelog]
Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The _BIX method returns extended battery info as a package.
According the ACPI spec (ACPI 5, Section 10.2.2.2), the first member
of that package should be "Revision".  However, the current ACPI
battery driver treats the first member as "Power Unit" which should
be the second member.  This causes the result of _BIX return data
parsing to be incorrect.

Fix this by adding a new member called 'revision' to struct
acpi_battery and adding the offsetof() information on it to
extended_info_offsets[] as the first row.

[rjw: Changelog]
Reported-and-tested-by: NJan Hoffmann <jan.christian.hoffmann@gmail.com>
References: http://bugzilla.kernel.org/show_bug.cgi?id=60519Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Cc: 2.6.34+ <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

We attempted to address a regression introduced by commit a57f7f91
(ACPICA: Add Windows8/Server2012 string for _OSI method.) after which
ACPI video backlight support doesn't work on a number of systems,
because the relevant AML methods in the ACPI tables in their BIOSes
become useless after the BIOS has been told that the OS is compatible
with Windows 8.  That problem is tracked by the bug entry at:

https://bugzilla.kernel.org/show_bug.cgi?id=51231

Commit 8c5bd7ad (ACPI / video / i915: No ACPI backlight if firmware
expects Windows 8) introduced for this purpose essentially prevented
the ACPI backlight support from being used if the BIOS had been told
that the OS was compatible with Windows 8 and the i915 driver was
loaded, in which case the backlight would always be handled by i915.
Unfortunately, however, that turned out to cause problems with
backlight to appear on multiple systems with symptoms indicating that
i915 was unable to control the backlight on those systems as
expected.

For this reason, revert commit 8c5bd7ad, but leave the function
acpi_video_backlight_quirks() introduced by it, because another
commit on top of it uses that function.

References: https://lkml.org/lkml/2013/7/21/119
References: https://lkml.org/lkml/2013/7/22/261
References: https://lkml.org/lkml/2013/7/23/429
References: https://lkml.org/lkml/2013/7/23/459
References: https://lkml.org/lkml/2013/7/23/81
References: https://lkml.org/lkml/2013/7/24/27Reported-and-tested-by: NJames Hogan <james@albanarts.com>
Reported-and-tested-by: NKamal Mostafa <kamal@canonical.com>
Reported-and-tested-by: NJörg Otte <jrg.otte@gmail.com>
Reported-and-tested-by: NSteven Newbury <steve@snewbury.org.uk>
Reported-by: NMartin Steigerwald <Martin@lichtvoll.de>
Reported-by: NKalle Valo <kvalo@adurom.com>
Tested-by: NJoerg Platte <jplatte@naasa.net>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This patch cleans up the following sparse warning:

# make C=2 drivers/acpi/osl.o
...
drivers/acpi/osl.c:1775:20: warning: symbol 'acpi_os_initialize1' was not declared. Should it be static?
...
  CC      drivers/acpi/osl.o
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The BIOS of FUjitsu E753 reports an incorrect initial backlight value
for WIN8 compatible OS, causing backlight to be dark during startup.
This change causes the incorrect initial value from BIOS to be ignored.

References: https://bugzilla.kernel.org/show_bug.cgi?id=60161Reported-and-tested-by: NJan Hinnerk Stosch <janhinnerk.stosch@gmail.com>
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Cc: 3.7+ <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Starting from win8, MS backlight control driver will set bit 2 of the
parameter of control method _DOS, to inform firmware it should not
perform any automatic brightness changes. This mostly affects hotkey
notification deliver - if we do not set this bit, on hotkey press,
firmware may choose to adjust brightness level instead of sending out
notification and doing nothing.

So this patch sets bit 2 when calling _DOS so that GUIs can show the
notification window on hotkey press.  This behavior change is only
necessary for win8 systems.

The MS document on win8 backlight control is here:
http://msdn.microsoft.com/en-US/library/windows/hardware/jj159305

References: https://bugzilla.kernel.org/show_bug.cgi?id=52951
References: https://bugzilla.kernel.org/show_bug.cgi?id=56711Reported-by: NMicael Dias <kam1kaz3@gmail.com>
Reported-by: NDan Garton <dan.garton@gmail.com>
Reported-by: NBob Ziuchkovski <bob.ziuchkovski@gmail.com>
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

According to Matthew Garrett, "Windows 8 leaves backlight control up
to individual graphics drivers rather than making ACPI calls itself.
There's plenty of evidence to suggest that the Intel driver for
Windows [8] doesn't use the ACPI interface, including the fact that
it's broken on a bunch of machines when the OS claims to support
Windows 8.  The simplest thing to do appears to be to disable the
ACPI backlight interface on these systems".

There's a problem with that approach, however, because simply
avoiding to register the ACPI backlight interface if the firmware
calls _OSI for Windows 8 may not work in the following situations:
 (1) The ACPI backlight interface actually works on the given system
     and the i915 driver is not loaded (e.g. another graphics driver
     is used).
 (2) The ACPI backlight interface doesn't work on the given system,
     but there is a vendor platform driver that will register its
     own, equally broken, backlight interface if not prevented from
     doing so by the ACPI subsystem.
Therefore we need to allow the ACPI backlight interface to be
registered until the i915 driver is loaded which then will unregister
it if the firmware has called _OSI for Windows 8 (or will register
the ACPI video driver without backlight support if not already
present).

For this reason, introduce an alternative function for registering
ACPI video, acpi_video_register_with_quirks(), that will check
whether or not the ACPI video driver has already been registered
and whether or not the backlight Windows 8 quirk has to be applied.
If the quirk has to be applied, it will block the ACPI backlight
support and either unregister the backlight interface if the ACPI
video driver has already been registered, or register the ACPI
video driver without the backlight interface otherwise.  Make
the i915 driver use acpi_video_register_with_quirks() instead of
acpi_video_register() in i915_driver_load().

This change is based on earlier patches from Matthew Garrett,
Chun-Yi Lee and Seth Forshee and includes a fix from Aaron Lu's.

References: https://bugzilla.kernel.org/show_bug.cgi?id=51231Tested-by: NAaron Lu <aaron.lu@intel.com>
Tested-by: NIgor Gnatenko <i.gnatenko.brain@gmail.com>
Tested-by: NYves-Alexis Perez <corsac@debian.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NAaron Lu <aaron.lu@intel.com>
Acked-by: NMatthew Garrett <matthew.garrett@nebula.com>

We have to call acpi_video_init_brightness() even if we're not going
to initialise the backlight - Thinkpads seem to use this as the
trigger for enabling ACPI notifications rather than handling it in
firmware.

[rjw: Drop the brightness object created by
 acpi_video_init_brightness() if we are not going to use it.]
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Expose acpi_gbl_osi_data so that code outside of ACPICA can check
the value of the last successfull _OSI call.  The definitions for
OSI versions are moved to actypes.h so that other components can
access them too.

Based on a patch from Matthew Garrett which in turn was based on
an earlier patch from Seth Forshee.

[rjw: Changelog]
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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

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

The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications.  For example, the fix in
commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.

After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out.  Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.

This removes all the drivers/acpi uses of the __cpuinit macros
from all C files.

[1] https://lkml.org/lkml/2013/5/20/589

Cc: Len Brown <lenb@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: linux-acpi@vger.kernel.org
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

device->driver_data needs to be cleared when releasing its data,
mem_device, in an error path of acpi_memory_device_add().

The function evaluates the _CRS of memory device objects, and fails
when it gets an unexpected resource or cannot allocate memory.  A
kernel crash or data corruption may occur when the kernel accesses
the stale pointer.
Signed-off-by: NToshi Kani <toshi.kani@hp.com>
Reviewed-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: 2.6.32+ <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

An ACPI_NOTIFY_BUS_CHECK notification means that we should scan the
entire namespace starting from the given handle even if the device
represented by that handle is present (other devices below it may
just have appeared).

For this reason, modify acpi_scan_bus_device_check() to always run
acpi_bus_scan() if the notification being handled is of type
ACPI_NOTIFY_BUS_CHECK.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NToshi Kani <toshi.kani@hp.com>
Cc: 3.10+ <stable@vger.kernel.org>

In acpi_bus_device_attach(), if there is an ACPI device object
for the given handle and that device object has a scan handler
attached to it already, there's nothing more to do for that handle.
Moreover, if acpi_scan_attach_handler() is called then, it may
execute the .attach() callback of the ACPI scan handler already
attached to the device object and that may lead to interesting
breakage.

For this reason, make acpi_bus_device_attach() return success
immediately when the handle's device object has a scan handler
attached to it.
Reported-by: NToshi Kani <toshi.kani@hp.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NToshi Kani <toshi.kani@hp.com>
Cc: 3.10+ <stable@vger.kernel.org>

There are few places in power.c where debug messages have no newline
at the end.  Reading such debug messages from dmesg is not fun, so
fix this by adding the missing newlines.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Cc: All <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Make the following compiler warning go away:

 CC      drivers/acpi/fan.o
drivers/acpi/fan.c: In function ‘fan_get_cur_state’:
drivers/acpi/fan.c:96:9: warning: ‘acpi_state’ may be used uninitialized in this function [-Wuninitialized]

by initializing the local variable acpi_state in fan_get_cur_state().

[rjw: Changelog]
Signed-off-by: NNaresh Bhat <naresh.bhat@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The acpi_device_list list is not used, so removed it.

[rjw: Changelog]
Signed-off-by: NHaicheng Li <haicheng.li@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit 94add0f8 (ACPI / dock: Initialize ACPI dock subsystem upfront)
changed the header of acpi_dock_init() in internal.h so that it is
supposed to be a void function now, but it forgot to update its
actual definition in dock.c according to which it still is supposed
to return int.

Although that didn't cause any visible breakage or even a compiler
warning to be thrown, which is odd enough, fix it.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: 3.10+ <stable@vger.kernel.org>

The role of acpi_bus_update_power() is to update the given ACPI
device object's power.state field to reflect the current physical
state of the device (as inferred from the configuration of power
resources and _PSC, if available).  For this purpose it calls
acpi_device_set_power() that should update the power resources'
reference counters and set power.state as appropriate.  However,
that doesn't work if the "new" state is D1, D2 or D3hot and the
the current value of power.state means D3cold, because in that
case acpi_device_set_power() will refuse to transition the device
from D3cold to non-D0.

To address this problem, make acpi_bus_update_power() call
acpi_power_transition() directly to update the power resources'
reference counters and only use acpi_device_set_power() to put
the device into D0 if the current physical state of it cannot
be determined.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: 3.9+ <stable@vger.kernel.org>

Fix various weird constructions of strncpy(dst, src, strlen(src)).

Length limits should be about the space available in the destination,
not repurposed as a method to either always include or always exclude a
trailing NULL byte.  Either the NULL should always be copied (using
strlcpy), or it should not be copied (using something like memcpy).
Readable code should not depend on the weird behavior of strncpy when it
hits the length limit.  Better to avoid the anti-pattern entirely.

[akpm@linux-foundation.org: revert getdelays.c part due to missing bsd/string.h]
Signed-off-by: NKees Cook <keescook@chromium.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>	[staging]
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>	[acpi]
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Ursula Braun <ursula.braun@de.ibm.com>
Cc: Frank Blaschka <blaschka@linux.vnet.ibm.com>
Cc: Richard Weinberger <richard@nod.at>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Header size is needed to distinguish between header and the dump data.
Incorporate the addition of new argument (hsize) in the pstore write
callback.
Signed-off-by: NAruna Balakrishnaiah <aruna@linux.vnet.ibm.com>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>