On Wed, 17 Sep 2003, David Brownell wrote:
Example: several different drivers "know"ing the correct configuration for a device, but they disagree on which config that is. System ping-pongs between the configs: one driver overrides the config, then another, repeat forever.
... However, I don't see how this
would happen under either the current scheme or the one you're proposing. Once a driver overrides the config then it ought to bind with no errors,
so the other driver wouldn't even get probed. Unless it was a driver for
a different interface.
Exactly. The multi-configuration devices we commonly see today are also multi-interface devices.
The effort of keeping track of all the N-second timeouts and devices being probed sounds a little messy. But no doubt it can be done.
Simple to do: one bit in the config, "did we probe this yet"; and the device records the last-probe-ed time. The rest just needs a timer ... and something to do the deferred work bit, which we do agree needs to exist.
Perhaps it would be okay not to let drivers change configurations. But there remains the question of how to handle the "device-morphed" path in usb_reset_device(), which involves basically the same questions.
I see them as different in the following way: switching configurations retains the same "struct usb_device". Morphing the device, after a DFU style firmware update (host-initiated reset) or an EZ-USB style one ("Renumeration(tm)", device initiated reset), should in both cases involve a new usb_device and complete re-enumeration.
However, notice that I wasn't saying drivers shouldn't be able to change configurations. Just that probe() can't do it directly ... and that we can make it so that in common cases they won't _need_ to change configs.
- Dave
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
