summaryrefslogtreecommitdiffstats
path: root/include/acpi/acpi_bus.h
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'pci-v3.9-changes' of ↵Linus Torvalds2013-02-251-1/+9
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ...
| * Merge branch 'pci/yinghai-root-bus-hotplug' into nextBjorn Helgaas2013-01-261-0/+9
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * pci/yinghai-root-bus-hotplug: 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 PCI/ACPI: Print info if host bridge notify handler installation fails PCI: acpiphp: Move host bridge hotplug to pci_root.c PCI/ACPI: acpiphp: Rename alloc_acpiphp_hp_work() to alloc_acpi_hp_work() PCI: Make device create/destroy logic symmetric PCI: Fix reference count leak in pci_dev_present() PCI: Set pci_dev dev_node early so IOAPIC irq_descs are allocated locally PCI: Add root bus children dev's res to fail list PCI: acpiphp: Add is_hotplug_bridge detection Conflicts: drivers/pci/pci.h
| | * PCI/ACPI: acpiphp: Rename alloc_acpiphp_hp_work() to alloc_acpi_hp_work()Yinghai Lu2013-01-251-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | Merge branch 'pci/acpi-scan2' into nextBjorn Helgaas2013-01-261-6/+3
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * pci/acpi-scan2: ACPI / scan: Drop acpi_bus_add() and use acpi_bus_scan() instead ACPI: update ej_event interface to take acpi_device ACPI / scan: Add second pass to acpi_bus_trim() ACPI / scan: Change the implementation of acpi_bus_trim() ACPI / scan: Drop the second argument of acpi_bus_trim() ACPI / scan: Drop the second argument of acpi_device_unregister() ACPI: Remove the ops field from struct acpi_device ACPI: remove unused acpi_op_bind and acpi_op_unbind ACPI / scan: Fix check of device_attach() return value.
| * | ACPI / PCI: Set root bridge ACPI handle in advanceRafael J. Wysocki2013-01-131-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ACPI handles of PCI root bridges need to be known to acpi_bind_one(), so that it can create the appropriate "firmware_node" and "physical_node" files for them, but currently the way it gets to know those handles is not exactly straightforward (to put it lightly). This is how it works, roughly: 1. acpi_bus_scan() finds the handle of a PCI root bridge, creates a struct acpi_device object for it and passes that object to acpi_pci_root_add(). 2. acpi_pci_root_add() creates a struct acpi_pci_root object, populates its "device" field with its argument's address (device->handle is the ACPI handle found in step 1). 3. The struct acpi_pci_root object created in step 2 is passed to pci_acpi_scan_root() and used to get resources that are passed to pci_create_root_bus(). 4. pci_create_root_bus() creates a struct pci_host_bridge object and passes its "dev" member to device_register(). 5. platform_notify(), which for systems with ACPI is set to acpi_platform_notify(), is called. So far, so good. Now it starts to be "interesting". 6. acpi_find_bridge_device() is used to find the ACPI handle of the given device (which is the PCI root bridge) and executes acpi_pci_find_root_bridge(), among other things, for the given device object. 7. acpi_pci_find_root_bridge() uses the name (sic!) of the given device object to extract the segment and bus numbers of the PCI root bridge and passes them to acpi_get_pci_rootbridge_handle(). 8. acpi_get_pci_rootbridge_handle() browses the list of ACPI PCI root bridges and finds the one that matches the given segment and bus numbers. Its handle is then used to initialize the ACPI handle of the PCI root bridge's device object by acpi_bind_one(). However, this is *exactly* the ACPI handle we started with in step 1. Needless to say, this is quite embarassing, but it may be avoided thanks to commit f3fd0c8 (ACPI: Allow ACPI handles of devices to be initialized in advance), which makes it possible to initialize the ACPI handle of a device before passing it to device_register(). Accordingly, add a new __weak routine, pcibios_root_bridge_prepare(), defaulting to an empty implementation that can be replaced by the interested architecutres (x86 and ia64 at the moment) with functions that will set the root bridge's ACPI handle before its dev member is passed to device_register(). Make both x86 and ia64 provide such implementations of pcibios_root_bridge_prepare() and remove acpi_pci_find_root_bridge() and acpi_get_pci_rootbridge_handle() that aren't necessary any more. Included is a fix for breakage on systems with non-ACPI PCI host bridges from Bjorn Helgaas. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
* | | ACPI / hotplug: Fix concurrency issues and memory leaksRafael J. Wysocki2013-02-131-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changeset is aimed at fixing a few different but related problems in the ACPI hotplug infrastructure. First of all, since notify handlers may be run in parallel with acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device() and some of them are installed for ACPI handles that have no struct acpi_device objects attached (i.e. before those objects are created), those notify handlers have to take acpi_scan_lock to prevent races from taking place (e.g. a struct acpi_device is found to be present for the given ACPI handle, but right after that it is removed by acpi_bus_trim() running in parallel to the given notify handler). Moreover, since some of them call acpi_bus_scan() and acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock should be acquired by the callers of these two funtions rather by these functions themselves. For these reasons, make all notify handlers that can handle device addition and eject events take acpi_scan_lock and remove the acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim(). Accordingly, update all of their users to make sure that they are always called under acpi_scan_lock. Furthermore, since eject operations are carried out asynchronously with respect to the notify events that trigger them, with the help of acpi_bus_hot_remove_device(), even if notify handlers take the ACPI scan lock, it still is possible that, for example, acpi_bus_trim() will run between acpi_bus_hot_remove_device() and the notify handler that scheduled its execution and that acpi_bus_trim() will remove the device node passed to acpi_bus_hot_remove_device() for ejection. In that case, the struct acpi_device object obtained by acpi_bus_hot_remove_device() will be invalid and not-so-funny things will ensue. To protect agaist that, make the users of acpi_bus_hot_remove_device() run get_device() on ACPI device node objects that are about to be passed to it and make acpi_bus_hot_remove_device() run put_device() on them and check if their ACPI handles are not NULL (make acpi_device_unregister() clear the device nodes' ACPI handles for that check to work). Finally, observe that acpi_os_hotplug_execute() actually can fail, in which case its caller ought to free memory allocated for the context object to prevent leaks from happening. It also needs to run put_device() on the device node that it ran get_device() on previously in that case. Modify the code accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
* | | ACPI / scan: Introduce struct acpi_scan_handlerRafael J. Wysocki2013-01-301-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce struct acpi_scan_handler for representing objects that will do configuration tasks depending on ACPI device nodes' hardware IDs (HIDs). Currently, those tasks are done either directly by the ACPI namespace scanning code or by ACPI device drivers designed specifically for this purpose. None of the above is desirable, however, because doing that directly in the namespace scanning code makes that code overly complicated and difficult to follow and doing that in "special" device drivers leads to a great deal of confusion about their role and to confusing interactions with the driver core (for example, sysfs directories are created for those drivers, but they are completely unnecessary and only increase the kernel's memory footprint in vain). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Acked-by: Toshi Kani <toshi.kani@hp.com>
* | | Merge branch 'acpi-scan' into acpi-cleanupRafael J. Wysocki2013-01-291-1/+1
|\ \ \ | | | | | | | | | | | | The following commits depend on the 'acpi-scan' material.
| * | | ACPI / scan: Make it clear that acpi_bus_trim() cannot failRafael J. Wysocki2013-01-261-1/+1
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | Since acpi_bus_trim() cannot fail, change its definition to a void function, so that its callers don't check the return value in vain and update the callers. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Acked-by: Toshi Kani <toshi.kani@hp.com>
* | | Merge branch 'acpi-pm' into acpi-cleanupRafael J. Wysocki2013-01-291-4/+50
|\ \ \ | | | | | | | | | | | | The following commits depend on the 'acpi-pm' material.
| * | | ACPI / PM: Expose current status of ACPI power resourcesRafael J. Wysocki2013-01-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | ACPI / PM: Move device power management functions to device_pm.cRafael J. Wysocki2013-01-191-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | ACPI / PM: Common string representations of device power statesRafael J. Wysocki2013-01-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | ACPI / PM: More visible function for retrieving device power statesRafael J. Wysocki2013-01-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | ACPI / PM: Take order attribute of wakeup power resources into accountRafael J. Wysocki2013-01-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | ACPI / PM: Take order attribute of power resources into accountRafael J. Wysocki2013-01-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | ACPI / PM: Rework the handling of devices depending on power resourcesRafael J. Wysocki2013-01-171-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | ACPI: Drop device start operation that is not usedRafael J. Wysocki2013-01-261-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | ACPI: Remove useless type argument of driver .remove() operationRafael J. Wysocki2013-01-261-1/+1
| |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | ACPI / scan: Drop acpi_bus_add() and use acpi_bus_scan() insteadRafael J. Wysocki2013-01-191-1/+1
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | ACPI: update ej_event interface to take acpi_deviceYinghai Lu2013-01-151-1/+1
| | | | | | | | | | | | | | | | 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>
* | ACPI / scan: Drop the second argument of acpi_bus_trim()Rafael J. Wysocki2013-01-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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>
* | ACPI: Remove the ops field from struct acpi_deviceRafael J. Wysocki2013-01-151-1/+0
| | | | | | | | | | | | | | | | | | | | 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>
* | ACPI: remove unused acpi_op_bind and acpi_op_unbindJiang Liu2013-01-141-2/+0
|/ | | | | | | | | 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>
* ACPI: Remove unused struct acpi_pci_root.id memberBjorn Helgaas2013-01-031-1/+0
| | | | | | | 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>
* ACPI: Drop ACPI device .bind() and .unbind() callbacksRafael J. Wysocki2013-01-031-2/+0
| | | | | | | | | | 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>
* ACPI: Add .setup() and .cleanup() callbacks to struct acpi_bus_typeRafael J. Wysocki2013-01-031-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* ACPI: Make acpi_bus_scan() and acpi_bus_add() take only one argumentRafael J. Wysocki2013-01-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ACPI: Replace ACPI device add_type field with a match_driver flagRafael J. Wysocki2013-01-031-9/+2
| | | | | | | | | | | 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>
* ACPI: Remove the arguments of acpi_bus_add() that are not usedRafael J. Wysocki2013-01-031-2/+1
| | | | | | | | | | | | | | | 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>
* ACPI: Remove acpi_start_single_object() and acpi_bus_start()Rafael J. Wysocki2013-01-031-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* ACPI: Replace struct acpi_bus_ops with enum typeRafael J. Wysocki2013-01-031-7/+8
| | | | | | | | | | | | | | | | | 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>
* ACPI: Separate adding ACPI device objects from probing ACPI driversRafael J. Wysocki2013-01-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'acpi-general'Rafael J. Wysocki2012-11-291-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * acpi-general: (38 commits) ACPI / thermal: _TMP and _CRT/_HOT/_PSV/_ACx dependency fix ACPI: drop unnecessary local variable from acpi_system_write_wakeup_device() ACPI: Fix logging when no pci_irq is allocated ACPI: Update Dock hotplug error messages ACPI: Update Container hotplug error messages ACPI: Update Memory hotplug error messages ACPI: Update CPU hotplug error messages ACPI: Add acpi_handle_<level>() interfaces ACPI: remove use of __devexit ACPI / PM: Add Sony Vaio VPCEB1S1E to nonvs blacklist. ACPI / battery: Correct battery capacity values on Thinkpads Revert "ACPI / x86: Add quirk for "CheckPoint P-20-00" to not use bridge _CRS_ info" ACPI: create _SUN sysfs file ACPI / memhotplug: bind the memory device when the driver is being loaded ACPI / memhotplug: don't allow to eject the memory device if it is being used ACPI / memhotplug: free memory device if acpi_memory_enable_device() failed ACPI / memhotplug: fix memory leak when memory device is unbound from acpi_memhotplug ACPI / memhotplug: deal with eject request in hotplug queue ACPI / memory-hotplug: add memory offline code to acpi_memory_device_remove() ACPI / memory-hotplug: call acpi_bus_trim() to remove memory device ... Conflicts: include/linux/acpi.h (two additions at the end of the same file)
| * ACPI: create _SUN sysfs fileYasuaki Ishimatsu2012-11-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | _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>
| * ACPI: Remove unused lockable in acpi_device_flagsToshi Kani2012-11-151-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'acpi-dev-pm' into acpi-enumerationRafael J. Wysocki2012-11-271-3/+69
|\ \ | | | | | | | | | | | | Subsequent commits in this branch will depend on 'acpi-dev-pm' material.
| * | ACPI / PM: Introduce os_accessible flag for power_stateAaron Lu2012-11-211-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | ACPI / PM: Fix build problem related to acpi_target_system_state()David Rientjes2012-11-151-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | ACPI / PM: Move device PM functions related to sleep statesRafael J. Wysocki2012-11-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | ACPI / PM: Provide device PM functions operating on struct acpi_deviceRafael J. Wysocki2012-11-151-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | ACPI / PM: Split device wakeup management routinesRafael J. Wysocki2012-11-151-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | ACPI / PM: Move device power state selection routine to device_pm.cRafael J. Wysocki2012-11-151-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | ACPI / PM: Move routines for adding/removing device wakeup notifiersRafael J. Wysocki2012-11-151-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | ACPI / PM: Fix device PM kernedoc comments and #ifdefsRafael J. Wysocki2012-11-151-2/+6
| |/ | | | | | | | | | | | | | | | | | | | | | | 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>
* | ACPI / driver core: Introduce struct acpi_dev_node and related macrosRafael J. Wysocki2012-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | driver core / ACPI: Move ACPI support to core device and driver typesMika Westerberg2012-11-151-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
*-------. Merge branches 'acpica', 'acpidump', 'intel-idle', 'misc', ↵Len Brown2012-10-061-32/+28
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'module_acpi_driver-simplify', 'turbostat' and 'usb3' into release add acpidump utility intel_idle driver now supports IVB Xeon turbostat can now count SMIs ACPI can now bind to USB3 hubs misc fixes
| | | | | * ACPI: Allow ACPI binding with USB-3.0 hubLan Tianyu2012-09-211-2/+13
| |_|_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | | | * ACPI: introduce module_acpi_driver() helper macroMika Westerberg2012-09-211-0/+13
| |_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-24 05:38:21 +0000