pm24.git/drivers/acpi/glue.c, branch v3.8

ACPI / glue: Fix build with ACPI_GLUE_DEBUG set

2013-01-12T13:00:06Z

If ACPI_GLUE_DEBUG is different from 0 (setting this requires a manual change of glue.c), build breaks because of a leftover reference to dev->acpi_handle in acpi_platform_notify(). Fix this by using ACPI_HANDLE(dev) instead as appropriate. [rjw: Subject and changelog] Signed-off-by: Yinghai Lu Signed-off-by: Rafael J. Wysocki

ACPI / glue: Update DBG macro to include KERN_DEBUG

2013-01-03T12:10:21Z

Currently these DBG statements are emitted at KERN_DEFAULT. Change the macro to emit at KERN_DEBUG. This can help avoid unexpected message interleaving. Signed-off-by: Joe Perches Signed-off-by: Rafael J. Wysocki

ACPI / driver core: Introduce struct acpi_dev_node and related macros

2012-11-20T23:21:50Z

To avoid adding an ACPI handle pointer to struct device on architectures that don't use ACPI, or generally when CONFIG_ACPI is not set, in which cases that pointer is useless, define struct acpi_dev_node that will contain the handle pointer if CONFIG_ACPI is set and will be empty otherwise and use it to represent the ACPI device node field in struct device. In addition to that define macros for reading and setting the ACPI handle of a device that don't generate code when CONFIG_ACPI is unset. Modify the ACPI subsystem to use those macros instead of referring to the given device's ACPI handle directly. Signed-off-by: Rafael J. Wysocki Reviewed-by: Mika Westerberg Acked-by: Greg Kroah-Hartman

ACPI: Allow ACPI handles of devices to be initialized in advance

2012-11-20T23:21:39Z

Currently, the ACPI handles of devices are initialized from within device_add(), by acpi_bind_one() called from acpi_platform_notify() which first uses the .find_device() routine provided by the device's bus type to find the matching device node in the ACPI namespace. This is a source of some computational overhead and, moreover, the correctness of the result depends on the implementation of .find_device() which is known to fail occasionally for some bus types (e.g. PCI). In some cases, however, the corresponding ACPI device node is known already before calling device_add() for the given struct device object and the whole .find_device() dance in acpi_platform_notify() is then simply unnecessary. For this reason, make it possible to initialize the ACPI handles of devices before calling device_add() for them. Modify acpi_platform_notify() to call acpi_bind_one() in advance to check the device's existing ACPI handle and skip the .find_device() search if that is successful. Change acpi_bind_one() accordingly. Signed-off-by: Rafael J. Wysocki Reviewed-by: Mika Westerberg

driver core / ACPI: Move ACPI support to core device and driver types

2012-11-14T23:28:00Z

With ACPI 5 we are starting to see devices that don't natively support discovery but can be enumerated with the help of the ACPI namespace. Typically, these devices can be represented in the Linux device driver model as platform devices or some serial bus devices, like SPI or I2C devices. Since we want to re-use existing drivers for those devices, we need a way for drivers to specify the ACPI IDs of supported devices, so that they can be matched against device nodes in the ACPI namespace. To this end, it is sufficient to add a pointer to an array of supported ACPI device IDs, that can be provided by the driver, to struct device. Moreover, things like ACPI power management need to have access to the ACPI handle of each supported device, because that handle is used to invoke AML methods associated with the corresponding ACPI device node. The ACPI handles of devices are now stored in the archdata member structure of struct device whose definition depends on the architecture and includes the ACPI handle only on x86 and ia64. Since the pointer to an array of supported ACPI IDs is added to struct device_driver in an architecture-independent way, it is logical to move the ACPI handle from archdata to struct device itself at the same time. This also makes code more straightforward in some places and follows the example of Device Trees that have a poiter to struct device_node in there too. This changeset is based on Mika Westerberg's work. Signed-off-by: Mika Westerberg Acked-by: Greg Kroah-Hartman Acked-by: H. Peter Anvin Acked-by: Tony Luck Signed-off-by: Rafael J. Wysocki

ACPI: Fix memory leak in acpi_bind_one()

2012-10-22T22:53:58Z

Memory is allocated with kzalloc() and assigned to 'physical_node'. Then 'physical_node->node_id' is initialized with a call to 'find_first_zero_bit()', if that results in a value greater than ACPI_MAX_PHYSICAL_NODE we'll end up jumping to the 'err:' label and there leave the function and let 'physical_node' go out of scope and leak the memory we allocated. This patch fixes the leak by simply freeing the unused/unneeded memory pointed to by 'physical_node' just before we jump to 'err:'. [rjw: The problem has been introduced by commit 1033f90 (ACPI: Allow ACPI binding with USB-3.0 hub), which is new in 3.7-rc.] Signed-off-by: Jesper Juhl Reviewed-by: Toshi Kani Reviewed-by: Yasuaki Ishimatsu Acked-by: David Rientjes Signed-off-by: Rafael J. Wysocki

ACPI: Allow ACPI binding with USB-3.0 hub

2012-09-21T17:30:29Z

A USB port's position and connectability can't be identified on some boards via USB hub registers. ACPI _UPC and _PLD can help to resolve this issue and so it is necessary to bind USB with ACPI. This patch is to allow ACPI binding with USB-3.0 hub. Current ACPI only can bind one struct-device to one ACPI device node. This can not work with USB-3.0 hub, because the USB-3.0 hub has two logical devices. Each works for USB-2.0 and USB-3.0 devices. In the Linux USB subsystem, those two logical hubs are treated as two seperate devices that have two struct devices. But in the ACPI DSDT, these two logical hubs share one ACPI device node. So there is a requirement to bind multi struct-devices to one ACPI device node. This patch is to resolve such problem. Following is the ACPI device nodes' description under xhci hcd. Device (XHC) Device (RHUB) Device (HSP1) Device (HSP2) Device (HSP3) Device (HSP4) Device (SSP1) Device (SSP2) Device (SSP3) Device (SSP4) Topology in the Linux device XHC USB-2.0 logical hub USB-3.0 logical hub HSP1 SSP1 HSP2 SSP2 HSP3 SSP3 HSP4 SSP4 This patch also modifies the output of /proc/acpi/wakeup. One ACPI node can be associated with multiple devices: XHC S4 *enabled pci:0000:00:14.0 RHUB S0 disabled usb:usb1 disabled usb:usb2 Signed-off-by: Lan Tianyu Acked-by: Sarah Sharp Signed-off-by: Len Brown

drivers/acpi/glue: revert accidental license-related 6b66d95895c bits

2012-07-25T18:24:13Z

Commit 6b66d95895c149cbc04d4fac5a2f5477c543a8ae should not have changed EXPORT_SYMBOL_GPL to EXPORT_SYMBOL. Signed-off-by: Jeff Garzik

libata: bind the Linux device tree to the ACPI device tree

2012-06-29T15:38:10Z

Associate the ACPI device tree and libata devices. This patch uses the generic ACPI glue framework to do so. Signed-off-by: Matthew Garrett Signed-off-by: Holger Macht Signed-off-by: Lin Ming Signed-off-by: Jeff Garzik

ACPI: Add stubs for (un)register_acpi_bus_type

2012-05-12T00:03:12Z

It's unreasonable to have CONFIG_ACPI for these in drivers, so add some stub functions. Signed-off-by: Matthew Garrett Signed-off-by: Lan Tianyu Signed-off-by: Greg Kroah-Hartman