aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* Merge branch 'acpi-ost'Rafael J. Wysocki2014-03-17
|\ | | | | | | | | | | | | | | | | | | * acpi-ost: ACPI: Drop acpi_evaluate_hotplug_ost() and ACPI_HOTPLUG_OST ACPI: use device name LNXSYBUS.xx for ACPI \_SB and \_TZ objects ACPI / processor: use acpi_evaluate_ost() to replace open-coded version ACPI / PAD / xen: use acpi_evaluate_ost() to replace open-coded version ACPI / PAD: use acpi_evaluate_ost() to replace open-coded version ACPI: rename acpi_evaluate_hotplug_ost() to acpi_evaluate_ost()
| * ACPI: Drop acpi_evaluate_hotplug_ost() and ACPI_HOTPLUG_OSTRafael J. Wysocki2014-02-21
| | | | | | | | | | | | | | | | | | Replace acpi_evaluate_hotplug_ost() with acpi_evaluate_ost() everywhere and drop the ACPI_HOTPLUG_OST symbol so that hotplug _OST is supported unconditionally. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com>
| * Merge branch 'acpi-pci-hotplug' into acpi-ostRafael J. Wysocki2014-02-20
| |\
| * | ACPI: use device name LNXSYBUS.xx for ACPI \_SB and \_TZ objectsJiang Liu2014-02-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use device name "LNXSYBUS:xx" instead of "device.xx" for ACPI objects \_SB and \_TZ. BTW, the original check of "handle == ACPI_ROOT_OBJECT" in statment "else if (list_empty(&pnp->ids) && handle == ACPI_ROOT_OBJECT)" is always false because of the code at the begin of that block. if (handle == ACPI_ROOT_OBJECT) { acpi_add_id(pnp, ACPI_SYSTEM_HID); break; } Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | ACPI / processor: use acpi_evaluate_ost() to replace open-coded versionJiang Liu2014-02-20
| | | | | | | | | | | | | | | | | | | | | | | | Use public function acpi_evaluate_ost() to replace open-coded version of evaluating ACPI _OST method. Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | ACPI / PAD / xen: use acpi_evaluate_ost() to replace open-coded versionJiang Liu2014-02-20
| | | | | | | | | | | | | | | | | | | | | | | | Use public function acpi_evaluate_ost() to replace open-coded version of evaluating ACPI _OST method. Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | ACPI / PAD: use acpi_evaluate_ost() to replace open-coded versionJiang Liu2014-02-20
| | | | | | | | | | | | | | | | | | | | | | | | Use public function acpi_evaluate_ost() to replace open-coded version of evaluating ACPI _OST method. Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | ACPI: rename acpi_evaluate_hotplug_ost() to acpi_evaluate_ost()Jiang Liu2014-02-20
| | | | | | | | | | | | | | | | | | | | | | | | Rename acpi_evaluate_hotplug_ost() to acpi_evaluate_ost() for later resue. Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | | Merge branch 'acpi-config'Rafael J. Wysocki2014-03-17
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | * acpi-config: ACPI: Remove Kconfig symbol ACPI_PROCFS ACPI / APEI: Remove X86 redundant dependency for APEI GHES. ACPI: introduce CONFIG_ACPI_REDUCED_HARDWARE_ONLY
| * | | ACPI: Remove Kconfig symbol ACPI_PROCFSPaul Bolle2014-02-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Nothing cares about ACPI_PROCFS. This has been the case since v2.6.38. This Kconfig symbol serves no purpose and its help text is now misleading. It can safely be removed. If this symbol would be needed again in the future it can be readded in a commit that adds code that actually uses it. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | | ACPI / APEI: Remove X86 redundant dependency for APEI GHES.Tomasz Nowicki2014-02-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ACPI_APEI already depends on X86, so there is no need to define such dependency for ACPI_APEI_GHES (Generic Hardware Error Source) again. Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org> Acked-by: Borislav Petkov <bp@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | | ACPI: introduce CONFIG_ACPI_REDUCED_HARDWARE_ONLYAl Stone2014-02-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ACPI hardware reduced mode exists to allow newer platforms to use a simpler form of ACPI that does not require supporting legacy versions of the specification and their associated hardware. This mode was introduced in the ACPI 5.0 specification. The ACPI hardware reduced mode is supposed to be used on systems having the HW_REDUCED_ACPI flag set in the FADT. ACPICA checks that flag to determine whether or not it should work in the HW reduced mode and there are pieces of code in it that will never be used in that case. Since some architecutres will always use the ACPI HW reduced mode, it doesn't make sense for them to ever compile support for anything else. Thus, they should set the flag ACPI_REDUCED_HARDWARE to TRUE in the ACPICA source. To enable them to do that, introduce a new kernel configuration option, CONFIG_ACPI_REDUCED_HARDWARE_ONLY, that will cause the ACPICA's ACPI_REDUCED_HARDWARE flag to be TRUE when set. Introducing this configuration item is based on suggestions from Lv Zheng saying that this does not belong in ACPICA, but rather to the Linux kernel itself. References: http://www.spinics.net/lists/linux-acpi/msg46369.html Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Al Stone <al.stone@linaro.org> [rjw: Subject and changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | | | Merge branch 'acpi-hotplug'Rafael J. Wysocki2014-03-17
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * acpi-hotplug: ACPI / hotplug: Rework deferred execution of acpi_device_hotplug() ACPI / dock: Update copyright notice ACPI / dock: Drop remove_dock_dependent_devices() ACPI / dock: Drop struct acpi_dock_ops and all code related to it ACPI / ATA: Add hotplug contexts to ACPI companions of SATA devices ACPI / dock: Add .uevent() callback to struct acpi_hotplug_context ACPI / dock: Use callback pointers from devices' ACPI hotplug contexts ACPI / dock: Use ACPI device object pointers instead of ACPI handles ACPI / hotplug: Add .fixup() callback to struct acpi_hotplug_context ACPI / hotplug / PCI: Do not clear event callback pointer for docks ACPI / dock: Associate dock platform devices with ACPI device objects ACPI / dock: Pass ACPI device pointer to acpi_device_is_battery() ACPI / dock: Dispatch dock notifications from the global notify handler
| * \ \ \ Merge branch 'acpi-pci-hotplug' into acpi-hotplugRafael J. Wysocki2014-03-05
| |\ \ \ \
| * | | | | ACPI / hotplug: Rework deferred execution of acpi_device_hotplug()Rafael J. Wysocki2014-03-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the only function executed by acpi_hotplug_execute() is acpi_device_hotplug() and it only is called by the ACPI core, simplify its definition so that it only takes two arguments, the ACPI device object pointer and event code, rename it to acpi_hotplug_schedule() and move its header from acpi_bus.h to the ACPI core's internal header file internal.h. Modify the definition of acpi_device_hotplug() so that its first argument is an ACPI device object pointer and modify the definition of struct acpi_hp_work accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com>
| * | | | | ACPI / dock: Update copyright noticeRafael J. Wysocki2014-02-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update the copyright notice of the ACPI dock driver to reflect the fact that substantial changes have been made to it recently. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | | | | ACPI / dock: Drop remove_dock_dependent_devices()Rafael J. Wysocki2014-02-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since remove_dock_dependent_devices() is only called from acpi_dock_add() and it only is called if the add_dock_dependent_device() adding the dock station to its own list of dependent devices has failed, it is not really necessary, because the dock station's list of dependent devices is guaranteed to be empty at that point. Drop it, then. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | | | | ACPI / dock: Drop struct acpi_dock_ops and all code related to itRafael J. Wysocki2014-02-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since struct acpi_dock_ops and the code handling it don't have any users any more after the previous changes, drop that structure and the code related to it altogether. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | | | | ACPI / ATA: Add hotplug contexts to ACPI companions of SATA devicesRafael J. Wysocki2014-02-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Modify the SATA subsystem to add hotplug contexts to ACPI companions of SATA devices and ports instead of registering special ACPI dock operations using register_hotplug_dock_device(). That change will allow the entire code handling those special ACPI dock operations to be dropped in the next commit. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Tejun Heo <tj@kernel.org>
| * | | | | ACPI / dock: Add .uevent() callback to struct acpi_hotplug_contextRafael J. Wysocki2014-02-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to avoid the need to register special ACPI dock operations for SATA devices add a .uevent() callback pointer to struct acpi_hotplug_context and make dock_hotplug_event() use that callback if available. Also rename the existing .event() callback in struct acpi_hotplug_context to .notify() to avoid possible confusion in the future. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | | | | ACPI / dock: Use callback pointers from devices' ACPI hotplug contextsRafael J. Wysocki2014-02-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of requiring a set of special dock operations to be registered via register_hotplug_dock_device() for each ACPI dock device, it is much more straightforward to use callback pointers from the devices' hotplug contexts if available. For this reason, modify dock_hotplug_event() to use callback pointers from the hotplug contexts of ACPI devices and fall back to using the special dock operarions only if those callbacks are missing. Also make the ACPI-based PCI hotplug (ACPIPHP) subsystem set the .fixup callback pointer in the hotplug contexts of devices handled by it to a new function, acpiphp_post_dock_fixup(), so that the dock station driver can use the callbacks from those contexts instead of special dock operations registered via register_hotplug_dock_device(). Along with the above changes drop the ACPIPHP's dock operations that are not necessary any more. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | | | | ACPI / dock: Use ACPI device object pointers instead of ACPI handlesRafael J. Wysocki2014-02-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rework the ACPI dock station driver to store ACPI device object pointers instead of ACPI handles in its internal data structures. The purpose is moslty to make subsequent simplifications possible, but also this allows the overall code size to be reduced slightly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | | | | Merge branch 'acpi-pci-hotplug' into acpi-dockRafael J. Wysocki2014-02-20
| |\ \ \ \ \ | | | |_|_|/ | | |/| | |
| * | | | | ACPI / hotplug: Add .fixup() callback to struct acpi_hotplug_contextRafael J. Wysocki2014-02-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order for the ACPI dock station code to be able to use the callbacks pointed to by the ACPI device objects' hotplug contexts add a .fixup() callback pointer to struct acpi_hotplug_context. That callback will be useful to handle PCI devices located in dock stations. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | | | | ACPI / hotplug / PCI: Do not clear event callback pointer for docksRafael J. Wysocki2014-02-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After recent changes adding dock station handling to the ACPI hotplug core, it is not necessary to clear the .event() pointer in the ACPIPHP device hotplug context for dock stations any more, so don't do that. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | | | | ACPI / dock: Associate dock platform devices with ACPI device objectsRafael J. Wysocki2014-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To allow user space to check which ACPI device object the dock station is represented by, make acpi_dock_add() indicate to platform_device_register_full() which ACPI device object should be the companion of the new platform device. This also ensures that the ACPI device object in question will not go away while the dock platform device is present (which is always). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | | | | ACPI / dock: Pass ACPI device pointer to acpi_device_is_battery()Rafael J. Wysocki2014-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since we already know what the device's PNP IDs are when acpi_device_is_battery() is called, it is not necessary to run acpi_get_object_info() for the device in that function. Instead, if acpi_device_is_battery() is passed a pointer to a struct acpi_device object, it can use the list of PNP IDs from that object, so make that happen and modify the function's header accordingly Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | | | | ACPI / dock: Dispatch dock notifications from the global notify handlerRafael J. Wysocki2014-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ACPI dock station code carries out an extra namespace scan before the main one in order to find and register all of the dock device objects. Then, it registers a notify handler for each of them for handling dock events. However, dock device objects need not be scanned for upfront. They very well can be enumerated and registered during the first phase of the main namespace scan, before attaching scan handlers and ACPI drivers to ACPI device objects. Then, the dependent devices can be added to the in the second phase. That makes it possible to drop the extra namespace scan, so do it. Moreover, it is not necessary to register notify handlers for all of the dock stations' namespace nodes, becuase notifications may be dispatched from the global notify handler for them. Do that and drop two functions used for dock notify handling, acpi_dock_deferred_cb() and dock_notify_handler(), that aren't necessary any more. Finally, some dock station objects have _HID objects matching the ACPI container scan handler which causes it to claim those objects and try to handle their hotplug, but that is not a good idea, because those objects have their own special hotplug handling anyway. For this reason, the hotplug_notify flag should not be set for ACPI device objects representing dock stations and the container scan handler should be made ignore those objects, so make that happen. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | | | | Merge back earlier 'acpi-dock' material.Rafael J. Wysocki2014-02-15
| |\ \ \ \ \
* | \ \ \ \ \ Merge branch 'acpi-pci-hotplug'Rafael J. Wysocki2014-03-17
|\ \ \ \ \ \ \ | | |_|_|/ / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * acpi-pci-hotplug: (23 commits) ACPI / hotplug / PCI: Use pci_device_is_present() ACPI / hotplug / PCI: Add ACPIPHP contexts to devices handled by PCIeHP ACPI / hotplug / PCI: Rename register_slot() to acpiphp_add_context() ACPI / hotplug / PCI: Execute _EJ0 under the ACPI scan lock ACPI / hotplug / PCI: Rework acpiphp_check_host_bridge() ACPI / hotplug / PCI: Hotplug notifications from acpi_bus_notify() ACPI / hotplug / PCI: Simplify acpi_install_hotplug_notify_handler() ACPI / hotplug / PCI: Rework the handling of eject requests ACPI / hotplug / PCI: Consolidate ACPIPHP with ACPI core hotplug ACPI / hotplug / PCI: Define hotplug context lock in the core ACPI / hotplug: Fix potential race in acpi_bus_notify() ACPICA: Introduce acpi_get_data_full() and rework acpi_get_data() ACPI / hotplug / PCI: Do not pass ACPI handle to hotplug_event() ACPI / hotplug / PCI: Use acpi_handle_debug() in hotplug_event() ACPI / hotplug / PCI: Simplify hotplug_event() ACPI / hotplug / PCI: Drop crit_sect locking ACPI / hotplug / PCI: Drop acpiphp_bus_add() ACPI / hotplug / PCI: Store acpi_device pointer in acpiphp_context ACPI / hotplug / PCI: Rework acpiphp_no_hotplug() ACPI / hotplug / PCI: Drop acpiphp_bus_trim() ...
| * | | | | | ACPI / hotplug / PCI: Use pci_device_is_present()Rafael J. Wysocki2014-03-04
| | |_|/ / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make the ACPI-based PCI hotplug (ACPIPHP) code use pci_device_is_present() for checking if devices are present instead of open coding the same thing. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
| * | | | | ACPI / hotplug / PCI: Add ACPIPHP contexts to devices handled by PCIeHPRafael J. Wysocki2014-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, ACPIPHP does not add hotplug context to devices that should be handled by the native PCI hotplug (PCIeHP) code. The reason why was because PCIeHP didn't know about the devices' connections with ACPI and would not clean up things properly during an eject of an ACPI-backed device, for example. However, after recent changes that made the ACPI core create struct acpi_device objects for all namespace nodes regardless of the underlying devices' status and added PCI rescan-remove locking to both ACPIPHP and PCIeHP, that concern is not valid any more. Namely, after those changes PCIeHP need not care about the ACPI side of things any more and it should be serialized with respect to ACPIPHP and they won't be running concurrently with each other in any case. For this reason, make ACPIPHP to add its hotplug context to all devices with ACPI companions, even the ones that should be handled by PCIeHP in principle. That may work around hotplug issues on some systems where PCIeHP is supposed to work, but it doesn't and the ACPI hotplug signaling works instead. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | | | | ACPI / hotplug / PCI: Rename register_slot() to acpiphp_add_context()Rafael J. Wysocki2014-02-15
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The name of register_slot() doesn't really reflect what the function is does, so rename it to acpiphp_add_context() and add a proper kerneldoc comment to it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | | | Merge back earlier 'acpi-pci-hotplug' material.Rafael J. Wysocki2014-02-12
| |\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: drivers/pci/hotplug/acpiphp_glue.c
| | * | | | ACPI / hotplug / PCI: Execute _EJ0 under the ACPI scan lockRafael J. Wysocki2014-02-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since acpi_device_hotplug() assumes that ACPI handles of device objects passed to it will not become invalid while acpi_scan_lock is being held, make acpiphp_disable_slot() acquire acpi_scan_lock, because it generally causes _EJ0 to be executed for one of the devices in the slot and that may cause its ACPI handle to become invalid. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | * | | | Merge branch 'acpi-hotplug' into acpi-pci-hotplugRafael J. Wysocki2014-02-06
| | |\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: drivers/acpi/scan.c
| | * | | | | ACPI / hotplug / PCI: Rework acpiphp_check_host_bridge()Rafael J. Wysocki2014-02-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the only existing caller of acpiphp_check_host_bridge(), which is acpi_pci_root_scan_dependent(), already has a struct acpi_device pointer needed to obtain the ACPIPHP context, it doesn't make sense to execute acpi_bus_get_device() on its handle in acpiphp_handle_to_bridge() just in order to get that pointer back. For this reason, modify acpiphp_check_host_bridge() to take a struct acpi_device pointer as its argument and rearrange the code accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
| | * | | | | ACPI / hotplug / PCI: Hotplug notifications from acpi_bus_notify()Rafael J. Wysocki2014-02-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since acpi_bus_notify() is executed on all notifications for all devices anyway, make it execute acpi_device_hotplug() for all hotplug events instead of installing notify handlers pointing to the same function for all hotplug devices. This change reduces both the size and complexity of ACPI-based device hotplug code. Moreover, since acpi_device_hotplug() only does significant things for devices that have either an ACPI scan handler, or a hotplug context with .eject() defined, and those devices had notify handlers pointing to acpi_hotplug_notify_cb() installed before anyway, this modification shouldn't change functionality. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | * | | | | ACPI / hotplug / PCI: Simplify acpi_install_hotplug_notify_handler()Rafael J. Wysocki2014-02-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since acpi_hotplug_notify_cb() does not use its data argument any more, the second argument of acpi_install_hotplug_notify_handler() can be dropped, so do that and update its callers accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | * | | | | ACPI / hotplug / PCI: Rework the handling of eject requestsRafael J. Wysocki2014-02-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To avoid the need to install a hotplug notify handler for each ACPI namespace node representing a device and having a matching scan handler, move the check whether or not the ejection of the given device is enabled through its scan handler from acpi_hotplug_notify_cb() to acpi_generic_hotplug_event(). Also, move the execution of ACPI_OST_SC_EJECT_IN_PROGRESS _OST to acpi_generic_hotplug_event(), because in acpi_hotplug_notify_cb() or in acpi_eject_store() we really don't know whether or not the eject is going to be in progress (for example, acpi_hotplug_execute() may still fail without queuing up the work item). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
| | * | | | | ACPI / hotplug / PCI: Consolidate ACPIPHP with ACPI core hotplugRafael J. Wysocki2014-02-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ACPI-based PCI hotplug (ACPIPHP) code currently attaches its hotplug context objects directly to ACPI namespace nodes representing hotplug devices. However, after recent changes causing struct acpi_device to be created for every namespace node representing a device (regardless of its status), that is not necessary any more. Moreover, it's vulnerable to the theoretical issue that the ACPI handle passed in the context between handle_hotplug_event() and hotplug_event_work() may become invalid in the meantime (as a result of a concurrent table unload). In principle, this issue might be addressed by adding a non-empty release handler for ACPIPHP hotplug context objects analogous to acpi_scan_drop_device(), but that would duplicate the code in that function and in acpi_device_del_work_fn(). For this reason, it's better to modify ACPIPHP to attach its device hotplug contexts to struct device objects representing hotplug devices and make it use acpi_hotplug_notify_cb() as its notify handler. At the same time, acpi_device_hotplug() can be modified to dispatch the new .hp.event() callback pointing to acpiphp_hotplug_event() from ACPI device objects associated with PCI devices or use the generic ACPI device hotplug code for device objects with matching scan handlers. This allows the existing code duplication between ACPIPHP and the ACPI core to be reduced too and makes further ACPI-based device hotplug consolidation possible. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | * | | | | ACPI / hotplug / PCI: Define hotplug context lock in the coreRafael J. Wysocki2014-02-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Subsequent changes will require the ACPI core to acquire the lock protecting the ACPIPHP hotplug contexts, so move the definition of the lock to the core and change its name to be more generic. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
| | * | | | | ACPI / hotplug: Fix potential race in acpi_bus_notify()Rafael J. Wysocki2014-02-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a slight possibility for the ACPI device object pointed to by adev in acpi_hotplug_notify_cb() to become invalid between the acpi_bus_get_device() that it comes from and the subsequent dereference of that pointer under get_device(). Namely, if acpi_scan_drop_device() runs in parallel with acpi_hotplug_notify_cb(), acpi_device_del_work_fn() queued up by it may delete the device object in question right after a successful execution of acpi_bus_get_device() in acpi_bus_notify(). An analogous problem is present in acpi_bus_notify() where the device pointer coming from acpi_bus_get_device() may become invalid before it subsequent dereference in the "if" block. To prevent that from happening, introduce a new function, acpi_bus_get_acpi_device(), working analogously to acpi_bus_get_device() except that it will grab a reference to the ACPI device object returned by it and it will do that under the ACPICA's namespace mutex. Then, make both acpi_hotplug_notify_cb() and acpi_bus_notify() use acpi_bus_get_acpi_device() instead of acpi_bus_get_device() so as to ensure that the pointers used by them will not become stale at one point. In addition to that, introduce acpi_bus_put_acpi_device() as a wrapper around put_device() to be used along with acpi_bus_get_acpi_device() and make the (new) users of the latter use acpi_bus_put_acpi_device() too. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
| | * | | | | ACPICA: Introduce acpi_get_data_full() and rework acpi_get_data()Rafael J. Wysocki2014-02-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a new function, acpi_get_data_full(), working in analogy with acpi_get_data() except that it can execute a callback provided as its 4th argument right after acpi_ns_get_attached_data() has returned a success. That will allow Linux to reference count the object pointed to by *data before the namespace mutex is released so as to ensure that it will not be freed going forward until the reference to it acquired by acpi_get_data_full() is dropped. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
| | * | | | | ACPI / hotplug / PCI: Do not pass ACPI handle to hotplug_event()Rafael J. Wysocki2014-02-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since hotplug_event() can get the ACPI handle needed for debug printouts from its context argument, there's no need to pass the handle to it. Moreover, the second argument's type may be changed to (struct acpiphp_context *), because that's what is always passed to hotplug_event() as the second argument anyway. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
| | * | | | | ACPI / hotplug / PCI: Use acpi_handle_debug() in hotplug_event()Rafael J. Wysocki2014-02-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make hotplug_event() use acpi_handle_debug() instead of an open-coded debug message printing and clean up the messages printed by it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
| | * | | | | ACPI / hotplug / PCI: Simplify hotplug_event()Rafael J. Wysocki2014-02-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A few lines of code can be cut from hotplug_event() by defining and initializing the slot variable at the top of the function, so do that. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
| | * | | | | ACPI / hotplug / PCI: Drop crit_sect lockingRafael J. Wysocki2014-02-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After recent PCI core changes related to the rescan/remove locking, the code sections under crit_sect mutexes from ACPIPHP slot objects are always executed under the general PCI rescan/remove lock. For this reason, the crit_sect mutexes are simply redundant, so drop them. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
| | * | | | | ACPI / hotplug / PCI: Drop acpiphp_bus_add()Rafael J. Wysocki2014-02-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | acpiphp_bus_add() is only called from one place, so move the code out of it into that place and drop it. Also make that code use func_to_acpi_device() to get the struct acpi_device pointer it needs instead of calling acpi_bus_get_device() which may be costly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
| | * | | | | ACPI / hotplug / PCI: Store acpi_device pointer in acpiphp_contextRafael J. Wysocki2014-02-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After recent modifications of the ACPI core making it create a struct acpi_device object for every namespace node representing a device regardless of the current status of that device the ACPIPHP code can store a struct acpi_device pointer instead of an ACPI handle in struct acpiphp_context. This immediately makes it possible to avoid making potentially costly calls to acpi_bus_get_device() in two places and allows some more simplifications to be made going forward. The reason why that is correct is because ACPIPHP only installs hotify handlers for namespace nodes that exist when acpiphp_enumerate_slots() is called for their parent bridge. That only happens if the parent bridge has an ACPI companion associated with it, which means that the ACPI namespace scope in question has been scanned already at that point. That, in turn, means that struct acpi_device objects have been created for all namespace nodes in that scope and pointers to those objects can be stored directly instead of their ACPI handles. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>