On Mon, 15 Sep 2003, David Brownell wrote:
> This is the latest update of the patch resolving bugs in how device
> configurations were reflected in the driver model. It addresses
> the last significant problems I know about in that area.
>
> - Moves code around so that usb_set_configuration() updates sysfs
> to reflect the current configuration. Previously, that only
> worked right for the initial configuration chosen by khubd.
>
> * Previous interfaces are inaccessible. The code to handle this
> moved from usb_disconnect() into usb_disable_device(), which
> is now called both on disconnect and set_configuration paths.
>
> * There are new interfaces. The code to handle this moved
> from usb_new_device() into usb_set_configuration().
>
> * Use device_del() not device_unregister(), which matches
> with using device_add() to create the devices instead of
> device_register() ... resolves one refcounting problem.
>
> 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:
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;
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.
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.
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.
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
