That is not a fundamental difference. The reset logic also has a device morphed code path.
The reset logic doesn't have a "load firmware path" though.
That's why there's a resume() among other things.
Actually, drivers do that in probe() not resume(). And as Alan noted, there's no real option to do it in resume, since the firmware load process involves the "no-firmware" device disappearing and being replaced by the "new-firmware" device ... the disconnect() can't be avoided.
You really don't like the notion that losing VBUS power is the least bit significant, do you? :)
Well, the only electrical power I really attach fundamental relevance to is found within the brains of a few human beings.
But no, loss of power of course has significance. It implies a total loss of state. This means that a more comprehensive action in suspend/resume is needed. But that isn't fundamental.
The thing you're saying that I most object to is this "need", "must", and similar language. Today we have a self-consistent framework that shows terms like "need" and "must" are wrong; it works without the behavior you're describing, so what you're describing is _purely_ optional.
If you were to say "I, Oliver, wish <X> were so" then there could be a reasonable discussion about tradeoffs. Instead it sounds to me like like you're arguing against reality.
So for example, I'd say that making resume() handle extra duties associated with probe() is a big PITA for drivers, on top of the big PITA in usbcore to start tracking all kinds of extra state. (State that's only tracked in one special path, instead of all the paths it could be useful; a observation you've overlooked ...) And those sorts of changes sure sound "fundamental" to me, in terms of some basic architectural notions. (Like device identity, and definition of host-to-device sessions.)
Let's make a thought experiment. Suppose that USB defined a power state where the device would lose all state but eg. the bus address. It wouldn't be different in any important way from total power loss.
However, there is no such USB state. That's not part of reality.
Thanks to swsusp we can do some form of power management on machines without hardware support at all. The spec can tell us how we must do certain things. It cannot tell us what is useful and sensible.
And that "some form of..." happens to involve complete re-enumeration of USB, in today's systems. You're arguing to add a kind of memory to help avoid some of that. What are the limits of that memory?
Why not just accept that "some form of" doesn't involve USB suspend?
Your "some form of..." adds memory to USB, but it's a curiously selective sort. If I unplug a disk drive and plug it into another port, why shouldn't that "just work"? After all, the same mechanism that somehow deduces "same disk" (how, given that serial numbers are known not to work?) on one port could as easily apply it to another port. If it shouldn't work that way, why should it work if it's unplugged from one port and plugged back into the same port? (Which is exactly what you're arguing, by saying power fail "must not" matter.) And if it should, why shouldn't it work even outside the scope of that particular swsusp state memory? (Unplug today, replug tomorrow, and no system suspend/powerdown in between.) Both cases are simple variants of the case Linux vetoed kernel support for some time ago.
- 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
