summaryrefslogtreecommitdiffstats
path: root/arch/ia64/hp
diff options
context:
space:
mode:
authorRafael J. Wysocki <rafael.j.wysocki@intel.com>2013-06-16 00:36:26 +0200
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2013-06-20 01:24:29 +0200
commit66345d5f79fcfa0214f5d98763643d4ee8e6965d (patch)
tree54e0765b867681dc85c6422a048e1c9a0ae25bd9 /arch/ia64/hp
parentd9e455f53f6fb93c764de2399c3894bbdfd2caa7 (diff)
downloadtalos-op-linux-66345d5f79fcfa0214f5d98763643d4ee8e6965d.tar.gz
talos-op-linux-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')
-rw-r--r--arch/ia64/hp/common/sba_iommu.c24
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
/*
OpenPOWER on IntegriCloud