On Fri, 2 Jul 2004, David Brownell wrote: > So I'm updating the latest suspend patch so that'll start to > be possible (especially with your hub driver changes): > > - usb_suspend(udev,state) syntax ... but currently maps > poweroff to suspend (needs selective port power on/off > in the hub driver and sysfs, nyet implemented);
We also need some way to tell usb drivers that they are resuming from a power-off state. > - drivers without a suspend() hook get automatically > unbound/disconnected (not yet finished); > > That'll start aiming us towards better default behavior; > drivers won't act unreasonably if they don't have direct > support for USB suspend/resume. Like HID, which right > now breaks annoyingly on suspend. 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. > So when usb-storage::resume() gets resume-from-poweroff > for a device with known bogus serial numbers, what's > it going to be doing? :) 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 can change the medium at any time.) When the first command is issued after a poweroff-resume, the device is supposed to respond with Unit Attention status and sense data indicating that power was off. Or if it's externally powered and the medium was changed, there should be sense data indicating that fact. The SCSI layer may or may not catch such things now, but it definitely should. Then it'll be up to the high-level SCSI driver to revalidate the medium and decide whether it's the same old one or a new one. We'll probably have to coordinate this with the SCSI developers. The real question, as far as I'm concerned, is how does usb-storage inform the SCSI layer that a suspend is about to occur? Simply call the suspend() hook in the SCSI host's struct driver? > > To continue the analogy I made earlier, consider what difference there is > > between power-off suspend of a device and reset of its parent hub. Not > > much at all; resetting a hub will cause it to turn off power to all its > > ports. If we want to try handling unsolicited resets then we ought to > > cover cases like this. > > Eventually we ought to handle everything. That change > sounds to me like one we shouldn't rush into though; > it changes models, and those things cascade. 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. > > Going back to one of the earlier aspects of this thread, here's a > > disturbing thought. From time to time usb-storage may try to issue device > > resets. The implication is that everything in the reset pathway must use > > GFP_NOIO or GFP_ATOMIC -- and that's a large part of the hub driver! If > > we go farther and allow unsolicited resets, then the pathway includes > > almost everything in the hub driver! Consider what would happen if we > > have to reset a hub behind which is a USB disk containing a swap > > partition. > > > > Maybe everything in the hub driver should use GFP_NOIO as a matter of > > course. > > Well, robustness would argue that it never allocate any memory > associated with a hub except once up front, when it's probed! 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. 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. > Using GFP_NOIO everywhere in khubd sounds reasonable to me, > at least as a first step. Actually usb_control/bulk_msg() already uses it, so the required changes may end up being pretty small. 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
