Am Samstag 29 September 2007 schrieb Alan Stern: > I disagree. That bug report shows that problems arise when we try to > suspend a parent without making sure the children are suspended first. > If the sd suspend method had already run then it would have been okay > for the enclosure to cut power. That is true. The question is who is to call the suspend method. > > Suspension in a higher layer can have effects that are different to suspension > > of all devices on a lower level. Therefore the higher level must ask the lower > > level to prepare itself. > > When the lower level is suspended then it is supposed to be prepared > for the higher layer to suspend. No additional preparation should be > needed. Yes. If it returns from suspend without error a driver must keep that guarantee. > (That's true for USB and SCSI. Other buses can have additional > complications, like PCI with its multiple D states. But the principle > remains the same.) > > > Ideally it would ask the lower level for permission to do an autosuspend. I'd > > like to change the API so that you can do that. But I don't think that the > > lower levels have to implement autosuspend on their own to have levels > > above them support autosuspend. Can you summarize your requirements > > for supporting autosuspend in the higher levels? > > It's very simple: The higher level can't autosuspend if doing so would > cause harm to the lower level. > > There are two ways to avoid harm. One is for the lower level to be > such that it can never be harmed, no matter what the higher level does. > For example, a purely logical entity like a partition won't be harmed > if the drive it belongs to is suspended. In fact we don't try to > suspend partitions, and they don't even have drivers. > > The other way is for the lower level to be suspended already. That's > how the autosuspend framework operates: the lower level autosuspends > and tells the higher level that it is now safe for the higher level to This is how the hub driver works. > autosuspend. It's not supposed to work by the higher level announcing: > "I want to autosuspend now, so all you lower guys had better get > ready." I see. And there's an appealing simplicity to it. But why insist that this is the one true way? > Even in the case of system suspend things don't work that way. We > don't have higher-level drivers telling lower-level drivers to suspend. > Rather, the PM core (acting on behalf of the user) tells _every_ driver > to suspend -- in the correct order, of course. True. And putting the notification into a driver is a kludge at best. It simply was the only way I could come up with without moving autosuspend into generic code. Nevertheless, I am not convinced that autosuspend has to work on the device level only. > Now, how much extra work is involved in having the lower-level drivers > implement autosuspend as opposed to having the higher-level driver ask > permission? Not much more than adding the autosuspend timers. > Everything else is needed anyway for supporting manual runtime suspend. Move autosuspend into generic code and I'll certainly try to come up with something better than what I wrote. Regards Oliver - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
