On Monday, February 07, 2011, Matthew Garrett wrote: > On Mon, Feb 07, 2011 at 12:01:25AM +0100, Rafael J. Wysocki wrote: > > > Yes, it seems so, but I'm not sure what the short term consequences of that > > change will be. Perhaps there will be none. :-) > > Ok, I'll have a play with that. Maybe we should be fixing this up > somehow in the acpi-pci glue code? It seems wrong to have acpi devices > resumed before the PCI device they're associated with. Those device's don't have ACPI drivers and therefore they are not really suspended or resumed, so we don't need to fix anything in that area. Still, IMO, there is a design issue in the entire ACPI subsystem, because the idea of "ACPI device" really is not well defined, so to speak. Sometimes they are just "device interfaces" that can be used to ask the firmware for something (like in the case of the "ACPI devices" associated with PCI devices) and sometimes they are "real devices" with real drivers. The video device apparently wants to be both at the same time, which is even more confusing. :-) I _think_ that struct acpi_device shouldn't really contain the embedded device object and each of struct acpi_device objects should be pointed to by the archdata member of certain struct device. In turn, struct acpi_device should contain a pointer to the struct device that it's pointed to by via the archdata field. Then, the struct acpi_device objects will always be "device interfaces" and all of the device-driver interactions will be represented through their corresponding device objects. That should allow us to avoid all of the suspend-resume complications (and all sorts of other ugliness). -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
