> > > > 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?
A good example of a manufactured problem. In my proposal, there is only one driver for a given device, so your questions disappear. > > But of course there may be vendor specific devices whose drivers should > set configuration. We need to accomodate both. The question is, how exactly? Certainly there are two categories of drivers: generic and vendor. While my proposal is primarily oriented toward vendor drivers, the architecture is equally applicable to both. My goal is to simplify the vendor development environment as much as possible, since these are the people who must be convinced to "get with the program" ;-) > > Regards > Oliver > Thanks and best regards. Leigh Bassett ------------------------------------------------------- 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
