diff options
author | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2013-06-16 00:36:26 +0200 |
---|---|---|
committer | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2013-06-20 01:24:29 +0200 |
commit | 66345d5f79fcfa0214f5d98763643d4ee8e6965d (patch) | |
tree | 54e0765b867681dc85c6422a048e1c9a0ae25bd9 /arch/ia64/hp/common/sba_iommu.c | |
parent | d9e455f53f6fb93c764de2399c3894bbdfd2caa7 (diff) | |
download | linux-stable-66345d5f79fcfa0214f5d98763643d4ee8e6965d.tar.gz linux-stable-66345d5f79fcfa0214f5d98763643d4ee8e6965d.tar.bz2 linux-stable-66345d5f79fcfa0214f5d98763643d4ee8e6965d.zip |
ACPI / ia64 / sba_iommu: Use ACPI scan handler for device 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
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>
Diffstat (limited to 'arch/ia64/hp/common/sba_iommu.c')
-rw-r--r-- | arch/ia64/hp/common/sba_iommu.c | 24 |
1 files changed, 16 insertions, 8 deletions
diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c index bcda5b2d121a..d43daf192b21 100644 --- a/arch/ia64/hp/common/sba_iommu.c +++ b/arch/ia64/hp/common/sba_iommu.c @@ -2042,7 +2042,8 @@ sba_map_ioc_to_node(struct ioc *ioc, acpi_handle handle) #endif static int __init -acpi_sba_ioc_add(struct acpi_device *device) +acpi_sba_ioc_add(struct acpi_device *device, + const struct acpi_device_id *not_used) { struct ioc *ioc; acpi_status status; @@ -2090,14 +2091,18 @@ static const struct acpi_device_id hp_ioc_iommu_device_ids[] = { {"HWP0004", 0}, {"", 0}, }; -static struct acpi_driver acpi_sba_ioc_driver = { - .name = "IOC IOMMU Driver", - .ids = hp_ioc_iommu_device_ids, - .ops = { - .add = acpi_sba_ioc_add, - }, +static struct acpi_scan_handler acpi_sba_ioc_handler = { + .ids = hp_ioc_iommu_device_ids, + .attach = acpi_sba_ioc_add, }; +static int __init acpi_sba_ioc_init_acpi(void) +{ + return acpi_scan_add_handler(&acpi_sba_ioc_handler); +} +/* This has to run before acpi_scan_init(). */ +arch_initcall(acpi_sba_ioc_init_acpi); + extern struct dma_map_ops swiotlb_dma_ops; static int __init @@ -2122,7 +2127,10 @@ sba_init(void) } #endif - acpi_bus_register_driver(&acpi_sba_ioc_driver); + /* + * ioc_list should be populated by the acpi_sba_ioc_handler's .attach() + * routine, but that only happens if acpi_scan_init() has already run. + */ if (!ioc_list) { #ifdef CONFIG_IA64_GENERIC /* |