>>>* Zero is not a valid configuration value as it is used to reference the >>>unconfigured state. >> >>So requesting a device to assume that configuration violates the >>specification ? > > > No. It requests the device to get de-configured, i.e. enter the ADDRESSED > state. ... See USB spec 9.4.7.
So are you suggesting that we not provide a way to re-enter that state? I was suggesting that we do provide it. Basically the internal "physical" call to set_configuration(dev,0) would be used -- matching 9.4.7. Ignore the terminology issue about what "config zero" means in any context other than a set_configuration() call. > 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. > If a driver bounds to the whole device he owns the configuration-lock and > may issue SetConfiguration request when- and however it would like to do. > > If no driver binds the device as a whole and it is single-config the > configuration-lock should be acquired by usbcore. Then it should issue > a SetConfiguration(config_descr[0].bConfigurationValue) request and > re-probe on a per-interface basis. As long as at least on interface is > bound to a driver, the configuration remains locked. If all interfaces > are unbound, the device is unconfigured - SetConfiguration(0) - and the > lock finally released. 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. >>Additional questions, may a hub have several configurations ? >>May changing a hub's configuration lead to its children being >>disconnected ? Must the hub single disconnections to the host >>before it changes its configuration, if that leads to child >>disconnection ? > > > cf 11.23.1: All hubs (USB_CLASS_HUB) are single-config, even for highspeed > capable USB-2.0 hubs with several TT's. Note: I'm not talking about the > other-speed configurations here - to switch speed one has to go through a > port RESET anyway. And I think if you go through a USB 2.0 hub you may not have a choice about enumeration speed ... only through an EHCI root hub. (But I've not checked the spec there.) 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! :) - 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
