I wonder if he'd comment on what it'd mean to call device_unregister() earlier in usb_disconnect() ... like right at the top, not the last thing. The docs imply that'd be OK.Which device_unregister? For the interfaces or the device?
Well the whole device is DEVICE_GONE, including interfaces, so whichever order would work. Certainly the device itself, since that's what currently drives the submit logic ... so that's what would need to know that it's GONE, to let the submit logic reject new urb submissions. There could be a usb-specific notion of state, I guess, but it sure seems to me like there ought to be one inside the device registration/etc core logic that USB (and CardBus, PCMCIA, etc) would rely on.
And we need to call device_unregister on our children before ourself, like the code currently does.
But what's the semantics of that "register"? That's what I'm not clear on. Register to what, and to enable what tasks? There are lots of things that know about devices. Is anything in the cleanup path going to depend on that "registration" to be active?
It sets dev->state == DEVICE_GONE, which is useful to know since itBut that should not matter, device_unregister() does not do much besides remove the device from the driverfs tree. Well, it currently could cause the whole device's memory to be freed, but it doesn't :)
means that the only legal thing to do from there on is clean up.
- Dave
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
