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.
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.)
- 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.
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.
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
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 ...)
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.
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.
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?
Good question. That's likely the best answer for now, although probably someday the PM framework needs to really understand how to apply the PM hierarchy rules itself ... even outside the context of a system-wide suspend/resume.
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.
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.
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.
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.
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.
- Dave
-------------------------------------------------------
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
