> > As for cdc-acm, I don't think it should be doing that. The code
> > that chooses a configuration can reasonably change its mind, for
> > example if there was a choice and no driver could bind to that
> > initial selection ... I don't think probe() should be allowed
> > to change configurations.
>
> To the contrary, probe() is the only component in the system that
> actually understands a device configuration. The higher-level code
> is just blindly flipping through a list looking for help.
>
> The driver is the component that understands the attached device and
> should be able to determine its configuration. That's the definition
> of a driver, IMHO.
A device may have several interfaces in its configurations. Which driver
shall decide? And who shall decide which driver is to decide?
But of course there may be vendor specific devices whose drivers should
set configuration. We need to accomodate both. The question is, how exactly?
Regards
Oliver
-------------------------------------------------------
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
