> It's certainly implemented that way, except for iSCSI and > so on where the "hierarchy" is sort of multipath/abstract... Not a problem. Suspending with an iSCSI mounted is asking for trouble anyway unless the protocol know how to recover on resume from the packet loss ... > But also, what I was talking about was a bit different. > Yes, SCSI does need to be able to quiesce queues. But > that doesn't mean that one of the other transports in > that hierarchy can't do so independently ... such as for > example USB-storage, or drive firmware. That's a non-issue. If implemented properly (that is like IDE), the sd will get the suspend request first and will block the IO queue after all pending requests have been completed. At the point where the SCSI host (usb storage for example) gets the suspend message, no requests is pending and none will come from "upstream". What happens on the USB bus is almost irrelevant. The USB driver can do additional things if it wants before suspending itself, or just make sure it doesn't have any pending URBs (like periodic status URBs or whatever, I'm not familiar with the USB storage protocol) or can just do nothing at this point. > USB_SUSPEND just quiesces the whole queue. All the drivers are told > to suspend, and if they do so then the queue will be empty. If > they don't, the root hub will just disable the schedules when it's > told to suspend; it'll resume them later. (Something I'd rather > discourage from happening, since disabling active schedules can > mean spinning with irqs blocked for several msecs. But for now, > that'll be typical if CONFIG_PM without USB_SUSPEND.) You are mixing up queues. The USB queue is irrelevant to my discussion above, which was about the block layer queue. It's that queue that when blocked makes sure no requests are going down to usb-storage. > Ditto for USB, though few drivers will try to handle > suspend/resume yet. So the HCD has more to do with > making it be correct than I'd prefer. Yes, it's MUCH easier for USB as the URB queues can be "lossy", that is not lose URBs but complete them with an error, which is fine. On block, I can't do that, I have to wait for completion of pending ones and make sure I keep all new ones in the queue (queue blocked means I don't process what's in it, requests just stack up until resume). > You could just do it with a usb-storage device. > Don't you have a Swiss Army Knife with USB? ;) I do :) I have a HD disk enclosure too. > Oh -- that won't address the "ub" driver. Hmm... This one is a pure block, it will need a similar treatment, but easier than going through the SCSI stack. Ben.
