On Sun, 2 Aug 2009, Oliver Neukum wrote: > > > The SCSI layer is written to export such stuff to transport handlers. > > > > And there is no USB transport class. We really should write one. But > > how would it know whether there is any state to lose? > > Very well. The important point is that we realise that sd alone > is insufficient. But I am not sure that for two drivers an explicit transport > layer is worth the effort. _Something_ has to be responsible for detecting when an autosuspend is possible, and usb-storage doesn't have enough information to do it. > The hard stuff is recognising that we have state to lose. > I basically failed trying to implement that when I tried to buil up on > your original patch. > > I think it is time for a gross hack. We simply don't autosuspend > devices that > - are bus powered > - draw more than 100mA The second alone would be better. A self-powered device that nevertheless also draws more than 100 mA from the bus probably isn't a good candidate for autosuspend, in the absence of better information. > > That's backward. USB shouldn't tell SCSI that it's time to suspend a > > device, since USB doesn't know what the device is doing. In fact, USB > > doesn't even know what devices there are! (It's not aware of targets > > or LUNs, only of the host.) Things should work the other way around: > > SCSI (or the transport class) should tell USB when the host is not > > being used and can safely be suspended. > > OK, so we agree that this is the job of the transport. What do we do for > drivers that don't have a transport? I don't understand the question. Are you asking what we should do for transports that don't have a transport class? (Taken literally the question is meaningless. Drivers don't have transports; devices do. But a device without a transport is unusable, since the transport provides the communications channel between the computer and the device.) > > > > Or to put it another way, we should do _exactly_ what sd would do -- by > > > > asking sd to do it! Or more properly, by getting the SCSI core to tell > > > > the appropriate drivers to do their own things. > > > > > > These are really two different proposals. > > > > You mean mine is different from your proposal? Yes, certainly. As I > > said, your proposal violates layering by working backward. > > No. Either > - by asking sd to do it > - getting the SCSI core to tell the appropriate drivers to do their own things Oh. I did not mean that usb-storage should ask sd to suspend its devices; I meant that usb-storage shouldn't do anything until some part of the SCSI layer (The core? A transport class? Take your pick) informed it that all the relevant SCSI drivers -- which might or might not include sd.c -- were prepared for the host to be suspended. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
