Am Sonntag, 2. August 2009 17:43:59 schrieb Alan Stern: > On Sun, 2 Aug 2009, Oliver Neukum wrote: > > Am Samstag, 1. August 2009 17:56:00 schrieb Alan Stern: > > 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. 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 > 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? > > > 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 > I think we should. Otherwise all the SCSI work will have to be redone > to use the framework, anyway. I see. Regards Oliver -- 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
