aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/acpi/scan.c
Commit message (Collapse)AuthorAge
* Merge branch 'acpi-hotplug'Rafael J. Wysocki2013-11-18
|\ | | | | | | | | | | | | | | * acpi-hotplug: ACPI / scan: Set flags.match_driver in acpi_bus_scan_fixed() ACPI / PCI root: Clear driver_data before failing enumeration ACPI / hotplug: Fix PCI host bridge hot removal ACPI / hotplug: Fix acpi_bus_get_device() return value check
| * ACPI / scan: Set flags.match_driver in acpi_bus_scan_fixed()Rafael J. Wysocki2013-11-18
| | | | | | | | | | | | | | | | | | | | | | | | | | Before commit 6931007cc90b (ACPI / scan: Start matching drivers after trying scan handlers) the match_driver flag for all devices was set in acpi_add_single_object(), but now it is set by acpi_bus_device_attach() which is not called for the "fixed" devices added by acpi_bus_scan_fixed(). This means that flags.match_driver is never set for those devices now, so make acpi_bus_scan_fixed() set it before calling device_attach(). Fixes: 6931007cc90b (ACPI / scan: Start matching drivers after trying scan handlers) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPI / hotplug: Fix PCI host bridge hot removalRafael J. Wysocki2013-11-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the PCI host bridge scan handler does not set hotplug.enabled, the check of it in acpi_bus_device_eject() effectively prevents the root bridge hot removal from working after commit a3b1b1ef78cd (ACPI / hotplug: Merge device hot-removal routines). However, that check is not necessary, because the other acpi_bus_device_eject() users, acpi_hotplug_notify_cb and acpi_eject_store(), do the same check by themselves before executing that function. For this reason, remove the scan handler check from acpi_bus_device_eject() to make PCI hot bridge hot removal work again. Fixes: a3b1b1ef78cd (ACPI / hotplug: Merge device hot-removal routines) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com>
| * ACPI / hotplug: Fix acpi_bus_get_device() return value checkRafael J. Wysocki2013-11-18
| | | | | | | | | | | | | | | | | | Since acpi_bus_get_device() returns a plain int and not acpi_status, ACPI_FAILURE() should not be used for checking its return value. Fix that. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com>
* | Merge branch 'acpi-hotplug'Rafael J. Wysocki2013-11-07
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * acpi-hotplug: ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines ACPI / hotplug: Do not execute "insert in progress" _OST ACPI / hotplug: Carry out PCI root eject directly ACPI / hotplug: Merge device hot-removal routines ACPI / hotplug: Make acpi_bus_hot_remove_device() internal ACPI / hotplug: Simplify device ejection routines ACPI / hotplug: Fix handle_root_bridge_removal() ACPI / hotplug: Refuse to hot-remove all objects with disabled hotplug ACPI / scan: Start matching drivers after trying scan handlers ACPI: Remove acpi_pci_slot_init() headers from internal.h Conflicts: include/acpi/acpiosxf.h (with the 'acpica' branch)
| * ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routinesRafael J. Wysocki2013-11-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two different interfaces for queuing up work items on the ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host bridge hotplug code and acpi_os_hotplug_execute() used by the common ACPI hotplug code and docking stations. They both are somewhat cumbersome to use and work slightly differently. The users of alloc_acpi_hp_work() have to submit a work function that will extract the necessary data items from a struct acpi_hp_work object allocated by alloc_acpi_hp_work() and then will free that object, while it would be more straightforward to simply use a work function with one more argument and let the interface take care of the execution details. The users of acpi_os_hotplug_execute() also have to deal with the fact that it takes only one argument in addition to the work function pointer, although acpi_os_execute_deferred() actually takes care of the allocation and freeing of memory, so it would have been able to pass more arguments to the work function if it hadn't been constrained by the connection with acpi_os_execute(). Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory allocations, which is correct, because hotplug work items are always queued up from process context, acpi_os_hotplug_execute() uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also, acpi_os_execute_deferred() queued up by it waits for the ACPI event workqueues to flush before executing the work function, whereas alloc_acpi_hp_work() can't do anything similar. That leads to somewhat arbitrary differences in behavior between various ACPI hotplug code paths and has to be straightened up. For this reason, replace both alloc_acpi_hp_work() and acpi_os_hotplug_execute() with a single interface, acpi_hotplug_execute(), combining their behavior and being more friendly to its users than any of the two. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
| * ACPI / hotplug: Do not execute "insert in progress" _OSTRafael J. Wysocki2013-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to the ACPI spec (5.0, Section 6.3.5), the "Device insertion in progress (pending)" (0x80) _OST status code is reserved for the "Insertion Processing" (0x200) source event which is "a result of an OSPM action". Specifically, it is not a notification, so that status code should not be used during notification processing, which unfortunately is done by acpi_scan_bus_device_check(). For this reason, drop the ACPI_OST_SC_INSERT_IN_PROGRESS _OST status evaluation from there (it was a mistake to put it in there in the first place). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: All applicable <stable@vger.kernel.org>
| * ACPI / hotplug: Carry out PCI root eject directlyRafael J. Wysocki2013-11-06
| | | | | | | | | | | | | | | | | | | | Since _handle_hotplug_event_root() is run from the ACPI hotplug workqueue, it doesn't need to queue up a work item to eject a PCI host bridge on the same workqueue. Instead, it can just carry out the eject by calling acpi_bus_device_eject() directly, so make that happen. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * ACPI / hotplug: Merge device hot-removal routinesRafael J. Wysocki2013-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | There is no real reasn why acpi_bus_device_eject() and acpi_bus_hot_remove_device() should work differently, so rework acpi_bus_device_eject() so that it can be called internally by both acpi_bus_hot_remove_device() and acpi_eject_store_work(). Accordingly, rework acpi_hotplug_notify_cb() to queue up the execution of acpi_bus_hot_remove_device() through acpi_os_hotplug_execute() on eject request notifications. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com>
| * ACPI / hotplug: Make acpi_bus_hot_remove_device() internalRafael J. Wysocki2013-11-06
| | | | | | | | | | | | | | | | | | Notice that handle_root_bridge_removal() is the only user of acpi_bus_hot_remove_device(), so it doesn't have to be exported any more and can be made internal to the ACPI core. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com>
| * ACPI / hotplug: Simplify device ejection routinesRafael J. Wysocki2013-11-06
| | | | | | | | | | | | | | | | | | Simplify handle_root_bridge_removal() and acpi_eject_store() by getting rid of struct acpi_eject_event and passing device objects directly to async routines executed via acpi_os_hotplug_execute(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com>
| * ACPI / hotplug: Refuse to hot-remove all objects with disabled hotplugRafael J. Wysocki2013-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In theory, an ACPI device object may be the parent of another device object whose hotplug is disabled by user space through its scan handler. In that case, the eject operation targeting the parent should fail as though the parent's own hotplug was disabled, but currently this is not the case, because acpi_scan_hot_remove() doesn't check the disable/enable hotplug status of the children of the top-most object passed to it. To fix this, modify acpi_bus_offline_companions() to return an error code if hotplug is disabled for the given device object. [Also change the name of the function to acpi_bus_offline(), because it is not only about companions any more, and change the name of acpi_bus_online_companions() accordingly.] Make acpi_scan_hot_remove() propagate that error to its callers. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com>
| * ACPI / scan: Start matching drivers after trying scan handlersRafael J. Wysocki2013-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ACPI scan handlers should always be attached to struct acpi_device objects before any ACPI drivers, but there is a window during which a driver may be attached to a struct acpi_device before checking if there is a matching scan handler. Namely, that will happen if an ACPI driver module is loaded during acpi_bus_scan() right after the first namespace walk is complete and before the given device is processed by the second namespace walk. To prevent that from happening, set the match_driver flags of struct acpi_device objects right before running device_attach() for them in acpi_bus_device_attach(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com>
* | ACPI / PM: Drop two functions that are not used any moreRafael J. Wysocki2013-10-17
| | | | | | | | | | | | | | | | | | | | | | | | Two functions defined in device_pm.c, acpi_dev_pm_add_dependent() and acpi_dev_pm_remove_dependent(), have no callers and may be dropped, so drop them. Moreover, they are the only functions adding entries to and removing entries from the power_dependent list in struct acpi_device, so drop that list too. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI: Use EXPORT_SYMBOL() for acpi_bus_get_device()Rafael J. Wysocki2013-10-01
| | | | | | | | | | | | | | | | | | | | Commit caf5c03f (ACPI: Move acpi_bus_get_device() from bus.c to scan.c) caused acpi_bus_get_device() to be exported using EXPORT_SYMBOL_GPL(), but that broke some binary drivers in existence, so revert that change. Reported-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI / scan: fix typo in comments of acpi_bus_unregister_driver()Hanjun Guo2013-09-25
|/ | | | | | | "APIC" should be "ACPI" here. Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge branch 'acpi-hotplug'Rafael J. Wysocki2013-09-10
|\ | | | | | | | | | | | | * acpi-hotplug: PM / hibernate / memory hotplug: Rework mutual exclusion PM / hibernate: Create memory bitmaps after freezing user space ACPI / scan: Change ordering of locks for device hotplug
| * ACPI / scan: Change ordering of locks for device hotplugRafael J. Wysocki2013-08-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change the ordering of device hotplug locks in scan.c so that acpi_scan_lock is always acquired after device_hotplug_lock. This will make it possible to use device_hotplug_lock around some code paths that acquire acpi_scan_lock safely (most importantly system suspend and hibernation). Apart from that, acpi_scan_lock is platform-specific and device_hotplug_lock is general, so the new ordering appears to be more appropriate from the overall design viewpoint. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com>
* | Merge branch 'acpi-hotplug'Rafael J. Wysocki2013-08-30
|\| | | | | | | | | | | * acpi-hotplug: ACPI / hotplug: Remove containers synchronously driver core / ACPI: Avoid device hot remove locking issues
| * ACPI / hotplug: Remove containers synchronouslyRafael J. Wysocki2013-08-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current protocol for handling hot remove of containers is very fragile and causes acpi_eject_store() to acquire acpi_scan_lock which may deadlock with the removal of the device that it is called for (the reason is that device sysfs attributes cannot be removed while their callbacks are being executed and ACPI device objects are removed under acpi_scan_lock). The problem is related to the fact that containers are handled by acpi_bus_device_eject() in a special way, which is to emit an offline uevent instead of just removing the container. Then, user space is expected to handle that uevent and use the container's "eject" attribute to actually remove it. That is fragile, because user space may fail to complete the ejection (for example, by not using the container's "eject" attribute at all) leaving the BIOS kind of in a limbo. Moreover, if the eject event is not signaled for a container itself, but for its parent device object (or generally, for an ancestor above it in the ACPI namespace), the container will be removed straight away without doing that whole dance. For this reason, modify acpi_bus_device_eject() to remove containers synchronously like any other objects (user space will get its uevent anyway in case it does some other things in response to it) and remove the eject_pending ACPI device flag that is not used any more. This way acpi_eject_store() doesn't have a reason to acquire acpi_scan_lock any more and one possible deadlock scenario goes away (plus the code is simplified a bit). Reported-and-tested-by: Gu Zheng <guz.fnst@cn.fujitsu.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Toshi Kani <toshi.kani@hp.com>
* | Merge branch 'acpi-assorted'Rafael J. Wysocki2013-08-26
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * acpi-assorted: ACPI / osl: Kill macro INVALID_TABLE(). earlycpio.c: Fix the confusing comment of find_cpio_data(). ACPI / x86: Print Hot-Pluggable Field in SRAT. ACPI / thermal: Use THERMAL_TRIPS_NONE macro to replace number ACPI / thermal: Remove unused macros in the driver/acpi/thermal.c ACPI / thermal: Remove the unused lock of struct acpi_thermal ACPI / osl: Fix osi_setup_entries[] __initdata attribute location ACPI / numa: Fix __init attribute location in slit_valid() ACPI / dock: Fix __init attribute location in find_dock_and_bay() ACPI / Sleep: Fix incorrect placement of __initdata ACPI / processor: Fix incorrect placement of __initdata ACPI / EC: Fix incorrect placement of __initdata ACPI / scan: Drop unnecessary label from acpi_create_platform_device() ACPI: Move acpi_bus_get_device() from bus.c to scan.c ACPI / scan: Allow platform device creation without any IO resources ACPI: Cleanup sparse warning on acpi_os_initialize1() platform / thinkpad: Remove deprecated hotkey_report_mode parameter ACPI: Remove the old /proc/acpi/event interface
| * \ Merge back earlier 'acpi-assorted' materialRafael J. Wysocki2013-08-14
| |\ \ | | |/ | |/|
| | * ACPI: Move acpi_bus_get_device() from bus.c to scan.cRafael J. Wysocki2013-08-06
| | | | | | | | | | | | | | | | | | | | | Move acpi_bus_get_device() from bus.c to scan.c which allows acpi_bus_data_handler() to become static and clean up the latter. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | | Merge branch 'acpi-pm'Rafael J. Wysocki2013-08-26
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * acpi-pm: ACPI / PM: Add state information to error message in acpi_device_set_power() ACPI / PM: Remove redundant power manageable check from acpi_bus_set_power() ACPI / PM: Use ACPI_STATE_D3_COLD instead of ACPI_STATE_D3 everywhere ACPI / PM: Make messages in acpi_device_set_power() print device names ACPI / PM: Only set power states of devices that are power manageable
| * | | ACPI / PM: Use ACPI_STATE_D3_COLD instead of ACPI_STATE_D3 everywhereRafael J. Wysocki2013-07-30
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are several places in the tree where ACPI_STATE_D3 is used instead of ACPI_STATE_D3_COLD which should be used instead for clarity. Modify them all to use ACPI_STATE_D3_COLD as appropriate. [The definition of ACPI_STATE_D3 itself cannot go away at this point as it is part of ACPICA.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com>
* | | Merge branch 'acpi-cleanup'Rafael J. Wysocki2013-08-26
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * acpi-cleanup: (21 commits) ACPI / dock: fix error return code in dock_add() ACPI / dock: Drop unnecessary local variable from dock_add() ACPI / dock / PCI: Drop ACPI dock notifier chain ACPI / dock: Do not check CONFIG_ACPI_DOCK_MODULE ACPI / dock: Do not leak memory on falilures to add a dock station ACPI: Drop ACPI bus notifier call chain ACPI / dock: Rework the handling of notifications ACPI / dock: Simplify dock_init_hotplug() and dock_release_hotplug() ACPI / dock: Walk list in reverse order during removal of devices ACPI / dock: Rework and simplify find_dock_devices() ACPI / dock: Drop the hp_lock mutex from struct dock_station ACPI: simplify acpiphp driver with new helper functions ACPI: simplify dock driver with new helper functions ACPI: Export acpi_(bay)|(dock)_match() from scan.c ACPI: introduce two helper functions for _EJ0 and _LCK ACPI: introduce helper function acpi_execute_simple_method() ACPI: introduce helper function acpi_has_method() ACPI / dock: simplify dock_create_acpi_device() ACPI / dock: mark initialization functions with __init ACPI / dock: drop redundant spin lock in dock station object ...
| * | ACPI: Export acpi_(bay)|(dock)_match() from scan.cJiang Liu2013-07-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Functions acpi_dock_match() and acpi_bay_match() in scan.c can be shared with dock.c to reduce code duplication, so export them as global functions. Also add a new function acpi_ata_match() to check whether an ACPI device object represents an ATA device. [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | ACPI: introduce two helper functions for _EJ0 and _LCKJiang Liu2013-07-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce two helper functions, acpi_evaluate_ej0() and acpi_evaluate_lck(), that will execute the _EJ0 and _LCK ACPI control methods, respectively, and use them to simplify the ACPI scan code. [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | ACPI: introduce helper function acpi_has_method()Jiang Liu2013-07-14
| |/ | | | | | | | | | | | | | | | | Introduce helper function acpi_has_method() and use it in a number of places to simplify code. [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI / scan: Always call acpi_bus_scan() for bus check notificationsRafael J. Wysocki2013-07-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An ACPI_NOTIFY_BUS_CHECK notification means that we should scan the entire namespace starting from the given handle even if the device represented by that handle is present (other devices below it may just have appeared). For this reason, modify acpi_scan_bus_device_check() to always run acpi_bus_scan() if the notification being handled is of type ACPI_NOTIFY_BUS_CHECK. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Cc: 3.10+ <stable@vger.kernel.org>
* | ACPI / scan: Do not try to attach scan handlers to devices having themRafael J. Wysocki2013-07-14
|/ | | | | | | | | | | | | | | | | | | In acpi_bus_device_attach(), if there is an ACPI device object for the given handle and that device object has a scan handler attached to it already, there's nothing more to do for that handle. Moreover, if acpi_scan_attach_handler() is called then, it may execute the .attach() callback of the ACPI scan handler already attached to the device object and that may lead to interesting breakage. For this reason, make acpi_bus_device_attach() return success immediately when the handle's device object has a scan handler attached to it. Reported-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Cc: 3.10+ <stable@vger.kernel.org>
* ACPI / scan: remove unused LIST_HEAD(acpi_device_list)Haicheng Li2013-07-04
| | | | | | | | The acpi_device_list list is not used, so removed it. [rjw: Changelog] Signed-off-by: Haicheng Li <haicheng.li@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge branch 'acpi-assorted'Rafael J. Wysocki2013-06-28
|\ | | | | | | | | | | | | | | | | | | | | * acpi-assorted: ACPI / EC: Add HP Folio 13 to ec_dmi_table in order to skip DSDT scan ACPI: Add CMOS RTC Operation Region handler support ACPI: Remove unused flags in acpi_device_flags ACPI: Remove useless initializers ACPI / battery: Make sure all spaces are in correct places ACPI: add _STA evaluation at do_acpi_find_child() ACPI / EC: access user space with get_user()/put_user()
| * ACPI: Add CMOS RTC Operation Region handler supportLan Tianyu2013-06-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On HP Folio 13-2000, the BIOS defines a CMOS RTC Operation Region and the EC's _REG methord accesses that region. Thus an appropriate address space handler must be registered for that region before the EC driver is loaded. Introduce a mechanism for adding CMOS RTC address space handlers. Register an ACPI scan handler for CMOS RTC devices such that, when a device of that kind is detected during an ACPI namespace scan, a common CMOS RTC operation region address space handler will be installed for it. References: https://bugzilla.kernel.org/show_bug.cgi?id=54621 Reported-and-tested-by: Stefan Nagy <public@stefan-nagy.at> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Cc: 3.9+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | Merge branch 'acpi-scan'Rafael J. Wysocki2013-06-28
|\ \ | | | | | | | | | | | | | | | | | | * acpi-scan: ACPI / scan: Do not bind ACPI drivers to objects with scan handlers ACPI / ia64 / sba_iommu: Use ACPI scan handler for device discovery ACPI / scan: Simplify ACPI driver probing
| * | ACPI / scan: Do not bind ACPI drivers to objects with scan handlersRafael J. Wysocki2013-06-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ACPI drivers must not be bound to device objects having scan handlers attatched to them, so make acpi_device_probe() fail with -EINVAL if the device object being probed has an ACPI scan handler. After this change the analogous check introduced into the ACPI video driver by commit 8c9b7a7 (ACPI / video: Do not bind to device objects with a scan handler) is not necessary any more and may be dropped, so drop it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Tony Luck <tony.luck@gmail.com> Acked-by: Toshi Kani <toshi.kani@hp.com>
| * | ACPI / scan: Simplify ACPI driver probingRafael J. Wysocki2013-06-15
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no particular reason why acpi_bus_driver_init() needs to be a separate function and its location with respect to its only caller, acpi_device_probe(), makes the code a bit difficult to follow. Besides, it doesn't really make sense to check if 'device' is not NULL in acpi_bus_driver_init(), because we've already dereferenced dev->driver in acpi_device_probe() at that point and, moreover, 'device' cannot be NULL then, because acpi_device_probe() is called via really_probe() (which also sets dev->driver for that matter). For these reasons, drop acpi_bus_driver_init() altogether and move the remaining code from it directly into acpi_device_probe(). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | Merge branch 'acpi-hotplug'Rafael J. Wysocki2013-06-28
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * acpi-hotplug: ACPI: Do not use CONFIG_ACPI_HOTPLUG_MEMORY_MODULE ACPI / cpufreq: Add ACPI processor device IDs to acpi-cpufreq Memory hotplug: Move alternative function definitions to header ACPI / processor: Fix potential NULL pointer dereference in acpi_processor_add() Memory hotplug / ACPI: Simplify memory removal ACPI / scan: Add second pass of companion offlining to hot-remove code Driver core / MM: Drop offline_memory_block() ACPI / processor: Pass processor object handle to acpi_bind_one() ACPI: Drop removal_type field from struct acpi_device Driver core / memory: Simplify __memory_block_change_state() ACPI / processor: Initialize per_cpu(processors, pr->id) properly CPU: Fix sysfs cpu/online of offlined CPUs Driver core: Introduce offline/online callbacks for memory blocks ACPI / memhotplug: Bind removable memory blocks to ACPI device nodes ACPI / processor: Use common hotplug infrastructure ACPI / hotplug: Use device offline/online for graceful hot-removal Driver core: Use generic offline/online for CPU offline/online Driver core: Add offline/online device operations
| * | ACPI / scan: Add second pass of companion offlining to hot-remove codeRafael J. Wysocki2013-06-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As indicated by comments in mm/memory_hotplug.c:remove_memory(), if CONFIG_MEMCG is set, it may not be possible to offline all of the memory blocks held by one module (FRU) in one pass (because one of them may be used by the others to store page cgroup in that case and that block has to be offlined before the other ones). To handle that arguably corner case, add a second pass of companion device offlining to acpi_scan_hot_remove() and make it ignore errors returned in the first pass (and make it skip the second pass if the first one is successful). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com>
| * | ACPI: Drop removal_type field from struct acpi_deviceRafael J. Wysocki2013-06-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ACPI processor driver was the only user of the removal_type field in struct acpi_device, but it doesn't use that field any more after recent changes. Thus, removal_type has no more users, so drop it along with the associated data type. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Toshi Kani <toshi.kani@hp.com>
| * | ACPI / processor: Use common hotplug infrastructureRafael J. Wysocki2013-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Split the ACPI processor driver into two parts, one that is non-modular, resides in the ACPI core and handles the enumeration and hotplug of processors and one that implements the rest of the existing processor driver functionality. The non-modular part uses an ACPI scan handler object to enumerate processors on the basis of information provided by the ACPI namespace and to hook up with the common ACPI hotplug infrastructure. It also populates the ACPI handle of each processor device having a corresponding object in the ACPI namespace, which allows the driver proper to bind to those devices, and makes the driver bind to them if it is readily available (i.e. loaded) when the scan handler's .attach() routine is running. There are a few reasons to make this change. First, switching the ACPI processor driver to using the common ACPI hotplug infrastructure reduces code duplication and size considerably, even though a new file is created along with a header comment etc. Second, since the common hotplug code attempts to offline devices before starting the (non-reversible) removal procedure, it will abort (and possibly roll back) hot-remove operations involving processors if cpu_down() returns an error code for one of them instead of continuing them blindly (if /sys/firmware/acpi/hotplug/force_remove is unset). That is a more desirable behavior than what the current code does. Finally, the separation of the scan/hotplug part from the driver proper makes it possible to simplify the driver's .remove() routine, because it doesn't need to worry about the possible cleanup related to processor removal any more (the scan/hotplug part is responsible for that now) and can handle device removal and driver removal symmetricaly (i.e. as appropriate). Some user-visible changes in sysfs are made (for example, the 'sysdev' link from the ACPI device node to the processor device's directory is gone and a 'physical_node' link is present instead and a corresponding 'firmware_node' is present in the processor device's directory, the processor driver is now visible under /sys/bus/cpu/drivers/ and bound to the processor device), but that shouldn't affect the functionality that users care about (frequency scaling, C-states and thermal management). Tested on my venerable Toshiba Portege R500. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Toshi Kani <toshi.kani@hp.com>
| * | ACPI / hotplug: Use device offline/online for graceful hot-removalRafael J. Wysocki2013-05-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Modify the generic ACPI hotplug code to be able to check if devices scheduled for hot-removal may be gracefully removed from the system using the device offline/online mechanism introduced previously. Namely, make acpi_scan_hot_remove() handling device hot-removal call device_offline() for all physical companions of the ACPI device nodes involved in the operation and check the results. If any of the device_offline() calls fails, the function will not progress to the removal phase (which cannot be aborted), unless its (new) force argument is set (in case of a failing offline it will put the devices offlined by it back online). In support of 'forced' device hot-removal, add a new sysfs attribute 'force_remove' that will reside under /sys/firmware/acpi/hotplug/. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Toshi Kani <toshi.kani@hp.com>
* | | ACPI / dock: Initialize ACPI dock subsystem upfrontJiang Liu2013-06-22
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 3b63aaa70e1 (PCI: acpiphp: Do not use ACPI PCI subdriver mechanism) introduced an ACPI dock support regression, because it changed the relative initialization order of the ACPI dock subsystem and the ACPI-based PCI hotplug (acpiphp). Namely, the ACPI dock subsystem has to be initialized before acpiphp_enumerate_slots() is first run, which after commit 3b63aaa70e1 happens during the initial enumeration of the PCI hierarchy triggered by the initial ACPI namespace scan in acpi_scan_init(). For this reason, the dock subsystem has to be initialized before the initial ACPI namespace scan in acpi_scan_init(). To make that happen, modify the ACPI dock subsystem to be non-modular and add the invocation of its initialization routine, acpi_dock_init(), to acpi_scan_init() directly before the initial namespace scan. [rjw: Changelog, removal of dock_exit().] References: https://bugzilla.kernel.org/show_bug.cgi?id=59501 Reported-and-tested-by: Alexander E. Patrakov <patrakov@gmail.com> Tested-by: Illya Klymov <xanf@xanf.me> Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Cc: 3.9+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | ACPI / video: Do not bind to device objects with a scan handlerRafael J. Wysocki2013-06-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the introduction of ACPI scan handlers, ACPI device objects with an ACPI scan handler attached to them must not be bound to by ACPI drivers any more. Unfortunately, however, the ACPI video driver attempts to do just that if there is a _ROM ACPI control method defined under a device object with an ACPI scan handler. Prevent that from happening by making the video driver's "add" routine check if the device object already has an ACPI scan handler attached to it and return an error code in that case. That is not sufficient, though, because acpi_bus_driver_init() would then clear the device object's driver_data that may be set by its scan handler, so for the fix to work acpi_bus_driver_init() has to be modified to leave driver_data as is on errors. References: https://bugzilla.kernel.org/show_bug.cgi?id=58091 Bisected-and-tested-by: Dmitry S. Demin <dmitryy.demin@gmail.com> Reported-and-tested-by: Jason Cassell <bluesloth600@gmail.com> Tracked-down-by: Aaron Lu <aaron.lu@intel.com> Cc: 3.9+ <stable@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com>
* | Revert "ACPI / scan: do not match drivers against objects having scan handlers"Rafael J. Wysocki2013-06-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 9f29ab11ddbf ("ACPI / scan: do not match drivers against objects having scan handlers") introduced a boot regression on Tony's ia64 HP rx2600. Tony says: "It panics with the message: Kernel panic - not syncing: Unable to find SBA IOMMU: Try a generic or DIG kernel [...] my problem comes from arch/ia64/hp/common/sba_iommu.c where the code in sba_init() says: acpi_bus_register_driver(&acpi_sba_ioc_driver); if (!ioc_list) { but because of this change we never managed to call ioc_init() so ioc_list doesn't get set up, and we die." Revert it to avoid this breakage and we'll fix the problem it attempted to address later. Reported-by: Tony Luck <tony.luck@gmail.com> Cc: 3.9+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | ACPI / scan: do not match drivers against objects having scan handlersAaron Lu2013-06-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the introduction of ACPI scan handlers, an ACPI device object with an ACPI scan handler attached to it must not be bound to an ACPI driver any more. Therefore it doesn't make sense to match those ACPI device objects against a newly registered ACPI driver in acpi_bus_match(), so make that function return 0 if the device object passed to it has an ACPI scan handler attached. This also addresses a regression related to a broken ACPI table in the BIOS, where it has defined a _ROM method under the PCI root bridge object. This causes the video module to treat that object as a display controller device (since only display devices are supposed to have a _ROM method defined according to the ACPI spec). As a result, the ACPI video driver binds to the PCI root bridge object and overwrites the previously assigned driver_data field of it, causing subsequent calls to acpi_get_pci_dev() to fail. [rjw: Subject and changelog] References: https://bugzilla.kernel.org/show_bug.cgi?id=58091 Reported-by: Jason Cassell <bluesloth600@gmail.com> Reported-and-bisected-by: Dmitry S. Demin <dmitryy.demin@gmail.com> Cc: 3.9+ <stable@kernel.org> Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | Merge branch 'fixes' of git://git.infradead.org/users/vkoul/slave-dmaLinus Torvalds2013-05-25
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | Pull slave-dma fixes from Vinod Koul: "We have two patches from Andy & Rafael fixing the Lynxpoint dma" * 'fixes' of git://git.infradead.org/users/vkoul/slave-dma: ACPI / LPSS: register clock device for Lynxpoint DMA properly dma: acpi-dma: parse CSRT to extract additional resources
| * | dma: acpi-dma: parse CSRT to extract additional resourcesAndy Shevchenko2013-05-14
| |/ | | | | | | | | | | | | | | | | | | Since we have CSRT only to get additional DMA controller resources, let's get rid of drivers/acpi/csrt.c and move its logic inside ACPI DMA helpers code. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
* / ACPI / scan: Fix memory leak on acpi_scan_init_hotplug() error pathCatalin Marinas2013-05-15
|/ | | | | | | | | | | | | | | | Following commit 6b772e8f9 (ACPI: Update PNPID match handling for notify), the acpi_scan_init_hotplug() calls acpi_set_pnp_ids() which allocates acpi_hardware_id and copies a few strings (kstrdup). If the devices does not have hardware_id set, the function exits without freeing the previously allocated ids (and kmemleak complains). This patch calls simply changes 'return' on error to a 'goto out' which calls acpi_free_pnp_ids(). Reported-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Toshi Kani <toshi.kani@hp.com> Tested-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge tag 'pm+acpi-3.10-rc1' of ↵Linus Torvalds2013-04-30
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management and ACPI updates from Rafael J Wysocki: - ARM big.LITTLE cpufreq driver from Viresh Kumar. - exynos5440 cpufreq driver from Amit Daniel Kachhap. - cpufreq core cleanup and code consolidation from Viresh Kumar and Stratos Karafotis. - cpufreq scalability improvement from Nathan Zimmer. - AMD "frequency sensitivity feedback" powersave bias for the ondemand cpufreq governor from Jacob Shin. - cpuidle code consolidation and cleanups from Daniel Lezcano. - ARM OMAP cpuidle fixes from Santosh Shilimkar and Daniel Lezcano. - ACPICA fixes and other improvements from Bob Moore, Jung-uk Kim, Lv Zheng, Yinghai Lu, Tang Chen, Colin Ian King, and Linn Crosetto. - ACPI core updates related to hotplug from Toshi Kani, Paul Bolle, Yasuaki Ishimatsu, and Rafael J Wysocki. - Intel Lynxpoint LPSS (Low-Power Subsystem) support improvements from Rafael J Wysocki and Andy Shevchenko. * tag 'pm+acpi-3.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (192 commits) cpufreq: Revert incorrect commit 5800043 cpufreq: MAINTAINERS: Add co-maintainer cpuidle: add maintainer entry ACPI / thermal: do not always return THERMAL_TREND_RAISING for active trip points ARM: s3c64xx: cpuidle: use init/exit common routine cpufreq: pxa2xx: initialize variables ACPI: video: correct acpi_video_bus_add error processing SH: cpuidle: use init/exit common routine ARM: S5pv210: compiling issue, ARM_S5PV210_CPUFREQ needs CONFIG_CPU_FREQ_TABLE=y ACPI: Fix wrong parameter passed to memblock_reserve cpuidle: fix comment format pnp: use %*phC to dump small buffers isapnp: remove debug leftovers ARM: imx: cpuidle: use init/exit common routine ARM: davinci: cpuidle: use init/exit common routine ARM: kirkwood: cpuidle: use init/exit common routine ARM: calxeda: cpuidle: use init/exit common routine ARM: tegra: cpuidle: use init/exit common routine for tegra3 ARM: tegra: cpuidle: use init/exit common routine for tegra2 ARM: OMAP4: cpuidle: use init/exit common routine ...