On 09/19/2012 08:50 PM, Rafael J. Wysocki wrote: > On Wednesday, September 19, 2012, James Bottomley wrote: >> On Wed, 2012-09-19 at 16:03 +0800, Aaron Lu wrote: >>> Hi James, >>> >>> May I know if this patchset will enter v3.7? >> >> Sigh, well, I was hoping to persuade the PM people to sort this out >> first. >> >> The first observation is that all this looks to be too specific. ZPO >> may be ACPI specific, but the property it abstracts: whether the >> particular device is powered off or not is generic and probably should >> be known at the generic PM level. Nothing actually really cares about >> how we power off the device until you get all the way down to the ACPI >> controller. >> >> I think we could do this with a couple of flags sitting inside struct >> device itself: one for pm state and capabilities defined at a generic >> level and one for device specific pm state. The latter would be for >> things like the door lock information which is very specific to CDs >> (although not specific to SCSI CDs). Alternatively, even if we can't >> use these capabilities at the generic pm level, we still need an >> internal state set of flags because power state stuff traverses the >> stack and struct device is the only universal object in that stack. >> >> So I definitely think all of the sdev flags should become either generic >> or specific flags in device. > > Well, the problem is that it is kind of irrelevant to the core whether or > not the given device can be powered off. Moreover, the actual meaning of > what "power off" means depends on the platform (it may be an individual device > state or a power domain state, for instance). Also, the set of available > low-power states depends on the platform (or the bus type) and generally > cannot be universally represented and there are low-power states that > aren't "power off" per se, but still require the device state to be > restored when putting it back into full power. > > We've discussed that for a few times and each time we've ended up agreeing > that struct device is not the right place to store this information (for > example, PCI stores it in struct pci_dev, USB has its own rules etc.). > > I'll have a look at the patchset again and see what can be done about this. Thanks Rafael, and if there is any question/problem, please kindly let me know. -Aaron -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
