On Thursday 21 June 2007, Rafael J. Wysocki wrote: > On Thursday, 21 June 2007 16:48, David Brownell wrote: > > They really don't care what the state is. The $SUBJECT patch isn't > > driver code ... it's for platform hooks that expose attributes to > > the drivers. Specifically, it's ACPI code, talking to drivers that > > must run on non-ACPI systems. Any driver that thinks it needs to > > understand anything about ACPI states is sadly broken. > > But finally it has to place the device into a specific state and that state > needs to be determined somehow. I suppose I'm still thinking that the approach in my original patch works Just Fine. Layering is kind of like this, going from top to bottom (and omitting the go-to-pci-hardware stack, and the initial ACPI pm hook before suspension starts): PM infrastructure ... calling suspend() for everything PCI bus support ... translates to PCI-specific typed call PCI driver ... suspend() calling pci_choose_state() ACPI support for PCI ... implementing choose_state() ACPI core code ... remembering ACPI_STATE_Sx, calling AML That is, ACPI gets invoked at various points, but the driver and core code doesn't need to know ACPI from Rumpelstiltskin. - Dave - 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
