On Sat, 29 Sep 2007, Oliver Neukum wrote: > > 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? Well, I don't really insist on it. But keeping things unidirectional makes life easier and helps prevent deadlock issues. Another thing to consider is this: If SCSI autosuspend is initiated by the host adapter driver, then it won't be possible for different devices on a SCSI bus to autosuspend at different times. With usb-storage this doesn't matter much, because there's almost always only one target. But for other buses it could matter. > > 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. Well, suppose usb-storage decides it is ready to autosuspend and it asks sd for permission. What if sd says "No"? How long should usb-storage wait before asking again? Why should usb-storage have to poll sd, instead of being notified just once when sd is ready? Another thing: I haven't followed the current work in new SCSI development, but it wouldn't be at all surprising to learn that Power Management is one of the topics they are focused on. We should expect that it will eventually become part of the standard, with associated special commands and other requirements. When that happens, Linux's SCSI stack should be ready to implement the new specs. Basing our SCSI autosuspend on hacky code in usb-storage doesn't seem like a good way to prepare. > > 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. It's hard to make something generic when there's only one example to work from! Suppose we do it the other way: Add autosuspend support into the SCSI drivers and then see what common features it shares with USB. Those common parts can be moved into generic code. Alan Stern - 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
