Make the ACPI-based PCI hotplug (ACPIPHP) code use
pci_device_is_present() for checking if devices are present instead
of open coding the same thing.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
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>
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>
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>
In order for the ACPI dock station code to be able to use the
callbacks pointed to by the ACPI device objects' hotplug contexts
add a .fixup() callback pointer to struct acpi_hotplug_context.
That callback will be useful to handle PCI devices located in
dock stations.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
After recent changes adding dock station handling to the ACPI hotplug
core, it is not necessary to clear the .event() pointer in the
ACPIPHP device hotplug context for dock stations any more, so don't
do that.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Currently, ACPIPHP does not add hotplug context to devices that
should be handled by the native PCI hotplug (PCIeHP) code. The
reason why was because PCIeHP didn't know about the devices'
connections with ACPI and would not clean up things properly
during an eject of an ACPI-backed device, for example.
However, after recent changes that made the ACPI core create struct
acpi_device objects for all namespace nodes regardless of the
underlying devices' status and added PCI rescan-remove locking to
both ACPIPHP and PCIeHP, that concern is not valid any more.
Namely, after those changes PCIeHP need not care about the ACPI
side of things any more and it should be serialized with respect to
ACPIPHP and they won't be running concurrently with each other in
any case.
For this reason, make ACPIPHP to add its hotplug context to
all devices with ACPI companions, even the ones that should be
handled by PCIeHP in principle. That may work around hotplug
issues on some systems where PCIeHP is supposed to work, but it
doesn't and the ACPI hotplug signaling works instead.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The name of register_slot() doesn't really reflect what the function
is does, so rename it to acpiphp_add_context() and add a proper
kerneldoc comment to it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The ACPI specification (ACPI 5.0A, Section 6.3.7) says:
_STA may return bit 0 clear (not present) with bit 3 set (device is
functional). This case is used to indicate a valid device for which
no device driver should be loaded (for example, a bridge device.)
Children of this device may be present and valid. OSPM should
continue enumeration below a device whose _STA returns this bit
combination.
Evidently, some BIOSes follow that and return 0x0A from _STA, which
causes problems to happen when they trigger bus check or device check
notifications for those devices too. Namely, ACPIPHP thinks that they
are gone and may drop them, for example, if such a notification is
triggered during a resume from system suspend.
To fix that, modify ACPICA to regard devies as present and
functioning if _STA returns both the ACPI_STA_DEVICE_ENABLED
and ACPI_STA_DEVICE_FUNCTIONING bits set for them.
Reported-and-tested-by: Peter Wu <lekensteyn@gmail.com>
Cc: 3.12+ <stable@vger.kernel.org> # 3.12+
[rjw: Subject and changelog, minor code modifications]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Since acpi_device_hotplug() assumes that ACPI handles of device
objects passed to it will not become invalid while acpi_scan_lock
is being held, make acpiphp_disable_slot() acquire acpi_scan_lock,
because it generally causes _EJ0 to be executed for one of the
devices in the slot and that may cause its ACPI handle to become
invalid.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
