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.
Posted back in June! No wonder I don't remember it :-) (Quite aside from it being the simplified version.)
There were preceding email threads, too. If it hadn't been preventing me from finishing up a workspace, I might have forgotten it too! :)
I expect I'll post the 2.6.0-test3 version soon. It won't do anything more than make usb_set_configuration() work right in all currently-legal cases (and from sysfs): no configure() call.
I read the archived message, and I see what you have in mind.
Basically we're talking about a design decision here. Should drivers be able to request configuration changes at arbitrary times, or should they be restricted to config matching in this new callback routine (which gets invoked when the core wants to select a config)?
Yes, choosing between those assumptions/approaches implies design choices beyond "usb_set_configuration() needs a task context" and "kernel code other than khubd should be able to choose configurations".
Many of the advantages of the second choice would be negated by the fact that config changes can be requested via usbfs or sysfs at any time.
How could a constraint on both choices affect only one of them? :) I don't see any negation.
What about drivers that are loaded by hand, well after the initial device setup has finished? Would they get a say in choosing a configuration?
Certainly they should. In the same way their probe() gets called. It's another way to (implicitly) request a config change.
Alternatively, write the sysfs bConfigurationValue after modprobe.
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.
Don't forget, this discussion applies equally well to usb_reset_device() in the "device morphed" pathway. I doubt you want to restrict that capability to these configure() contexts.
No, but I think that the "morphed" case should go through complete re-enumeration, from khubd as usual, instead of making a special case. Enumeration is one of those contexts, and that "hand off to khubd" is something you had pointed out was essential.
- 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
