Skip to contentSkip to conversation

Patch [4/4] x86_64 sparsmem add- acpi fixup take 2 motherboard.c

RFC In review keith mannthey 2 participants 2 messages Jun 24, 2006

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

RFC 1/1 Patch [4/4] x86_64 sparsmem add- acpi fixup take 2 motherboard.c

patch against the motherboard driver. I am unsure what the correct fix is but there are 3 options.

1. The motherboard driver needs to be fixed (my patch or something like it)
2. The algorithm in acpi_bus_match/acpi_bus_find_driver is flawed.
3. There is somthing wrong with the ACPI namespace on the box (BIOS).

Let me explain what is happening from a I don't know much about acpi point of view.

My system loads to acpi memory hot plug driver just fine during boot.
It installs and registers acpi_memory_device_driver and it's handler. When the hot add memory event occurs the handler is called. this is the relevant call path

acpi_memory_get_device
acpi_bus_add
acpi_add_single_object
acpi_bus_find_driver
acpi_bus_driver_init
driver->ops.add

The algorithm it try to match devices from acpi_bus_drivers. It looks
for drivers that are on the right bus and calls acpi_bus_driver_init. If it gets a good return value for acpi_bus_driver_init it thinks it found the device and returns. The problem is the motherboard driver driver->ops.add is getting called and it ALWAYS returns AE_OK.

The device that is passed back up the call chain is the wrong one and
things break down.

My fix is to make the motherboard driver return an error when it sees
resources it doesn't know about. I don't know if this is the correct solution or to but it highlights the problem I am having. With this patch in place this work as expected with regards to the acpi memory device.

Kame (who helped me greatly in tracking down the source my troubles) thinks that the root cause is that the device has both a _HID and _CID The driver for _HID is different for _CID and the driver for _CID is found before _HID and I run the wrong add.

I am not sure what the correct solution to this problem is. Built against 2.6.17-mm1 but should apply with fuzz just about anywhere.

drivers/acpi/motherboard.c +5 -2
diff -urN linux-2.6.17-mm1-orig/drivers/acpi/motherboard.c linux-2.6.17-mm1/drivers/acpi/motherboard.c
@@ -88,6 +88,7 @@
 		}
 	} else {
 		/* Memory mapped IO? */
+		 return -EINVAL;
 	}
 
 	if (requested_res)
@@ -97,12 +98,14 @@
 
 static int acpi_motherboard_add(struct acpi_device *device)
 {
+	acpi_status status;
 	if (!device)
 		return -EINVAL;
-	acpi_walk_resources(device->handle, METHOD_NAME__CRS,
+
+	status = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
 			    acpi_reserve_io_ranges, NULL);
 
-	return 0;
+	return status;
 }
 
 static struct acpi_driver acpi_motherboard_driver1 = {
#1 lore raw
Quoted 5 lines · On Fri, 23 Jun 2006 19:06:17 -0700 keith mannthey <[email protected]> wrote:

I am not sure what the correct solution to this problem is. Built against 2.6.17-mm1 but should apply with fuzz just about anywhere.

What I can say now is..
1. In this case, a driver for _CID is attached before a driver for _HID
2. I don't find description in acpi SPEC, "how to handle a device which has _HID and _CID, and drivers for them are different from each other"
3. maybe memory device shouldn't be described as compatible device of mother board.

-Kame

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>