On Fri, 6 Jun 2003, David Brownell wrote: > 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() ...
> > 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. Sorry, I misspoke in my original message. I didn't mean usb_reset_config(); I was thinking about drivers that want to change to a different configuration during their probe(). How do you plan to accomodate that? 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
