>>>Yes, I know what I've said above is not how it currently works. I believe >>>for proper support of multiple-configuration devices we need an option to >>>probe drivers one a per-device basis first (with the device still >>>unconfigured). >> >>In which case we may need an internal primitive to enter that state during >>re-binding sequences ... the reset_device() logic goes all the way to >>the "default" device state, it doesn't pause in the "addressed" state. > > > s/default/configured/ you mean?
Err, yes. It's not the "default chosen today during enumeration" case, I'd expect the reset_device logic to support reset into other configs. It's worth noting in passing that we're really near having something useful for that new "device hotplug" event to handle. It might make a lot of sense to not issue SET_CONFIGURATION for devices that have multiple configurations, insisting that device hotplug handle that. For single config devices (what people usually use) there's no point in changing this behavior in 2.5 (IMO), but for that case it might be a Good Thing to do. > I'm not sure about reset_device(), IMHO it's used by usb_storage only and > I don't really understand all the issues there. Me either, but having a way to reset devices in software seems like something reasonable to have. >>I'm not convinced we need to change the device probe model, but maybe >>that's because multi-config devices aren't generally available off the >>shelf. If we do need to change it, that sounds like a plausible scheme. > > > I believe the whole point of the driver-bound-to-interface approach is to > restrict the driver to this particular interface, and on the other hand > protect it from interference originating from other drivers. Changing > configuration effects all interfaces by definition. Similar issue would be > the Set/ClearFeature-Remote_Wakeup_Enable request - which interface driver > should handle this? Remote wakeup should be owned exclusively by usbcore, and set as part of suspend processing only if the HCD supports remote wakeup. I'm told some devices malfunction if that's set earlier than "right before suspend". If someone wants to implement remote wakeup, I'd like to see the patches! :) >>If anyone is arguing that we need to modify the reset_device() logic >>to give us an option to run high-speed capable devices at either speed, >>I'll expect them to provide initial patches implementing it! :) > > > Well, the patch is called 1K5 resistor - it's applied with some soldering. > I don't see how to do this with software ;-) Actually someone just offered a similar sort of hardware to me ... in concept, a cable that's got a software-controlled switch to trigger unplugging. - 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
