... 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.
But what we probe is an _interface_ not a device; and not a device configuration.
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.
Actually I'd say we don't yet have a component, even in userspace, which understands "configuration". In fact even today, we know there are bugs in the Linux code to handle non-default configurations.
I see that as a problem. One we're attacking on a few different fronts:
- First, usb_set_configuration() still doesn't do what it needs to do ... the main remaining bug I know about is that changing a config (or setting it to zero) doesn't get rid of old sysfs files.
- Second, that capability is unavailable from userspace, where we can expect intelligence about such policies.
- Third, drivers using usb_set_configuration() have basically been wanting something other than a configuration change, since configuration changes haven't worked. (Except that the hub enumeration logic has worked for initial config 0 --> default.)
We're also ignoring the power management issues, like never enabling configurations that exceed the hub's power budget.
Periodically I've thought we might need to add a new notion to the API, a "configuration driver". Here's a rough idea of how it might work:
* New driver call, analagous to probe() but accepting a usb_device. It'd match only device descriptor fields.
* Devices that need non-default configuration (index != 0) would need such driver support.
* When selecting an initial configuration, usbcore would first check to see if there's a configuration driver.
- If so, that driver's configure() call [or whatever]
would be used ... it could set the "Linux Config" vs
the "Windows Config", or whatever.- Otherwise, use the current scheme: config index 0.
Such an approach would address some of the issues that come up during enumeration. And if sysfs could be used to change the configuration, bad kernel choices could be reversed.
- Dave
------------------------------------------------------- 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
