Now usb_reset_device() doesn't use usb_set_configuration(), except in that broken "device morphed" codepath (which is still broken).
Near as I can tell, the only time device drivers have any business using the SET_CONFIGURATION protocol request is as part of a reset that's retaining the _same_ configuration.
There's another time. That's if the device driver happens to know that the device has to operate in a configuration other than the default one (or other than the one installed when probe() is called). Yes, I know there are issues of policy involved there, and just who should decide which configuration to use, but it's a legitimate thing to do.
Eventually. But it's never really worked correctly yet, so to that extent it's a new feature -- not a backwards compatibility issue. Essentially all current callers of usb_set_configuration() other than khubd (setting the default) and usbfs (causing trouble) want usb_reset_configuration() functionality -- not config changes.
I just noticed that my previous usb_set_configuration() experiment
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=105484578921888&w=2
was the simplified version, without a driver configure() callback.
Sorry, I forgot I didn't send that. Briefly, for multi-config devices, drivers that matched the device descriptor and had a configure() callback were given the opportunity to choose a non-default configuration.
Seems to me that drivers can't ever complete disconnect() before their pending calls to usb_reset_device() return, since returning from disconnect would mean other pending calls already completed. Using usb_set_configuration() from a driver is rather likely to self-deadlock ... unless maybe it's done in contexts that are designed for that purpose, like that configure() callback.
Precisely. That's why my proposal stated that such change-config calls
would queue a state_change request that khubd would handle asynchronously,
after the usb_set_configuration() call returned. Go back and re-read my proposal from last week; it's in there.
You refreshed my memory enough, I think!
I'm still expecting that any driver API would use something like that configure() callback. I think that approach is simpler. (But I also don't think kernel drivers need that capability much at all today, and it's enough to be available from userland.)
The only case that _really_ needs deferred processing seems to be the re-enumeration paths when device reset failed; enumeration should be handled by khubd in any case. In other cases the driver bind/unbind logic can be immediate.
No, as you pointed out above, unbind for the driver/interface making the usb_set_configuration() call must be deferred also. All the other interfaces can be unbound immediately. Also, I don't see any harm in always deferring the re-binding -- it would simplify things, and in any case it can't be done until the calling driver has been unbound.
I see different assumptions: namely, that usb_set_configuration() should be available to device drivers in almost all contexts, not just in controlled configure() contexts.
There _is_ a problem, which Oliver identified. What if one driver
requests a reset or config change at the same time that another interface
is being probed (or unbound)? Then the serialization must block the
request until the probe is done. But if a driver makes such a request
within its own probe(), serialization shouldn't block it. Arranging that will require a little effort.
It's easy to serialize for a new configure() callback, which isn't doing double duty. Or to let userspace deal with the problem.
- Dave
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
