Revision tags: v3.14-rc2 |
|
#
1f7c164b |
| 03-Feb-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Rework acpiphp_check_host_bridge()
Since the only existing caller of acpiphp_check_host_bridge(), which is acpi_pci_root_scan_dependent(), already has a struct acpi_device poin
ACPI / hotplug / PCI: Rework acpiphp_check_host_bridge()
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>
show more ...
|
#
1a699476 |
| 06-Feb-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Hotplug notifications from acpi_bus_notify()
Since acpi_bus_notify() is executed on all notifications for all devices anyway, make it execute acpi_device_hotplug() for all hotp
ACPI / hotplug / PCI: Hotplug notifications from acpi_bus_notify()
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>
show more ...
|
#
5e6f236c |
| 06-Feb-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Simplify acpi_install_hotplug_notify_handler()
Since acpi_hotplug_notify_cb() does not use its data argument any more, the second argument of acpi_install_hotplug_notify_handle
ACPI / hotplug / PCI: Simplify acpi_install_hotplug_notify_handler()
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>
show more ...
|
#
3c2cc7ff |
| 06-Feb-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Consolidate ACPIPHP with ACPI core hotplug
The ACPI-based PCI hotplug (ACPIPHP) code currently attaches its hotplug context objects directly to ACPI namespace nodes representin
ACPI / hotplug / PCI: Consolidate ACPIPHP with ACPI core hotplug
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>
show more ...
|
#
e525506f |
| 03-Feb-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Define hotplug context lock in the core
Subsequent changes will require the ACPI core to acquire the lock protecting the ACPIPHP hotplug contexts, so move the definition of the
ACPI / hotplug / PCI: Define hotplug context lock in the core
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>
show more ...
|
#
d3a1ebb0 |
| 03-Feb-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Do not pass ACPI handle to hotplug_event()
Since hotplug_event() can get the ACPI handle needed for debug printouts from its context argument, there's no need to pass the handl
ACPI / hotplug / PCI: Do not pass ACPI handle to hotplug_event()
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>
show more ...
|
#
1d4a5b61 |
| 03-Feb-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Use acpi_handle_debug() in hotplug_event()
Make hotplug_event() use acpi_handle_debug() instead of an open-coded debug message printing and clean up the messages printed by it.
ACPI / hotplug / PCI: Use acpi_handle_debug() in hotplug_event()
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>
show more ...
|
#
b75cece1 |
| 03-Feb-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Simplify hotplug_event()
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-
ACPI / hotplug / PCI: Simplify hotplug_event()
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>
show more ...
|
#
661b4064 |
| 03-Feb-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Drop crit_sect locking
After recent PCI core changes related to the rescan/remove locking, the code sections under crit_sect mutexes from ACPIPHP slot objects are always execut
ACPI / hotplug / PCI: Drop crit_sect locking
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>
show more ...
|
#
b6708fbf |
| 03-Feb-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Drop acpiphp_bus_add()
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() t
ACPI / hotplug / PCI: Drop acpiphp_bus_add()
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>
show more ...
|
#
bbcbfc0e |
| 03-Feb-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Store acpi_device pointer in acpiphp_context
After recent modifications of the ACPI core making it create a struct acpi_device object for every namespace node representing a de
ACPI / hotplug / PCI: Store acpi_device pointer in acpiphp_context
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>
show more ...
|
#
b2118d6a |
| 03-Feb-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Rework acpiphp_no_hotplug()
If a struct acpi_device pointer is passed to acpiphp_no_hotplug() instead of an ACPI handle, the function won't need to call acpi_bus_get_device(),
ACPI / hotplug / PCI: Rework acpiphp_no_hotplug()
If a struct acpi_device pointer is passed to acpiphp_no_hotplug() instead of an ACPI handle, the function won't need to call acpi_bus_get_device(), which may be costly, any more. Then, trim_stale_devices() can call acpiphp_no_hotplug() passing the struct acpi_device object it already has directly to that function.
Make those changes and update slot_no_hotplug() accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
4dc3082d |
| 03-Feb-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Drop acpiphp_bus_trim()
If trim_stale_devices() calls acpi_bus_trim() directly, we can save a potentially costly acpi_bus_get_device() invocation. After making that change acp
ACPI / hotplug / PCI: Drop acpiphp_bus_trim()
If trim_stale_devices() calls acpi_bus_trim() directly, we can save a potentially costly acpi_bus_get_device() invocation. After making that change acpiphp_bus_trim() would only be called from one place, so move the code from it to that place and drop it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
146fc68a |
| 03-Feb-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Simplify register_slot()
The err label in register_slot() is only jumped to from one place, so move the code under the label to that place and drop the label.
Signed-off-by: R
ACPI / hotplug / PCI: Simplify register_slot()
The err label in register_slot() is only jumped to from one place, so move the code under the label to that place and drop the label.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
454481ad |
| 03-Feb-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Proper kerneldoc comments for enumeration/removal
Add proper kerneldoc comments describing acpiphp_enumerate_slots() and acpiphp_remove_slots().
Signed-off-by: Rafael J. Wysoc
ACPI / hotplug / PCI: Proper kerneldoc comments for enumeration/removal
Add proper kerneldoc comments describing acpiphp_enumerate_slots() and acpiphp_remove_slots().
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
1c0c5443 |
| 03-Feb-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Simplify disable_slot()
After recent PCI core changes related to the rescan/remove locking, the ACPIPHP's disable_slot() function is only called under the general PCI rescan/re
ACPI / hotplug / PCI: Simplify disable_slot()
After recent PCI core changes related to the rescan/remove locking, the ACPIPHP's disable_slot() function is only called under the general PCI rescan/remove lock, so it doesn't have to use dev_in_slot() any more to avoid race conditions. Make it simply walk the devices on the bus and drop the ones in the slot being disabled and drop dev_in_slot() which has no more users.
Moreover, to avoid problems described in the changelog of commit 29ed1f29b68a (PCI: pciehp: Fix null pointer deref when hot-removing SR-IOV device), make disable_slot() carry out the list walk in reverse order.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
af9d8adc |
| 03-Feb-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Fix bridge removal race vs dock events
If a PCI bridge with an ACPIPHP context attached is removed via sysfs, the code path executed as a result is the following:
pci_stop_and
ACPI / hotplug / PCI: Fix bridge removal race vs dock events
If a PCI bridge with an ACPIPHP context attached is removed via sysfs, the code path executed as a result is the following:
pci_stop_and_remove_bus_device_locked pci_remove_bus pcibios_remove_bus acpi_pci_remove_bus acpiphp_remove_slots cleanup_bridge unregister_hotplug_dock_device (drops dock references to the bridge) put_bridge free_bridge acpiphp_put_context (for each child, under context lock) kfree (context)
Now, if a dock event affecting one of the bridge's child devices occurs (roughly at the same time), it will lead to the following code path:
acpi_dock_deferred_cb dock_notify handle_eject_request hot_remove_dock_devices dock_hotplug_event hotplug_event (dereferences context)
That may lead to a kernel crash in hotplug_event() if it is executed after the last kfree() in the bridge removal code path.
To prevent that from happening, add a wrapper around hotplug_event() called dock_event() and point the .handler pointer in acpiphp_dock_ops to it. Make that wrapper retrieve the device's ACPIPHP context using acpiphp_get_context() (instead of taking it from the data argument) under acpiphp_context_lock and check if the parent bridge's is_going_away flag is set. If that flag is set, it will return immediately and if it is not set it will grab a reference to the device's parent bridge before executing hotplug_event().
Then, in the above scenario, the reference to the parent bridge held by dock_event() will prevent free_bridge() from being executed for it until hotplug_event() returns.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
1b360f44 |
| 03-Feb-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Fix bridge removal race in handle_hotplug_event()
If a PCI bridge with an ACPIPHP context attached is removed via sysfs, the code path executed as a result is the following:
p
ACPI / hotplug / PCI: Fix bridge removal race in handle_hotplug_event()
If a PCI bridge with an ACPIPHP context attached is removed via sysfs, the code path executed as a result is the following:
pci_stop_and_remove_bus_device_locked pci_remove_bus pcibios_remove_bus acpi_pci_remove_bus acpiphp_remove_slots cleanup_bridge put_bridge free_bridge acpiphp_put_context (for each child, under context lock) kfree (child context)
Now, if a hotplug notify is dispatched for one of the bridge's children and the timing is such that handle_hotplug_event() for that notify is executed while free_bridge() above is running, the get_bridge(context->func.parent) in handle_hotplug_event() will not really help, because it is too late to prevent the bridge from going away and the child's context may be freed before hotplug_event_work() scheduled from handle_hotplug_event() dereferences the pointer to it passed via the data argument. That will cause a kernel crash to happpen in hotplug_event_work().
To prevent that from happening, make handle_hotplug_event() check the is_going_away flag of the function's parent bridge (under acpiphp_context_lock) and bail out if it's set. Also, make cleanup_bridge() set the bridge's is_going_away flag under acpiphp_context_lock so that it cannot be changed between the check and the subsequent get_bridge(context->func.parent) in handle_hotplug_event().
Then, in the above scenario, handle_hotplug_event() will notice that context->func.parent->is_going_away is already set and it will exit immediately preventing the crash from happening.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
d42f5da2 |
| 02-Feb-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Scan root bus under the PCI rescan-remove lock
Since acpiphp_check_bridge() called by acpiphp_check_host_bridge() does things that require PCI rescan-remove locking around it,
ACPI / hotplug / PCI: Scan root bus under the PCI rescan-remove lock
Since acpiphp_check_bridge() called by acpiphp_check_host_bridge() does things that require PCI rescan-remove locking around it, make acpiphp_check_host_bridge() use that locking.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
f41b3261 |
| 02-Feb-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Move PCI rescan-remove locking to hotplug_event()
Commit 9217a984671e (ACPI / hotplug / PCI: Use global PCI rescan-remove locking) modified ACPIPHP to protect its PCI device re
ACPI / hotplug / PCI: Move PCI rescan-remove locking to hotplug_event()
Commit 9217a984671e (ACPI / hotplug / PCI: Use global PCI rescan-remove locking) modified ACPIPHP to protect its PCI device removal and addition code paths from races against sysfs-driven rescan and remove operations with the help of PCI rescan-remove locking. However, it overlooked the fact that hotplug_event_work() is not the only caller of hotplug_event() which may also be called by dock_hotplug_event() and that code path is missing the PCI rescan-remove locking. This means that, although the PCI rescan-remove lock is held as appropriate during the handling of events originating from handle_hotplug_event(), the ACPIPHP's operations resulting from dock events may still suffer the race conditions that commit 9217a984671e was supposed to eliminate.
To address that problem, move the PCI rescan-remove locking from hotplug_event_work() to hotplug_event() so that it is used regardless of the way that function is invoked.
Revamps: 9217a984671e (ACPI / hotplug / PCI: Use global PCI rescan-remove locking) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
#
2d7c1b77 |
| 02-Feb-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Remove entries from bus->devices in reverse order
According to the changelog of commit 29ed1f29b68a (PCI: pciehp: Fix null pointer deref when hot-removing SR-IOV device) it is
ACPI / hotplug / PCI: Remove entries from bus->devices in reverse order
According to the changelog of commit 29ed1f29b68a (PCI: pciehp: Fix null pointer deref when hot-removing SR-IOV device) it is unsafe to walk the bus->devices list of a PCI bus and remove devices from it in direct order, because that may lead to NULL pointer dereferences related to virtual functions.
For this reason, change all of the bus->devices list walks in acpiphp_glue.c during which devices may be removed to be carried out in reverse order.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
show more ...
|
Revision tags: v3.14-rc1, v3.13, v3.13-rc8 |
|
#
9217a984 |
| 10-Jan-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / hotplug / PCI: Use global PCI rescan-remove locking
Multiple race conditions are possible between the ACPI-based PCI hotplug (ACPIPHP) and the generic PCI bus rescan and device removal that c
ACPI / hotplug / PCI: Use global PCI rescan-remove locking
Multiple race conditions are possible between the ACPI-based PCI hotplug (ACPIPHP) and the generic PCI bus rescan and device removal that can be triggered via sysfs.
To avoid those race conditions make the ACPIPHP code use global PCI rescan-remove locking.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
show more ...
|
Revision tags: v3.13-rc7 |
|
#
f244d8b6 |
| 31-Dec-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug
The changes in the ACPI-based PCI hotplug (ACPIPHP) subsystem made during the 3.12 development cycle uncovered a problem wit
ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug
The changes in the ACPI-based PCI hotplug (ACPIPHP) subsystem made during the 3.12 development cycle uncovered a problem with VGA switcheroo that on some systems, when the device-specific method (ATPX in the radeon case, _DSM in the nouveau case) is used to turn off the discrete graphics, the BIOS generates ACPI hotplug events for that device and those events cause ACPIPHP to attempt to remove the device from the system (they are events for a device that was present previously and is not present any more, so that's what should be done according to the spec). Then, the system stops functioning correctly.
Since the hotplug events in question were simply silently ignored previously, the least intrusive way to address that problem is to make ACPIPHP ignore them again. For this purpose, introduce a new ACPI device flag, no_hotplug, and modify ACPIPHP to ignore hotplug events for PCI devices whose ACPI companions have that flag set. Next, make the radeon and nouveau switcheroo detection code set the no_hotplug flag for the discrete graphics' ACPI companion.
Fixes: bbd34fcdd1b2 (ACPI / hotplug / PCI: Register all devices under the given bridge) References: https://bugzilla.kernel.org/show_bug.cgi?id=61891 References: https://bugzilla.kernel.org/show_bug.cgi?id=64891 Reported-and-tested-by: Mike Lothian <mike@fireburn.co.uk> Reported-and-tested-by: <madcatx@atlas.cz> Reported-and-tested-by: Joaquín Aramendía <samsagax@gmail.com> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Dave Airlie <airlied@linux.ie> Cc: Takashi Iwai <tiwai@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 3.12+ <stable@vger.kernel.org> # 3.12+
show more ...
|
Revision tags: v3.13-rc6, v3.13-rc5, v3.13-rc4, v3.13-rc3, v3.13-rc2 |
|
#
f26ca1d6 |
| 27-Nov-2013 |
Toshi Kani <toshi.kani@hp.com> |
ACPI / PCI / hotplug: Avoid warning when _ADR not present
acpiphp_enumerate_slots() walks ACPI namenamespace under a PCI host bridge with callback register_slot(). register_slot() evaluates _ADR for
ACPI / PCI / hotplug: Avoid warning when _ADR not present
acpiphp_enumerate_slots() walks ACPI namenamespace under a PCI host bridge with callback register_slot(). register_slot() evaluates _ADR for all the device objects and emits a warning message for any error. Some platforms have _HID device objects (such as HPET and IPMI), which trigger unnecessary warning messages.
This patch avoids emitting a warning message when a target device object does not have _ADR.
Signed-off-by: Toshi Kani <toshi.kani@hp.com> Cc: 3.12+ <stable@vger.kernel.org> # 3.12+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
202317a5 |
| 22-Nov-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / scan: Add acpi_device objects for all device nodes in the namespace
Modify the ACPI namespace scanning code to register a struct acpi_device object for every namespace node representing a dev
ACPI / scan: Add acpi_device objects for all device nodes in the namespace
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>
show more ...
|