On Mon, 15 Sep 2003, David Brownell wrote:
Its kerneldoc is updated appropriately. The main point being that calling usb_set_configuration() in driver probe() methods is even more of a no-no, since it'll self-deadlock.
I've been thinking that it would be good to allow drivers to call usb_set_configuration() and usb_reset_device() during probe(). Doing so would require breaking each operation up into two parts:
I've been thinking differently for the "no thanks, but this driver should work in some other config" probe() case. For cdc-acm, which is the only problem I know about today.
I don't like any driver to be making these policy decisions as absolutes. Some other driver, not yet (mod)probed, might have better luck binding to this interface (or might already be bound to another interface in this config!) ... the config may be a lot better than this driver thinks it is, with just its current local perspective!
The notion I've recently been tossing around is this. Usbcore can easily notice that that after N seconds since usb_set_configuration():
- It's still true that none of the interfaces has a driver;
- There's still a config we haven't tried, and it even fits within the power budget available for that port;
- So make some task call usb_set_configuration(that-config), to let the usb drivers try binding to that one.
No new API needed; user/admin control is possible with sysfs (write bConfigurationValue); and it's simple enough that it won't go haywire. In particular, it stops after bNumConfigurations attempts, or when a semi-functional configuration has been found.
I suspect that kind of solution would get rid of the cdc-acm issue, as well as solving the corresponding issue for the CDC Ethernet class support...
the immediate part, done at the time of the call, which unbinds and destroys all the interfaces _except_ the caller's, and sends the actual SET_CONFIGURATION or PORT_RESET message;
I don't like the notion of having such an immediate action for config issues, for the reasons sketched above: we don't know that this config is really so bad. Device drivers only have local knowledge, not global.
the deferred part, running in another thread (using schedule_work(), for example) would unbind and destroy any remaining interfaces and finish whatever needed to be done: choose a configuration, probe interfaces, or perhaps destroy the struct usb_device.
So whatever task runs would look at the device and do the right thing. The "choose a config" steps could be as I sketched above, and of course the updated usb_set_configuration() is in charge of probing (as it must be).
Is that "destroy the device" bit needed for the "probe()-does-DFU" case, where a re-enumeration gets forced? I recall that coming up, it's something of a new case (to have working) which I keep thinking will want a new api call.
The deferred part could also be invoked by the hub driver to handle connect and disconnect events. This would help take some of the load off the khubd thread, which right now is trying to do too much.
As we've discussed. Yes, I think the disconnect() bit would be easy enough to snip off in that way -- and we'd get better DFU support from it, right away.
The connect processing -- going from ADDRESS to CONFIGURED state the first time around -- could also be split out. In fact it'd be easy to make it use that "try the next config" logic I sketched...
Implementing this would also mean changing the API, since callers of usb_set_configuration() and usb_reset_device() would have to pass in a pointer to the interface they drive. That shouldn't pose much of a problem, since neither of these routines is called from very many places.
I can see that for the current usb_reset_device() functionality, but that's it.
The whole point of _changing_ a configuration is that it's going to change -- so all "current" interfaces become invalid! Remember that almost all the previous users of usb_set_configuration() are now using usb_reset_configuration(), which has the right kind of semantics (no config changes except to altsetting 0).
- Dave
Alan Stern
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
