Completed a major update for the acpi_get_object_info external interface.
Changes include:
- Support for variable, unlimited length HID, UID, and CID strings
- Support Processor objects the same as Devices (HID,UID,CID,ADR,STA, etc.)
- Call the _SxW power methods on behalf of a device object
- Determine if a device is a PCI root bridge
- Change the ACPI_BUFFER parameter to ACPI_DEVICE_INFO.
These changes will require an update to all callers of this interface.
See the ACPICA Programmer Reference for details.
Also, update all invocations of acpi_get_object_info interface
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>
If the memory block size is zero, ignore it and don't do the memory hotplug
flowchart. Otherwise it will complain the following warning message:
>System RAM resource 0 - ffffffffffffffff cannot be added
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Don't treat the generic error as ACPI error code. Otherwise when the generic
code is returned, it will complain the following warning messag:
>ACPI Exception (acpi_memhotplug-0171): UNKNOWN_STATUS_CODE,
Cannot get acpi bus device [20080609]
>ACPI: Cannot find driver data
> ACPI Error (utglobal-0127): Unknown exception code: 0xFFFFFFED [20080609]
> Pid: 85, comm: kacpi_notify Not tainted 2.6.27.19-5-default #1
Call Trace:
[<ffffffff8020da29>] show_trace_log_lvl+0x41/0x58
[<ffffffff8049a3da>] dump_stack+0x69/0x6f
.....
At the same time when the generic error code is returned, the ACPI_EXCEPTION
is replaced by the printk.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch folds the .start() method into .add().
The .start() method is called in two paths: boot-time device enumeration
and run-time node addition, currently via container_device_add(). In both
cases, .start() is called immediately after .add(), so there's no reason
to make them separate methods.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Reviewed-by: Alex Chiang <achiang@hp.com>
CC: Yasunori Goto <y-goto@jp.fujitsu.com>
CC: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Fix misspelling of "firmware" in acpi_memhotplug.c
It's spelled "firmware".
Signed-off-by: Nick Andrew <nick@nick-andrew.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Move all the component definitions for drivers to a single shared place,
include/acpi/acpi_drivers.h.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
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>
Catch attempts to use of acpi_driver_data on pointers of wrong type.
akpm: rewritten to use proper C typechecking and remove the
"function"-used-as-lvalue thing.
Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
modpost is going to use these to create e.g. acpi:ACPI0001
in modules.alias.
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
No need to duplicate the existing definitions in include/acpi/actypes.h.
syntax only -- no functional change.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
It was erroneously used as a description rather than a name.
ie. turn this:
lenb@se7525gp2:/sys> ls bus/acpi/drivers
ACPI AC Adapter Driver ACPI Embedded Controller Driver ACPI Power Resource Driver
ACPI Battery Driver ACPI Fan Driver ACPI Processor Driver
ACPI Button Driver ACPI PCI Interrupt Link Driver ACPI Thermal Zone Driver
ACPI container driver ACPI PCI Root Bridge Driver hpet
into this:
lenb@se7525gp2:~> ls /sys/bus/acpi/drivers
ac battery button container ec fan hpet pci_link pci_root power processor thermal
Signed-off-by: Len Brown <len.brown@intel.com>
cosmetic only
Make "module name" actually match the file name.
Invoke with ';' as leaving it off confuses Lindent and gcc doesn't care.
Fix indentation where Lindent did get confused.
Signed-off-by: Len Brown <len.brown@intel.com>
I wrote a patch to avoid redundant memory hot-add call at boot time. This
was cause of strange fail message of memory hotplug like "ACPI: add_memory
failed". Memory is recognized by early boot code with EFI/E820.
But, if DSDT describes memory devices for them, then hot-add code is called
for already recognized memory, and it shows fail messages with -EEXIST.
So, sys admin will misunderstand this message as something wrong by it.
This patch avoids them by preventing redundant hot-add call until
completion of driver initialization.
[akpm@osdl.org: cleanups]
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Cc: "Brown, Len" <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I suppose this message seems quite useless except debugging. It just shows
"Hotplug Mem Device". System admin can't know anything by this message.
So, I would like to change it to KERN_DEBUG.
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
In cases where the acpi memory-add event does not containe the pxm (node)
infomation allow the driver to look up node info based on the address. The
acpi_get_node call returns -1 if it can't decode the pxm info, this causes
add_memory to panic. acpi_get_node would have to decode the resource from the
handle (a lenghty proposition). This seems to be the cleanist point to
interject the hook.
[kamezawa.hiroyu@jp.fujitsu.com: build fixes]
[y-goto@jp.fujitsu.com: build fixes]
Signed-off-by: Keith Mannthey <kmannth@us.ibm.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Andi Kleen <ak@muc.de>
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This is to remove noisy useless message at boot. The message is a ton of
"ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device"
In my emulation, number of memory devices are not so many (only 6), but,
this messages are displayed 114 times.
It is showed by acpi_memory_register_notify_handler() which is called by
acpi_walk_namespace().
acpi_walk_namespace() parses all of ACPI's namespace and execute
acpi_memory_register_notify_handler(). So, it is called for all of the
device which is defined in namespace. If the parsing device is not memory,
acpi_memhotplug ignores it due to "no match" and will parse next device.
This is normal route, not an exception.
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>