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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
