On Fri, 2 Jul 2004, David Brownell wrote: > > We also need some way to tell usb drivers that they are resuming from a > > power-off state. > > True, "start to be possible". Likewise something is going > to need to look at devices to see if they're "the same" as > what was there before; otherwise it'd be rather dangerous to > try the "resume-after-poweroff" sorts of path. (Overwriting > one disk with data intended for another one, etc.)
We've already got a large part of that done, in usb_reset_device(). Certainly it's capable of telling that the devices are of the same type as what was there before. Deciding whether they're exactly the same ones is a harder problem and probably should be deferred to other layers. > > HID should be one of the first things to get suspend()/resume() callbacks. > > Even if all they did was kill/resubmit the interrupt URB that would be a > > good start. > > I don't really see why a mouse or keyboard would need > such support; it should behave just fine without it. > (Except _maybe_ for remote wakeup.) > > After all, users require that mice/keybaords work correctly > if they just plug/unplug, so doing that on suspend/resume > will just go through well-debugged code. No loss of valid > state either. If unbinding and rebinding will work, then fine. I don't know much about the input layer; are there programs that might care if the mouse they are using goes away and another one appears? > > I think we'll pass the buck. Since it now supports hotpluggable > > transports, the SCSI layer ought to be aware that devices might go away at > > any time. (It's been true all along with some SCSI devices that the user > > And how will it be telling that the device went away? > You suggest below how it can tell power off; USB must > have known that already. I expect it to work safely if > while I power the system off, I swap one device for an > externally identical one that's got different data. > > (So for example, disconnect/reconnect is safe ...) How do you expect the system to work if you mount a floppy disk, then replace the disk with an externally identical one that's got different data (even without powering anything off)? What if you remove the disk and then place the same disk back in? The problems you're worried about aren't new and aren't confined to SCSI. > I think the last N times that issue has come up, the conclusion > is that userspace can put the right policies together, sometimes, > maybe, if you've got the right nicely-behaving hardware revisions. Having well behaved hardware is essential, of course. Beyond that I wouldn't want to commit myself... > > We can start off small by deciding how to handle unsolicited power-on > > resets. From there to power-off suspend isn't such a big step. > > Since USB doesn't really have very usable notions of device identity, > other than "part of the same power session", it's actually a rather > large step. Just remember what Neil Armstrong said about small steps. :-) > > One problem here is that some of these things _aren't_ associated with the > > hub, they're associated with the child device. The URB used to request > > the actual port reset, for example. It's allocated from code called in > > hub.c, but it executes in the child device's thread. It's not the sort of > > thing you can preallocate and store with the hub, since in principle there > > might be several children being reset all at the same time. > > Each device could have one pre-allocated control urb, used in all the > synchronous calls. That one's easy! Harder is the memory allocated > by the HCD ... the URB API fights preallocation there. Agreed; it will be nice when we make the HCDs allocate all URBs, complete with whatever private storage space they need. > > Also, consider this. Right now usb_control_msg() and usb_bulk_msg() > > allocate their timers on the stack. In the future, support for URB > > timeouts is liable to be added to the core for all URBs. (Currently only > > UHCI provides that support, but clearly it doesn't belong in the HC > > drivers.) When that's done it will make a lot of sense for > > usb_control/bulk_msg() to use the central timeout facility instead of > > their own. The central facility will have to allocate timers dynamically > > though, since it won't wait for URBs to complete. So when the hub driver > > calls these routines it won't be able to use pre-allocated timers. Not > > unless a timer is added to struct urb, which is probably not such a good > > idea. > > Drivers could store pointers to timers they allocate, either on the > stack or otherwise. In fact, they could pre-initialize the end-time, > and so usbcore just checks if urb->timer is non-null and throws in > whatever logic it needs. You're suggesting a substantial change to the API. Not a bad one, but it would affect a couple of drivers that do use the urb->timeout facility. Alan Stern ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
