summaryrefslogtreecommitdiff
path: root/drivers/acpi/dock.c
AgeCommit message (Collapse)Author
2017-11-09ACPI: Mark expected switch fall-throughsGustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-03ACPI / dock: constify attribute_group structureAmitoj Kaur Chawla
Functions working with attribute_groups provided by <linux/sysfs.h> work with const attribute_group. These attribute_group structures do not change at runtime so mark them as const. File size before: text data bss dec hex filename 7902 3528 64 11494 2ce6 drivers/acpi/dock.o File size after: text data bss dec hex filename 7998 3432 64 11494 2ce6 drivers/acpi/dock.o This change was made with the help of Coccinelle. Signed-off-by: Amitoj Kaur Chawla <amitoj1606@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-07-16ACPI / dock: make dock explicitly non-modularPaul Gortmaker
The Kconfig for this file is: drivers/acpi/Kconfig:config ACPI_DOCK drivers/acpi/Kconfig: bool "Dock" ...and so it is not built as a module. Hence including module.h and everything that comes with it just for the no-op MODULE_LICENSE and friends is rather heavy handed. The license/author info is found at the top of the file, so we just remove the MODULE_LICENSE etc and the include of module.h The file does still have some module_param() so we add the right include for that infrastructure. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-08ACPI: Remove FSF mailing addressesJarkko Nikula
There is no need to carry potentially outdated Free Software Foundation mailing address in file headers since the COPYING file includes it. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-16driver core / ACPI: Represent ACPI companions using fwnode_handleRafael J. Wysocki
Now that we have struct fwnode_handle, we can use that to point to ACPI companions from struct device objects instead of pointing to struct acpi_device directly. There are two benefits from that. First, the somewhat ugly and hackish struct acpi_dev_node can be dropped and, second, the same struct fwnode_handle pointer can be used in the future to point to other (non-ACPI) firmware device node types. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Grant Likely <grant.likely@linaro.org>
2014-04-07ACPI / dock: Drop dock_device_ids[] tableRafael J. Wysocki
There are no references to the dock_device_ids[] table anywhere in the code and it is not even useful for module autoloading, because the dock driver can only be built in, so drop it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-20Merge branches 'acpi-cleanup', 'acpi-thermal', 'acpi-pci', 'acpi-lpss' and ↵Rafael J. Wysocki
'acpi-button' * acpi-cleanup: ACPI: Remove duplicate definitions of PREFIX ACPI / tables: Replace printk with pr_* * acpi-thermal: ACPI / thermal: make acpi_thermal_check asynchronous on resume * acpi-pci: ACPI / PCI: Do not call ISA-specific code if ISA is not supported * acpi-lpss: ACPI / LPSS: Add Intel BayTrail ACPI mode PWM * acpi-button: ACPI / button: Add ACPI Button event via netlink routine
2014-03-19ACPI: Remove duplicate definitions of PREFIXHanjun Guo
We already have a macro for PREFIX of "ACPI: " in drivers/acpi/internal.h, so remove the duplicate ones in ACPI drivers when internal.h is included. Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-22ACPI / dock: Update copyright noticeRafael J. Wysocki
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>
2014-02-22ACPI / dock: Drop remove_dock_dependent_devices()Rafael J. Wysocki
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>
2014-02-22ACPI / dock: Drop struct acpi_dock_ops and all code related to itRafael J. Wysocki
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>
2014-02-21ACPI / dock: Add .uevent() callback to struct acpi_hotplug_contextRafael J. Wysocki
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>
2014-02-21ACPI / dock: Use callback pointers from devices' ACPI hotplug contextsRafael J. Wysocki
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>
2014-02-21ACPI / dock: Use ACPI device object pointers instead of ACPI handlesRafael J. Wysocki
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>
2014-02-16ACPI / dock: Associate dock platform devices with ACPI device objectsRafael J. Wysocki
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>
2014-02-16ACPI / dock: Pass ACPI device pointer to acpi_device_is_battery()Rafael J. Wysocki
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>
2014-02-16ACPI / dock: Dispatch dock notifications from the global notify handlerRafael J. Wysocki
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>
2014-02-15ACPI / dock: Make 'docked' sysfs attribute work as documentedRafael J. Wysocki
After recent ACPI core changes acpi_bus_get_device() will always succeed for dock station ACPI device objects, so show_docked() should not use that function's return value as an indicator of whether or not the dock device is present. Make it use acpi_device_enumerated() for this purpose. Fixes: 202317a573b2 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-10ACPI / dock: Use acpi_device_enumerated() to check if dock is presentRafael J. Wysocki
After commit 202317a573b2 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace) acpi_bus_get_device() will always return 0 for dock devices in dock_notify(), so the dock station docking code under ACPI_NOTIFY_DEVICE_CHECK will never be executed and docking will not work as a result of that. Fix the problem by making dock_notify() use acpi_device_enumerated() to check the presence of the device instead of checking the return value of acpi_bus_get_device(). Fixes: 202317a573b2 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-12Merge branch 'acpi-hotplug'Rafael J. Wysocki
* acpi-hotplug: ACPI / scan: ACPI device object sysfs attribute for _STA evaluation ACPI / hotplug / driver core: Handle containers in a special way ACPI / hotplug: Add demand_offline hotplug profile flag ACPI / bind: Move acpi_get_child() to drivers/ide/ide-acpi.c ACPI / bind: Pass struct acpi_device pointer to acpi_bind_one() ACPI / bind: Rework struct acpi_bus_type ACPI / bind: Redefine acpi_preset_companion() ACPI / bind: Redefine acpi_get_child() PCI / ACPI: Use acpi_find_child_device() for child devices lookup ACPI / bind: Simplify child device lookups ACPI / scan: Use direct recurrence for device hierarchy walks ACPI: Introduce acpi_set_device_status() ACPI / hotplug: Drop unfinished global notification handling routines ACPI / hotplug: Rework generic code to handle suprise removals ACPI / hotplug: Move container-specific code out of the core ACPI / hotplug: Make ACPI PCI root hotplug use common hotplug code ACPI / hotplug: Introduce common hotplug function acpi_device_hotplug() ACPI / hotplug: Do not fail bus and device checks for disabled hotplug ACPI / scan: Add acpi_device objects for all device nodes in the namespace ACPI / scan: Define non-empty device removal handler
2014-01-06ACPI / dock: Include appropriate header file in dock.cRashika
Includes appropriate header file internal.h in dock.c because function acpi_dock_init() has its prototype declaration in internal.h. This eliminates the following warning in dock.c: drivers/acpi/dock.c:899:13: warning: no previous prototype for ‘acpi_dock_init’ [-Wmissing-prototypes] Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-12-07ACPI / dock: Drop redundant acpi_disabled checkHanjun Guo
acpi_dock_init() is only called from acpi_scan_init() and the code logic shows that it doesn't need to check acpi_disabled: acpi_init(); if (acpi_disabled) return; acpi_scan_init(); acpi_dock_init(); if (acpi_disabled) /* redundant */ return; Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> [rjw: Subject and changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-12-07Merge branch 'acpi-cleanup' into acpi-hotplugRafael J. Wysocki
Conflicts: drivers/acpi/scan.c
2013-12-07ACPI: Clean up inclusions of ACPI header filesLv Zheng
Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h> inclusions and remove some inclusions of those files that aren't necessary. First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h> should not be included directly from any files that are built for CONFIG_ACPI unset, because that generally leads to build warnings about undefined symbols in !CONFIG_ACPI builds. For CONFIG_ACPI set, <linux/acpi.h> includes those files and for CONFIG_ACPI unset it provides stub ACPI symbols to be used in that case. Second, there are ordering dependencies between those files that always have to be met. Namely, it is required that <acpi/acpi_bus.h> be included prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the latter depends on are always there. And <acpi/acpi.h> which provides basic ACPICA type declarations should always be included prior to any other ACPI headers in CONFIG_ACPI builds. That also is taken care of including <linux/acpi.h> as appropriate. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Tony Luck <tony.luck@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff) Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-11-22ACPI / scan: Add acpi_device objects for all device nodes in the namespaceRafael J. Wysocki
Modify the ACPI namespace scanning code to register a struct acpi_device object for every namespace node representing a device, processor and so on, even if the device represented by that namespace node is reported to be not present and not functional by _STA. There are multiple reasons to do that. First of all, it avoids quite a lot of overhead when struct acpi_device objects are deleted every time acpi_bus_trim() is run and then added again by a subsequent acpi_bus_scan() for the same scope, although the namespace objects they correspond to stay in memory all the time (which always is the case on a vast majority of systems). Second, it will allow user space to see that there are namespace nodes representing devices that are not present at the moment and may be added to the system. It will also allow user space to evaluate _SUN for those nodes to check what physical slots the "missing" devices may be put into and it will make sense to add a sysfs attribute for _STA evaluation after this change (that will be useful for thermal management on some systems). Next, it will help to consolidate the ACPI hotplug handling among subsystems by making it possible to store hotplug-related information in struct acpi_device objects in a standard common way. Finally, it will help to avoid a race condition related to the deletion of ACPI namespace nodes. Namely, namespace nodes may be deleted as a result of a table unload triggered by _EJ0 or _DCK. If a hotplug notification for one of those nodes is triggered right before the deletion and it executes a hotplug callback via acpi_hotplug_execute(), the ACPI handle passed to that callback may be stale when the callback actually runs. One way to work around that is to always pass struct acpi_device pointers to hotplug callbacks after doing a get_device() on the objects in question which eliminates the use-after-free possibility (the ACPI handles in those objects are invalidated by acpi_scan_drop_device(), so they will trigger ACPICA errors on attempts to use them). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-07Merge branch 'acpi-hotplug'Rafael J. Wysocki
* 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)
2013-11-07ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routinesRafael J. Wysocki
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>
2013-09-24ACPI: dock: convert acpi_evaluate_object() to acpi_evaluate_integer()Zhang Rui
acpi_evaluate_integer() is an ACPI API introduced to evaluate an ACPI control method that is known to have an integer return value. This API can simplify the code because the calling function does not need to use the specified acpi_buffer structure required by acpi_evaluate_object(); Convert acpi_evaluate_object() to acpi_evaluate_integer() in drivers/acpi/dock.c in this patch. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-08-27Merge branch 'acpi-assorted'Rafael J. Wysocki
* 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
2013-08-13ACPI / dock: Fix __init attribute location in find_dock_and_bay()Hanjun Guo
__init belongs after the return type on functions, not before it. Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-26ACPI / dock: fix error return code in dock_add()Wei Yongjun
Fix to return -ENODEV in the acpi notify handler install error handling case instead of 0, as done elsewhere in this function. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-15ACPI / dock: Drop unnecessary local variable from dock_add()Rafael J. Wysocki
The local variable id in dock_add() is not necessary, so drop it. While we're at it, use an initializer to clear the local variable ds and drop the memset() used for this purpose. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-15ACPI / dock / PCI: Drop ACPI dock notifier chainRafael J. Wysocki
The only user of the ACPI dock notifier chain is the ACPI-based PCI hotplug (acpiphp) driver that uses it to carry out post-dock fixups needed by some systems with broken _DCK. However, it is not necessary to use a separate notifier chain for that, as it can be simply replaced with a new callback in struct acpi_dock_ops. For this reason, add a new .fixup() callback to struct acpi_dock_ops and make hotplug_dock_devices() execute it for all dock devices with hotplug operations registered. Accordingly, make acpiphp point that callback to the function carrying out the post-dock fixups and do not register a separate dock notifier for each device registering dock operations. Finally, drop the ACPI dock notifier chain that has no more users. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-15ACPI / dock: Do not leak memory on falilures to add a dock stationRafael J. Wysocki
The function creating and registering dock station objects, dock_add(), leaks memory if there's an error after it's walked the ACPI namespace calling find_dock_devices(), because it doesn't free the list of dependent devices it's just created in those cases. Fix that issue by adding the missing code to free the list of dependent devices on errors. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-15ACPI / dock: Rework the handling of notificationsRafael J. Wysocki
The ACPI dock driver uses register_acpi_bus_notifier() which installs a notifier triggered globally for all system notifications. That first of all is inefficient, because the dock driver is only interested in notifications associated with the devices it handles, but it has to handle all system notifies for all devices. Moreover, it does that even if no docking stations are present in the system (CONFIG_ACPI_DOCK set is sufficient for that to happen). Besides, that is inconvenient, because it requires the driver to do extra work for each notification to find the target dock station object. For these reasons, rework the dock driver to install a notify handler individually for each dock station in the system using acpi_install_notify_handler(). This allows the dock station object to be passed directly to the notify handler and makes it possible to simplify the dock driver quite a bit. It also reduces the overhead related to the handling of all system notifies when CONFIG_ACPI_DOCK is set. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-07-15ACPI / dock: Simplify dock_init_hotplug() and dock_release_hotplug()Rafael J. Wysocki
Make dock_init_hotplug() and dock_release_hotplug() slightly simpler and move some checks in those functions to the code paths where they are needed. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-07-15ACPI / dock: Walk list in reverse order during removal of devicesRafael J. Wysocki
If there are indirect dependencies between devices in a dock station's dependent devices list, they may be broken if the devices are removed in the same order in which they have been added. For this reason, make the code in handle_eject_request() walk the list of dependent devices in reverse order. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-07-15ACPI / dock: Rework and simplify find_dock_devices()Rafael J. Wysocki
Since acpi_walk_namespace() calls find_dock_devices() during tree pre-order visit, the latter doesn't need to add devices whose parents have _EJD pointing to the docking station to the list of that station's dependent devices, because those parents are going to be added to that list anyway and the removal of a parent will take care of the removal of its children in those cases. For this reason, rework find_dock_devices() to only call add_dock_dependent_device() for devices whose _EJD point directy to the docking station represented by its context argument and simplify it slightly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2013-07-15ACPI / dock: Drop the hp_lock mutex from struct dock_stationRafael J. Wysocki
The only existing user of the hp_lock mutex in struct dock_station, hotplug_dock_devices(), is always called under acpi_scan_lock and cannot race with another instance of itself, so drop the mutex which is not necessary. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-15ACPI: simplify dock driver with new helper functionsJiang Liu
Use helper functions introduced previously to simplify the ACPI dock driver. [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-15ACPI / dock: simplify dock_create_acpi_device()Jiang Liu
The return value of dock_create_acpi_device() is not used at all, so change its signature to return void and simplify the implementation of it. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-15ACPI / dock: mark initialization functions with __initJiang Liu
Mark all initialization functions with __init to reduce runtime memory consumption. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-15ACPI / dock: drop redundant spin lock in dock station objectJiang Liu
All dock station objects are created during initialization and don't change at runtime, so drop the redundant spin lock from struct dock_station. [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-15ACPI / dock: avoid initializing acpi_dock_notifier_list multiple timesJiang Liu
Function dock_add() will be called multiple times if there are multiple dock stations, which causes acpi_dock_notifier_list to be initialized multiple times. To avoid that, move the initialization of acpi_dock_notifier_list from dock_add() to acpi_dock_init(). [rjw: Changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-07-04ACPI / dock: Actually define acpi_dock_init() as voidRafael J. Wysocki
Commit 94add0f (ACPI / dock: Initialize ACPI dock subsystem upfront) changed the header of acpi_dock_init() in internal.h so that it is supposed to be a void function now, but it forgot to update its actual definition in dock.c according to which it still is supposed to return int. Although that didn't cause any visible breakage or even a compiler warning to be thrown, which is odd enough, fix it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 3.10+ <stable@vger.kernel.org>
2013-06-24ACPI / dock / PCI: Synchronous handling of dock events for PCI devicesRafael J. Wysocki
The interactions between the ACPI dock driver and the ACPI-based PCI hotplug (acpiphp) are currently problematic because of ordering issues during hot-remove operations. First of all, the current ACPI glue code expects that physical devices will always be deleted before deleting the companion ACPI device objects. Otherwise, acpi_unbind_one() will fail with a warning message printed to the kernel log, for example: [ 185.026073] usb usb5: Oops, 'acpi_handle' corrupt [ 185.035150] pci 0000:1b:00.0: Oops, 'acpi_handle' corrupt [ 185.035515] pci 0000:18:02.0: Oops, 'acpi_handle' corrupt [ 180.013656] port1: Oops, 'acpi_handle' corrupt This means, in particular, that struct pci_dev objects have to be deleted before the struct acpi_device objects they are "glued" with. Now, the following happens the during the undocking of an ACPI-based dock station: 1) hotplug_dock_devices() invokes registered hotplug callbacks to destroy physical devices associated with the ACPI device objects depending on the dock station. It calls dd->ops->handler() for each of those device objects. 2) For PCI devices dd->ops->handler() points to handle_hotplug_event_func() that queues up a separate work item to execute _handle_hotplug_event_func() for the given device and returns immediately. That work item will be executed later. 3) hotplug_dock_devices() calls dock_remove_acpi_device() for each device depending on the dock station. This runs acpi_bus_trim() for each of them, which causes the underlying ACPI device object to be destroyed, but the work items queued up by handle_hotplug_event_func() haven't been started yet. 4) _handle_hotplug_event_func() queued up in step 2) are executed and cause the above failure to happen, because the PCI devices they handle do not have the companion ACPI device objects any more (those objects have been deleted in step 3). The possible breakage doesn't end here, though, because hotplug_dock_devices() may return before at least some of the _handle_hotplug_event_func() work items spawned by it have a chance to complete and then undock() will cause _DCK to be evaluated and that will cause the devices handled by the _handle_hotplug_event_func() to go away possibly while they are being accessed. This means that dd->ops->handler() for PCI devices should not point to handle_hotplug_event_func(). Instead, it should point to a function that will do the work of _handle_hotplug_event_func() synchronously. For this reason, introduce such a function, hotplug_event_func(), and modity acpiphp_dock_ops to point to it as the handler. Unfortunately, however, this is not sufficient, because if the dock code were not changed further, hotplug_event_func() would now deadlock with hotplug_dock_devices() that called it, since it would run unregister_hotplug_dock_device() which in turn would attempt to acquire the dock station's hp_lock mutex already acquired by hotplug_dock_devices(). To resolve that deadlock use the observation that unregister_hotplug_dock_device() won't need to acquire hp_lock if PCI bridges the devices on the dock station depend on are prevented from being removed prematurely while the first loop in hotplug_dock_devices() is in progress. To make that possible, introduce a mechanism by which the callers of register_hotplug_dock_device() can provide "init" and "release" routines that will be executed, respectively, during the addition and removal of the physical device object associated with the given ACPI device handle. Make acpiphp use two new functions, acpiphp_dock_init() and acpiphp_dock_release(), that call get_bridge() and put_bridge(), respectively, on the acpiphp bridge holding the given device, for this purpose. In addition to that, remove the dock station's list of "hotplug devices" and make the dock code always walk the whole list of "dependent devices" instead in such a way that the loops in hotplug_dock_devices() and dock_event() (replacing the loops over "hotplug devices") will take references to the list entries that register_hotplug_dock_device() has been called for. That prevents the "release" routines associated with those entries from being called while the given entry is being processed and for PCI devices this means that their bridges won't be removed (by a concurrent thread) while hotplug_event_func() handling them is being executed. This change is based on two earlier patches from Jiang Liu. References: https://bugzilla.kernel.org/show_bug.cgi?id=59501 Reported-and-tested-by: Alexander E. Patrakov <patrakov@gmail.com> Tracked-down-by: Jiang Liu <jiang.liu@huawei.com> Tested-by: Illya Klymov <xanf@xanf.me> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Cc: 3.9+ <stable@vger.kernel.org>
2013-06-23ACPI / dock: Initialize ACPI dock subsystem upfrontJiang Liu
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>
2013-06-19ACPI / dock: Take ACPI scan lock in write_undock()Rafael J. Wysocki
Since commit 3757b94 (ACPI / hotplug: Fix concurrency issues and memory leaks) acpi_bus_scan() and acpi_bus_trim() must always be called under acpi_scan_lock, but currently the following scenario violating that requirement is possible: write_undock() handle_eject_request() hotplug_dock_devices() dock_remove_acpi_device() acpi_bus_trim() Fix that by making write_undock() acquire acpi_scan_lock before calling handle_eject_request() as appropriate (begin_undock() is under the lock too in analogy with acpi_dock_deferred_cb()). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 3.9+ <stable@vger.kernel.org> Acked-by: Toshi Kani <toshi.kani@hp.com>
2013-02-13ACPI / hotplug: Fix concurrency issues and memory leaksRafael J. Wysocki
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>
2013-02-02ACPI / dock: Fix acpi_bus_get_device() check in drivers/acpi/dock.cYasuaki Ishimatsu
acpi_bus_get_device() returns int not acpi_status. The patch change not to apply ACPI_SUCCESS() to the return value of acpi_bus_get_device(). Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>