On Thu, 5 Jun 2003, David Brownell wrote:
Yes, something like usb_reset_config(dev) call is needed. As well as converting code to use it, instead of the current calls to usb_set_configuration() in drivers.
I want to echo Oliver's sentiment; this is a great patch.
Needed a few others to be merged first though ... :)
Implementing usb_reset_config(dev) will be tricky. Since it is called
from within probe() it can't call usb_set_configuration() directly because
the sysfs lock is already held. Somehow it needs to tell the process that's registering the interfaces to stop -- no point binding any more drivers when you're just going to change the configuration anyway -- and then do the set_config.
The way I see it, usb_reset_config(dev) should actually be easy ... but it'll necessarily have significant restrictions when used on devices with multiple interfaces. Basically, don't use it unless you're the only driver bound (or being bound) to the device -- else you'll likely break the other driver(s). In those cases, usb_set_interface() provides the relevant single-driver scope.
The reset_config() implementation could just issue control requests directly, either set_config to zero then set_config back to previous value; or just set_config to current. And it'll clear reset all toggles (and halt status, if we keep that). It's not _changing_ the config, so it'd be safe to call within probe() ...
Your current scheme of unbinding the drivers before changing the configuration doesn't lend itself easily to invoking a callback in the driver once the set_config is complete. How do you propose to let the driver know whether the call succeeded or failed?
A reset_config() call would just return zero-or-negative-errno, and wouldn't unbind.
Come to think of it, what use could the driver make of that information? If the call failed there's nothing the driver can do, and if it succeeded
the driver will be probed again anyway.
You mean, for a usb_reset_config(dev)? I'd imagine that it wouldn't even bother unbinding. As I recall, the current usage is almost exclusively in probe() calls for single-interface devices.
- Dave
Alan Stern
------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel