Re: [linux-usb-devel] question on flushing buffers and spinning down disk

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