On Thu, 21 Jun 2007, David Brownell wrote: > If drivers actually need a handle on that state, that'd be a fair > approach; make it an opaque type though, platform-specific. > > But actually I don't see much point to having such a struct. What > matters is the attributes of the target state (what resources will > be present, especially), and that rarely needs to be indicated by > any kind of cookie. Your meaning isn't clear. You just said there isn't much point in having a struct, and now you say that there rarely needs to be a cookie. Did you mean to say that a cookie can do a better job of encapsulating the information than a struct can? System suspend is different from runtime suspend in that the requirements are passed from the top down: "The whole system is going to enter this state, so prepare yourself". Not "All your children are in low-power states, so feel free to reduce your own power level". A driver can't rely on purely local information to know what will happen. If a driver wants to find out whether some resource will be available in the target system state, the only way is to ask the resource's provider. Hence the driver needs to have some cookie (representing the target state) that it can pass to the provider. Alan Stern - 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
