This patch exports acpi_tb_validate_rsdp(), so that code duplication in
some ACPICA utilities can be reduced.
This patch also includes lint changes.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael 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: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Rafael 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: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Rafael 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: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The error code path in acpi_unbind_one() is unnecessarily complicated
(in particular, the err label is not really necessary) and the error
message printed by it is inaccurate (there's nothing called
'acpi_handle' in that function), so clean up those things.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Since acpi_unbind_one() walks physical_node_list under the ACPI
device object's physical_node_lock mutex and the walk may be
terminated as soon as the matching entry has been found, it is
not necessary to use list_for_each_safe() for that walk, so use
list_for_each_entry() instead and make the code slightly more
straightforward.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Clean up some inconsistent use of whitespace in acpi_bind_one() and
acpi_unbind_one().
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Put the creation of symlinks in acpi_bind_one() under the
physical_node_lock mutex of the given ACPI device object, because
that is part of the binding operation logically (those links are
already removed under that mutex too).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Move some duplicated code from acpi_bind_one() and acpi_unbind_one()
into a separate function and make that function use snprintf()
instead of sprintf() for extra safety.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Modify acpi_bind_one() so that it doesn't fail if the device
represented by its first argument has already been bound to the
given ACPI handle (second argument), because that is not a good
enough reason for returning an error code.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Lan Tianyu <tianyu.lan@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.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
33f767d (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
33f767d 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=60561
Reported-by: Peter Wu <lekensteyn@gmail.com>
Tested-by: Vladimir Lalov <mail@vlalov.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Bjorn 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 cecdb19 "ACPI / scan:
Change the implementation of acpi_bus_trim()".
[rjw: Changelog]
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Cc: 3.9+ <stable@vger.kernel.org> # 3.9+
Signed-off-by: Rafael 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: Rafael 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 e2ff394 (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: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Yasuaki 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: Rafael 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: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Rafael 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: Rafael 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: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Since v3.7 the ACPI backlight driver doesn't work at all on this
machine, because presumably the backlight AML code in the ACPI
tables contains a code path that triggers when the OS identifies
itself as compatible with Windows 8 (which the kernel started to
do in 3.7). That code path is never used by Windows and on this
particular machine it turns out to be unusable at all.
Work around this problem by blacklisting the win8 OSI, so we are back
to v3.6 behavior (that is, we don't tell the BIOS that we are
compatible with Windows 8).
Since v3.7, users have been forced to work around the initial
regression by modifying the boot arguments [1].
[1] https://wiki.archlinux.org/index.php/ASUS_Zenbook_Prime_UX31A
[rjw: Changelog]
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The _BCM_use_index and _BCL_use_index fields in struct
acpi_video_brightness_flags are not used, so drop them.
[rjw: Changelog]
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Remove type casting from assignments involving void pointers
in two places in drivers/acpi/video.c.
[rjw: Changelog]
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Fix several coding style defects in drivers/acpi/video.c:
- Initialization of static variables.
- Whitespace in expressions, variable definitions, function
headers, etc.
- Positioning of labels.
- Braces around single statements.
[rjw: Changelog]
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Fix whitespace and comments in several places in
drivers/acpi/video.c.
[rjw: Changelog]
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The state information can be useful to know what the problem is when
an error message about a device can not being set to a higher power
state than its parent appeared, so this patch adds such state
information for both the target state of the device and the current
state of its parent.
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Like acpi_os_prepare_sleep(), register a callback for use in systems
like tboot, and xen, which have system specific requirements outside
of ACPICA. This mirrors the functionality in acpi_os_prepare_sleep(),
called from acpi_hw_sleep()
Signed-off-by: Ben Guthro <benjamin.guthro@citrix.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Now that acpi_device_set_power() checks whether or not the given
device is power manageable, it is not necessary to do this check in
acpi_bus_set_power() any more, so remove it.
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
... according to acpi/apei/ conventions. Use standard pr_fmt prefix
while at it.
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
There are several places in the tree where ACPI_STATE_D3 is used
instead of ACPI_STATE_D3_COLD which should be used instead for
clarity. Modify them all to use ACPI_STATE_D3_COLD as appropriate.
[The definition of ACPI_STATE_D3 itself cannot go away at this point
as it is part of ACPICA.]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
Modify acpi_device_set_power() so that diagnostic messages printed by
it to the kernel log always contain the name of the device concerned
to make it possible to identify the device that triggered the message
if need be.
Also replace printk(KERN_WARNING ) with dev_warn() everywhere in that
function.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
Make acpi_device_set_power() check if the given device is power
manageable before checking if the given power state is valid for that
device. Otherwise it will print that "Device does not support" that
power state into the kernel log, which may not make sense for some
power states (D0 and D3cold are supported by all devices by
definition).
Tested-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Rafael 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: Jan Hoffmann <jan.christian.hoffmann@gmail.com>
References: http://bugzilla.kernel.org/show_bug.cgi?id=60519
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Cc: 2.6.34+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
We attempted to address a regression introduced by commit a57f7f9
(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 8c5bd7a (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 8c5bd7a, 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/27
Reported-and-tested-by: James Hogan <james@albanarts.com>
Reported-and-tested-by: Kamal Mostafa <kamal@canonical.com>
Reported-and-tested-by: Jörg Otte <jrg.otte@gmail.com>
Reported-and-tested-by: Steven Newbury <steve@snewbury.org.uk>
Reported-by: Martin Steigerwald <Martin@lichtvoll.de>
Reported-by: Kalle Valo <kvalo@adurom.com>
Tested-by: Joerg Platte <jplatte@naasa.net>
Signed-off-by: Rafael 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: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Fix to return -ENODEV in the acpi notify handler install error
handling case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
When hot-adding an ACPI host bridge, use
pci_assign_unassigned_root_bus_resources() instead of
pci_assign_unassigned_bus_resources().
The former is more aggressive and will release and reassign existing
resources if necessary. This is safe at hot-add time because no drivers
are bound to devices below the new host bridge yet.
[bhelgaas: changelog, split __init changes out for reviewability]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
We currently enable PCI bridges after scanning a bus and assigning
resources. This is often done in arch code.
This patch changes this so we don't enable a bridge until necessary, i.e.,
until we enable a PCI device behind the bridge. We do this in the generic
pci_enable_device() path, so this also removes the arch-specific code to
enable bridges.
[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
This patch changes the "acpi_osi=" boot parameter implementation so
that:
1. "acpi_osi=!" can be used to disable all _OSI OS vendor strings by
default. It is meaningless to specify "acpi_osi=!" multiple
times as it can only affect the default state of the target _OSI
strings.
2. "acpi_osi=!*" can be used to remove all _OSI OS vendor strings
and all _OSI feature group strings. It is useful to specify
"acpi_osi=!*" multiple times through kernel command line to
override the current state of the target _OSI strings.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch introduces "acpi_osi=!" command line to force Linux replying
"UNSUPPORTED" to all of the _OSI strings. This patch is based on an
ACPICA enhancement - the new API acpi_update_interfaces().
The _OSI object provides the platform with the ability to query OSPM
to determine the set of ACPI related interfaces, behaviors, or
features that the operating system supports. The argument passed to
the _OSI is a string like the followings:
1. Feature Group String, examples include
Module Device
Processor Device
3.0 _SCP Extensions
Processor Aggregator Device
...
2. OS Vendor String, examples include
Linux
FreeBSD
Windows
...
There are AML codes provided in the ACPI namespace written in the
following style to determine OSPM interfaces / features:
Method(OSCK)
{
if (CondRefOf(_OSI, Local0))
{
if (\_OSI("Windows"))
{
Return (One)
}
if (\_OSI("Windows 2006"))
{
Return (Ones)
}
Return (Zero)
}
Return (Zero)
}
There is a debugging facility implemented in Linux. Users can pass
"acpi_osi=" boot parameters to the kernel to tune the _OSI evaluation
result so that certain AML codes can be executed. Current
implementation includes:
1. 'acpi_osi=' - this makes CondRefOf(_OSI, Local0) TRUE
2. 'acpi_osi="Windows"' - this makes \_OSI("Windows") TRUE
3. 'acpi_osi="!Windows"' - this makes \_OSI("Windows") FALSE
The function to implement this feature is also used as a quirk mechanism
in the Linux ACPI subystem.
When _OSI is evaluatated by the AML codes, ACPICA replies "SUPPORTED"
to all Windows operating system vendor strings. This is because
Windows operating systems return "SUPPORTED" if the argument to the
_OSI method specifies an earlier version of Windows. Please refer to
the following MSDN document:
How to Identify the Windows Version in ACPI by Using _OSI
http://msdn.microsoft.com/en-us/library/hardware/gg463275.aspx
This adds difficulties when developers want to feed specific Windows
operating system vendor string to the BIOS codes for debugging
purpose, multiple acpi_osi="!xxx" have to be specified in the command
line to force Linux replying "UNSUPPORTED" to the Windows OS vendor
strings listed in the AML codes.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add new API to allow OSPM to disable/enable specific types of _OSI
interface strings.
ACPICA does not have the knowledge about whether an _OSI interface
string is an OS vendor string or a feature group string and there
isn't any API interface to allow OSPM to install a new interface
string as a feature group string.
This patch simply adds all feature group strings defined by ACPI
specification into the acpi_default_supported_interfaces with
ACPI_OSI_FEATURE flag set to fix this gap. This patch also adds
codes to keep their default states as ACPI_OSI_INVALID before the
initialization and after the termination.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Conflicts:
include/acpi/actypes.h (with commit 242b228)
Since acpi_pci_slot_enumerate() and acpiphp_enumerate_slots() can get
the ACPI device handle they need from bus->bridge, it is not
necessary to pass that handle to them as an argument.
Drop the second argument of acpi_pci_slot_enumerate() and
acpiphp_enumerate_slots(), rework them to obtain the ACPI handle
from bus->bridge and make acpi_pci_add_bus() and
acpi_pci_remove_bus() entirely symmetrical.
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Fixes compiler warnings from GCC 4.2 and perhaps other compilers.
Jung-uk Kim <jkim@FreeBSD.org>
Signed-off-by: Jung-uk Kim <jkim@FreeBSD.org>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The FADT can support over 1000 GPEs, so remove any restriction
on the GPE numbers.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Was 256 bytes max. The original purpose of this constraint was to
limit the amount of debug output. However, the string function in
question (UtPrintString) is now used for the disassembler also,
where 256 bytes is insufficient. Reported by RehabMan@GitHub.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch exports this function to be used by other ACPICA utilities.
Chao Guan, Bob Moore.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
No functional change. Add some comments concerning behavior
when the _STA method does not exist. According to the ACPI
specification, in this case the device should be assumed to be
present, functional, and enabled.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
- Change from Aaron Lu makes ACPICA export a variable which can be
used by driver code to determine whether or not the BIOS believes
that we are compatible with Windows 8.
- Change from Matthew Garrett makes the ACPI video driver initialize
the ACPI backlight even if it is not going to be used afterward
(that is needed for backlight control to work on Thinkpads).
- Fix from Rafael J Wysocki implements Windows 8 backlight support
workaround making i915 take over bakclight control if the firmware
thinks it's dealing with Windows 8. Based on the work of multiple
developers including Matthew Garrett, Chun-Yi Lee, Seth Forshee,
and Aaron Lu.
- Fix from Aaron Lu makes the kernel follow Windows 8 by informing
the firmware through the _DOS method that it should not carry out
automatic brightness changes, so that brightness can be controlled
by GUI.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJR6yY7AAoJEKhOf7ml8uNsbGUQAIVXwX8HF+9AOnqEIQYEaBiF
HqfLDtHS5qobraK06auF/YmVaA17RdUnHssTuGiEbtIxpiUbuLPJaecZ9BeAf0Pz
V4Y2IxF27aF9TDZrzkZXHcnYflzQ/kxj36eR9AmM2vSXmKZKxhfqLMeihVh2GgMv
IlOs9PltK2GNX6C/CzjUQuUj4TYw8yxXsG93Gta0Z8scmxR7mpq9a9d0cPU/TjN/
iatIhZLFU8ujp8xFiG9MDeG948AtperLu3g0v1D4mPnkmDJTuyMuE3FiioKL2zMY
7jh6mDPkWUYdjdZkJcmyzgKZh5lAlZIJTZnJV6TrW5fjIpUz5F8XeD4ArMVU/u+A
smro6XFcpgToRZTtmaEuraxzJHCS44FTjlXyH01FSIiN/Ll6YKyxDYsAzz4Z2sf6
X5BJofAAiRelZh/o1MaMQzs3QeTUo44TaboGr2zka0cQ37KK9+8YRGYqcWo/BvGs
sicgFKMeA6SANxHnCVNTslQzMYFrPp4yyMEu4gD7EE+U7cG6FSVhVHQjjTO9CmBd
ZnX2EDX0Uy+oHTQ9BkyjWAD7rXF6StnOm37FPWHNZ+HnplHEoQQAn+vXsSfl9tbO
7CPefZ/LQQEo1PZwLLkxruZ67NgxOd8/9I/aVjLUKgd8CDjez0UJVJ65gIXl1J4V
kvaDy6faYTnUF8h/AYJf
=vlwF
-----END PGP SIGNATURE-----
Merge tag 'acpi-video-3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI video support fixes from Rafael Wysocki:
"I'm sending a separate pull request for this as it may be somewhat
controversial. The breakage addressed here is not really new and the
fixes may not satisfy all users of the affected systems, but we've had
so much back and forth dance in this area over the last several weeks
that I think it's time to actually make some progress.
The source of the problem is that about a year ago we started to tell
BIOSes that we're compatible with Windows 8, which we really need to
do, because some systems shipping with Windows 8 are tested with it
and nothing else, so if we tell their BIOSes that we aren't compatible
with Windows 8, we expose our users to untested BIOS/AML code paths.
However, as it turns out, some Windows 8-specific AML code paths are
not tested either, because Windows 8 actually doesn't use the ACPI
methods containing them, so if we declare Windows 8 compatibility and
attempt to use those ACPI methods, things break. That occurs mostly
in the backlight support area where in particular the _BCM and _BQC
methods are plain unusable on some systems if the OS declares Windows
8 compatibility.
[ The additional twist is that they actually become usable if the OS
says it is not compatible with Windows 8, but that may cause
problems to show up elsewhere ]
Investigation carried out by Matthew Garrett indicates that what
Windows 8 does about backlight is to leave backlight control up to
individual graphics drivers. At least there's evidence that it does
that if the Intel graphics driver is used, so we've decided to follow
Windows 8 in that respect and allow i915 to control backlight (Daniel
likes that part).
The first commit from Aaron Lu makes ACPICA export the variable from
which we can infer whether or not the BIOS believes that we are
compatible with Windows 8.
The second commit from Matthew Garrett prepares the ACPI video driver
by making it initialize the ACPI backlight even if it is not going to
be used afterward (that is needed for backlight control to work on
Thinkpads).
The third commit implements the actual workaround making i915 take
over backlight control if the firmware thinks it's dealing with
Windows 8 and is based on the work of multiple developers, including
Matthew Garrett, Chun-Yi Lee, Seth Forshee, and Aaron Lu.
The final commit from Aaron Lu makes us follow Windows 8 by informing
the firmware through the _DOS method that it should not carry out
automatic brightness changes, so that brightness can be controlled by
GUI.
Hopefully, this approach will allow us to avoid using blacklists of
systems that should not declare Windows 8 compatibility just to avoid
backlight control problems in the future.
- Change from Aaron Lu makes ACPICA export a variable which can be
used by driver code to determine whether or not the BIOS believes
that we are compatible with Windows 8.
- Change from Matthew Garrett makes the ACPI video driver initialize
the ACPI backlight even if it is not going to be used afterward
(that is needed for backlight control to work on Thinkpads).
- Fix from Rafael J Wysocki implements Windows 8 backlight support
workaround making i915 take over bakclight control if the firmware
thinks it's dealing with Windows 8. Based on the work of multiple
developers including Matthew Garrett, Chun-Yi Lee, Seth Forshee,
and Aaron Lu.
- Fix from Aaron Lu makes the kernel follow Windows 8 by informing
the firmware through the _DOS method that it should not carry out
automatic brightness changes, so that brightness can be controlled
by GUI"
* tag 'acpi-video-3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI / video: no automatic brightness changes by win8-compatible firmware
ACPI / video / i915: No ACPI backlight if firmware expects Windows 8
ACPI / video: Always call acpi_video_init_brightness() on init
ACPICA: expose OSI version
- Two cpufreq commits from the 3.10 cycle introduced regressions.
The first of them was buggy (it did way much more than it needed
to do) and the second one attempted to fix an issue introduced by
the first one. Fixes from Srivatsa S Bhat revert both.
- If autosleep triggers during system shutdown and the shutdown
callbacks of some device drivers have been called already, it may
crash the system. Fix from Liu Shuo prevents that from happening
by making try_to_suspend() check system_state.
- The ACPI memory hotplug driver doesn't clear its driver_data on
errors which may cause a NULL poiter dereference to happen later.
Fix from Toshi Kani.
- The ACPI namespace scanning code should not try to attach scan
handlers to device objects that have them already, which may confuse
things quite a bit, and it should rescan the whole namespace branch
starting at the given node after receiving a bus check notify event
even if the device at that particular node has been discovered
already. Fixes from Rafael J Wysocki.
- New ACPI video blacklist entry for a system whose initial backlight
setting from the BIOS doesn't make sense. From Lan Tianyu.
- Garbage string output avoindance for ACPI PNP from Liu Shuo.
- Two Kconfig fixes for issues introduced recently in the s3c24xx
cpufreq driver (when moving the driver to drivers/cpufreq) from
Paul Bolle.
- Trivial comment fix in pm_wakeup.h from Chanwoo Choi.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJR6Sq+AAoJEKhOf7ml8uNsrGQP/0HRDW+QmTGM8znDTHXngbn9
X3pqlpjEOiCtcmJaSJlD7GwLHMscwWcHKEezteaZ7KUI4mcnysJX6EY5YVbNriDC
xlLcDQn9c6Xx1maCSfp+WMygvqItxZwuc8veRjrT3XtOfCNWS/FlX40Voh63BCAe
GbfQ/HesmUg5CKplyD8/XypLWh5OFXmHzCe8IhrKGfhsZukXdSgSBjwQZMRrEMsQ
kJjDCF8zUu0JisiWqL+xE6IFSKme9i6LBlHpzU0Y1g4RqAqkIbuS0Z3vezOYzoTD
oZjBNa9XAgCS3x0l5g3G0ChgDAU+Mpji/imXA7JysrwbirGFbtPHtQYh2HzpAtnw
Hkah/0ocBM7/w7VTsUQiRsFPdIJTCBLlm6J38x8yh7n84h4nJgOpK69dBLrMwCUZ
f3kid6KIPVLBvnC3QSULrCAKUcUcVVWYtNho+sfXBMjP+cPwTmc3DvATnpru6twa
0KjR5o585UOcciq7EWAoMrCFCfZYF5C4XGaZAxHI/SWooxeCQH84S8vfNLL2epVC
ixmLYo4X2ANDsnfbUV+ewhB0/L2905Et6NhPUgPD/1rm15MEZbowbB2K0pzr0QL9
/1hTL61InXx3jLxducJJFKN+HZ0zfDQdTkyafKrR9jb+GsdmnzYJ/vnfDG8MfPjp
GZ281YBqVmUeYJh5CPU+
=IUmn
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-3.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management and ACPI fixes from Rafael Wysocki:
"These are fixes collected over the last week, most importnatly two
cpufreq reverts fixing regressions introduced in 3.10, an autoseelp
fix preventing systems using it from crashing during shutdown and two
ACPI scan fixes related to hotplug.
Specifics:
- Two cpufreq commits from the 3.10 cycle introduced regressions.
The first of them was buggy (it did way much more than it needed to
do) and the second one attempted to fix an issue introduced by the
first one. Fixes from Srivatsa S Bhat revert both.
- If autosleep triggers during system shutdown and the shutdown
callbacks of some device drivers have been called already, it may
crash the system. Fix from Liu Shuo prevents that from happening
by making try_to_suspend() check system_state.
- The ACPI memory hotplug driver doesn't clear its driver_data on
errors which may cause a NULL poiter dereference to happen later.
Fix from Toshi Kani.
- The ACPI namespace scanning code should not try to attach scan
handlers to device objects that have them already, which may
confuse things quite a bit, and it should rescan the whole
namespace branch starting at the given node after receiving a bus
check notify event even if the device at that particular node has
been discovered already. Fixes from Rafael J Wysocki.
- New ACPI video blacklist entry for a system whose initial backlight
setting from the BIOS doesn't make sense. From Lan Tianyu.
- Garbage string output avoindance for ACPI PNP from Liu Shuo.
- Two Kconfig fixes for issues introduced recently in the s3c24xx
cpufreq driver (when moving the driver to drivers/cpufreq) from
Paul Bolle.
- Trivial comment fix in pm_wakeup.h from Chanwoo Choi"
* tag 'pm+acpi-3.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI / video: ignore BIOS initial backlight value for Fujitsu E753
PNP / ACPI: avoid garbage in resource name
cpufreq: Revert commit 2f7021a8 to fix CPU hotplug regression
cpufreq: s3c24xx: fix "depends on ARM_S3C24XX" in Kconfig
cpufreq: s3c24xx: rename CONFIG_CPU_FREQ_S3C24XX_DEBUGFS
PM / Sleep: Fix comment typo in pm_wakeup.h
PM / Sleep: avoid 'autosleep' in shutdown progress
cpufreq: Revert commit a66b2e to fix suspend/resume regression
ACPI / memhotplug: Fix a stale pointer in error path
ACPI / scan: Always call acpi_bus_scan() for bus check notifications
ACPI / scan: Do not try to attach scan handlers to devices having them
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=60161
Reported-and-tested-by: Jan Hinnerk Stosch <janhinnerk.stosch@gmail.com>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Cc: 3.7+ <stable@vger.kernel.org>
Signed-off-by: Rafael 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=56711
Reported-by: Micael Dias <kam1kaz3@gmail.com>
Reported-by: Dan Garton <dan.garton@gmail.com>
Reported-by: Bob Ziuchkovski <bob.ziuchkovski@gmail.com>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael 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=51231
Tested-by: Aaron Lu <aaron.lu@intel.com>
Tested-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Tested-by: Yves-Alexis Perez <corsac@debian.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
Acked-by: Matthew 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: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: Rafael 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: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael 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: Thomas Renninger <trenn@suse.de>
Acked-by: Matthew Garrett <matthew.garrett@nebula.com>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This functions is really weird. It sets rc to -ENOMEM, then overrides
it. It was converted to PTR_RET in a1458187 when it should have
simply been rewritten.
This version makes it more explicit, with a single IS_ERR() test.
Cc: Alexandru Gheorghiu <gheorghiuandru@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Acked-by: Rafael 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 5e427ec2d0 ("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: Paul Gortmaker <paul.gortmaker@windriver.com>
The local variable id in dock_add() is not necessary, so drop it.
While we're at it, use an initializer to clear the local variable ds
and drop the memset() used for this purpose.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The only user of the ACPI dock notifier chain is the ACPI-based PCI
hotplug (acpiphp) driver that uses it to carry out post-dock fixups
needed by some systems with broken _DCK. However, it is not
necessary to use a separate notifier chain for that, as it can be
simply replaced with a new callback in struct acpi_dock_ops.
For this reason, add a new .fixup() callback to struct acpi_dock_ops
and make hotplug_dock_devices() execute it for all dock devices with
hotplug operations registered. Accordingly, make acpiphp point that
callback to the function carrying out the post-dock fixups and
do not register a separate dock notifier for each device
registering dock operations. Finally, drop the ACPI dock notifier
chain that has no more users.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The function creating and registering dock station objects,
dock_add(), leaks memory if there's an error after it's walked
the ACPI namespace calling find_dock_devices(), because it doesn't
free the list of dependent devices it's just created in those cases.
Fix that issue by adding the missing code to free the list of
dependent devices on errors.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There are no users of the ACPI bus notifier call chain,
acpi_bus_notify_list, any more, so drop it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The ACPI dock driver uses register_acpi_bus_notifier() which
installs a notifier triggered globally for all system notifications.
That first of all is inefficient, because the dock driver is only
interested in notifications associated with the devices it handles,
but it has to handle all system notifies for all devices. Moreover,
it does that even if no docking stations are present in the system
(CONFIG_ACPI_DOCK set is sufficient for that to happen). Besides,
that is inconvenient, because it requires the driver to do extra work
for each notification to find the target dock station object.
For these reasons, rework the dock driver to install a notify
handler individually for each dock station in the system using
acpi_install_notify_handler(). This allows the dock station
object to be passed directly to the notify handler and makes it
possible to simplify the dock driver quite a bit. It also
reduces the overhead related to the handling of all system
notifies when CONFIG_ACPI_DOCK is set.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Make dock_init_hotplug() and dock_release_hotplug() slightly simpler
and move some checks in those functions to the code paths where they
are needed.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
If there are indirect dependencies between devices in a dock
station's dependent devices list, they may be broken if the devices
are removed in the same order in which they have been added.
For this reason, make the code in handle_eject_request() walk the
list of dependent devices in reverse order.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Since acpi_walk_namespace() calls find_dock_devices() during tree
pre-order visit, the latter doesn't need to add devices whose
parents have _EJD pointing to the docking station to the list of
that station's dependent devices, because those parents are going to
be added to that list anyway and the removal of a parent will take
care of the removal of its children in those cases.
For this reason, rework find_dock_devices() to only call
add_dock_dependent_device() for devices whose _EJD point directy to
the docking station represented by its context argument and simplify
it slightly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
The only existing user of the hp_lock mutex in struct dock_station,
hotplug_dock_devices(), is always called under acpi_scan_lock and
cannot race with another instance of itself, so drop the mutex
which is not necessary.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Use helper functions introduced previously to simplify the ACPI dock
driver.
[rjw: Changelog]
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Functions acpi_dock_match() and acpi_bay_match() in scan.c can be
shared with dock.c to reduce code duplication, so export them as
global functions.
Also add a new function acpi_ata_match() to check whether an ACPI
device object represents an ATA device.
[rjw: Changelog]
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Introduce two helper functions, acpi_evaluate_ej0() and
acpi_evaluate_lck(), that will execute the _EJ0 and _LCK ACPI
control methods, respectively, and use them to simplify the
ACPI scan code.
[rjw: Changelog]
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Introduce helper function acpi_execute_simple_method() and use it in
a number of places to simplify code.
[rjw: Changelog]
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Introduce helper function acpi_has_method() and use it in a number
of places to simplify code.
[rjw: Changelog]
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The return value of dock_create_acpi_device() is not used at all,
so change its signature to return void and simplify the
implementation of it.
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Mark all initialization functions with __init to reduce runtime
memory consumption.
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
All dock station objects are created during initialization and
don't change at runtime, so drop the redundant spin lock from
struct dock_station.
[rjw: Changelog]
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Function dock_add() will be called multiple times if there are
multiple dock stations, which causes acpi_dock_notifier_list to be
initialized multiple times.
To avoid that, move the initialization of acpi_dock_notifier_list
from dock_add() to acpi_dock_init().
[rjw: Changelog]
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.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: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: 2.6.32+ <stable@vger.kernel.org>
Signed-off-by: Rafael 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi 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: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Cc: 3.10+ <stable@vger.kernel.org>
- Fix for a recent cpufreq regression that caused WARN() to trigger
overzealously in a couple of places and spam the kernel log with
useless garbage as a result. From Viresh Kumar.
- ACPI dock fix removing a discrepancy between the definition of
acpi_dock_init(), which says that the function returns int, and
its header in the header file, which says that it is a void
function. The function is now defined as void too.
- ACPI PM fix for failures to update device power states as needed,
for example, during resume from system suspend, because the old
state was deeper than the new one, but the new one is not D0.
- Fix for two debug messages in the ACPI power resources code that
don't have a newline at the end and make the kernel log difficult
to read. From Mika Westerberg.
- Two ACPI cleanups from Naresh Bhat and Haicheng Li.
- cpupower updates from Thomas Renninger, including Intel Haswell
support improvements and a new idle-set subcommand among other
things.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJR3U6pAAoJEKhOf7ml8uNs8p8P/Ro4MjXKmk/gMRraZ+wG9I6V
VWgnrdk988PeJ8tRtD5y3KlOzAAsmOdiqCq4dcvJdo+ZaVVgn6NGN46NO5qcd1Qf
pDDJTC0IduskQeKsgd5YbXyBzehIOOFuYhJW7ZO7TPajpVBsBc73D87CwAskmqfd
t2YTztrR6KvJDoXffK+nYoVinCdy1wR6EIFEGxPqYxjvpiwRGDPbbRYStnFVN09S
9epjze+iuWcAoBQtOfPOa+FySkHb2xBrOz8Mg3lqCVL2B7orZ7hsTNFQJMrMkq6+
wjGsbEJCcv7H+/5sTozTI/yaBN6TL8P2256P0n6rZDiWXLnsbbe7bl1mrvp5Uvmp
1TXyhqToRGjpLD3zdkvX33ti4Se0EH6GCUdbO5FpV5PxX9Kro4qYOIw49CZSyR2q
oxGHNWFm5uEqfC1kc49zUMZzIjnVkh3btHTNhu9re5E2GfRnh7iPStYz/u33UiTi
W0FDtzWe1aolS3+PNzoFFZ9YlJV6H6DGsthpKIEqY3j4CTBOc3kSYyzpGE9j8vNJ
jlajer2xM0PfJBTk8NcCoTw/y/NyHPgXxpe6uVWxujxQpFJ2h9jeeUUmxOebvDpk
6RYXq0FRM1o9DbiEPCH6JAWhn+dM6zAwo8J660eSoz82W5kMqLn1gwsoWs6FKB09
hA3rFnwEqCB+rEN2Ezkm
=2tp3
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-3.11-rc1-more' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull more power management and ACPI updates from Rafael Wysocki:
- Fix for a recent cpufreq regression that caused WARN() to trigger
overzealously in a couple of places and spam the kernel log with
useless garbage as a result. From Viresh Kumar.
- ACPI dock fix removing a discrepancy between the definition of
acpi_dock_init(), which says that the function returns int, and its
header in the header file, which says that it is a void function.
The function is now defined as void too.
- ACPI PM fix for failures to update device power states as needed, for
example, during resume from system suspend, because the old state was
deeper than the new one, but the new one is not D0.
- Fix for two debug messages in the ACPI power resources code that
don't have a newline at the end and make the kernel log difficult to
read. From Mika Westerberg.
- Two ACPI cleanups from Naresh Bhat and Haicheng Li.
- cpupower updates from Thomas Renninger, including Intel Haswell
support improvements and a new idle-set subcommand among other
things.
* tag 'pm+acpi-3.11-rc1-more' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI / power: add missing newline to debug messages
cpupower: Add Haswell family 0x45 specific idle monitor to show PC8,9,10 states
cpupower: Haswell also supports the C-states introduced with SandyBridge
cpupower: Introduce idle-set subcommand and C-state enabling/disabling
cpupower: Implement disabling of cstate interface
cpupower: Make idlestate usage unsigned
ACPI / fan: Initialize acpi_state variable
ACPI / scan: remove unused LIST_HEAD(acpi_device_list)
ACPI / dock: Actually define acpi_dock_init() as void
ACPI / PM: Fix corner case in acpi_bus_update_power()
cpufreq: Fix serialization of frequency transitions
If the firmware indicates in GHES error data entry that the error threshold
has exceeded for a corrected error event, then we try to soft-offline the
page. This could be called in interrupt context, so we queue this up similar
to how we handle memory failure scenarios.
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Acked-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Add a boot option to disable firmware first mode for corrected errors.
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Acked-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Tony Luck <tony.luck@intel.com>
The Corrected Machine Check structure (CMC) in HEST has a flag which can be
set by the firmware to indicate to the OS that it prefers to process the
corrected error events first. In this scenario, the OS is expected to not
monitor for corrected errors (through CMCI/polling). Instead, the firmware
notifies the OS on corrected error events through GHES.
Linux already has support for GHES. This patch adds support for parsing CMC
structure and to disable CMCI/polling if the firmware first flag is set.
Further, the list of machine check bank structures at the end of CMC is used
to determine which MCA banks function in FF mode, so that we continue to
monitor error events on the other banks.
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Acked-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Tony Luck <tony.luck@intel.com>
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: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: All <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Pull powerpc updates from Ben Herrenschmidt:
"This is the powerpc changes for the 3.11 merge window. In addition to
the usual bug fixes and small updates, the main highlights are:
- Support for transparent huge pages by Aneesh Kumar for 64-bit
server processors. This allows the use of 16M pages as transparent
huge pages on kernels compiled with a 64K base page size.
- Base VFIO support for KVM on power by Alexey Kardashevskiy
- Wiring up of our nvram to the pstore infrastructure, including
putting compressed oopses in there by Aruna Balakrishnaiah
- Move, rework and improve our "EEH" (basically PCI error handling
and recovery) infrastructure. It is no longer specific to pseries
but is now usable by the new "powernv" platform as well (no
hypervisor) by Gavin Shan.
- I fixed some bugs in our math-emu instruction decoding and made it
usable to emulate some optional FP instructions on processors with
hard FP that lack them (such as fsqrt on Freescale embedded
processors).
- Support for Power8 "Event Based Branch" facility by Michael
Ellerman. This facility allows what is basically "userspace
interrupts" for performance monitor events.
- A bunch of Transactional Memory vs. Signals bug fixes and HW
breakpoint/watchpoint fixes by Michael Neuling.
And more ... I appologize in advance if I've failed to highlight
something that somebody deemed worth it."
* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: (156 commits)
pstore: Add hsize argument in write_buf call of pstore_ftrace_call
powerpc/fsl: add MPIC timer wakeup support
powerpc/mpic: create mpic subsystem object
powerpc/mpic: add global timer support
powerpc/mpic: add irq_set_wake support
powerpc/85xx: enable coreint for all the 64bit boards
powerpc/8xx: Erroneous double irq_eoi() on CPM IRQ in MPC8xx
powerpc/fsl: Enable CONFIG_E1000E in mpc85xx_smp_defconfig
powerpc/mpic: Add get_version API both for internal and external use
powerpc: Handle both new style and old style reserve maps
powerpc/hw_brk: Fix off by one error when validating DAWR region end
powerpc/pseries: Support compression of oops text via pstore
powerpc/pseries: Re-organise the oops compression code
pstore: Pass header size in the pstore write callback
powerpc/powernv: Fix iommu initialization again
powerpc/pseries: Inform the hypervisor we are using EBB regs
powerpc/perf: Add power8 EBB support
powerpc/perf: Core EBB support for 64-bit book3s
powerpc/perf: Drop MMCRA from thread_struct
powerpc/perf: Don't enable if we have zero events
...
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: Naresh Bhat <naresh.bhat@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The acpi_device_list list is not used, so removed it.
[rjw: Changelog]
Signed-off-by: Haicheng Li <haicheng.li@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit 94add0f (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: Rafael 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Merge first patch-bomb from Andrew Morton:
- various misc bits
- I'm been patchmonkeying ocfs2 for a while, as Joel and Mark have been
distracted. There has been quite a bit of activity.
- About half the MM queue
- Some backlight bits
- Various lib/ updates
- checkpatch updates
- zillions more little rtc patches
- ptrace
- signals
- exec
- procfs
- rapidio
- nbd
- aoe
- pps
- memstick
- tools/testing/selftests updates
* emailed patches from Andrew Morton <akpm@linux-foundation.org>: (445 commits)
tools/testing/selftests: don't assume the x bit is set on scripts
selftests: add .gitignore for kcmp
selftests: fix clean target in kcmp Makefile
selftests: add .gitignore for vm
selftests: add hugetlbfstest
self-test: fix make clean
selftests: exit 1 on failure
kernel/resource.c: remove the unneeded assignment in function __find_resource
aio: fix wrong comment in aio_complete()
drivers/w1/slaves/w1_ds2408.c: add magic sequence to disable P0 test mode
drivers/memstick/host/r592.c: convert to module_pci_driver
drivers/memstick/host/jmb38x_ms: convert to module_pci_driver
pps-gpio: add device-tree binding and support
drivers/pps/clients/pps-gpio.c: convert to module_platform_driver
drivers/pps/clients/pps-gpio.c: convert to devm_* helpers
drivers/parport/share.c: use kzalloc
Documentation/accounting/getdelays.c: avoid strncpy in accounting tool
aoe: update internal version number to v83
aoe: update copyright date
aoe: perform I/O completions in parallel
...
PCI device hotplug
- Add pci_alloc_dev() interface (Gu Zheng)
- Add pci_bus_get()/put() for reference counting (Jiang Liu)
- Fix SR-IOV reference count issues (Jiang Liu)
- Remove unused acpi_pci_roots list (Jiang Liu)
MSI
- Conserve interrupt resources on x86 (Alexander Gordeev)
AER
- Force fatal severity when component has been reset (Betty Dall)
- Reset link below Root Port as well as Downstream Port (Betty Dall)
- Fix "Firmware first" flag setting (Bjorn Helgaas)
- Don't parse HEST for non-PCIe devices (Bjorn Helgaas)
ASPM
- Warn when we can't disable ASPM as driver requests (Bjorn Helgaas)
Miscellaneous
- Add CircuitCo PCI IDs (Darren Hart)
- Add AMD CZ SATA and SMBus PCI IDs (Shane Huang)
- Work around Ivytown NTB BAR size issue (Jon Mason)
- Detect invalid initial BAR values (Kevin Hao)
- Add pcibios_release_device() (Sebastian Ott)
- Fix powerpc & sparc PCI_UNKNOWN power state usage (Bjorn Helgaas)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJR0dhDAAoJEFmIoMA60/r8AUoP/RrKOXC2GGZCqUIKjUyxaCU+
NXwaNhjfRuge5lZHE8fUAnYVveFTv0iNo8if/md866/pS4il3vxaMWRhZrBddXqe
juyxPUGaOb5NmI2C+g5ebQ1xHhnOU6kWrgQ5kQk5GmJdm6BpiWDCFaalyioYj27v
FoN/25IG+5EtJjP6kRdQGFZq+RYOqlBfQp4fdFmY5bDsQiCLREH6YWHeNSkH+t1I
Eh84WESqGzgaZyCb9QKM2AcU/HMKLux4VXAYp9idVr3tH1j9b/klQI7xNW7sPnkY
LIzKTcfF89iXkhxc7zrF0O/n5rC5Cp7LQpiFMV6yCT3w25yWpq9itOwqcZ/nfCv6
fje8P1B2lwGrizkwKKLcosTzWkJewvfLkVye90WS3g0i3zlijF4pfEiw3a2ujA91
MP9/JmX+ZZ5QeGyPuFmYJyMlInH4vtSdegl9jtaeuX4cOnuMP+Ouxnxc+mH2bOfl
Z5/K1OSCYLfb27uWM7od2lgb+GFHLMP+RMy073h0ZMpDvM6EnZy5iu1zU9+yJO4S
8/aRhBz4h+YEBinnXOJvHzMfu3wQQ7UvXZqEspgsug2Z5xHvxhMLhrJQgpVUSdsW
Nrdm1dNdACV/cvt/lWzUE7SmUaOua/r/cVmViF2ryeRET7t65in+5NHXmXP8ET+r
1WA7pbykfegC9uY84PaK
=X3Lo
-----END PGP SIGNATURE-----
Merge tag 'pci-v3.11-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
Pull PCI changes from Bjorn Helgaas:
"PCI device hotplug
- Add pci_alloc_dev() interface (Gu Zheng)
- Add pci_bus_get()/put() for reference counting (Jiang Liu)
- Fix SR-IOV reference count issues (Jiang Liu)
- Remove unused acpi_pci_roots list (Jiang Liu)
MSI
- Conserve interrupt resources on x86 (Alexander Gordeev)
AER
- Force fatal severity when component has been reset (Betty Dall)
- Reset link below Root Port as well as Downstream Port (Betty Dall)
- Fix "Firmware first" flag setting (Bjorn Helgaas)
- Don't parse HEST for non-PCIe devices (Bjorn Helgaas)
ASPM
- Warn when we can't disable ASPM as driver requests (Bjorn Helgaas)
Miscellaneous
- Add CircuitCo PCI IDs (Darren Hart)
- Add AMD CZ SATA and SMBus PCI IDs (Shane Huang)
- Work around Ivytown NTB BAR size issue (Jon Mason)
- Detect invalid initial BAR values (Kevin Hao)
- Add pcibios_release_device() (Sebastian Ott)
- Fix powerpc & sparc PCI_UNKNOWN power state usage (Bjorn Helgaas)"
* tag 'pci-v3.11-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: (51 commits)
MAINTAINERS: Add ACPI folks for ACPI-related things under drivers/pci
PCI: Add CircuitCo vendor ID and subsystem ID
PCI: Use pdev->pm_cap instead of pci_find_capability(..,PCI_CAP_ID_PM)
PCI: Return early on allocation failures to unindent mainline code
PCI: Simplify IOV implementation and fix reference count races
PCI: Drop redundant setting of bus->is_added in virtfn_add_bus()
unicore32/PCI: Remove redundant call of pci_bus_add_devices()
m68k/PCI: Remove redundant call of pci_bus_add_devices()
PCI / ACPI / PM: Use correct power state strings in messages
PCI: Fix comment typo for pcie_pme_remove()
PCI: Rename pci_release_bus_bridge_dev() to pci_release_host_bridge_dev()
PCI: Fix refcount issue in pci_create_root_bus() error recovery path
ia64/PCI: Clean up pci_scan_root_bus() usage
PCI/AER: Reset link for devices below Root Port or Downstream Port
ACPI / APEI: Force fatal AER severity when component has been reset
PCI/AER: Remove "extern" from function declarations
PCI/AER: Move AER severity defines to aer.h
PCI/AER: Set dev->__aer_firmware_first only for matching devices
PCI/AER: Factor out HEST device type matching
PCI/AER: Don't parse HEST table for non-PCIe devices
...
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: Kees 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: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
- Hotplug changes allowing device hot-removal operations to fail
gracefully (instead of crashing the kernel) if they cannot be
carried out completely. From Rafael J Wysocki and Toshi Kani.
- Freezer update from Colin Cross and Mandeep Singh Baines targeted
at making the freezing of tasks a bit less heavy weight operation.
- cpufreq resume fix from Srivatsa S Bhat for a regression introduced
during the 3.10 cycle causing some cpufreq sysfs attributes to
return wrong values to user space after resume.
- New freqdomain_cpus sysfs attribute for the acpi-cpufreq driver to
provide information previously available via related_cpus from
Lan Tianyu.
- cpufreq fixes and cleanups from Viresh Kumar, Jacob Shin,
Heiko Stübner, Xiaoguang Chen, Ezequiel Garcia, Arnd Bergmann, and
Tang Yuantian.
- Fix for an ACPICA regression causing suspend/resume issues to
appear on some systems introduced during the 3.4 development cycle
from Lv Zheng.
- ACPICA fixes and cleanups from Bob Moore, Tomasz Nowicki, Lv Zheng,
Chao Guan, and Zhang Rui.
- New cupidle driver for Xilinx Zynq processors from Michal Simek.
- cpuidle fixes and cleanups from Daniel Lezcano.
- Changes to make suspend/resume work correctly in Xen guests from
Konrad Rzeszutek Wilk.
- ACPI device power management fixes and cleanups from Fengguang Wu
and Rafael J Wysocki.
- ACPI documentation updates from Lv Zheng, Aaron Lu and Hanjun Guo.
- Fix for the IA-64 issue that was the reason for reverting commit
9f29ab1 and updates of the ACPI scan code from Rafael J Wysocki.
- Mechanism for adding CMOS RTC address space handlers from Lan Tianyu
(to allow some EC-related breakage to be fixed on some systems).
- Spec-compliant implementation of acpi_os_get_timer() from
Mika Westerberg.
- Modification of do_acpi_find_child() to execute _STA in order to
to avoid situations in which a pointer to a disabled device object
is returned instead of an enabled one with the same _ADR value.
From Jeff Wu.
- Intel BayTrail PCH (Platform Controller Hub) support for the ACPI
Intel Low-Power Subsystems (LPSS) driver and modificaions of that
driver to work around a couple of known BIOS issues from
Mika Westerberg and Heikki Krogerus.
- EC driver fix from Vasiliy Kulikov to make it use get_user() and
put_user() instead of dereferencing user space pointers blindly.
- Assorted ACPI code cleanups from Bjorn Helgaas, Nicholas Mazzuca and
Toshi Kani.
- Modification of the "runtime idle" helper routine to take the return
values of the callbacks executed by it into account and to call
rpm_suspend() if they return 0, which allows some code bloat
reduction to be done, from Rafael J Wysocki and Alan Stern.
- New trace points for PM QoS from Sahara <keun-o.park@windriver.com>.
- PM QoS documentation update from Lan Tianyu.
- Assorted core PM code cleanups and changes from Bernie Thompson,
Bjorn Helgaas, Julius Werner, and Shuah Khan.
- New devfreq driver for the Exynos5-bus device from Abhilash Kesavan.
- Minor devfreq cleanups, fixes and MAINTAINERS update from
MyungJoo Ham, Abhilash Kesavan, Paul Bolle, Rajagopal Venkat, and
Wei Yongjun.
- OMAP Adaptive Voltage Scaling (AVS) SmartReflex voltage control
driver updates from Andrii Tseglytskyi and Nishanth Menon.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJR0ZNOAAoJEKhOf7ml8uNsDLYP/0EU4rmvw0TWTITfp6RS1KDE
9GwBn96ZR4Q5bJd9gBCTPSqhHOYMqxWEUp99sn/M2wehG1pk/jw5LO56+2IhM3UZ
g1HDcJ7te2nVT/iXsKiAGTVhU9Rk0aYwoVSknwk27qpIBGxW9w/s5tLX8pY3Q3Zq
wL/7aTPjyL+PFFFEaxgH7qLqsl3DhbtYW5AriUBTkXout/tJ4eO1b7MNBncLDh8X
VQ/0DNCKE95VEJfkO4rk9RKUyVp9GDn0i+HXCD/FS4IA5oYzePdVdNDmXf7g+swe
CGlTZq8pB+oBpDiHl4lxzbNrKQjRNbGnDUkoRcWqn0nAw56xK+vmYnWJhW99gQ/I
fKnvxeLca5po1aiqmC4VSJxZIatFZqLrZAI4dzoCLWY+bGeTnCKmj0/F8ytFnZA2
8IuLLs7/dFOaHXV/pKmpg6FAlFa9CPxoqRFoyqb4M0GjEarADyalXUWsPtG+6xCp
R/p0CISpwk+guKZR/qPhL7M654S7SHrPwd2DPF0KgGsvk+G2GhoB8EzvD8BVp98Z
9siCGCdgKQfJQVI6R0k9aFmn/4gRQIAgyPhkhv9tqULUUkiaXki+/t8kPfnb8O/d
zep+CA57E2G8MYLkDJfpFeKS7GpPD6TIdgFdGmOUC0Y6sl9iTdiw4yTx8O2JM37z
rHBZfYGkJBrbGRu+Q1gs
=VBBq
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-3.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management and ACPI updates from Rafael Wysocki:
"This time the total number of ACPI commits is slightly greater than
the number of cpufreq commits, but Viresh Kumar (who works on cpufreq)
remains the most active patch submitter.
To me, the most significant change is the addition of offline/online
device operations to the driver core (with the Greg's blessing) and
the related modifications of the ACPI core hotplug code. Next are the
freezer updates from Colin Cross that should make the freezing of
tasks a bit less heavy weight.
We also have a couple of regression fixes, a number of fixes for
issues that have not been identified as regressions, two new drivers
and a bunch of cleanups all over.
Highlights:
- Hotplug changes to support graceful hot-removal failures.
It sometimes is necessary to fail device hot-removal operations
gracefully if they cannot be carried out completely. For example,
if memory from a memory module being hot-removed has been allocated
for the kernel's own use and cannot be moved elsewhere, it's
desirable to fail the hot-removal operation in a graceful way
rather than to crash the kernel, but currenty a success or a kernel
crash are the only possible outcomes of an attempted memory
hot-removal. Needless to say, that is not a very attractive
alternative and it had to be addressed.
However, in order to make it work for memory, I first had to make
it work for CPUs and for this purpose I needed to modify the ACPI
processor driver. It's been split into two parts, a resident one
handling the low-level initialization/cleanup and a modular one
playing the actual driver's role (but it binds to the CPU system
device objects rather than to the ACPI device objects representing
processors). That's been sort of like a live brain surgery on a
patient who's riding a bike.
So this is a little scary, but since we found and fixed a couple of
regressions it caused to happen during the early linux-next testing
(a month ago), nobody has complained.
As a bonus we remove some duplicated ACPI hotplug code, because the
ACPI-based CPU hotplug is now going to use the common ACPI hotplug
code.
- Lighter weight freezing of tasks.
These changes from Colin Cross and Mandeep Singh Baines are
targeted at making the freezing of tasks a bit less heavy weight
operation. They reduce the number of tasks woken up every time
during the freezing, by using the observation that the freezer
simply doesn't need to wake up some of them and wait for them all
to call refrigerator(). The time needed for the freezer to decide
to report a failure is reduced too.
Also reintroduced is the check causing a lockdep warining to
trigger when try_to_freeze() is called with locks held (which is
generally unsafe and shouldn't happen).
- cpufreq updates
First off, a commit from Srivatsa S Bhat fixes a resume regression
introduced during the 3.10 cycle causing some cpufreq sysfs
attributes to return wrong values to user space after resume. The
fix is kind of fresh, but also it's pretty obvious once Srivatsa
has identified the root cause.
Second, we have a new freqdomain_cpus sysfs attribute for the
acpi-cpufreq driver to provide information previously available via
related_cpus. From Lan Tianyu.
Finally, we fix a number of issues, mostly related to the
CPUFREQ_POSTCHANGE notifier and cpufreq Kconfig options and clean
up some code. The majority of changes from Viresh Kumar with bits
from Jacob Shin, Heiko Stübner, Xiaoguang Chen, Ezequiel Garcia,
Arnd Bergmann, and Tang Yuantian.
- ACPICA update
A usual bunch of updates from the ACPICA upstream.
During the 3.4 cycle we introduced support for ACPI 5 extended
sleep registers, but they are only supposed to be used if the
HW-reduced mode bit is set in the FADT flags and the code attempted
to use them without checking that bit. That caused suspend/resume
regressions to happen on some systems. Fix from Lv Zheng causes
those registers to be used only if the HW-reduced mode bit is set.
Apart from this some other ACPICA bugs are fixed and code cleanups
are made by Bob Moore, Tomasz Nowicki, Lv Zheng, Chao Guan, and
Zhang Rui.
- cpuidle updates
New driver for Xilinx Zynq processors is added by Michal Simek.
Multidriver support simplification, addition of some missing
kerneldoc comments and Kconfig-related fixes come from Daniel
Lezcano.
- ACPI power management updates
Changes to make suspend/resume work correctly in Xen guests from
Konrad Rzeszutek Wilk, sparse warning fix from Fengguang Wu and
cleanups and fixes of the ACPI device power state selection
routine.
- ACPI documentation updates
Some previously missing pieces of ACPI documentation are added by
Lv Zheng and Aaron Lu (hopefully, that will help people to
uderstand how the ACPI subsystem works) and one outdated doc is
updated by Hanjun Guo.
- Assorted ACPI updates
We finally nailed down the IA-64 issue that was the reason for
reverting commit 9f29ab11dd ("ACPI / scan: do not match drivers
against objects having scan handlers"), so we can fix it and move
the ACPI scan handler check added to the ACPI video driver back to
the core.
A mechanism for adding CMOS RTC address space handlers is
introduced by Lan Tianyu to allow some EC-related breakage to be
fixed on some systems.
A spec-compliant implementation of acpi_os_get_timer() is added by
Mika Westerberg.
The evaluation of _STA is added to do_acpi_find_child() to avoid
situations in which a pointer to a disabled device object is
returned instead of an enabled one with the same _ADR value. From
Jeff Wu.
Intel BayTrail PCH (Platform Controller Hub) support is added to
the ACPI driver for Intel Low-Power Subsystems (LPSS) and that
driver is modified to work around a couple of known BIOS issues.
Changes from Mika Westerberg and Heikki Krogerus.
The EC driver is fixed by Vasiliy Kulikov to use get_user() and
put_user() instead of dereferencing user space pointers blindly.
Code cleanups are made by Bjorn Helgaas, Nicholas Mazzuca and Toshi
Kani.
- Assorted power management updates
The "runtime idle" helper routine is changed to take the return
values of the callbacks executed by it into account and to call
rpm_suspend() if they return 0, which allows us to reduce the
overall code bloat a bit (by dropping some code that's not
necessary any more after that modification).
The runtime PM documentation is updated by Alan Stern (to reflect
the "runtime idle" behavior change).
New trace points for PM QoS are added by Sahara
(<keun-o.park@windriver.com>).
PM QoS documentation is updated by Lan Tianyu.
Code cleanups are made and minor issues are addressed by Bernie
Thompson, Bjorn Helgaas, Julius Werner, and Shuah Khan.
- devfreq updates
New driver for the Exynos5-bus device from Abhilash Kesavan.
Minor cleanups, fixes and MAINTAINERS update from MyungJoo Ham,
Abhilash Kesavan, Paul Bolle, Rajagopal Venkat, and Wei Yongjun.
- OMAP power management updates
Adaptive Voltage Scaling (AVS) SmartReflex voltage control driver
updates from Andrii Tseglytskyi and Nishanth Menon."
* tag 'pm+acpi-3.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (162 commits)
cpufreq: Fix cpufreq regression after suspend/resume
ACPI / PM: Fix possible NULL pointer deref in acpi_pm_device_sleep_state()
PM / Sleep: Warn about system time after resume with pm_trace
cpufreq: don't leave stale policy pointer in cdbs->cur_policy
acpi-cpufreq: Add new sysfs attribute freqdomain_cpus
cpufreq: make sure frequency transitions are serialized
ACPI: implement acpi_os_get_timer() according the spec
ACPI / EC: Add HP Folio 13 to ec_dmi_table in order to skip DSDT scan
ACPI: Add CMOS RTC Operation Region handler support
ACPI / processor: Drop unused variable from processor_perflib.c
cpufreq: tegra: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: s3c64xx: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: omap: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: imx6q: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: exynos: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: dbx500: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: davinci: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: arm-big-little: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: powernow-k8: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: pcc: call CPUFREQ_POSTCHANGE notfier in error cases
...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJRzg7SAAoJEKurIx+X31iBYsEP/A06TUjFMx8ZmPBdya1u0thq
4fMD8hUFv/vG90Opk1PBBCLWwAJJ6wwrQ8EQd5ieBInYSYW4bDlDFqCk7X0cZ7LE
tlRNsUVDS7LpscWEXoYshRzquj7xyCg0nJMBlMSca3vPYQ82iUD0v9vp5/TKwOgu
ti0mpj7kRj18FPkhokl+ja6fuUgUICPiRBvNR8DPskrnJ0lXv2Zyo0CKER47Wfa4
+fVqXZL0Ih1tivqH/3abA1MYXjxh9k9Db+USupYpQnPwZwDTWap0z/OYU9Swni6I
/XW5c5vrAX9LyMPxMenD0RUWMZXmRDc9ddseRBwVSzQtowQxFGChgwz1+41nFers
KTSLlrU1kij7+axBsjgPMli0SUoPlspv7Lt3JzEoJb0rtkOZmCDXu254qbDy7zxH
Q06Zmb86XtJRGQH43lxEUDZ4QSg+OHA4Uskp6s12Ly1KNvLpk5KOkbuM1DT2jPJb
6KbfOJNcATeCAoax/qJky++qh4E42okG5gOeqC1zquWcfRoVuS+nWBbu4kubKlNs
Qe3IjmybR2S6c1pidDViTnnR/FiununknZaBPavqvuqaf5wBaBwDKiBi973TYFyu
D4g+KyaMwvicGp59Z+u9QLGTaeVxHlVv1l3oSd3x7SVhJBwVLihgz7tULS4+X+YX
csTLhy2n8wE0aOHWH5su
=Xcer
-----END PGP SIGNATURE-----
Merge tag 'please-pull-pstore' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux
Pull pstore update from Tony Luck:
"Fixes for pstore for 3.11 merge window"
* tag 'please-pull-pstore' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux:
efivars: If pstore_register fails, free unneeded pstore buffer
acpi: Eliminate console msg if pstore.backend excludes ERST
pstore: Return unique error if backend registration excluded by kernel param
pstore: Fail to unlink if a driver has not defined pstore_erase
pstore/ram: remove the power of buffer size limitation
pstore/ram: avoid atomic accesses for ioremapped regions
efi, pstore: Cocci spatch "memdup.spatch"
Pull x86 RAS update from Ingo Molnar:
"The changes in this tree are:
- ACPI APEI (ACPI Platform Error Interface) improvements, by Chen
Gong
- misc MCE fixes/cleanups"
* 'x86-ras-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/mce: Update MCE severity condition check
mce: acpi/apei: Add comments to clarify usage of the various bitfields in the MCA subsystem
ACPI/APEI: Update einj documentation for param1/param2
ACPI/APEI: Add parameter check before error injection
ACPI, APEI, EINJ: Fix error return code in einj_init()
x86, mce: Fix "braodcast" typo
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: Aruna Balakrishnaiah <aruna@linux.vnet.ibm.com>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This is patch 2/3 of a patch set that avoids what misleadingly appears
to be a error during boot:
ERST: Could not register with persistent store
This message is displayed if the system has a valid ACPI ERST table and the
pstore.backend kernel parameter has been used to disable use of ERST by
pstore. But this same message is used for errors that preclude registration.
In erst_init don't complain if the setting of kernel parameter pstore.backend
precludes use of ACPI ERST for pstore. Routine pstore_register will inform
about the facility that does register.
Also, don't leave a dangling pointer to deallocated mem for the pstore
buffer when registration fails.
Signed-off-by: Lenny Szubowicz <lszubowi@redhat.com>
Reported-by: Naotaka Hamaguchi <n.hamaguchi@jp.fujitsu.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
* acpi-assorted:
ACPI / EC: Add HP Folio 13 to ec_dmi_table in order to skip DSDT scan
ACPI: Add CMOS RTC Operation Region handler support
ACPI: Remove unused flags in acpi_device_flags
ACPI: Remove useless initializers
ACPI / battery: Make sure all spaces are in correct places
ACPI: add _STA evaluation at do_acpi_find_child()
ACPI / EC: access user space with get_user()/put_user()
* acpi-pm:
ACPI / PM: Rework and clean up acpi_dev_pm_get_state()
ACPI / PM: Replace ACPI_STATE_D3 with ACPI_STATE_D3_COLD in device_pm.c
ACPI / PM: Rename function acpi_device_power_state() and make it static
ACPI / PM: acpi_processor_suspend() can be static
xen / ACPI / sleep: Register an acpi_suspend_lowlevel callback.
x86 / ACPI / sleep: Provide registration for acpi_suspend_lowlevel.
* acpica: (21 commits)
ACPICA: Update version to 20130517
ACPICA: _CST repair: Handle null package entries
ACPICA: Add several repairs for _CST predefined name
ACPICA: Move _PRT repair into the standard complex repair module
ACPICA: Clear events initialized flag upon event component termination
ACPICA: Fix possible memory leak in GPE init error path
ACPICA: ACPICA Termination: Delete global lock pending lock
ACPICA: Update interface to acpi_ut_valid_acpi_name()
ACPICA: Do not use extended sleep registers unless HW-reduced bit is set
ACPICA: Split table print utilities to a new a separate file
ACPICA: Add option to disable loading of SSDTs from the RSDT/XSDT
ACPICA: Standardize all switch() blocks
ACPICA: Split internal error msg routines to a separate file
ACPICA: Split buffer dump routines into separate file
ACPICA: Update version to 20130418
ACPICA: Update for "orphan" embedded controller _REG method support
ACPICA: Remove unused macros, no functional change
ACPICA: Predefined name support: Remove unused local variable
ACPICA: Add argument typechecking for all predefined ACPI names
ACPICA: Add BIOS error interface for predefined name validation support
...
After commit fa1675b (ACPI / PM: Rework and clean up
acpi_dev_pm_get_state()) a NULL pointer dereference will take place
if NULL is passed to acpi_pm_device_sleep_state() as the second
argument.
Fix that by avoiding to use the pointer that may be NULL until
it's necessary to store a return value at the location pointed to
by it (if not NULL).
Reported-and-tested-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI Timer() opcode should return monotonically increasing clock with 100ns
granularity according the ACPI 5.0 spec.
Testing the current Timer() implementation with following ASL code (and an
additional debug print in acpi_os_sleep() to get the sleep times dumped out
to dmesg):
// Test: 10ms
Store(Timer, Local1)
Sleep(10)
Divide(Subtract(Timer, Local1), 10000,, Local1)
Sleep(Local1)
// Test: 200ms
Store(Timer, Local1)
Sleep(200)
Divide(Subtract(Timer, Local1), 10000,, Local1)
Sleep(Local1)
// Test 1300ms
Store(Timer, Local1)
Sleep(1300)
Divide(Subtract(Timer, Local1), 10000,, Local1)
Sleep(Local1)
The second sleep value is calculated using Timer(). If the implementation
is good enough we should be able to get the second value pretty close to
the first.
However, the current Timer() gives pretty bad sleep times:
[ 11.488100] ACPI: acpi_os_get_timer() TBD
[ 11.492150] ACPI: Sleep(10)
[ 11.502993] ACPI: Sleep(0)
[ 11.506315] ACPI: Sleep(200)
[ 11.706237] ACPI: Sleep(0)
[ 11.709550] ACPI: Sleep(1300)
[ 13.008929] ACPI: Sleep(0)
Fix this with the help of ktime_get(). Once the fix is applied and run
against the same ASL code we get:
[ 11.486786] ACPI: Sleep(10)
[ 11.499029] ACPI: Sleep(12)
[ 11.512350] ACPI: Sleep(200)
[ 11.712282] ACPI: Sleep(200)
[ 11.912170] ACPI: Sleep(1300)
[ 13.211577] ACPI: Sleep(1300)
That is much more closer to the values we expected.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
HP Folio 13's BIOS defines CMOS RTC Operation Region and the EC's
_REG method will access that region. To allow the CMOS RTC region
handler to be installed before the EC _REG method is first invoked,
add ec_skip_dsdt_scan() as HP Folio 13's callback to ec_dmi_table.
References: https://bugzilla.kernel.org/show_bug.cgi?id=54621
Reported-and-tested-by: Stefan Nagy <public@stefan-nagy.at>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
On HP Folio 13-2000, the BIOS defines a CMOS RTC Operation Region and
the EC's _REG methord accesses that region. Thus an appropriate
address space handler must be registered for that region before the
EC driver is loaded.
Introduce a mechanism for adding CMOS RTC address space handlers.
Register an ACPI scan handler for CMOS RTC devices such that, when
a device of that kind is detected during an ACPI namespace scan, a
common CMOS RTC operation region address space handler will be
installed for it.
References: https://bugzilla.kernel.org/show_bug.cgi?id=54621
Reported-and-tested-by: Stefan Nagy <public@stefan-nagy.at>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The count variable in acpi_processor_preregister_performance() is
only initalized as 1 for one CPU and incremented when another CPU
sharing the same dependency domain is found. It isn't referenced
anywhere else, so drop it.
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI_PROCESSOR_FILE_INFO, ACPI_PROCESSOR_FILE_THROTTLING and
ACPI_PROCESSOR_FILE_LIMIT are used for procfs, but this feature was removed
in commit d09fe555 (ACPI processor: remove deprecated ACPI procfs I/F) long
ago. So, these macros should also be removed.
ACPI_PROCESSOR_LIMIT_USER and ACPI_PROCESSOR_LIMIT_THERMAL are not used
by any code, remove them too.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The interactions between the ACPI dock driver and the ACPI-based PCI
hotplug (acpiphp) are currently problematic because of ordering
issues during hot-remove operations.
First of all, the current ACPI glue code expects that physical
devices will always be deleted before deleting the companion ACPI
device objects. Otherwise, acpi_unbind_one() will fail with a
warning message printed to the kernel log, for example:
[ 185.026073] usb usb5: Oops, 'acpi_handle' corrupt
[ 185.035150] pci 0000:1b:00.0: Oops, 'acpi_handle' corrupt
[ 185.035515] pci 0000:18:02.0: Oops, 'acpi_handle' corrupt
[ 180.013656] port1: Oops, 'acpi_handle' corrupt
This means, in particular, that struct pci_dev objects have to
be deleted before the struct acpi_device objects they are "glued"
with.
Now, the following happens the during the undocking of an ACPI-based
dock station:
1) hotplug_dock_devices() invokes registered hotplug callbacks to
destroy physical devices associated with the ACPI device objects
depending on the dock station. It calls dd->ops->handler() for
each of those device objects.
2) For PCI devices dd->ops->handler() points to
handle_hotplug_event_func() that queues up a separate work item
to execute _handle_hotplug_event_func() for the given device and
returns immediately. That work item will be executed later.
3) hotplug_dock_devices() calls dock_remove_acpi_device() for each
device depending on the dock station. This runs acpi_bus_trim()
for each of them, which causes the underlying ACPI device object
to be destroyed, but the work items queued up by
handle_hotplug_event_func() haven't been started yet.
4) _handle_hotplug_event_func() queued up in step 2) are executed
and cause the above failure to happen, because the PCI devices
they handle do not have the companion ACPI device objects any
more (those objects have been deleted in step 3).
The possible breakage doesn't end here, though, because
hotplug_dock_devices() may return before at least some of the
_handle_hotplug_event_func() work items spawned by it have a
chance to complete and then undock() will cause _DCK to be
evaluated and that will cause the devices handled by the
_handle_hotplug_event_func() to go away possibly while they are
being accessed.
This means that dd->ops->handler() for PCI devices should not point
to handle_hotplug_event_func(). Instead, it should point to a
function that will do the work of _handle_hotplug_event_func()
synchronously. For this reason, introduce such a function,
hotplug_event_func(), and modity acpiphp_dock_ops to point to
it as the handler.
Unfortunately, however, this is not sufficient, because if the dock
code were not changed further, hotplug_event_func() would now
deadlock with hotplug_dock_devices() that called it, since it would
run unregister_hotplug_dock_device() which in turn would attempt to
acquire the dock station's hp_lock mutex already acquired by
hotplug_dock_devices().
To resolve that deadlock use the observation that
unregister_hotplug_dock_device() won't need to acquire hp_lock
if PCI bridges the devices on the dock station depend on are
prevented from being removed prematurely while the first loop in
hotplug_dock_devices() is in progress.
To make that possible, introduce a mechanism by which the callers of
register_hotplug_dock_device() can provide "init" and "release"
routines that will be executed, respectively, during the addition
and removal of the physical device object associated with the
given ACPI device handle. Make acpiphp use two new functions,
acpiphp_dock_init() and acpiphp_dock_release(), that call
get_bridge() and put_bridge(), respectively, on the acpiphp bridge
holding the given device, for this purpose.
In addition to that, remove the dock station's list of
"hotplug devices" and make the dock code always walk the whole list
of "dependent devices" instead in such a way that the loops in
hotplug_dock_devices() and dock_event() (replacing the loops over
"hotplug devices") will take references to the list entries that
register_hotplug_dock_device() has been called for. That prevents
the "release" routines associated with those entries from being
called while the given entry is being processed and for PCI
devices this means that their bridges won't be removed (by a
concurrent thread) while hotplug_event_func() handling them is
being executed.
This change is based on two earlier patches from Jiang Liu.
References: https://bugzilla.kernel.org/show_bug.cgi?id=59501
Reported-and-tested-by: Alexander E. Patrakov <patrakov@gmail.com>
Tracked-down-by: Jiang Liu <jiang.liu@huawei.com>
Tested-by: Illya Klymov <xanf@xanf.me>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Cc: 3.9+ <stable@vger.kernel.org>
Commit 3b63aaa70e (PCI: acpiphp: Do not use ACPI PCI subdriver
mechanism) introduced an ACPI dock support regression, because it
changed the relative initialization order of the ACPI dock subsystem
and the ACPI-based PCI hotplug (acpiphp).
Namely, the ACPI dock subsystem has to be initialized before
acpiphp_enumerate_slots() is first run, which after commit
3b63aaa70e happens during the initial enumeration of the PCI
hierarchy triggered by the initial ACPI namespace scan in
acpi_scan_init(). For this reason, the dock subsystem has to be
initialized before the initial ACPI namespace scan in
acpi_scan_init().
To make that happen, modify the ACPI dock subsystem to be
non-modular and add the invocation of its initialization routine,
acpi_dock_init(), to acpi_scan_init() directly before the initial
namespace scan.
[rjw: Changelog, removal of dock_exit().]
References: https://bugzilla.kernel.org/show_bug.cgi?id=59501
Reported-and-tested-by: Alexander E. Patrakov <patrakov@gmail.com>
Tested-by: Illya Klymov <xanf@xanf.me>
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Cc: 3.9+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Sort package only after null/bad elements have been removed.
Fixes a problem where the _CST sort was performed too early. This
change sorts the package only after null/bad elements have been
removed.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Sort list based on the C-state, remove invalid/zero entries.
ACPICA BZ 890. Lv Zheng.
Fixes these possible problems with the _CST object:
1. Sort the list ascending by C state type.
2. Ensure type cannot be zero.
3. A sub-package count of zero means _CST is meaningless.
4. Count must match the number of C state sub-packages.
References: https://bugs.acpica.org/show_bug.cgi?id=890
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Moved this longstanding repair to the relatively new predefined
name repair module. ACPICA BZ 783. Lv Zheng.
No functional change. This change simply moves the repair code from
where it was originally implemented to the (more recent) repair
module where it now belongs.
References: https://bugs.acpica.org/show_bug.cgi?id=783
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI drivers must not be bound to device objects having scan handlers
attatched to them, so make acpi_device_probe() fail with -EINVAL if the
device object being probed has an ACPI scan handler.
After this change the analogous check introduced into the ACPI video
driver by commit 8c9b7a7 (ACPI / video: Do not bind to device objects
with a scan handler) is not necessary any more and may be dropped, so
drop it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Tony Luck <tony.luck@gmail.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Commit 7cd8407 (ACPI / PM: Do not execute _PS0 for devices without
_PSC during initialization) introduced a regression on some systems
with Intel Lynxpoint Low-Power Subsystem (LPSS) where some devices
need to be powered up during initialization, but their device objects
in the ACPI namespace have _PS0 and _PS3 only (without _PSC or power
resources).
To work around this problem, make the ACPI LPSS driver power up
devices it knows about by using a new helper function
acpi_device_fix_up_power() that does all of the necessary
sanity checks and calls acpi_dev_pm_explicit_set() to put the
device into D0.
Reported-and-tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit 781d737 (ACPI: Drop power resources driver) introduced a
bug in the power resources initialization error code path causing
a NULL pointer to be referenced in acpi_release_power_resource()
if there's an error triggering a jump to the 'err' label in
acpi_add_power_resource(). This happens because the list_node
field of struct acpi_power_resource has not been initialized yet
at this point and doing a list_del() on it is a bad idea.
To prevent this problem from occuring, initialize the list_node
field of struct acpi_power_resource upfront.
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Since commit 3757b94 (ACPI / hotplug: Fix concurrency issues and
memory leaks) acpi_bus_scan() and acpi_bus_trim() must always be
called under acpi_scan_lock, but currently the following scenario
violating that requirement is possible:
write_undock()
handle_eject_request()
hotplug_dock_devices()
dock_remove_acpi_device()
acpi_bus_trim()
Fix that by making write_undock() acquire acpi_scan_lock before
calling handle_eject_request() as appropriate (begin_undock() is
under the lock too in analogy with acpi_dock_deferred_cb()).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
acpi_get_override_irq() was added because there was a problem with
buggy BIOSes passing wrong IRQ() resource for the RTC IRQ. The
commit that added the workaround was 61fd47e0c8 (ACPI: fix two
IRQ8 issues in IOAPIC mode).
With ACPI 5 enumerated devices there are typically one or more
extended IRQ resources per device (and these IRQs can be shared).
However, the acpi_get_override_irq() workaround forces all IRQs in
range 0 - 15 (the legacy ISA IRQs) to be edge triggered, active high
as can be seen from the dmesg below:
ACPI: IRQ 6 override to edge, high
ACPI: IRQ 7 override to edge, high
ACPI: IRQ 7 override to edge, high
ACPI: IRQ 13 override to edge, high
Also /proc/interrupts for the I2C controllers (INT33C2 and INT33C3) shows
the same thing:
7: 4 0 0 0 IO-APIC-edge INT33C2:00, INT33C3:00
The _CSR method for INT33C2 (and INT33C3) device returns following
resource:
Interrupt (ResourceConsumer, Level, ActiveLow, Shared,,, )
{
0x00000007,
}
which states that this is supposed to be level triggered, active low,
shared IRQ instead.
Fix this by making sure that acpi_get_override_irq() gets only called
when we are dealing with legacy IRQ() or IRQNoFlags() descriptors.
While we are there, correct pr_warning() to print the right triggering
value.
This change turns out to be necessary to make DMA work correctly on
systems based on the Intel Lynxpoint PCH (Platform Controller Hub).
[rjw: Changelog]
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The acpi_dev_pm_get_state() function defined in device_pm.c is quite
convoluted, which isn't really necessary, and it doesn't validate the
values returned by the ACPI methods executed by it appropriately.
To address these shortcomings modify it in the following way.
(1) Make its return value only mean whether or not it succeeded and
pass the device power states determined by it through pointers.
(2) Drop the d_max_in argument, used by only one of its callers,
from it, and move the code related to d_max_in into that caller,
acpi_pm_device_sleep_state().
(3) Make it always check the return value of acpi_evaluate_integer()
and handle failures as appropriate. Moreover, make it check if
the values returned by the executed ACPI methods are not out of
range.
(4) Make it check if the values returned by the executed ACPI
methods represent valid power states of the given device and
handle situations in which that's not the case gracefully.
Also update the kerneldoc comments of acpi_dev_pm_get_state() and
acpi_pm_device_sleep_state() to reflect the code changes.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The two symbols ACPI_STATE_D3 and ACPI_STATE_D3_COLD actually
represent the same number (4), but ACPI_STATE_D3 is slightly
ambigugous, because it may not be clear that it really means D3cold
and not D3hot at first sight.
Remove that ambiguity from drivers/acpi/device_pm.c by making it
use ACPI_STATE_D3_COLD everywhere instead of ACPI_STATE_D3.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There is a name clash between function acpi_device_power_state()
defined in drivers/acpi/device_pm.c and structure type
acpi_device_power_state defined in include/acpi/acpi_bus.h, which
may be resolved by renaming the function. Additionally, that
funtion may be made static, because it is not used anywhere outside
of the file it is defined in.
Rename acpi_device_power_state() to acpi_dev_pm_get_state(), which
better reflects its purpose, and make it static.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Since acpi_processor_suspend() and acpi_processor_resume() need not
be visible outside of the file they are defined in, make them
static.
[rjw: Changelog]
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Which by default will be x86_acpi_suspend_lowlevel.
This registration allows us to register another callback
if there is a need to use another platform specific callback.
Signed-off-by: Liang Tang <liang.tang@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Ben Guthro <benjamin.guthro@citrix.com>
Acked-by: "H. Peter Anvin" <hpa@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
These local variables are all initialized at their first use, so there's
no point in initializing them earlier.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add or remove spaces that give errors or warnings from checkpatch.pl.
Signed-off-by: Nicholas Mazzuca <nicholas@mazzucastuff.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Once do_acpi_find_child() has found the first matching handle, it
makes the acpi_get_child() loop stop and return that handle. On some
platforms, though, there are multiple devices with the same value of
"_ADR" in the same namespace scope, and if one of them is enabled,
the others will be disabled. For example:
Address : 0x1FFFF ; path : SB_PCI0.SATA.DEV0
Address : 0x1FFFF ; path : SB_PCI0.SATA.DEV1
Address : 0x1FFFF ; path : SB_PCI0.SATA.DEV2
If DEV0 and DEV1 are disabled and DEV2 is enabled, the handle of DEV2
should be returned, but actually the function always returns the
handle of DEV0.
To address that issue, make do_acpi_find_child() evaluate _STA to
check the device status. If a matching device object exists, but is
disabled, acpi_get_child() will continue to walk the namespace in the
hope of finding an enabled one. If one is found, its handle will be
returned, but otherwise the function will return the handle of the
disabled object found before (in case it is enabled going forward).
[rjw: Changelog]
Signed-off-by: Jeff Wu <zlinuxkernel@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
User space pointer may not be dereferenced. Use get_user()/put_user()
instead and check their return codes.
Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The SDIO device in Lynxpoint has its LTR registers reserved for a
WiFi device (a child of the SDIO device) in the ACPI namespace even
though those registers physically belong to the SDIO device itself.
In order to be able to access the SDIO LTR registers from the ACPI
LPSS driver for diagnostic purposes we need to use a size override
for the SDIO private register space.
Add a possibility to override the size of the private register space
of an LPSS device provided by the ACPI tables in the ACPI LPSS driver
and set the correct size for the SDIO device in there.
[rjw: Changelog]
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Intel LPSS provides an extra TX byte counter and an extra TX
completion interrupt for some of its bus controllers. However,
there is no use for the extra UART interrupt and it has to be
masked out during initialization.
Otherwise, if the firmware does not mask the interrupt and
the driver does not clear it, it may cause an interrupt flood
freezing the board to happen.
Add code masking that problematic interrupt to the ACPI LPSS driver.
[rjw: Changelog]
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Intel BayTrail has almost the same Low Power Subsystem than Lynxpoint with
few differences. Peripherals are clocked with different speeds (typically
lower) and the clock is not always gated. To support this we add
possibility to share a common fixed rate clock and make clock gating
optional.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Clear this flag to allow clean startup and even double termination.
ACPICA BZ 1013. Tomasz Nowicki <tomasz.nowicki@linaro.org>
References: https://bugs.acpica.org/show_bug.cgi?id=1013
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reviewed-by: Len Brown <len.brown@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Some GPE blocks were not deleted. ACPICA BZ 1018. Tomasz Nowicki
<tomasz.nowicki@linaro.org>
References: https://bugs.acpica.org/show_bug.cgi?id=1018
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reviewed-by: Len Brown <len.brown@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add deletion of this lock, used for the global lock. ACPICA BZ
1012. Tomasz Nowicki <tomasz.nowicki@linaro.org>
References: https://bugs.acpica.org/show_bug.cgi?id=1012
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reviewed-by: Len Brown <len.brown@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Clean up the interface by making the input argument a char *
string instead of a UINT32 name. This is easier to use for all
callers and eliminates casting to *(UINT32*)
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Previous implementation incorrectly used the ACPI 5.0 extended
sleep registers if they were simply populated. This caused
problems on some non-HW-reduced machines. As per the ACPI spec,
they should only be used if the HW-reduced bit is set. Lv Zheng,
ACPICA BZ 1020.
References: https://bugzilla.kernel.org/show_bug.cgi?id=54181
References: https://bugs.acpica.org/show_bug.cgi?id=1020
Reported-by: Daniel Rowe <bart@fathom13.com>
Bisected-by: Brint E. Kriebel <kernel@bekit.net>
Cc: 3.4+ <stable@vger.kernel.org>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Improves configurability of ACPICA.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Optionally do not load any SSDTs from the RSDT/XSDT during
initialization. This can be useful for overriding SSDTs
using DSDT overriding, thus useful for debugging ACPI
problems on some machines. Lv Zheng. ACPICA BZ 1005.
References: https://bugs.acpica.org/show_bug.cgi?id=1005
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
After many years, different formatting for switch() has crept in.
This change makes every switch block identical. Chao Guan.
ACPICA bugzilla 997.
References: https://bugs.acpica.org/show_bug.cgi?id=997
Signed-off-by: Chao Guan <chao.guan@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Improves configurability of ACPICA.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
To enhance configurability of ACPICA. The new file is
utilities/utbuffer.c
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There is no particular reason why acpi_bus_driver_init() needs to be
a separate function and its location with respect to its only caller,
acpi_device_probe(), makes the code a bit difficult to follow.
Besides, it doesn't really make sense to check if 'device' is not
NULL in acpi_bus_driver_init(), because we've already dereferenced
dev->driver in acpi_device_probe() at that point and, moreover,
'device' cannot be NULL then, because acpi_device_probe() is called
via really_probe() (which also sets dev->driver for that matter).
For these reasons, drop acpi_bus_driver_init() altogether and move
the remaining code from it directly into acpi_device_probe().
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
With the introduction of ACPI scan handlers, ACPI device objects
with an ACPI scan handler attached to them must not be bound to
by ACPI drivers any more. Unfortunately, however, the ACPI video
driver attempts to do just that if there is a _ROM ACPI control
method defined under a device object with an ACPI scan handler.
Prevent that from happening by making the video driver's "add"
routine check if the device object already has an ACPI scan handler
attached to it and return an error code in that case.
That is not sufficient, though, because acpi_bus_driver_init() would
then clear the device object's driver_data that may be set by its
scan handler, so for the fix to work acpi_bus_driver_init() has to be
modified to leave driver_data as is on errors.
References: https://bugzilla.kernel.org/show_bug.cgi?id=58091
Bisected-and-tested-by: Dmitry S. Demin <dmitryy.demin@gmail.com>
Reported-and-tested-by: Jason Cassell <bluesloth600@gmail.com>
Tracked-down-by: Aaron Lu <aaron.lu@intel.com>
Cc: 3.9+ <stable@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
Commit 9f29ab11dd ("ACPI / scan: do not match drivers against objects
having scan handlers") introduced a boot regression on Tony's ia64 HP
rx2600. Tony says:
"It panics with the message:
Kernel panic - not syncing: Unable to find SBA IOMMU: Try a generic or DIG kernel
[...] my problem comes from arch/ia64/hp/common/sba_iommu.c
where the code in sba_init() says:
acpi_bus_register_driver(&acpi_sba_ioc_driver);
if (!ioc_list) {
but because of this change we never managed to call ioc_init()
so ioc_list doesn't get set up, and we die."
Revert it to avoid this breakage and we'll fix the problem it attempted
to address later.
Reported-by: Tony Luck <tony.luck@gmail.com>
Cc: 3.9+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* pci/betty-aer-v3:
PCI/AER: Reset link for devices below Root Port or Downstream Port
ACPI / APEI: Force fatal AER severity when component has been reset
PCI/AER: Remove "extern" from function declarations
PCI/AER: Move AER severity defines to aer.h
PCI/AER: Set dev->__aer_firmware_first only for matching devices
PCI/AER: Factor out HEST device type matching
PCI/AER: Don't parse HEST table for non-PCIe devices
* acpi-fixes:
ACPI / PM: Do not execute _PS0 for devices without _PSC during initialization
ACPI / scan: do not match drivers against objects having scan handlers
ACPI / APEI: fix error return code in ghes_probe()
ACPI / video: ignore BIOS initial backlight value for HP Pavilion g6
ACPI / video: ignore BIOS initial backlight value for HP m4
x86 / platform / hp_wmi: Fix bluetooth_rfkill misuse in hp_wmi_rfkill_setup()
Commit b378549 (ACPI / PM: Do not power manage devices in unknown
initial states) added code to force devices without _PSC, but having
_PS0 defined in the ACPI namespace, into ACPI power state D0 by
executing _PS0 for them. That turned out to break Toshiba P870-303,
however, so revert that code.
References: https://bugzilla.kernel.org/show_bug.cgi?id=58201
Reported-and-tested-by: Jerome Cantenot <jerome.cantenot@gmail.com>
Tracked-down-by: Lan Tianyu <tianyu.lan@intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
When param1 is enabled in EINJ but not assigned with a valid
value, sometimes it will cause the error like below:
APEI: Can not request [mem 0x7aaa7000-0x7aaa7007] for APEI EINJ Trigger registers
It is because some firmware will access target address specified in
param1 to trigger the error when injecting memory error. This will
cause resource conflict with regular memory. So It must be removed
from trigger table resources, but incorrect param1/param2
combination will stop this action. Add extra check to avoid
this kind of error.
Signed-off-by: Chen Gong <gong.chen@linux.intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
The CPER error record has a reset bit that indicates that the platform
has reset the component. The reset bit can be set for any severity
error including recoverable. From the AER code path's perspective,
any error is fatal if the component has been reset. This patch
upgrades the severity of the AER recovery to AER_FATAL whenever the
CPER error record indicates that the component has been reset.
[bhelgaas: s/bus has been reset/component has been reset/]
Signed-off-by: Betty Dall <betty.dall@hp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Fix to return -ENOMEM in the debugfs_create_xxx() error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Reviewed-by: Chen Gong <gong.chen@linux.intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
With the introduction of ACPI scan handlers, an ACPI device object
with an ACPI scan handler attached to it must not be bound to an ACPI
driver any more. Therefore it doesn't make sense to match those
ACPI device objects against a newly registered ACPI driver in
acpi_bus_match(), so make that function return 0 if the device
object passed to it has an ACPI scan handler attached.
This also addresses a regression related to a broken ACPI table in
the BIOS, where it has defined a _ROM method under the PCI root
bridge object. This causes the video module to treat that object
as a display controller device (since only display devices are
supposed to have a _ROM method defined according to the ACPI spec).
As a result, the ACPI video driver binds to the PCI root bridge
object and overwrites the previously assigned driver_data field of
it, causing subsequent calls to acpi_get_pci_dev() to fail.
[rjw: Subject and changelog]
References: https://bugzilla.kernel.org/show_bug.cgi?id=58091
Reported-by: Jason Cassell <bluesloth600@gmail.com>
Reported-and-bisected-by: Dmitry S. Demin <dmitryy.demin@gmail.com>
Cc: 3.9+ <stable@kernel.org>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Fix to return a negative error code in the acpi_gsi_to_irq() and
request_irq() error handling case instead of 0, as done elsewhere
in this function.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Reviewed-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The "runtime idle" helper routine, rpm_idle(), currently ignores
return values from .runtime_idle() callbacks executed by it.
However, it turns out that many subsystems use
pm_generic_runtime_idle() which checks the return value of the
driver's callback and executes pm_runtime_suspend() for the device
unless that value is not 0. If that logic is moved to rpm_idle()
instead, pm_generic_runtime_idle() can be dropped and its users
will not need any .runtime_idle() callbacks any more.
Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
ata_port_runtime_idle(), respectively, as well as a few drivers'
ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has
been returned by the .runtime_idle() callback executed by it.
To reduce overall code bloat, make the changes described above.
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Kevin Hilman <khilman@linaro.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
* pci/jiang-remove-global-list:
PCI/ACPI: Use dev_printk(), acpi_handle_print(), pr_xxx() when possible
PCI/ACPI: Remove unused global list acpi_pci_roots
PCI/ACPI: Introduce "handle" local for economy of expression
PCI/ACPI: Combine duplicate adjacent "if" tests
This patch addresses kernel bug 56661. BIOS reports an incorrect
backlight value, causing the driver to switch off the backlight
completely during startup. This patch ignores the incorrect value from
BIOS.
References: https://bugzilla.kernel.org/show_bug.cgi?id=56661
Signed-off-by: Ash Willis <ashwillis@programmer.net>
Cc: All <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
On HP m4 lapops, BIOS reports minimum backlight on boot and
causes backlight to dim completely. This ignores the initial backlight
values and set to max brightness.
References: https://bugs.launchpad.net/bugs/1184501
Cc: All <stable@vger.kernel.org>
Signed-off-by: Alex Hung <alex.hung@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In acpi_processor_add(), get_cpu_device() may return NULL in some cases
which is then passed to acpi_bind_one() and that will case a NULL
pointer dereference to occur.
Add a check to prevent that from happening.
[rjw: Changelog]
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This refers to _REG methods under the EC device that have no
corresponding operation region. This is allowed by the ACPI
specification. This update removes a dependency on having an
ECDT table, and will execute an orphan _REG method as long as
the handler for the EC is installed at the EC device node (not
the namespace root). Rui Zhang (original update), Bob Moore
(update/integrate).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
"Pathname" is no longer used.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Fully implements typechecking on all incoming arguments for all
predefined names. This ensures that ACPI-related drivers are
passing the correct number of arguments, each of the correct
object type.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
BIOS error message for errors found in predefined names.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Change the exception code for the case where the input DdbHandle
is invalid from AE_BAD_PARAMETER to the more appropriate
AE_AML_OPERAND_TYPE.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Now that the memory offlining should be taken care of by the
companion device offlining code in acpi_scan_hot_remove(), the
ACPI memory hotplug driver doesn't need to offline it in
remove_memory() any more. Moreover, since the return value of
remove_memory() is not used, it's better to make it be a void
function and trigger a BUG() if the memory scheduled for removal is
not offline.
Change the code in accordance with the above observations.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
As indicated by comments in mm/memory_hotplug.c:remove_memory(),
if CONFIG_MEMCG is set, it may not be possible to offline all of the
memory blocks held by one module (FRU) in one pass (because one of
them may be used by the others to store page cgroup in that case
and that block has to be offlined before the other ones).
To handle that arguably corner case, add a second pass of companion
device offlining to acpi_scan_hot_remove() and make it ignore errors
returned in the first pass (and make it skip the second pass if the
first one is successful).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Make acpi_processor_add() pass the ACPI handle of the processor
namespace object to acpi_bind_one() instead of setting it directly
to allow acpi_bind_one() to catch possible bugs causing the ACPI
handle of the processor device to be set earlier.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
The ACPI processor driver was the only user of the removal_type
field in struct acpi_device, but it doesn't use that field any more
after recent changes. Thus, removal_type has no more users, so drop
it along with the associated data type.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Commit ac212b6 (ACPI / processor: Use common hotplug infrastructure)
forgot about initializing the per-CPU 'processors' variables which
lead to ACPI cpuidle failure to use C-states and caused boot slowdown
on multi-CPU machines.
Fix the problem by adding per_cpu(processors, pr->id) initialization
to acpi_processor_add() and add make acpi_processor_remove() clean it
up as appropriate.
Also modify acpi_processor_stop() so that it doesn't clear
per_cpu(processors, pr->id) on processor driver removal which would
then cause problems to happen when the driver is loaded again.
This version of the patch contains fixes from Yinghai Lu.
Reported-and-tested-by: Yinghai Lu <yinghai@kernel.org>
Reported-and-tested-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The following warning was seen on 3.9 when a corrected PCIe error was being
handled by the AER subsystem.
WARNING: at .../drivers/pci/search.c:214 pci_get_dev_by_id+0x8a/0x90()
This occurred because a call to pci_get_domain_bus_and_slot() was added to
cper_print_pcie() to setup for the call to cper_print_aer(). The warning
showed up because cper_print_pcie() is called in an interrupt context and
pci_get* functions are not supposed to be called in that context.
The solution is to move the cper_print_aer() call out of the interrupt
context and into aer_recover_work_func() to avoid any warnings when calling
pci_get* functions.
Signed-off-by: Lance Ortiz <lance.ortiz@hp.com>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Use dev_printk(), acpi_handle_print(), and pr_xxx() to print messages
in pci_root.c.
[bhelgaas: fold in dev_printk() changes, use dev_printk() in
handle_root_bridge_insertion()]
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Len Brown <lenb@kernel.org>
Now the global list acpi_pci_roots pci_root.c is useless, remove it.
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Len Brown <lenb@kernel.org>
[bhelgaas: split out from acpi_handle_printk() changes]
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
- Additional CPU ID for the intel_pstate driver from Dirk Brandewie.
- More cpufreq fixes related to ARM big.LITTLE support and locking from
Viresh Kumar.
- VIA C7 cpufreq build fix from Rafał Bilski.
- ACPI power management fix making it possible to use device power
states regardless of the CONFIG_PM setting from Rafael J. Wysocki.
- New ACPI video blacklist item from Bastian Triller.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJRoRZjAAoJEKhOf7ml8uNsv9wQAKAMs9J8k6XqgNPisFKetw+K
hzCOsKFOpI0BQKFikgtWjhGre1SyNIRUvLXO7BHFHXYQW6cLvn1jAyJhvl+i4nvT
eOa+vdGd6grWncbhIxeidoyk9hTZ6bdMWlTBvKUz5KpHzvp4YGC2jlvwFwqsJkpg
nQ8Hcbrbhm4vz5h7EmrlYcELBNTi5LQtmnqlxtbn02GX75BFTpkCm5aLZWZNEUrE
Hix8BhN41+hSy+K34ztHFlP5g/s/lIa9dOX1tewqSigkDB/qYYIt2lpdD2icOIOW
qHAtvpZq8/fZOcoZ9KdFqKUjjbuKVavldb+YzGeTLQufOAwb4hgMRvAccdNFMHIW
9tVkp2TcK6K7pAYlXtgEf25ka7ulLWDBd4C662gZfpi+oPKx2BI/6m7J4VoTULeb
30hDMyZXrXWWvStwO05Pyno3W5lG+cn9jytc3hKkaFerb53NHcZHfb0Rih5NhDZD
Ep09IuPE8fOT9KndY2kw/WwoZyJurYCbrgE+G1QyA+hsNPkNhPlGTxdL8vCqxM4K
ZOaQQejpd1bXBSk8Koz8LRyQ38KJByvM64B0EDSP6BQUT+rlbkcvog1bJV+UdpbJ
4TlhrAFlobhRFQBqlIbRqMXFPH31YSm7wVK1eK/gEqNZI935Kd17YSFf8yyi2yli
vBlmPkiPEIJHysps+tvd
=Srt8
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-3.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management and ACPI fixes from Rafael Wysocki:
- Additional CPU ID for the intel_pstate driver from Dirk Brandewie.
- More cpufreq fixes related to ARM big.LITTLE support and locking from
Viresh Kumar.
- VIA C7 cpufreq build fix from Rafał Bilski.
- ACPI power management fix making it possible to use device power
states regardless of the CONFIG_PM setting from Rafael J Wysocki.
- New ACPI video blacklist item from Bastian Triller.
* tag 'pm+acpi-3.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI / video: Add "Asus UL30A" to ACPI video detect blacklist
cpufreq: arm_big_little_dt: Instantiate as platform_driver
cpufreq: arm_big_little_dt: Register driver only if DT has valid data
cpufreq / e_powersaver: Fix linker error when ACPI processor is a module
cpufreq / intel_pstate: Add additional supported CPU ID
cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXIT
ACPI / PM: Allow device power states to be used for CONFIG_PM unset
Pull slave-dma fixes from Vinod Koul:
"We have two patches from Andy & Rafael fixing the Lynxpoint dma"
* 'fixes' of git://git.infradead.org/users/vkoul/slave-dma:
ACPI / LPSS: register clock device for Lynxpoint DMA properly
dma: acpi-dma: parse CSRT to extract additional resources
Moorestown
Revert "x86/pci/mrst: Use configuration mechanism 1 for 00:00.0, 00:02.0, 00:03.0"
Hotplug
PCI: acpiphp: Re-enumerate devices when host bridge receives Bus Check
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJRnnUuAAoJEFmIoMA60/r8+JwQALrHdQvA8rGl/TNF0xkJjsU+
EfdkBj23+qYYsYNla7Z/CfY7k5gXTtymqauhzpa1VRoY/bkpSWMDBxK551CxgBae
RW0JbZxfoswLlA9eVRUz6mlUl7hL0Ky0/E6d9/UBXSAC0wsN6BB11lqKgi/uxAr2
ACuZBZW1EZP9zoD615Id5gtRAZe8+9w47p8d6kQcyJntmCoZwo8Na/HRE/tR+wVY
o3AHMxMOr9Ac+G3/rFl5ffzoHkLwTws4UEVNhvKBek3ogsAau3tgeIgjjvFRToFh
HxsdpCmgOAfjCF/RC0AxRugtykHw4n3WlaND2WM6JWolLeIQTZr41GlwYy4F1CRG
gSRk0dMNGBYs9OgDC81KJGYqstHwL0MTig2ul4BvlrLanLnySgVu1kbhaerR3WzA
11k0GwlJbkFMCbQLZDaq51KHAdDYnCsRVG/tOGmsM8puUPOTXu3pLbPk3SbgWVGc
7vbUkjJlHwlNoUbeyOOOElUMCRnIiCl/IetwjgZb+Qibq2dO4v6WF5GR+2DPBwua
8GNbzQXyNxOPzvYBHE4YgK5lcb7yVeLvlOtPgbM0UMqC1SnFISzJRiNpfbj21rAk
ADT4lqL29vqkX37uIQ55KPeTTThA65EKUoI3+dNtGHLSPoKdt3QlJc9wwQNKxEzx
EEHxGRkebYNcPB1GqwEl
=M8/H
-----END PGP SIGNATURE-----
Merge tag 'pci-v3.10-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
Pull PCI updates from Bjorn Helgaas:
"Here are some more fixes for v3.10. The Moorestown update broke Intel
Medfield devices, so I reverted it. The acpiphp change fixes a
regression: we broke hotplug notifications to host bridges when we
split acpiphp into the host-bridge related part and the
endpoint-related part.
Moorestown
Revert "x86/pci/mrst: Use configuration mechanism 1 for 00:00.0, 00:02.0, 00:03.0"
Hotplug
PCI: acpiphp: Re-enumerate devices when host bridge receives Bus Check"
* tag 'pci-v3.10-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
Revert "x86/pci/mrst: Use configuration mechanism 1 for 00:00.0, 00:02.0, 00:03.0"
PCI: acpiphp: Re-enumerate devices when host bridge receives Bus Check
Like on UL30VT, the ACPI video driver can't control backlight correctly on
Asus UL30A. Vendor driver (asus-laptop) can work. This patch is to
add "Asus UL30A" to ACPI video detect blacklist in order to use
asus-laptop for video control on the "Asus UL30A" rather than ACPI
video driver.
Signed-off-by: Bastian Triller <bastian.triller@gmail.com>
Cc: All <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Currently, drivers/acpi/device_pm.c depends on CONFIG_PM and all of
the functions defined in there are replaced with static inline stubs
if that option is unset. However, CONFIG_PM means, roughly, "runtime
PM or suspend/hibernation support" and some of those functions are
useful regardless of that. For example, they are used by the ACPI
fan driver for controlling fans and acpi_device_set_power() is called
during device removal. Moreover, device initialization may depend on
setting device power states properly.
For these reasons, make the routines manipulating ACPI device power
states defined in drivers/acpi/device_pm.c available for CONFIG_PM
unset too.
Reported-by: Zhang Rui <rui.zhang@intel.com>
Reported-and-tested-by: Michel Lespinasse <walken@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
When a PCI host bridge device receives a Bus Check notification, we
must re-enumerate starting with the bridge to discover changes (devices
that have been added or removed).
Prior to 668192b678 ("PCI: acpiphp: Move host bridge hotplug to
pci_root.c"), this happened in _handle_hotplug_event_bridge(). After that
commit, _handle_hotplug_event_bridge() is not installed for host bridges,
and the host bridge notify handler, _handle_hotplug_event_root() did not
re-enumerate.
This patch adds re-enumeration to _handle_hotplug_event_root().
This fixes cases where we don't notice the addition or removal of
PCI devices, e.g., the PCI-to-USB ExpressCard in the bugzilla below.
[bhelgaas: changelog, references]
Reference: https://lkml.kernel.org/r/CAAh6nkmbKR3HTqm5ommevsBwhL_u0N8Rk7Wsms_LfP=nBgKNew@mail.gmail.com
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=57961
Reported-by: Gavin Guo <tuffkidtt@gmail.com>
Tested-by: Gavin Guo <tuffkidtt@gmail.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jiang Liu <jiang.liu@huawei.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CC: stable@vger.kernel.org # v3.9+
Following commit 6b772e8f9 (ACPI: Update PNPID match handling for
notify), the acpi_scan_init_hotplug() calls acpi_set_pnp_ids() which
allocates acpi_hardware_id and copies a few strings (kstrdup). If the
devices does not have hardware_id set, the function exits without
freeing the previously allocated ids (and kmemleak complains). This
patch calls simply changes 'return' on error to a 'goto out' which
calls acpi_free_pnp_ids().
Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
We should check the acpi_resource_to_address64() return value, which
also removes the need to validate the resource type beforehand.
No functional change.
Found by Coverity (CID 113815).
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The DMA controller in Lynxpoint is enumerated as a regular ACPI device now. To
work properly it is using the LPSS root clock as a functional clock. That's why
we have to register the clock device accordingly to the ACPI ID of the DMA
controller. The acpi_lpss.c module is responsible to do the job.
This patch also removes hardcoded name of the DMA device in clk-lpt.c and the
name of the root clock in acpi_lpss.c.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Since we have CSRT only to get additional DMA controller resources, let's get
rid of drivers/acpi/csrt.c and move its logic inside ACPI DMA helpers code.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
During ACPI memory hotplug configuration bind memory blocks residing
in modules removable through the standard ACPI mechanism to struct
acpi_device objects associated with ACPI namespace objects
representing those modules. Accordingly, unbind those memory blocks
from the struct acpi_device objects when the memory modules in
question are being removed.
When "offline" operation for devices representing memory blocks is
introduced, this will allow the ACPI core's device hot-remove code to
use it to carry out remove_memory() for those memory blocks and check
the results of that before it actually removes the modules holding
them from the system.
Since walk_memory_range() is used for accessing all memory blocks
corresponding to a given ACPI namespace object, it is exported from
memory_hotplug.c so that the code in acpi_memhotplug.c can use it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Split the ACPI processor driver into two parts, one that is
non-modular, resides in the ACPI core and handles the enumeration
and hotplug of processors and one that implements the rest of the
existing processor driver functionality.
The non-modular part uses an ACPI scan handler object to enumerate
processors on the basis of information provided by the ACPI namespace
and to hook up with the common ACPI hotplug infrastructure. It also
populates the ACPI handle of each processor device having a
corresponding object in the ACPI namespace, which allows the driver
proper to bind to those devices, and makes the driver bind to them
if it is readily available (i.e. loaded) when the scan handler's
.attach() routine is running.
There are a few reasons to make this change.
First, switching the ACPI processor driver to using the common ACPI
hotplug infrastructure reduces code duplication and size considerably,
even though a new file is created along with a header comment etc.
Second, since the common hotplug code attempts to offline devices
before starting the (non-reversible) removal procedure, it will abort
(and possibly roll back) hot-remove operations involving processors
if cpu_down() returns an error code for one of them instead of
continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove
is unset). That is a more desirable behavior than what the current
code does.
Finally, the separation of the scan/hotplug part from the driver
proper makes it possible to simplify the driver's .remove() routine,
because it doesn't need to worry about the possible cleanup related
to processor removal any more (the scan/hotplug part is responsible
for that now) and can handle device removal and driver removal
symmetricaly (i.e. as appropriate).
Some user-visible changes in sysfs are made (for example, the
'sysdev' link from the ACPI device node to the processor device's
directory is gone and a 'physical_node' link is present instead
and a corresponding 'firmware_node' is present in the processor
device's directory, the processor driver is now visible under
/sys/bus/cpu/drivers/ and bound to the processor device), but
that shouldn't affect the functionality that users care about
(frequency scaling, C-states and thermal management).
Tested on my venerable Toshiba Portege R500.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Modify the generic ACPI hotplug code to be able to check if devices
scheduled for hot-removal may be gracefully removed from the system
using the device offline/online mechanism introduced previously.
Namely, make acpi_scan_hot_remove() handling device hot-removal call
device_offline() for all physical companions of the ACPI device nodes
involved in the operation and check the results. If any of the
device_offline() calls fails, the function will not progress to the
removal phase (which cannot be aborted), unless its (new) force
argument is set (in case of a failing offline it will put the devices
offlined by it back online).
In support of 'forced' device hot-removal, add a new sysfs attribute
'force_remove' that will reside under /sys/firmware/acpi/hotplug/.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
The Thinkpad e530's BIOS notifies the AC device first and then
sleeps for certain amount of time before doing real work in the
EC event handler (_Qxx):
Method (_Q27, 0, NotSerialized)
{
Notify (AC, 0x80)
Sleep (0x03E8)
Store (Zero, PWRS)
PNOT ()
}
This causes the AC driver to report an outdated AC state to user
space, because it reads the state information from the device while
the EC handler is sleeping.
Introduce a quirk to cause the AC driver to wait in acpi_ac_notify()
before calling acpi_ac_get_state() on systems known to have this
problem and add Thinkpad e530 to the list of quirky machines (with
a 1s delay which has been verified to be sufficient for that
machine).
[rjw: Changelog]
References: https://bugzilla.kernel.org/show_bug.cgi?id=45221
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The EC driver works abnormally with IBF flag always set.
IBF means "The host has written a byte of data to the command
or data port, but the embedded controller has not yet read it".
If IBF is set in the EC status and not cleared, this will cause
all subsequent EC requests to fail with a timeout error.
Change the EC driver so that it doesn't refuse to restart a
transaction if IBF is set in the status. Also increase the
number of transaction restarts to 5, as it turns out that 2
is not sufficient in some cases.
This bug happens on several different machines (Asus V1S,
Dell Latitude E6530, Samsung R719, Acer Aspire 5930G,
Sony Vaio SR19VN and others).
[rjw: Changelog]
References: https://bugzilla.kernel.org/show_bug.cgi?id=14733
References: https://bugzilla.kernel.org/show_bug.cgi?id=15560
References: https://bugzilla.kernel.org/show_bug.cgi?id=15946
References: https://bugzilla.kernel.org/show_bug.cgi?id=42945
References: https://bugzilla.kernel.org/show_bug.cgi?id=48221
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Cc: All <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
On HP 1000 lapops, BIOS reports minimum backlight on boot and
causes backlight to dim completely. This ignores the initial backlight
values and set to max brightness.
References:: https://bugs.launchpad.net/bugs/1167760
Signed-off-by: Alex Hung <alex.hung@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The system suspend routine of the ACPI processor driver saves
the BUS_MASTER_RLD register and its resume routine restores it.
However, there can be only one such register in the system and it
really should be saved after non-boot CPUs have been offlined and
restored before they are put back online during resume.
For this reason, move the saving and restoration of BUS_MASTER_RLD
to syscore suspend and syscore resume, respectively, and drop the no
longer necessary suspend/resume callbacks from the ACPI processor
driver.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
- _INI regression fix from Tomasz Nowicki.
- Fix for a possible memory leak in _OSI support routine from
Jung-uk Kim.
- Fix for a possible buffer overflow during field unit read operation
from Bob Moore.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJRi/KxAAoJEKhOf7ml8uNsngoP/Rgf9MeSyyNcR51WECDT0nQM
mwImWCHi1fwa+IKuj3Bc+fSqnv+7UxSOn2fUXoddPgxjSjFD7aCoWYbaWMU0PMtH
zCCr/+n0+7OckbwbeQORbooOY3mwu1w4Y420FO6okGfznunGt5gvswd3nvC8SPdw
gUqo7ZfHSn4xygxEXt4jL6ckrKuVwezl8FjUUNwzyhg09X13YQIEjlJv0WqQJAIk
uswpxIasZAyWgyc40Tt7FooIbM1MWI87POZ8NAG6ZXDj76Lj4tIh+TYdWMfDaKU7
jM4jjWxhlFONqT2XcZAdMDG6Ec8Xw0BzRNhH7K/LhU7TH6YVBiV77l+tOzpM+t7s
JeJYzvmbuZtk3hFYRr2FtVKBD3mUD6M0A3KUlCDPHH7oyaGI+Ue08Lrio/9Wrpqp
VMZAEcmaUN5je5kWo1UXJBip/yTEF31hfjUxQbnV2G2VtPajmql8guke5VfIBz2W
Plcp7l7kIzY+ShMuOrr2HK1uQFXJENsMxsBKkkaEiKR48p8g3Ncmuj05n1gDOzPO
/s3osHTQOlYGYTAmIJnvH1M0+hEvIliwkwR1MpTAibYXm7x4TPVeodcG7tWQPZ8Y
1aN/KovstdT9VPbZhWe9SQRHIM7vd00nFKYFqCngeHO+fKCKJYawt3nLV2lu2De2
Qwtna1f9qNMdoa8Si822
=asD2
-----END PGP SIGNATURE-----
Merge tag 'acpi-fixes-3.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPICA fixes from Rafael Wysocki:
- _INI regression fix from Tomasz Nowicki.
- Fix for a possible memory leak in _OSI support routine from Jung-uk
Kim.
- Fix for a possible buffer overflow during field unit read operation
from Bob Moore.
* tag 'acpi-fixes-3.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPICA: ACPICA: Fix for _INI regression
ACPICA: _OSI support: Fix possible memory leak
ACPICA: Fix possible buffer overflow during a field unit read operation
This change fixes a problem introduced by recent commit c34c82b
(ACPICA: Predefine names: Add allowed argument types to master info
table) in 20130328 where _INI methods are no longer executed properly
because of a memory block that is not initialized properly. ACPICA
BZ1016. Tomasz Nowicki <tomasz.nowicki@linaro.org>
References: https://bugs.acpica.org/show_bug.cgi?id=1016
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Fixes a possible memory leak in the error exit path introduced by
recent commit 388a990 ("ACPICA: _OSI Support: handle any errors from
acpi_os_acquire_mutex()").
[rjw: Changelog]
Signed-off-by: Jung-uk Kim <jkim@FreeBSD.org>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Can only happen under these conditions: 1) The DSDT version is 1,
meaning integers are 32-bits. 2) The field is between 33 and 64
bits long.
It applies cleanly back to ACPICA 20100806+ (Linux v2.6.37+).
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: 2.6.37+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Pull VFS updates from Al Viro,
Misc cleanups all over the place, mainly wrt /proc interfaces (switch
create_proc_entry to proc_create(), get rid of the deprecated
create_proc_read_entry() in favor of using proc_create_data() and
seq_file etc).
7kloc removed.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (204 commits)
don't bother with deferred freeing of fdtables
proc: Move non-public stuff from linux/proc_fs.h to fs/proc/internal.h
proc: Make the PROC_I() and PDE() macros internal to procfs
proc: Supply a function to remove a proc entry by PDE
take cgroup_open() and cpuset_open() to fs/proc/base.c
ppc: Clean up scanlog
ppc: Clean up rtas_flash driver somewhat
hostap: proc: Use remove_proc_subtree()
drm: proc: Use remove_proc_subtree()
drm: proc: Use minor->index to label things, not PDE->name
drm: Constify drm_proc_list[]
zoran: Don't print proc_dir_entry data in debug
reiserfs: Don't access the proc_dir_entry in r_open(), r_start() r_show()
proc: Supply an accessor for getting the data from a PDE's parent
airo: Use remove_proc_subtree()
rtl8192u: Don't need to save device proc dir PDE
rtl8187se: Use a dir under /proc/net/r8180/
proc: Add proc_mkdir_data()
proc: Move some bits from linux/proc_fs.h to linux/{of.h,signal.h,tty.h}
proc: Move PDE_NET() to fs/proc/proc_net.c
...
- ARM big.LITTLE cpufreq driver from Viresh Kumar.
- exynos5440 cpufreq driver from Amit Daniel Kachhap.
- cpufreq core cleanup and code consolidation from Viresh Kumar and
Stratos Karafotis.
- cpufreq scalability improvement from Nathan Zimmer.
- AMD "frequency sensitivity feedback" powersave bias for the ondemand
cpufreq governor from Jacob Shin.
- cpuidle code consolidation and cleanups from Daniel Lezcano.
- ARM OMAP cpuidle fixes from Santosh Shilimkar and Daniel Lezcano.
- ACPICA fixes and other improvements from Bob Moore, Jung-uk Kim,
Lv Zheng, Yinghai Lu, Tang Chen, Colin Ian King, and Linn Crosetto.
- ACPI core updates related to hotplug from Toshi Kani, Paul Bolle,
Yasuaki Ishimatsu, and Rafael J. Wysocki.
- Intel Lynxpoint LPSS (Low-Power Subsystem) support improvements
from Rafael J. Wysocki and Andy Shevchenko.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJRf8M8AAoJEKhOf7ml8uNsud4P/3cabXP5lDipzibRrpOiONse
puuvIdhtNdMRMc3t1oSDjNH/w/JA51Gc+ICGFAORiyVmqxBc85mpT6J5ibqV7hNd
pCqbKJceoB5PajHZSx22e4wG9O7YN1k3r80p38IfFzA+Ct0KNSuE0ixMEfHKYjiq
p5pXswk6TY3gtBReH9agrafHqDtXw4IMTE0asMuJ+BorPW7vQeiNlrkuA+0qmDuu
26O0Pm2TVkx1ryfTjdM9zSZ9X2G4JuM8rm1/VFZWQJTExwlv3bA2Za1nvQNJlJ99
6JZ0JXfAehcEW2Ye0sqsZ8HSEabDVHM29QvvOszJ5RpBXERiOCHOkhvFleCoTpn0
Xq0rtXPrLMH1G28Ej+cxmsAjfzOLV2Byg30CAoI/GCLuQ+xh+VMCpuNYQuld25CG
9rtYd0fWESeYsAebhDcX0E3xyzJtbrHtOb9PyGwNkbAJ8YQfhVSMCOPi2SX2wa+Q
qXLXi2VaHvjBSUKcAv5BmM+Ya57Be+88D0LxbgXbUeOnYefUK1ljldKDDshkMjgG
P4LPdm4JpoB5ncXSOO1Dz9w9QnNcFexSUySd/TtKLNMha1vEHV8ISzNPYY+9IdXf
XN0VZbFnUDzdj+Fwna7zyFb1cGihDYJKAtpXvRd8Y6RGUxKx9uGLAFJZw/xZB/cR
KZKuML5O8MgJuef37F38
=H/se
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-3.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management and ACPI updates from Rafael J Wysocki:
- ARM big.LITTLE cpufreq driver from Viresh Kumar.
- exynos5440 cpufreq driver from Amit Daniel Kachhap.
- cpufreq core cleanup and code consolidation from Viresh Kumar and
Stratos Karafotis.
- cpufreq scalability improvement from Nathan Zimmer.
- AMD "frequency sensitivity feedback" powersave bias for the ondemand
cpufreq governor from Jacob Shin.
- cpuidle code consolidation and cleanups from Daniel Lezcano.
- ARM OMAP cpuidle fixes from Santosh Shilimkar and Daniel Lezcano.
- ACPICA fixes and other improvements from Bob Moore, Jung-uk Kim, Lv
Zheng, Yinghai Lu, Tang Chen, Colin Ian King, and Linn Crosetto.
- ACPI core updates related to hotplug from Toshi Kani, Paul Bolle,
Yasuaki Ishimatsu, and Rafael J Wysocki.
- Intel Lynxpoint LPSS (Low-Power Subsystem) support improvements from
Rafael J Wysocki and Andy Shevchenko.
* tag 'pm+acpi-3.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (192 commits)
cpufreq: Revert incorrect commit 5800043
cpufreq: MAINTAINERS: Add co-maintainer
cpuidle: add maintainer entry
ACPI / thermal: do not always return THERMAL_TREND_RAISING for active trip points
ARM: s3c64xx: cpuidle: use init/exit common routine
cpufreq: pxa2xx: initialize variables
ACPI: video: correct acpi_video_bus_add error processing
SH: cpuidle: use init/exit common routine
ARM: S5pv210: compiling issue, ARM_S5PV210_CPUFREQ needs CONFIG_CPU_FREQ_TABLE=y
ACPI: Fix wrong parameter passed to memblock_reserve
cpuidle: fix comment format
pnp: use %*phC to dump small buffers
isapnp: remove debug leftovers
ARM: imx: cpuidle: use init/exit common routine
ARM: davinci: cpuidle: use init/exit common routine
ARM: kirkwood: cpuidle: use init/exit common routine
ARM: calxeda: cpuidle: use init/exit common routine
ARM: tegra: cpuidle: use init/exit common routine for tegra3
ARM: tegra: cpuidle: use init/exit common routine for tegra2
ARM: OMAP4: cpuidle: use init/exit common routine
...
Bob Moore