To avoid build problems and breaking dependencies between ACPI header
files, <acpi/acpi.h> should not be included directly by code outside
of the ACPI core subsystem. However, that is possible if
<linux/acpi_io.h> is included, because that file contains
a direct inclusion of <acpi/acpi.h>.
For this reason, remove the direct <acpi/acpi.h> inclusion from
<linux/acpi_io.h>, move that file from include/linux/ to include/acpi/
and make <linux/acpi.h> include it for CONFIG_ACPI set along with the
other ACPI header files. Accordingly, Remove the inclusions of
<linux/acpi_io.h> from everywhere.
Of course, that causes the contents of the new <acpi/acpi_io.h> file
to be available for CONFIG_ACPI set only, so intel_opregion.o that
depends on it should also depend on CONFIG_ACPI (and it really should
not be compiled for CONFIG_ACPI unset anyway).
References: https://01.org/linuxgraphics/sites/default/files/documentation/acpi_igd_opregion_spec.pdf
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[rjw: Subject and changelog]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and
<acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h>
inclusions and remove some inclusions of those files that aren't
necessary.
First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>
should not be included directly from any files that are built for
CONFIG_ACPI unset, because that generally leads to build warnings about
undefined symbols in !CONFIG_ACPI builds. For CONFIG_ACPI set,
<linux/acpi.h> includes those files and for CONFIG_ACPI unset it
provides stub ACPI symbols to be used in that case.
Second, there are ordering dependencies between those files that always
have to be met. Namely, it is required that <acpi/acpi_bus.h> be included
prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the
latter depends on are always there. And <acpi/acpi.h> which provides
basic ACPICA type declarations should always be included prior to any other
ACPI headers in CONFIG_ACPI builds. That also is taken care of including
<linux/acpi.h> as appropriate.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff)
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
If an ACPI namespace node is removed (usually, as a result of a
table unload), and there is a data object attached to that node,
acpi_ns_delete_node() executes the removal handler submitted to
acpi_attach_data() for that object. That handler is currently empty
for struct acpi_device objects, so it is necessary to detach those
objects from the corresponding ACPI namespace nodes in advance every
time a table unload may happen. That is cumbersome and inefficient
and leads to some design constraints that turn out to be quite
inconvenient (in particular, struct acpi_device objects cannot be
registered for namespace nodes representing devices that are not
reported as present or functional by _STA).
For this reason, introduce a non-empty removal handler for ACPI
device objects that will unregister them when their ACPI namespace
nodes go away.
This code modification alone should not change functionality except
for the ordering of the ACPI hotplug workqueue which should not
matter (without subsequent code changes).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
There are two different interfaces for queuing up work items on the
ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
bridge hotplug code and acpi_os_hotplug_execute() used by the common
ACPI hotplug code and docking stations. They both are somewhat
cumbersome to use and work slightly differently.
The users of alloc_acpi_hp_work() have to submit a work function that
will extract the necessary data items from a struct acpi_hp_work
object allocated by alloc_acpi_hp_work() and then will free that
object, while it would be more straightforward to simply use a work
function with one more argument and let the interface take care of
the execution details.
The users of acpi_os_hotplug_execute() also have to deal with the
fact that it takes only one argument in addition to the work function
pointer, although acpi_os_execute_deferred() actually takes care of
the allocation and freeing of memory, so it would have been able to
pass more arguments to the work function if it hadn't been
constrained by the connection with acpi_os_execute().
Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
allocations, which is correct, because hotplug work items are
always queued up from process context, acpi_os_hotplug_execute()
uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also,
acpi_os_execute_deferred() queued up by it waits for the ACPI event
workqueues to flush before executing the work function, whereas
alloc_acpi_hp_work() can't do anything similar. That leads to
somewhat arbitrary differences in behavior between various ACPI
hotplug code paths and has to be straightened up.
For this reason, replace both alloc_acpi_hp_work() and
acpi_os_hotplug_execute() with a single interface,
acpi_hotplug_execute(), combining their behavior and being more
friendly to its users than any of the two.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* acpi-assorted:
ACPI: Add Toshiba NB100 to Vista _OSI blacklist
ACPI / osl: remove an unneeded NULL check
ACPI / platform: add ACPI ID for a Broadcom GPS chip
ACPI: improve acpi_extract_package() utility
ACPI / LPSS: fix UART Auto Flow Control
ACPI / platform: Add ACPI IDs for Intel SST audio device
x86 / ACPI: fix incorrect placement of __initdata tag
ACPI / thermal: convert printk(LEVEL...) to pr_<lvl>
ACPI / sysfs: make GPE sysfs attributes only accept correct values
ACPI / EC: Convert all printk() calls to dynamic debug function
ACPI / button: Using input_set_capability() to mark device's event capability
ACPI / osl: implement acpi_os_sleep() with msleep()
"str" is never NULL here so I have removed the check. There are static
checkers which complain about superfluous NULL checks because it may
indicate confusion or a bug.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Currently, acpi_os_sleep() uses schedule_timeout_interruptible()
which can be interrupted by a signal, and that causes the real sleep
time to be shorter.
According to the ACPI spec:
The Sleep term is used to implement long-term timing requirements.
Execution is delayed for at least the required number of milliseconds.
The sleeping time should be at least the required number msecs, so use
msleep() which guarantees that to implement it.
Signed-off-by: Liu Chuansheng <chuansheng.liu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Current ACPI tables in initrd is limited to 10, that is too small.
64 should be good enough as we have 35 sigs and could have several
SSDT.
Two problems in current code prevent us from increasing limit:
1. The cpio file info array is put in stack, as every element is 32
bytes, could run out of stack if we have that array size to 64.
We can move it out from stack, make it global and put it into the
__initdata section.
2. early_ioremap() only can remap 256k one time. Current code maps
10 tables at a time. If we increased that limit, the whole size
could be more than 256k, so early_ioremap() would fail with that.
We can map chunks one by one during copying, instead of mapping
all of them together.
Signed-off-by: Yinghai <yinghai@kernel.org>
Acked-by: Tejun Heo <tj@kernel.org>
Tested-by: Thomas Renninger <trenn@suse.de>
Reviewed-by: Tang Chen <tangchen@cn.fujitsu.com>
Tested-by: Tang Chen <tangchen@cn.fujitsu.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* acpica:
ACPICA: Update version to 20130725.
ACPICA: Update names for walk_namespace callbacks to clarify usage.
ACPICA: Return error if DerefOf resolves to a null package element.
ACPICA: Make ACPI Power Management Timer (PM Timer) optional.
ACPICA: Fix divergences of the commit - ACPICA: Expose OSI version.
ACPICA: Fix possible fault for methods that optionally have no return value.
ACPICA: DeRefOf operator: Update to fully resolve FieldUnit and BufferField refs.
ACPICA: Emit all unresolved method externals in a text block
ACPICA: Export acpi_tb_validate_rsdp().
ACPI: Add facility to remove all _OSI strings
ACPI: Add facility to disable all _OSI OS vendor strings
ACPICA: Add acpi_update_interfaces() public interface
ACPICA: Update version to 20130626
ACPICA: Fix compiler warnings for casting issues (only some compilers)
ACPICA: Remove restriction of 256 maximum GPEs in any GPE block
ACPICA: Disassembler: Expand maximum output string length to 64K
ACPICA: TableManager: Export acpi_tb_scan_memory_for_rsdp()
ACPICA: Update comments about behavior when _STA does not exist
The macro INVALID_TABLE() is defined like this:
#define INVALID_TABLE(x, path, name) \
{ pr_err("ACPI OVERRIDE: " x " [%s%s]\n", path, name); continue; }
And it is used like this:
for (...) {
...
if (...)
INVALID_TABLE()
...
}
The "continue" in the macro makes the code hard to understand.
And also, this macro is only used several times in a single file.
As suggested by Joe Perches <joe@perches.com>, we can remote it and
use pr_err directly.
So after this patch, this macro is removed, and pr_err() is used
like this:
for (...) {
...
if (...) {
pr_err("ACPI OVERRIDE: ......");
continue;
}
...
}
Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
Suggested-by: Joe Perches <joe@perches.com>
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
__initdata should come after the variable name being declared and
nowhere else, in this way the variable will be placed in the
intended section.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
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>
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>
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>
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>
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>
Commit 53aac44 (ACPI: Store valid ACPI tables passed via early initrd
in reserved memblock areas) introduced acpi_initrd_override() that
passes a wrong value as the second argument to memblock_reserve().
Namely, the second argument of memblock_reserve() is the size of the
region, not the address of the top of it, so make
acpi_initrd_override() pass the size in there as appropriate.
[rjw: Changelog]
Signed-off-by: Wang YanQing <udknight@gmail.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Cc: 3.8+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Use the resource_size() function instead of explicit computation.
[rjw: Subject and changelog]
Signed-off-by: Alexandru Gheorghiu <gheorghiuandru@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Host bridge hotplug
- Major overhaul of ACPI host bridge add/start (Rafael Wysocki, Yinghai Lu)
- Major overhaul of PCI/ACPI binding (Rafael Wysocki, Yinghai Lu)
- Split out ACPI host bridge and ACPI PCI device hotplug (Yinghai Lu)
- Stop caching _PRT and make independent of bus numbers (Yinghai Lu)
PCI device hotplug
- Clean up cpqphp dead code (Sasha Levin)
- Disable ARI unless device and upstream bridge support it (Yijing Wang)
- Initialize all hot-added devices (not functions 0-7) (Yijing Wang)
Power management
- Don't touch ASPM if disabled (Joe Lawrence)
- Fix ASPM link state management (Myron Stowe)
Miscellaneous
- Fix PCI_EXP_FLAGS accessor (Alex Williamson)
- Disable Bus Master in pci_device_shutdown (Konstantin Khlebnikov)
- Document hotplug resource and MPS parameters (Yijing Wang)
- Add accessor for PCIe capabilities (Myron Stowe)
- Drop pciehp suspend/resume messages (Paul Bolle)
- Make pci_slot built-in only (not a module) (Jiang Liu)
- Remove unused PCI/ACPI bind ops (Jiang Liu)
- Removed used pci_root_bus (Bjorn Helgaas)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJRKS3hAAoJEFmIoMA60/r8xxoP/j1CS4oCZAnBIVT9fKBkis+/
CENcfHIUKj6J9iMfJEVvqBELvqaLqtpeNwAGMcGPxV7VuT3K1QumChfaTpRDP0HC
VDRmrjcmfenEK+YPOG7acsrTyqk2wjpLOyu9MKRxtC5u7tF6376KQpkEFpO4haL4
eUHTxfE76OkrPBSvx3+PUSf6jqrvrNbjX8K6HdDVVlm3sVAQKmYJU/Wphv2NPOqa
CAMyCzEGybFjr8hDRwvWgr+06c718GMwQUbnrPdHXAe7lMNMrN/XVBmU9ABN3Aas
icd3lrDs+yPObgcO/gT8+sAZErCtdJ9zuHGYHdYpRbIQj/5JT4TMk7tw/Bj7vKY9
Mqmho9GR5YmYTRN9f1r+2n5AQ/KYWXJDrRNOnt5/ys5BOM3vwJ7WJ902zpSwtFQp
nLX+oD/hLfzpnoIQGDuBAoAXp2Kam3XWRgVvG78buRNrPj+kUzimk14a8qQeY+CB
El6UKuwi5Uv/qgs1gAqqjmZmsAkon2DnsRZa6Fl8NTkDlis7LY4gp9OU38ySFpB+
PhCmRyCZmDDqTVtwj6XzR3nPQ5LBSbvsTfgMxYMIUSXHa06tyb2q5p4mEIas0OmU
RKaP5xQqZuTgD8fbdYrx0xgSrn7JHt/j/X//Qs6unlLCWhlpm3LjJZKxyw2FwBGr
o4Lci+PiBh3MowCrju9D
=ER3b
-----END PGP SIGNATURE-----
Merge tag 'pci-v3.9-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
Pull PCI changes from Bjorn Helgaas:
"Host bridge hotplug
- Major overhaul of ACPI host bridge add/start (Rafael Wysocki, Yinghai Lu)
- Major overhaul of PCI/ACPI binding (Rafael Wysocki, Yinghai Lu)
- Split out ACPI host bridge and ACPI PCI device hotplug (Yinghai Lu)
- Stop caching _PRT and make independent of bus numbers (Yinghai Lu)
PCI device hotplug
- Clean up cpqphp dead code (Sasha Levin)
- Disable ARI unless device and upstream bridge support it (Yijing Wang)
- Initialize all hot-added devices (not functions 0-7) (Yijing Wang)
Power management
- Don't touch ASPM if disabled (Joe Lawrence)
- Fix ASPM link state management (Myron Stowe)
Miscellaneous
- Fix PCI_EXP_FLAGS accessor (Alex Williamson)
- Disable Bus Master in pci_device_shutdown (Konstantin Khlebnikov)
- Document hotplug resource and MPS parameters (Yijing Wang)
- Add accessor for PCIe capabilities (Myron Stowe)
- Drop pciehp suspend/resume messages (Paul Bolle)
- Make pci_slot built-in only (not a module) (Jiang Liu)
- Remove unused PCI/ACPI bind ops (Jiang Liu)
- Removed used pci_root_bus (Bjorn Helgaas)"
* tag 'pci-v3.9-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: (51 commits)
PCI/ACPI: Don't cache _PRT, and don't associate them with bus numbers
PCI: Fix PCI Express Capability accessors for PCI_EXP_FLAGS
ACPI / PCI: Make pci_slot built-in only, not a module
PCI/PM: Clear state_saved during suspend
PCI: Use atomic_inc_return() rather than atomic_add_return()
PCI: Catch attempts to disable already-disabled devices
PCI: Disable Bus Master unconditionally in pci_device_shutdown()
PCI: acpiphp: Remove dead code for PCI host bridge hotplug
PCI: acpiphp: Create companion ACPI devices before creating PCI devices
PCI: Remove unused "rc" in virtfn_add_bus()
PCI: pciehp: Drop suspend/resume ENTRY messages
PCI/ASPM: Don't touch ASPM if forcibly disabled
PCI/ASPM: Deallocate upstream link state even if device is not PCIe
PCI: Document MPS parameters pci=pcie_bus_safe, pci=pcie_bus_perf, etc
PCI: Document hpiosize= and hpmemsize= resource reservation parameters
PCI: Use PCI Express Capability accessor
PCI: Introduce accessor to retrieve PCIe Capabilities Register
PCI: Put pci_dev in device tree as early as possible
PCI: Skip attaching driver in device_add()
PCI: acpiphp: Keep driver loaded even if no slots found
...
lockdep, but it's a mechanical change.
Cheers,
Rusty.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJRJAcuAAoJENkgDmzRrbjxsw0P/3eXb+LddYnx0V0uHYdKpCUf
4vdW7X0fX3Z+aUK69IWRL/6ahoO4TpaHYGHBDjEoivyQ0GDq14X7JNWsYYt3LdMf
3wmDgRc2cn/mZOJbFeVpNV8ox5l/xc0CUvV+iQ8tMjfQItXMXgWUFZKMECsXKSO6
eex3lrw9M2jAX2uL8LQPp9W8xtKu24nSZRC6tH5riE/8fCzi1cZPPAqfxP5c8Lee
ZXtbCRSyAFENZLpKyMe1PC7HvtJyi5NDn9xwOQiXULZV/VOlvP94DGBLIKCM/6dn
4QvZxpG0P0uOlpCgRAVLyh/z7g4XY4VF/fHopLCmEcqLsvgD+V2LQpQ9zWUalLPC
Z+pUpz2vu0gIddPU1nR8R6oGpEdJ8O12aJle62p/RSXWZGx12qUQ+Tamu0tgKcv1
AsiJfbUGNDYfxgU6sHsoQjl2f68LTVckCU1C1LqEbW/S104EIORtGx30CHM4LRiO
32kDC5TtgYDBKQAIqJ4bL48ZMh+9W3uX40p7xzOI5khHQjvswUKa3jcxupU0C1uv
lx8KXo7pn8WT33QGysWC782wJCgJuzSc2vRn+KQoqoynuHGM6agaEtR59gil3QWO
rQEcxH63BBRDgHlg4FM9IkJwwsnC3PWKL8gbX0uAWXAPMbgapJkuuGZAwt0WDGVK
+GszxsFkCjlW0mK0egTb
=tiSY
-----END PGP SIGNATURE-----
Merge tag 'modules-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux
Pull module update from Rusty Russell:
"The sweeping change is to make add_taint() explicitly indicate whether
to disable lockdep, but it's a mechanical change."
* tag 'modules-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux:
MODSIGN: Add option to not sign modules during modules_install
MODSIGN: Add -s <signature> option to sign-file
MODSIGN: Specify the hash algorithm on sign-file command line
MODSIGN: Simplify Makefile with a Kconfig helper
module: clean up load_module a little more.
modpost: Ignore ARC specific non-alloc sections
module: constify within_module_*
taint: add explicit flag to show whether lock dep is still OK.
module: printk message when module signature fail taints kernel.
Enable ACPI SCI during suspend so that SCI can be used
as wake events for PM_SUSPEND_FREEZE.
For S3/S4 transition,
We disable all GPEs in suspend_ops->prepare_late() to
fix a problem that GPEs may trigger SCI before
arch_suspend_disable_irqs() is run.
So it is safe to leave the SCI enabled until
arch_suspend_irq_disable() is run.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Originally 'efi_enabled' indicated whether a kernel was booted from
EFI firmware. Over time its semantics have changed, and it now
indicates whether or not we are booted on an EFI machine with
bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.
The immediate motivation for this patch is the bug report at,
https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
which details how running a platform driver on an EFI machine that is
designed to run under BIOS can cause the machine to become
bricked. Also, the following report,
https://bugzilla.kernel.org/show_bug.cgi?id=47121
details how running said driver can also cause Machine Check
Exceptions. Drivers need a new means of detecting whether they're
running on an EFI machine, as sadly the expression,
if (!efi_enabled)
hasn't been a sufficient condition for quite some time.
Users actually want to query 'efi_enabled' for different reasons -
what they really want access to is the list of available EFI
facilities.
For instance, the x86 reboot code needs to know whether it can invoke
the ResetSystem() function provided by the EFI runtime services, while
the ACPI OSL code wants to know whether the EFI config tables were
mapped successfully. There are also checks in some of the platform
driver code to simply see if they're running on an EFI machine (which
would make it a bad idea to do BIOS-y things).
This patch is a prereq for the samsung-laptop fix patch.
Cc: David Airlie <airlied@linux.ie>
Cc: Corentin Chary <corentincj@iksaif.net>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Olof Johansson <olof@lixom.net>
Cc: Peter Jones <pjones@redhat.com>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Steve Langasek <steve.langasek@canonical.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: <stable@vger.kernel.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Will need to use it for PCI root bridge hotplug support, so rename
*acpiphp* to *acpi* and move to osc.c. Also make kacpi_hotplug_wq static
after that.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CC: Len Brown <lenb@kernel.org>
CC: linux-acpi@vger.kernel.org
Fix up all callers as they were before, with make one change: an
unsigned module taints the kernel, but doesn't turn off lockdep.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Pull x86 ACPI update from Peter Anvin:
"This is a patchset which didn't make the last merge window. It adds a
debugging capability to feed ACPI tables via the initramfs.
On a grander scope, it formalizes using the initramfs protocol for
feeding arbitrary blobs which need to be accessed early to the kernel:
they are fed first in the initramfs blob (lots of bootloaders can
concatenate this at boot time, others can use a single file) in an
uncompressed cpio archive using filenames starting with "kernel/".
The ACPI maintainers requested that this patchset be fed via the x86
tree rather than the ACPI tree as the footprint in the general x86
code is much bigger than in the ACPI code proper."
* 'x86-acpi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
X86 ACPI: Use #ifdef not #if for CONFIG_X86 check
ACPI: Fix build when disabled
ACPI: Document ACPI table overriding via initrd
ACPI: Create acpi_table_taint() function to avoid code duplication
ACPI: Implement physical address table override
ACPI: Store valid ACPI tables passed via early initrd in reserved memblock areas
x86, acpi: Introduce x86 arch specific arch_reserve_mem_area() for e820 handling
lib: Add early cpio decoder
There is a seemingly useless check in drivers/acpi/osl.c added by
commit bc73675 (ACPI: fixes a false alarm from lockdep), which really
is necessary to avoid false positive lockdep complaints. Document
this and rearrange the code related to it so that it makes fewer
checks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Exported acpi_os_hotplug_execute() and acpi_bus_hot_remove_device()
so that they can be called from modules for hot-remove operations.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There are two ways of overriding ACPI tables now, both need to taint the
the kernel.
Signed-off-by: Thomas Renninger <trenn@suse.de>
Link: http://lkml.kernel.org/r/1349043837-22659-6-git-send-email-trenn@suse.de
Cc: Len Brown <lenb@kernel.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Eric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Previous patches stored ACPI tables provided via initrd in a memblock reserved
area.
If a table is loaded and the table type of an initrd provided one matches,
the one from initrd is prefered.
In case of a SSDT table, the OEM table id also has to match.
ACPI tables can be loaded at boot time (static table pointers in XSDT),
but also dynamically any time later via ASL commands load() or loadTable().
The override mechanism always works.
Signed-off-by: Thomas Renninger <trenn@suse.de>
Link: http://lkml.kernel.org/r/1349043837-22659-5-git-send-email-trenn@suse.de
Cc: Len Brown <lenb@kernel.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Eric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
A later patch will compare them with ACPI tables that get loaded at boot or
runtime and if criteria match, a stored one is loaded.
Signed-off-by: Thomas Renninger <trenn@suse.de>
Link: http://lkml.kernel.org/r/1349043837-22659-4-git-send-email-trenn@suse.de
Cc: Len Brown <lenb@kernel.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Eric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Remove the unused argument of acpi_os_wait_events_complete.
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This reverts commit 6fe0d06282.
Paul bisected this regression.
The conversion was done blindly and is wrong, as it does not provide a
primary handler to disable the level type irq on the device level.
Neither does it set the IRQF_ONESHOT flag which handles that at the irq
line level. This can't be done as the interrupt might be shared, though
we might extend the core to force it.
So an interrupt on this line will wake up the thread, but immediately
unmask the irq after that. Due to the interrupt being level type the
hardware interrupt is raised over and over and prevents the irq thread
from handling it. Fail.
request_irq() unfortunately does not refuse such a request and the patch
was obviously never tested with real interrupts.
Bisected-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Conflicts:
drivers/acpi/acpica/hwsleep.c
Text conflict between:
2feec47d4c
(ACPICA: ACPI 5: Support for new FADT SleepStatus, SleepControl registers)
which removed #include "actables.h"
and
09f98a825a
(x86, acpi, tboot: Have a ACPI os prepare sleep instead of calling tboot_sleep.)
which removed #include <linux/tboot.h>
The resolution is to remove them both.
Signed-off-by: Len Brown <len.brown@intel.com>
... so that acpi_unmap()'s behavior gets in sync with acpi_map()'s.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Some ACPI interrupt actions may need to wait, and it's easiest to
have a thread context for this. So turn the ACPI interrupt
into a threaded interrupt.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This interface allows the host to override a table via a
physical address, instead of the logical address required by
acpi_os_table_override. This simplifies the host implementation.
Initial implementation by Thomas Renninger. ACPICA implementation
creates a single function for table overrides that attempts both
a logical and a physical override.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This change expands acpi_os_read_memory and acpi_os_write_memory to a
full 64 bits. This allows 64 bit transfers via the acpi_read and
acpi_write interfaces. Note: The internal acpi_hw_read and acpi_hw_write
interfaces remain at 32 bits, because 64 bits is not needed to
access the standard ACPI registers.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The ACPI suspend path makes a call to tboot_sleep right before
it writes the PM1A, PM1B values. We replace the direct call to
tboot via an registration callback similar to __acpi_register_gsi.
CC: Len Brown <len.brown@intel.com>
Acked-by: Joseph Cihula <joseph.cihula@intel.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
[v1: Added __attribute__ ((unused))]
[v2: Introduced a wrapper instead of changing tboot_sleep return values]
[v3: Added return value AE_CTRL_SKIP for acpi_os_sleep_prepare]
Signed-off-by: Tang Liang <liang.tang@oracle.com>
[v1: Fix compile issues on IA64 and PPC64]
[v2: Fix where __acpi_os_prepare_sleep==NULL and did not go in sleep properly]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
This patch adds support for RAM to ACPI's mapping capabilities in order
to support APEI error injection (EINJ) actions.
This patch re-factors similar functionality introduced in commit
76da3fb357, bringing it into osl.c in preparation for removing
./drivers/acpi/atomicio.[ch].
Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Base ACPI (CA) currently does not support atomic 64-bit reads and writes
(acpi_read() and acpi_write() split 64-bit loads/stores into two
32-bit transfers) yet APEI expects 64-bit transfer capability, even
when running on 32-bit systems.
This patch implements 64-bit read and write routines for APEI usage.
This patch re-factors similar functionality introduced in commit
04c25997c9, bringing it into the ACPI subsystem in preparation for
removing ./drivers/acpi/atomicio.[ch]. In the implementation I have
replicated acpi_os_read_memory() and acpi_os_write_memory(), creating
64-bit versions for APEI to utilize, as opposed to something more
elegant. My thinking is that we should attempt to see if we can get
ACPI's CA/OSL changed so that the existing acpi_read() and acpi_write()
interfaces are natively 64-bit capable and then subsequently remove the
replication.
Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Export remapping and unmapping interfaces - acpi_os_map_generic_address()
and acpi_os_unmap_generic_address() - for ACPI generic registers that are
backed by memory mapped I/O (MMIO).
The acpi_os_map_generic_address() and acpi_os_unmap_generic_address()
declarations may more properly belong in include/acpi/acpiosxf.h next to
acpi_os_read_memory() but I believe that would require the ACPI CA making
them an official part of the ACPI CA - OS interface.
ACPI Generic Address Structure (GAS) reference (ACPI's fixed/generic
hardware registers use the GAS format):
ACPI Specification, Revision 4.0, Section 5.2.3.1, "Generic Address
Structure"
Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
Generic Address Structures (GAS) may reside within ACPI tables which
are byte aligned. This patch copies GAS 'address' references to a local
variable, which will be naturally aligned, to be used going forward.
ACPI Generic Address Structure (GAS) reference:
ACPI Specification, Revision 4.0, Section 5.2.3.1, "Generic Address
Structure"
Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Allows drivers to determine if any memory or I/O addresses
will conflict with addresses used by ACPI operation regions.
Introduces a new interface, acpi_check_address_range.
http://marc.info/?t=132251388700002&r=1&w=2
Reported-and-tested-by: Luca Tettamanti <kronos.it@gmail.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
I originally submitted a patch to workaround this by pushing all Ejection
Requests and Device Checks onto the kacpi_hotplug queue.
http://marc.info/?l=linux-acpi&m=131678270930105&w=2
The patch is still insufficient in that Bus Checks also need to be added.
Rather than add all events, including non-PCI-hotplug events, to the
hotplug queue, mjg suggested that a better approach would be to modify
the acpiphp driver so only acpiphp events would be added to the
kacpi_hotplug queue.
It's a longer patch, but at least we maintain the benefit of having separate
queues in ACPI. This, of course, is still only a workaround the problem.
As Bjorn and mjg pointed out, we have to refactor a lot of this code to do
the right thing but at this point it is a better to have this code working.
The acpi core places all events on the kacpi_notify queue. When the acpiphp
driver is loaded and a PCI card with a PCI-to-PCI bridge is removed the
following call sequence occurs:
cleanup_p2p_bridge()
-> cleanup_bridge()
-> acpi_remove_notify_handler()
-> acpi_os_wait_events_complete()
-> flush_workqueue(kacpi_notify_wq)
which is the queue we are currently executing on and the process will hang.
Move all hotplug acpiphp events onto the kacpi_hotplug workqueue. In
handle_hotplug_event_bridge() and handle_hotplug_event_func() we can simply
push the rest of the work onto the kacpi_hotplug queue and then avoid the
deadlock.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: mjg@redhat.com
Cc: bhelgaas@google.com
Cc: linux-acpi@vger.kernel.org
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Linux supports some optional features, but it should notify the BIOS about
them via the _OSI method. Currently Linux doesn't notify any, which might
make such features not work because the BIOS doesn't know about them.
Jarosz has a system which needs this to make ACPI processor aggregator
device work.
Reported-by: "Jarosz, Sebastian" <sebastian.jarosz@intel.com>
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Acked-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
There is a problem with putting the first kernel in EFI virtual mode,
it is that when the second kernel comes up it tries to initialize the
EFI again and once we have put EFI in virtual mode we can not really
do that.
Actually, EFI is not necessary for kdump, we can boot the second kernel
with "noefi" parameter, but the boot will mostly fail because 2nd kernel
cannot find RSDP.
In this situation, we introduced "acpi_rsdp=" kernel parameter, so that
kexec-tools can pass the "noefi acpi_rsdp=X" to the second kernel to
make kdump works. The physical address of the RSDP can be got from
sysfs(/sys/firmware/efi/systab).
Signed-off-by: Takao Indoh <indou.takao@jp.fujitsu.com>
Reviewed-by: WANG Cong <amwang@redhat.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Len Brown <len.brown@intel.com>
All ACPICA locks are allocated by the same function,
acpi_os_create_lock(), with the help of a local variable called
"lock". Thus, when lockdep is enabled, it uses "lock" as the
name of all those locks and regards them as instances of the same
lock, which causes it to report possible locking problems with them
when there aren't any.
To work around this problem, define acpi_os_create_lock() as a macro
and make it pass its argument to spin_lock_init(), so that lockdep
uses it as the name of the new lock. Define this macron in a
Linux-specific file, to minimize the resulting modifications of
the OS-independent ACPICA parts.
This change is based on an earlier patch from Andrea Righi and it
addresses a regression from 2.6.39 tracked as
https://bugzilla.kernel.org/show_bug.cgi?id=38152
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reported-and-tested-by: Borislav Petkov <bp@alien8.de>
Tested-by: Andrea Righi <andrea@betterlinux.com>
Reviewed-by: Florian Mickler <florian@mickler.org>
Signed-off-by: Len Brown <len.brown@intel.com>
In principle acpi_os_install_interrupt_handler() may be called
multiple times for different interrupts, either from
acpi_ev_get_gpe_xrupt_block(), or from acpi_ev_install_sci_handler().
However, it always attempts to request the same interrupt,
acpi_gbl_FADT.sci_interrupt and it doesn't check whether or not this
interrupt has already been requested.
Modify this function so that it refuses to request interrupts other
than acpi_gbl_FADT.sci_interrupt and change
acpi_os_remove_interrupt_handler() so that it refuses to free such
interrupts. Use the observation that the only supported ACPI
interrupt must be equal to acpi_gbl_FADT.sci_interrupt and drop an
unnecessary variable acpi_irq_irq.
This change has been tested on Toshiba Portege R500 and HP nx6325
without introducing any visible problems.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Introduce function acpi_os_get_iomem() that may be used by its callers
to get a reference to an ACPI iomap.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
The reference counting of ACPI iomaps is carried out entirely under
acpi_ioremap_lock, so it is sufficient to use simple counters instead
of krefs for this purpose.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Modify acpi_os_map_memory() so that it doesn't call acpi_os_ioremap()
unconditionally every time it is executed (except when
acpi_gbl_permanent_mmap is unset), which pretty much defeats the
purpose of maintaining the list of ACPI iomaps in osl.c.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Make acpi_os_unmap_generic_address() use acpi_map_lookup() to find
the desired iomap and drop the reference to it directly (and
eventually remove it if necessary) instead of calling
acpi_os_unmap_memory(), which requires us to walk the list of ACPI
iomaps twice in a row (first, to get the virtual address associated
with the iomap and second, to get the iomap itself).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
There's no reason why acpi_ioremap_lock has to be a spinlock,
because all of the functions it is used in may sleep anyway and
there's no reason why it should be locked with interrupts off.
Use a mutex instead (that's going to allow us to put some more
operations under the lock later).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
The functions acpi_os_map_generic_address() and
acpi_os_unmap_generic_address() are only used in drivers/acpi/osl.c,
so make them static and remove the extern definitions of them from
include/linux/acpi_io.h.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
The functions acpi_os_read_memory() and acpi_os_write_memory() do
two wrong things. First, they shouldn't call rcu_read_unlock()
before the looked up address is actually used for I/O, because in
that case the iomap it belongs to may be removed before the I/O
is done. Second, if they have to create a new mapping, they should
check the returned virtual address and tell the caller that the
operation failed if it is NULL (in fact, I think they even should not
attempt to map an address that's not present in one of the existing
ACPI iomaps, because that may cause problems to happen when they are
called from nonpreemptible context and their callers ought to know
what they are doing and map the requisite memory regions beforehand).
Make these functions call rcu_read_unlock() when the I/O is complete
(or if it's necessary to map the given address "on the fly") and
return an error code if the requested physical address is not present
in the existing ACPI iomaps and cannot be mapped.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
ACPI workqueues aren't used during memory reclaming. Use
alloc_workqueue() to create workqueues w/o rescuers.
If the purpose of the separation between kacpid_wq and kacpi_notify_wq
was to give notifications better response time, kacpi_notify_wq can be
dropped and kacpi_wq can be created with higher @max_active.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Len Brown <lenb@kernel.org>
Cc: linux-acpi@vger.kernel.org
Commit ca9b600be3 ("ACPI / PM: Make suspend_nvs_save() use
acpi_os_map_memory()") attempted to prevent the code in osl.c and nvs.c
from using different ioremap() variants by making the latter use
acpi_os_map_memory() for mapping the NVS pages. However, that also
requires acpi_os_unmap_memory() to be used for unmapping them, which
causes synchronize_rcu() to be executed many times in a row
unnecessarily and introduces substantial delays during resume on some
systems.
Instead of using acpi_os_map_memory() for mapping the NVS pages in nvs.c
introduce acpi_os_ioremap() calling ioremap_cache() and make the code in
both osl.c and nvs.c use it.
Reported-by: Jeff Chua <jeff.chua.linux@gmail.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
printk("%pR",...)
is for formatting struct resource only.
But the list built up in drivers/acpi/osl.c uses it's own struct:
struct acpi_res_list {}
Without this patch you can see wrongly formatted resources (SMRG is of IO type):
ACPI: resource 0000:00:1f.3 [io 0x0400-0x041f] conflicts with AC
PI region SMRG [mem 0x00000400-0x0000040f 64bit pref disabled]
https://bugzilla.kernel.org/show_bug.cgi?id=26342
Signed-off-by: Thomas Renninger <trenn@suse.de>
CC: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: Len Brown <len.brown@intel.com>
Although the temporary boot-time ACPI table mappings
were set up with CPU caching enabled, the permanent table
mappings and AML run-time region memory accesses were
set up with ioremap(), which on x86 is a synonym for
ioremap_nocache().
Changing this to ioremap_cache() improves performance as
seen when accessing the tables via acpidump,
or /sys/firmware/acpi/tables. It should also improve
AML run-time performance.
No change on ia64.
Reported-by: Jack Steiner <steiner@sgi.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
WARNING: drivers/acpi/acpi.o(.text+0xeda): Section mismatch in reference from the function acpi_os_initialize1() to the function .init.text:set_osi_linux()
The function acpi_os_initialize1() references
the function __init set_osi_linux().
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
commit b0ed7a91(ACPICA/ACPI: Add new host interfaces for _OSI suppor)
introduced another regression that only one _OSI string can be added or
removed.
Now multiple _OSI strings can be added or removed, for example
acpi_osi=Linux acpi_osi=FreeBSD acpi_osi="!Windows 2006"
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
commit b0ed7a91(ACPICA/ACPI: Add new host interfaces for _OSI suppor)
introduced a regression that _OSI string setup fails.
There are 2 paths to setup _OSI string.
DMI:
acpi_dmi_osi_linux -> set_osi_linux -> acpi_osi_setup -> copy _OSI
string to osi_setup_string
Boot command line:
acpi_osi_setup -> copy _OSI string to osi_setup_string
Later, acpi_osi_setup_late will be called to handle osi_setup_string.
If _OSI string is "Linux" or "!Linux", then the call path is,
acpi_osi_setup_late -> acpi_cmdline_osi_linux -> set_osi_linux ->
acpi_osi_setup -> copy _OSI string to osi_setup_string
This actually never installs _OSI string(acpi_install_interface not
called), but just copy the _OSI string to osi_setup_string.
This patch fixes the regression.
Reported-and-tested-by: Lukas Hejtmanek <xhejtman@ics.muni.cz>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch optimizes ACPI MMIO remappings by keeping track of the
remappings on a PAGE_SIZE granularity.
When an ioremap() occurs, the underlying infrastructure works on a 'page'
based granularity. As such, an ioremap() request for 1 byte for example,
will end up mapping in an entire (PAGE_SIZE) page. Huang Ying took
advantage of this in commit 15651291a2 by
checking if subsequent ioremap() requests reside within any of the list's
existing remappings still in place, and if so, incrementing a reference
count on the existing mapping as opposed to performing another ioremap().
Signed-off-by: Myron Stowe <myron.stowe@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Convert the simple locking introduced earlier for the ACPI MMIO
remappings list to an RCU based locking scheme.
Signed-off-by: Myron Stowe <myron.stowe@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
During ACPI initialization, pre-map fixed hardware registers that are
accessed during ACPI's 'system event' related IRQ handing.
ACPI's 'system event' handing accesses specific fixed hardware
registers; namely PM1a event, PM1b event, GPE0, and GPE1 register
blocks which are declared within the FADT. If these registers are
backed by MMIO, as opposed to I/O port space, accessing them within
interrupt context will cause a panic as acpi_os_read_memory()
depends on ioremap() in such cases - BZ 18012.
By utilizing the functionality provided in the previous two patches -
ACPI: Maintain a list of ACPI memory mapped I/O remappings, and, ACPI:
Add interfaces for ioremapping/iounmapping ACPI registers - accesses
to ACPI MMIO areas will now be safe from within interrupt contexts (IRQ
and/or NMI) provided the area was pre-mapped. This solves BZ 18012.
ACPI "System Event" reference(s):
ACPI Specification, Revision 4.0, Section 3 "ACPI Overview",
3.8 "System Events", 5.6 "ACPI Event Programming Model".
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=18012
Reported-by: <bjorn.helgaas@hp.com>
Signed-off-by: Myron Stowe <myron.stowe@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Add remapping and unmapping interfaces for ACPI registers that are
backed by memory mapped I/O (MMIO). These interfaces, along with
the MMIO remapping list, enable accesses of such registers from within
interrupt context.
ACPI Generic Address Structure (GAS) reference (ACPI's fixed/generic
hardware registers use the GAS format):
ACPI Specification, Revision 4.0, Section 5.2.3.1, "Generic Address
Structure".
Signed-off-by: Myron Stowe <myron.stowe@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
For memory mapped I/O (MMIO) remappings, add a list to maintain the
remappings and augment the corresponding mapping and unmapping interface
routines (acpi_os_map_memory() and acpi_os_unmap_memory()) to
dynamically add to, and delete from, the list.
The current ACPI I/O accessing methods - acpi_read() and acpi_write() -
end up calling ioremap() when accessing MMIO. This prevents use of these
methods within interrupt context (IRQ and/or NMI), since ioremap() may
block to allocate memory. Maintaining a list of MMIO remappings enables
accesses to such areas from within interrupt context provided they have
been pre-mapped.
Signed-off-by: Myron Stowe <myron.stowe@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The size used for I/O remapping MMIO read and write accesses has not
accounted for the basis of ACPI's Generic Address Structure (GAS)
'Register Bit Width' field which is bits, not bytes. This patch
adjusts the ioremap() 'size' argument accordingly.
ACPI "Generic Register" reference:
ACPI Specification, Revision 4.0, Section 5.2.3.1, "Generic Address
Structure".
Signed-off-by: Myron Stowe <myron.stowe@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Found by running make namespacecheck on linux-next
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Linux-2.6.22 initiated a dmesg complaint when it saw BIOS that invoked
OSI(Linux). Linux-2.6.23 continued that complaint and started our
policy of ignoring the bogus BIOS request.
Past-time for Linux to label that complaint with FW_BUG.
Signed-off-by: Len Brown <len.brown@intel.com>
This function is not OS-dependent and has been replaced by
acpi_hw_derive_pci_id, which is now in the ACPICA core code. Local
implementations of acpi_os_derive_pci_id are no longer necessary and
are removed. ACPICA BZ 857.
http://www.acpica.org/bugzilla/show_bug.cgi?id=857
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Adds install/remove interfaces so that the host can dynamically
alter the global _OSI table. Also adds support for _OSI handlers.
Additional support: new debugger command (osi), and test support in
the acpiexec utility. Adds new file, utilities/utosi.c.
ACPICA bugzilla 836.
The Linux OSL _OSI code is also changed.
acpi_osi_setup can't call acpi_install/remove_interface because ACPICA
is not initialized yet at this early time.
So we just save the osi string in acpi_osi_setup and will handle it
later in a new function acpi_osi_setup_late.
http://www.acpica.org/bugzilla/show_bug.cgi?id=836
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com
Signed-off-by: Len Brown <len.brown@intel.com>
Prototype in acpiosxf.h had the output value pointer as a (u32 *).
Should be a (u64 *).
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Some minor improvements in error handling, but overall it was mostly dead
code.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
* 'acpica' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (27 commits)
ACPI / ACPICA: Simplify acpi_ev_initialize_gpe_block()
ACPI / ACPICA: Fail acpi_gpe_wakeup() if ACPI_GPE_CAN_WAKE is unset
ACPI / ACPICA: Do not execute _PRW methods during initialization
ACPI: Fix bogus GPE test in acpi_bus_set_run_wake_flags()
ACPICA: Update version to 20100702
ACPICA: Fix for Alias references within Package objects
ACPICA: Fix lint warning for 64-bit constant
ACPICA: Remove obsolete GPE function
ACPICA: Update debug output components
ACPICA: Add support for WDDT - Watchdog Descriptor Table
ACPICA: Drop acpi_set_gpe
ACPICA: Use low-level GPE enable during GPE block initialization
ACPI / EC: Do not use acpi_set_gpe
ACPI / EC: Drop suspend and resume routines
ACPICA: Remove wakeup GPE reference counting which is not used
ACPICA: Introduce acpi_gpe_wakeup()
ACPICA: Rename acpi_hw_gpe_register_bit
ACPICA: Update version to 20100528
ACPICA: Add signatures for undefined tables: ATKG, GSCI, IEIT
ACPICA: Optimization: Reduce the number of namespace walks
...
Currently, during initialization ACPICA walks the entire ACPI
namespace in search of any device objects with assciated _PRW
methods. All of the _PRW methods found are executed in the process
to extract the GPE information returned by them, so that the GPEs in
question can be marked as "able to wakeup" (more precisely, the
ACPI_GPE_CAN_WAKE flag is set for them). The only purpose of this
exercise is to avoid enabling the CAN_WAKE GPEs automatically, even
if there are _Lxx/_Exx methods associated with them. However, it is
both costly and unnecessary, because the host OS has to execute the
_PRW methods anyway to check which devices can wake up the system
from sleep states. Moreover, it then uses full information
returned by _PRW, including the GPE information, so it can take care
of disabling the GPEs if necessary.
Remove the code that walks the namespace and executes _PRW from
ACPICA and modify comments to reflect that change. Make
acpi_bus_set_run_wake_flags() disable GPEs for wakeup devices
so that they don't cause spurious wakeup events to be signaled.
This not only reduces the complexity of the ACPICA initialization
code, but in some cases it should reduce the kernel boot time as
well.
Unfortunately, for this purpose we need a new ACPICA function,
acpi_gpe_can_wake(), to be called by the host OS in order to disable
the GPEs that can wake up the system and were previously enabled by
acpi_ev_initialize_gpe_block() or acpi_ev_update_gpes() (such a GPE
should be disabled only once, because the initialization code enables
it only once, but it may be pointed to by _PRW for multiple devices
and that's why the additional function is necessary).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
ACPI works need to be executed on cpu0 and acpi/osl.c achieves this by
creating singlethread workqueue and then binding it to cpu0 from a
work which is quite unorthodox. Make it create regular workqueues and
use queue_work_on() instead. This is in preparation of concurrency
managed workqueue and the extra workers won't be a problem after it's
implemented.
Signed-off-by: Tejun Heo <tj@kernel.org>
When the user passes the kernel parameter acpi_enforce_resources=lax,
the ACPI resources are no longer protected, so a native driver can
make use of them. In that case, we do not want the asus_atk0110 to be
loaded. Unfortunately, this driver loads automatically due to its
MODULE_DEVICE_TABLE, so the user ends up with two drivers loaded for
the same device - this is bad.
So I suggest that we prevent the asus_atk0110 driver from loading if
acpi_enforce_resources=lax.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Luca Tettamanti <kronos.it@gmail.com>
Cc: Len Brown <lenb@kernel.org>
By default, ACPI resource conflict messages are logged at level
KERN_ERR. This is a rather high level for a message that is more a
warning than an indication of a real kernel error. Also, KERN_ERR level
messages can appear over some boot splash screens, and this message is
not serious enough to warrant such treatment. Thus, the log level has
been reduced to KERN_WARNING.
[lenb changed to KERN_WARNING rather than all the way to KERN_INFO]
Also, cleanup message to use %pR resource printing format.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Len Brown <len.brown@intel.com>
acpi_integer is now obsolete and removed from the ACPICA code base,
replaced by u64.
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
acpi_check_resource_conflict() doesn't change the resource
it operates on, so the res parameter can be marked const.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Len Brown <len.brown@intel.com>
The message "ACPI: Device needs an ACPI driver" is misleading. The
device _may_ need an ACPI driver, if the BIOS implemented a custom
API for the device in question (which, AFAIK, can't be checked.) If
not, then either a generic ACPI driver may be used (for example
"thermal"), or nothing can be done (other than a white list).
I propose to reword the message to:
ACPI: If an ACPI driver is available for this device, you should use
it instead of the native driver
which I think is more correct. Comments and suggestions welcome.
I also added a message warning about possible problems and system
instability when users pass acpi_enforce_resources=lax, as suggested
by Len.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Thomas Renninger <trenn@suse.de>
Cc: Alan Jenkins <sourcejedi.lkml@googlemail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
set_cpus_allowed() is on the way out; replace it with
set_cpus_allowed_ptr().
Reference: http://lkml.org/lkml/2008/11/6/448
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Better to oops and learn about a bug than to silently cover it up.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
We had two functions, acpi_os_execute_deferred() and
acpi_os_execute_hp_deferred() that differed only in that the
latter did acpi_os_wait_events_complete(NULL) before executing
the deferred function.
This patch consolidates those two functions and uses a flag in
the struct acpi_os_dpc to determine whether to do the wait.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
http://bugzilla.kernel.org/show_bug.cgi?id=13620
If the dynamic region is created and added to resource list over and over again,
it has the potential to be a memory leak by growing the list every time.
This patch fixes the memory leak, as below
1) add a new field "count" to struct acpi_res_list.
When inserting, if the region(addr, len) is already in the resource
list, we just increase "count", otherwise, the region is inserted
with count=1.
When deleting, the "count" is decreased, if it's decreased to 0,
the region is deleted from the resource list.
With "count", the region with same address and length can only be
inserted to the resource list once, so prevent potential memory leak.
2) add a new function acpi_os_invalidate_address, which is called when
region is deleted.
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
On some machines, a software-initiated SMI causes corruption unless the
SMI runs on CPU 0. An SMI can be initiated by any AML, but typically it's
done in GPE-related methods that are run via workqueues, so we can avoid
the known corruption cases by binding the workqueues to CPU 0.
References:
http://bugzilla.kernel.org/show_bug.cgi?id=13751https://bugs.launchpad.net/bugs/157171https://bugs.launchpad.net/bugs/157691
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
we used to run the hotplug code in keventd_wq.
But when hot removing the ACPI battery device,
power_supply_unregister invokes flush_scheduled_work.
This causes a deadlock. i.e
1. When dock is unplugged, all the hotplug code is run on kevent_wq.
2. the hotplug code removes all the child devices of dock device.
3. removing the child device may invoke flush_scheduled_work
4. flush_scheduled_work waits until all the work on kevent_wq to be
finished, while this will never be true because the hotplug code
is running on keventd_wq...
Introduce a new workqueue for hotplug in this patch.
http://bugzilla.kernel.org/show_bug.cgi?id=13533
Tested-by: Paul Martin <pm@debian.org>
Tested-by: Vojtech Gondzala <vojtech.gondzala@gmail.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Reviewed-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Enforce strict resource checking - disallowing access by native
drivers to IO ports and memory regions claimed by ACPI firmware.
The patch is mainly aimed to block native hwmon drivers from touching
monitoring chips that ACPI thinks it own.
If this causes a regression, boot with "acpi_enforce_resources=lax"
which was the previous default.
http://bugzilla.kernel.org/show_bug.cgi?id=12376http://bugzilla.kernel.org/show_bug.cgi?id=12541
Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
Acked-by: Pavel Machek <pavel@suse.cz>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Len Brown <len.brown@intel.com>
This reverts commit 5ec5d38a1c.
because it caused spurious dmesg warmings.
We'll implement the check for off-limit ports
in a more clever way in the future.
http://bugzilla.kernel.org/show_bug.cgi?id=12758
Signed-off-by: Len Brown <len.brown@intel.com>
early_acpi_os_unmap_memory() is an __init function, and
acpi_os_unmap_memory() is allowed to access an __init function
until acpi_gbl_permanent_mmap is set up.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Len Brown <len.brown@intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
to prevent wrongly overwriting fixmap that still want to use.
ACPI used to rely on low mappings being all linearly mapped and
grew a habit: it never really unmapped certain kinds of tables
after use.
This can cause problems - for example the hypothetical case
when some spurious access still references it.
v2: remove prev_map and prev_size in __apci_map_table
v3: let acpi_os_unmap_memory() call early_iounmap too, so remove extral calling to
early_acpi_os_unmap_memory
v4: fix typo in one acpi_get_table_with_size calling
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
According to kerneljanitors todo list all printk calls (beginning
a new line) should have an according KERN_* constant.
Those are the missing peaces here for the acpi subsystem.
Signed-off-by: Frank Seidel <frank@f-seidel.de>
Signed-off-by: Len Brown <len.brown@intel.com>
ACPICA exports acpi_os_validate_address() so the OS
can prevent BIOS AML from accessing specified addresses.
Start using this interface to prevent AML from accessing
some well known IO addresses that the OS "owns".
Signed-off-by: Len Brown <len.brown@intel.com>
return_ACPI_STATUS is an internal acpica function, replace it with return.
acpi_gbl_permanent_mmap moved from acglobal.h to acpixf.h for external use
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Linux will continue to ignore OSI(Linux),
except for a white-list containing a few systems.
So delete the black-list,
and stop soliciting user-feedback on the console.
Signed-off-by: Len Brown <len.brown@intel.com>
ACPI_DB_ERROR and ACPI_DB_WARN were removed from ACPICA core.
So replace ACPI_DEBUG_PRINT((ACPI_DB_ERROR, ...) with printk(KERN_ERR PREFIX ...)
and ACPI_DEBUG_PRINT((ACPI_DB_WARN, ...) with printk(KERN_WARNING PREFIX ...)
We do not use ACPI_ERROR/ACPI_WARNING since they're not exported, see
-------------------------------------------------------------
commit 6468463abd
Author: Len Brown <len.brown@intel.com>
Date: Mon Jun 26 23:41:38 2006 -0400
ACPI: un-export ACPI_ERROR() -- use printk(KERN_ERR...)
Signed-off-by: Len Brown <len.brown@intel.com>
-------------------------------------------------------------
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
As of version 2.0, ACPI can return 64-bit integers. The current
acpi_evaluate_integer only supports 64-bit integers on 64-bit platforms.
Change the argument to take a pointer to an acpi_integer so we support
64-bit integers on all platforms.
lenb: replaced use of "acpi_integer" with "unsigned long long"
lenb: fixed bug in acpi_thermal_trips_update()
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The hotplug notification handler and drivers' notification handler all
run in one workqueue. Before hotplug removes an acpi device, the
device driver's notification handler is already be recorded to run just
after global notification handler. After hotplug notification handler
runs, acpica will notice a NULL notification handler and crash.
So now we run run hotplug in another workqueue and wait
for all acpi notication handlers finish.
This was found in battery hotplug, but actually all
hotplug can be affected.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Flush kacpi_notify_wq before notify handler is removed,
this can fix a bug which the deferred notify handler is executed
after the notify_handler has already been removed.
http://bugzilla.kernel.org/show_bug.cgi?id=9772
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
ACPI currently emulates a timeout for semaphores with calls to
down_trylock and sleep. This produces horrible behaviour in terms of
fairness and excessive wakeups. Now that we have a unified semaphore
implementation, adding a real down_trylock is almost trivial.
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
This essentially reverts commit 71fc47a9ad
("ACPI: basic initramfs DSDT override support"), because the code simply
isn't ready.
It did ugly things to the init sequence to populate the rootfs image
early, but that just ended up showing other problems with the whole
approach. The fact is, the VFS layer simply isn't initialized this
early, and the relevant ACPI code should either run much later, or this
shouldn't be done at all.
For 2.6.25, we'll just pick the latter option. We can revisit this
concept later if necessary.
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Tilman Schmidt <tilman@imap.cc>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Thomas Renninger <trenn@suse.de>
Cc: Eric Piel <eric.piel@tremplin-utc.net>
Cc: Len Brown <len.brown@intel.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Markus Gaugusch <dsdt@gaugusch.at>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The raw_pci_read() interface (as the raw_pci_ops->read() before it)
unconditionally fills in a 32-bit integer return value regardless of the
size of the operation requested.
So claiming to take a "void *" is wrong, as is passing in a pointer to
just a byte variable.
Noticed by pageexec when enabling -fstack-protector (which needs other
patches too to actually work, but that's a separate issue).
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We want to allow different implementations of pci_raw_ops for standard
and extended config space on x86. Rather than clutter generic code with
knowledge of this, we make pci_raw_ops private to x86 and use it to
implement the new raw interface -- raw_pci_read() and raw_pci_write().
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The acpi_no_initrd_override parameter permits to disable the load of an ACPI
table from the initramfs.
Signed-off-by: Eric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Len Brown <len.brown@intel.com>
Lv Zheng