Merge branch 'acpi-hotplug' into acpi-scan-bleeding-edge

* acpi-hotplug:
  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: Do not bind ACPI drivers to objects with scan handlers

ACPI drivers generally should not be bound to device objects having
scan handlers attatched to them.

However, there is one exception which is the container scan handler.
Namely, it turns out that some BIOSes (on ia64 HP rx2600 in
particular) put container device IDs into the same objects along with
some other more specific ones which makes those device objects match
the container scan handler as well as some other scan handlers or
ACPI drivers.  Fortunately, though, the container scan handler is
only needed for hotplug to work and it doesn't actually do anything
to the device objects in question, so it is really OK to have both
the container scan handler and something else attached to the same
device object at the same time.

Following that, make acpi_device_probe() fail with -EINVAL if the
device object being probed has an ACPI scan handler that is not the
container scan handler attached to it.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / scan: Separate hotplug profiles from scan handlers

Commit a33ec39 (ACPI / scan: Introduce common code for ACPI-based
device hotplug) decided to embed struct acpi_hotplug_profile into
struct acpi_scan_handler, because it looked like having a hotplug
profile without a scan handler wouldn't make sense.

While that still appears to be the case, it actually does make sense
to combine the container hotplug profile (that kind of plays the role
of a generic hotplug profile) with multiple different scan handlers.

To allow that to be done, replace the hotplug field of struct
acpi_scan_handler with a pointer and modify the code using that
field accordingly.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / scan: Add hotplug profile pointer to struct acpi_device

Since it generally make sense to combine different ACPI scan handlers
(that don't have their own hotplug profiles) with the container
hotplug profile, make it possible by adding a hotplug profile pointer
to struct acpi_device (so that the hotplug profile and scan handler
may be set for device objects independently of each other) and make
the generic hotplug code use the device object's hotplug profile
rather than the hotplug profile from its scan handler.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / scan: Use container hotplug profile with matching device objects

On some systems (ia64 HP rx2600 in particular) the ACPI namespace
contains device objects with container compatibility IDs in addition
to some other hardware IDs.  This means that those devices are
containers and if an ACPI scan handler without a hotplug profile is
attached to one of them, the container hotplug profile should be used
for that device.

Moreover, the container hotplug profile should be used for handling
bus check and device check notifications targeted at device handles
with matching scan handlers that don't provide hotplug profiles.

Modify the ACPI namespace scan code to ensure that the above will
happen.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / ia64 / sba_iommu: Use ACPI scan handler for discovery

The IA64 System Bus Adapter (SBA) I/O MMU driver uses an ACPI driver
object to look for device objects it needs in the ACPI namespace, but
the way that driver object is used by it is kind of abusive.

First of all, the ACPI driver is registered with the assumption that
its .add() routine (an equivalent of .probe()) will run immediately
during the registration, which in principle may or may not happen (it
happens in practice due to the way the kernel is built, but that's
not actually guaranteed).  Second, .add() is the only functionality
provided by that driver object (which means that it probes devices
without really doing anything with them afterward) and that .add() is
only supposed to run during system initialization, so having the
driver object registered (and present in sysfs) throughout the
system's life time isn't particularly useful.

A cleaner way to achieve the same goal that driver object is for
is to use an ACPI scan handler instead of it, which at least
prevents sysfs from being littered with useless data and causes
an improved algorithm of matching ACPI device IDs to be used.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge branch 'acpi-scan-bleeding-edge' into bleeding-edge

* acpi-scan-bleeding-edge:
  ACPI / ia64 / sba_iommu: Use ACPI scan handler for discovery
  ACPI / scan: Use container hotplug profile with matching device objects
  ACPI / scan: Add hotplug profile pointer to struct acpi_device
  ACPI / scan: Separate hotplug profiles from scan handlers
  ACPI / scan: Do not bind ACPI drivers to objects with scan handlers