On Wednesday 20 June 2007, Len Brown wrote: > I support the proposal that pm_message_t include the target state > in addition to the phase of entering that state. > The reasoning is simple, device drivers that receive a pm_message_t > will do different things depending on the target state. They should do that based on attributes of the target state, not any particular notion (e.g. from ACPI) of what the states may be ... > The example at hand is ACPI devices that need to know how deep a D-state > to go into based on the S-state, and this in-turn depends on if they > are enabled as wakeup devices or not. None of that needs to involve growing pm_message_t (yeech!), or even knowing that this system's PM infrastructure uses ACPI. The ACPI bits need to know about ACPI target state, agreed, but such stuff can (and should!) be interfaces that normal drivers never see. In fact, that's why pci_choose_state() exists. Its implementation has always sucked, sure, but not the notion that ACPI can answer the question following APCI rules, while other PCI platforms can answer the question using other (non-ACPI) rules. And likewise for other device types, including SOC devices. - 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
