I don't see why we can't try to provide partial support for a power-off suspend mode. While it clearly wouldn't work for every device, it would work for a great many.
In fact I recall arguing both sides of that myself ... :)
I think it'd be rather painful to try to make _every_ device's resume() handlers behave with resume-from-poweroff. In fact, most devices won't even have suspend() handlers for some time.
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); - 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.
So when usb-storage::resume() gets resume-from-poweroff for a device with known bogus serial numbers, what's it going to be doing? :)
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.
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!
Using GFP_NOIO everywhere in khubd sounds reasonable to me, at least as a first step.
- 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
