An error occurred fetching the project authors.
- 25 Jan, 2013 2 commits
-
-
Rafael J. Wysocki authored
The ACPI device start operation, acpi_op_start, is never used, so drop it. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Yinghai Lu <yinghai@kernel.org> Acked-by:
Toshi Kani <toshi.kani@hp.com>
-
Rafael J. Wysocki authored
The second argument of ACPI driver .remove() operation is only used by the ACPI processor driver and the value passed to that driver through it is always available from the given struct acpi_device object's removal_type field. For this reason, the second ACPI driver .remove() argument is in fact useless, so drop it. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
Jiang Liu <jiang.liu@huawei.com> Acked-by:
Toshi Kani <toshi.kani@hp.com> Acked-by:
Yinghai Lu <yinghai@kernel.org>
-
- 24 Jan, 2013 1 commit
-
-
Rafael J. Wysocki authored
Since ACPI power resources are going to be used more extensively on new hardware platforms, it becomes necessary for user space (powertop in particular) to observe some properties of those resources for diagnostics purposes. For this reason, expose the current status of each ACPI power resource to user space via sysfs by adding a new resource_in_use attribute to the sysfs directory representing the given power resource. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 19 Jan, 2013 2 commits
-
-
Rafael J. Wysocki authored
Move ACPI device power management functions from drivers/acpi/bus.c to drivers/acpi/device_pm.c. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
The only difference between acpi_bus_scan() and acpi_bus_add() is the invocation of acpi_update_all_gpes() in the latter which in fact is unnecessary, because acpi_update_all_gpes() has already been called by acpi_scan_init() and the way it is implemented guarantees the next invocations of it to do nothing. For this reason, drop acpi_bus_add() and make all its callers use acpi_bus_scan() directly instead of it. Additionally, rearrange the code in acpi_scan_init() slightly to improve the visibility of the acpi_update_all_gpes() call in there. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Yinghai Lu <yinghai@kernel.org>
-
- 17 Jan, 2013 5 commits
-
-
Rafael J. Wysocki authored
The function returning string representations of ACPI device power states, state_string((), is now static, because it is only used internally in drivers/acpi/bus.c. However, it will be used outside of that file going forward, so rename it to acpi_power_state_string(), add a kerneldoc comment to it and add its header to acpi_bus.h. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
The function used for retrieving ACPI device power states, __acpi_bus_get_power(), is now static, because it is only used internally in drivers/acpi/bus.c. However, it will be used outside of that file going forward, so rename it to acpi_device_get_power(), in analogy with acpi_device_set_power(), add a kerneldoc comment to it and add its header to acpi_bus.h. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
ACPI power resources have an order attribute that should be taken into account when turning them on and off, but it is not used now. Modify the power resources management code to preserve the spec-compliant ordering of wakeup power resources. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
ACPI power resources have an order attribute that should be taken into account when turning them on and off, but it is not used now. Modify the power resources management code to preserve the spec-compliant ordering of power resources that power states of devices depend on (analogous changes will be done separately for power resources used for wakeup). Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
Commit 0090def6 (ACPI: Add interface to register/unregister device to/from power resources) made it possible to indicate to the ACPI core that if the given device depends on any power resources, then it should be resumed as soon as all of the power resources required by it to transition to the D0 power state have been turned on. Unfortunately, however, this was a mistake, because all devices depending on power resources should be treated this way (i.e. they should be resumed when all power resources required by their D0 state have been turned on) and for the majority of those devices the ACPI core can figure out by itself which (physical) devices depend on what power resources. For this reason, replace the code added by commit 0090def6 with a new, much more straightforward, mechanism that will be used internally by the ACPI core and remove all references to that code from kernel subsystems using ACPI. For the cases when there are (physical) devices that should be resumed whenever a not directly related ACPI device node goes into D0 as a result of power resources configuration changes, like in the SATA case, add two new routines, acpi_dev_pm_add_dependent() and acpi_dev_pm_remove_dependent(), allowing subsystems to manage such dependencies. Convert the SATA subsystem to use the new functions accordingly. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 15 Jan, 2013 3 commits
-
-
Yinghai Lu authored
Should use acpi_device pointer directly instead of use handle and get the device pointer again later. Signed-off-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
All callers of acpi_bus_trim() pass 1 (true) as the second argument of it, so remove that argument entirely and change acpi_bus_trim() to always behave as though it were 1. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Toshi Kani <toshi.kani@hp.com> Acked-by:
Yinghai Lu <yinghai@kernel.org> Acked-by:
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
-
Rafael J. Wysocki authored
The ops field in struct acpi_device is not used anywhere, so remove it. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Toshi Kani <toshi.kani@hp.com> Acked-by:
Yinghai Lu <yinghai@kernel.org> Acked-by:
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
-
- 14 Jan, 2013 1 commit
-
-
Jiang Liu authored
With commit f2a33cde55a03 "ACPI: Drop ACPI device .bind() and .unbind() callbacks", acpi_op_bind and acpi_op_unbind are not used any more. So remove them. Signed-off-by:
Jiang Liu <jiang.liu@huawei.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 03 Jan, 2013 9 commits
-
-
Bjorn Helgaas authored
This member is never initialized and never referenced, so remove it. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
Drop the .bind() and .unbind() that have no more users from struct acpi_device_ops and remove all of the code referring to them from drivers/acpi/scan.c. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Yinghai Lu <yinghai@kernel.org> Acked-by:
Toshi Kani <toshi.kani@hp.com>
-
Rafael J. Wysocki authored
Add two new callbacks,.setup() and .cleanup(), struct acpi_bus_type and modify acpi_platform_notify() to call .setup() after executing acpi_bind_one() successfully and acpi_platform_notify_remove() to call .cleanup() before running acpi_unbind_one(). This will allow the users of struct acpi_bus_type, PCI in particular, to specify operations to be executed right after the given device has been associated with a companion struct acpi_device and right before it's going to be detached from that companion, respectively. The main motivation is to be able to get rid of acpi_pci_bind() and acpi_pci_unbind(), which are horrible horrible stuff. [In short, there are three problems with them: The way they populate the .bind() and .unbind() callbacks of ACPI devices is rather less than straightforward, they require special hotplug-specific paths to be present in the ACPI namespace scanning code and by the time acpi_pci_unbind() is called the PCI device object in question may not exist any more.] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Yinghai Lu <yinghai@kernel.org> Acked-by:
Toshi Kani <toshi.kani@hp.com>
-
Rafael J. Wysocki authored
The callers of acpi_bus_add() usually assume that if it has succeeded, then a struct acpi_device object has been attached to the handle passed as the first argument. Unfortunately, however, this assumption is wrong, because acpi_bus_scan(), and acpi_bus_add() too as a result, may return a pointer to a different struct acpi_device object on success (it may be an object corresponding to one of the descendant ACPI nodes in the namespace scope below that handle). For this reason, the callers of acpi_bus_add() who care about whether or not a struct acpi_device object has been created for its first argument need to check that using acpi_bus_get_device() anyway, so the second argument of acpi_bus_add() is not really useful for them. The same observation applies to acpi_bus_scan() executed directly from acpi_scan_init(). Therefore modify the relevant callers of acpi_bus_add() to check the existence of the struct acpi_device in question with the help of acpi_bus_get_device() and drop the no longer necessary second argument of acpi_bus_add(). Accordingly, modify acpi_scan_init() to use acpi_bus_get_device() to get acpi_root and drop the no longer needed second argument of acpi_bus_scan(). Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Yinghai Lu <yinghai@kernel.org> Acked-by:
Toshi Kani <toshi.kani@hp.com>
-
Rafael J. Wysocki authored
After the removal of the second argument of acpi_bus_scan() there is no difference between the ACPI_BUS_ADD_MATCH and ACPI_BUS_ADD_START add types, so the add_type field in struct acpi_device may be replaced with a single flag. Do that calling the flag match_driver. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Yinghai Lu <yinghai@kernel.org> Acked-by:
Toshi Kani <toshi.kani@hp.com>
-
Rafael J. Wysocki authored
Notice that acpi_bus_add() uses only 2 of its 4 arguments and redefine its header to match the body. Update all of its callers as necessary and observe that this leads to quite a number of removed lines of code (Linus will like that). Add a kerneldoc comment documenting acpi_bus_add() and wonder how its callers make wrong assumptions about the second argument (make note to self to take care of that later). Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Yinghai Lu <yinghai@kernel.org> Acked-by:
Toshi Kani <toshi.kani@hp.com>
-
Rafael J. Wysocki authored
The ACPI PCI root bridge driver was the only ACPI driver implementing the .start() callback, which isn't used by any ACPI drivers any more now. For this reason, acpi_start_single_object() has no purpose any more, so remove it and all references to it. Also remove acpi_bus_start_device(), whose only purpose was to call acpi_start_single_object(). Moreover, since after the removal of acpi_bus_start_device() the only purpose of acpi_bus_start() remains to call acpi_update_all_gpes(), move that into acpi_bus_add() and drop acpi_bus_start() too, remove its header from acpi_bus.h and update all of its former users accordingly. This change was previously proposed in a different from by Yinghai Lu. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Yinghai Lu <yinghai@kernel.org> Acked-by:
Toshi Kani <toshi.kani@hp.com>
-
Rafael J. Wysocki authored
Notice that one member of struct acpi_bus_ops, acpi_op_add, is not used anywhere any more and the relationship between its remaining members, acpi_op_match and acpi_op_start, is such that it doesn't make sense to set the latter without setting the former at the same time. Therefore, replace struct acpi_bus_ops with new a enum type, enum acpi_bus_add_type, with three values, ACPI_BUS_ADD_BASIC, ACPI_BUS_ADD_MATCH, ACPI_BUS_ADD_START, corresponding to both acpi_op_match and acpi_op_start unset, acpi_op_match set and acpi_op_start unset, and both acpi_op_match and acpi_op_start set, respectively. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Yinghai Lu <yinghai@kernel.org> Acked-by:
Toshi Kani <toshi.kani@hp.com>
-
Rafael J. Wysocki authored
Split the ACPI namespace scanning for devices into two passes, such that struct acpi_device objects are registerd in the first pass without probing ACPI drivers and the drivers are probed against them directly in the second pass. There are two main reasons for doing that. First, the ACPI PCI root bridge driver's .add() routine, acpi_pci_root_add(), causes struct pci_dev objects to be created for all PCI devices under the given root bridge. Usually, there are corresponding ACPI device nodes in the ACPI namespace for some of those devices and therefore there should be "companion" struct acpi_device objects to attach those struct pci_dev objects to. These struct acpi_device objects should exist when the corresponding struct pci_dev objects are created, but that is only guaranteed during boot and not during hotplug. This leads to a number of functional differences between the boot and the hotplug cases which are not strictly necessary and make the code more complicated. For example, this forces the ACPI PCI root bridge driver to defer the registration of the just created struct pci_dev objects and to use a special .start() callback routine, acpi_pci_root_start(), to make sure that all of the "companion" struct acpi_device objects will be present at PCI devices registration time during hotplug. If those differences can be eliminated, we will be able to consolidate the boot and hotplug code paths for the enumeration and registration of PCI devices and to reduce the complexity of that code quite a bit. The second reason is that, in general, it should be possible to resolve conflicts of resources assigned by the BIOS to different devices represented by ACPI namespace nodes before any drivers bind to them and before they are attached to "companion" objects representing physical devices (such as struct pci_dev). However, for this purpose we first need to enumerate all ACPI device nodes in the given namespace scope. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Yinghai Lu <yinghai@kernel.org> Acked-by:
Toshi Kani <toshi.kani@hp.com>
-
- 21 Nov, 2012 1 commit
-
-
Aaron Lu authored
Currently we have valid flag to represent if this ACPI device power state is valid. A device power state is valid does not necessarily mean we, as OSPM, has a mean to put the device into that power state, e.g. D3 cold is always a valid power state for any ACPI device, but if there is no _PS3 or _PRx for this device, we can't really put that device into D3 cold power state. The same is true for D0 power state. So here comes the os_accessible flag, which is only set if the device has provided us the required means to put it into that power state, e.g. if we have _PS3 or _PRx, we can put the device into D3 cold state and thus, D3 cold power state's os_accessible flag will be set in this case. And a new wrapper inline function is added to be used to check if firmware has provided us a way to power off the device during runtime. Signed-off-by:
Aaron Lu <aaron.lu@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 20 Nov, 2012 1 commit
-
-
Rafael J. Wysocki authored
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 <rafael.j.wysocki@intel.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 16 Nov, 2012 1 commit
-
-
Yasuaki Ishimatsu authored
_SUN method provides the slot unique-ID in the ACPI namespace. And The value is written in Advanced Configuration and Power Interface Specification as follows: "The _SUN value is required to be unique among the slots ofthe same type. It is also recommended that this number match the slot number printed on the physical slot whenever possible." So if we can know the value, we can identify the physical position of the slot in the system. The patch creates "sun" file in sysfs for identifying physical position of the slot. Signed-off-by:
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Reviewed-by:
Toshi Kani <toshi.kani@hp.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 14 Nov, 2012 9 commits
-
-
Mika Westerberg authored
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 <mika.westerberg@linux.intel.com> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by:
H. Peter Anvin <hpa@zytor.com> Acked-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Toshi Kani authored
Removed lockable in struct acpi_device_flags since it is no longer used by any code. acpi_bus_hot_remove_device() cannot use this flag because acpi_bus_trim() frees up its acpi_device object. Furthermore, the dock driver calls _LCK method without using this lockable flag. Signed-off-by:
Toshi Kani <toshi.kani@hp.com> Reviewed-by:
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
David Rientjes authored
Commit b87b49cd0efd ("ACPI / PM: Move device PM functions related to sleep states") declared acpi_target_system_state() for CONFIG_PM_SLEEP whereas it is only defined for CONFIG_ACPI_SLEEP, resulting in the following link error: drivers/built-in.o: In function `acpi_pm_device_sleep_wake': drivers/acpi/device_pm.c:342: undefined reference to `acpi_target_system_state' drivers/built-in.o: In function `acpi_dev_suspend_late': drivers/acpi/device_pm.c:501: undefined reference to `acpi_target_system_state' drivers/built-in.o: In function `acpi_pm_device_sleep_state': drivers/acpi/device_pm.c:221: undefined reference to `acpi_target_system_state' Define it only for CONFIG_ACPI_SLEEP and fallback to a dummy definition for other configs. [rjw: The problem only occurs for exotic .configs in which HIBERNATE_CALLBACKS is selected by XEN_SAVE_RESTORE and neither SUSPEND nor HIBERNATION is set.] Signed-off-by:
David Rientjes <rientjes@google.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
Introduce helper function returning the target sleep state of the system and use it to move the remaining device power management functions from sleep.c to device_pm.c. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
If the caller of acpi_bus_set_power() already has a pointer to the struct acpi_device object corresponding to the device in question, it doesn't make sense for it to go through acpi_bus_get_device(), which may be costly, because it involves acquiring the global ACPI namespace mutex. For this reason, export the function operating on struct acpi_device objects used internally by acpi_bus_set_power(), so that it may be called instead of acpi_bus_set_power() in the above case, and change its name to acpi_device_set_power(). Additionally, introduce two inline wrappers for checking ACPI PM capabilities of devices represented by struct acpi_device objects. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
Two device wakeup management routines in device_pm.c and sleep.c, acpi_pm_device_run_wake() and acpi_pm_device_sleep_wake(), take a device pointer argument and use it to obtain the ACPI handle of the corresponding ACPI namespace node. That handle is then used to get the address of the struct acpi_device object corresponding to the struct device passed as the argument. Unfortunately, that last operation may be costly, because it involves taking the global ACPI namespace mutex, so it shouldn't be carried out too often. However, the callers of those routines usually call them in a row with acpi_pm_device_sleep_state() which also takes that mutex for the same reason, so it would be more efficient if they ran acpi_bus_get_device() themselves to obtain a pointer to the struct acpi_device object in question and then passed that pointer to the appropriate PM routines. To make that possible, split each of the PM routines mentioned above in two parts, one taking a struct acpi_device pointer argument and the other implementing the current interface for compatibility. Additionally, change acpi_pm_device_run_wake() to actually return an error code if there is an error while setting up runtime remote wakeup for the device. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
The ACPI function for choosing device power state is now located in drivers/acpi/sleep.c, but drivers/acpi/device_pm.c is a more logical place for it, so move it there. However, instead of moving the function entirely, move its core only under a different name and with a different list of arguments, so that it is more flexible, and leave a wrapper around it in the original location. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
ACPI routines for adding and removing device wakeup notifiers are currently defined in a PCI-specific file, but they will be necessary for non-PCI devices too, so move them to a separate file under drivers/acpi and rename them to indicate their ACPI origins. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
The kerneldoc comments for acpi_pm_device_sleep_state(), acpi_pm_device_run_wake(), and acpi_pm_device_sleep_wake() are outdated or otherwise inaccurate and/or don't follow the common kerneldoc patterns, so fix them. Additionally, notice that acpi_pm_device_run_wake() should be under CONFIG_PM_RUNTIME rather than under CONFIG_PM_SLEEP, so fix that too. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 06 Oct, 2012 1 commit
-
-
Lance Ortiz authored
Add support to export the device description obtained from the ACPI _STR method, if one exists for a device, to user-space via a sysfs interface. This new interface provides a standard and platform neutral way for users to obtain the description text stored in the ACPI _STR method. If no _STR method exists for the device, no sysfs 'description' file will be created. The 'description' file will be located in the /sys/devices/ directory using the device's path. /sys/device/<bus>/<bridge path>/<device path>.../firmware_node/description Example: /sys/devices/pci0000:00/0000:00.07.0/0000:0e:00.0/firmware_node/description It can also be located using the ACPI device path, for example: /sys/devices/LNXSYSTM:00/device:00/ACPI0004:00/PNP0A08:00/device:13/device:15/description /sys/devices/LNXSYSTM:00/device:00/ACPI0004:00/ACPI0004:01/ACPI0007:02/description Execute the 'cat' command on the 'description' file to obtain the description string for that device. This patch also includes documentation describing how the new sysfs interface works Changes from v1-v2 based on comments by Len Brown and Fengguang Wu * Removed output "No Description" and leaving a NULL attribute if the _STR method failed to evaluate. * In acpi_device_remove_files() removed the redundent check of dev->pnp.str_obj before calling free. This check triggered a message from smatch. Signed-off-by:
Lance Ortiz <lance.ortiz@hp.com> Signed-off-by:
Len Brown <len.brown@intel.com>
-
- 21 Sep, 2012 3 commits
-
-
Mika Westerberg authored
Add a helper macro module_acpi_driver() which reduces the boilerplate code for ACPI drivers. This is similar what is done for other busses (PCI, SPI, I2C etc). Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Len Brown <len.brown@intel.com>
-
Lan Tianyu authored
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 <tianyu.lan@intel.com> Acked-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
Len Brown <len.brown@intel.com>
-
Feng Tang authored
This patch is on top of the ACPICA 20120816 release, which implemented a native way to decode PLD buffer, so use it instead of leting upper level users do the decoding. v2: Modify the check for PLD buffer length to reject buffers whose length < 16 Signed-off-by:
Feng Tang <feng.tang@intel.com> Signed-off-by:
Bob Moore <robert.moore@intel.com> Signed-off-by:
Len Brown <len.brown@intel.com>
-
- 01 Jul, 2012 1 commit
-
-
Rafael J. Wysocki authored
Since the legacy ACPI driver PM callbacks included into struct acpi_device_ops are not used any more, drop them. Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl>
-