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
that leads to an ordering issue between that driver and the container
scan handler on ia64 HP rx2600.

Namely, on that machine the SBA I/O MMU device object in the ACPI
namespace has a _HID returning its own specific device ID and a
_CID returning a generic container device ID.  According to Toshi
Kani, the idea is that if a _HID is not mached by an I/O MMU driver,
the _CID should be matched by a generic container driver, so those
device IDs should be used mutually exclusively.

That is not what happens, however, because the container driver uses
an ACPI scan handler which is matched against the device object in
question before registering the SBA I/O MMU driver object.  As a
result, that scan handler claims the device object first.  The driver
binds to the same device object later, however, and they both happily
use it simultaneously going forward (fortunately, that doesn't cause
any real breakage to happen).

To avoid that ordering issue, make the SBA I/O MMU code use an ACPI
scan handler instead of an ACPI driver, so that it can claim the SBA
I/O MMU device object before the container driver (thanks to an
improved algorithm of matching ACPI device IDs used for ACPI scan
handlers, which matches device _HIDs against the registered scan
handlers before _CIDs).

This also reduces the kernel's memory footprint slightly by
avoiding to register a driver object that's not used after system
initialization, so having it registered (and present in sysfs)
throughout the system's life time isn't particularly useful.
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>