On Mon, 14 Oct 2002, David Brownell wrote: > >>>* 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?
No, I do agree with you saying this is missing and it's worth having it. Maybe using the term "not valid" wasn't so good here. SetConfiguration(0) is obviously a valid (in fact mandatory) request. It's just not setting the device to any configuration as given by the descriptors. > 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, that would be useful. For example, it provides some kind of partial reset. Forcing a device to go through the ADDRESS state should cause it to re-initilize pretty much of its features. Compared to driving a RESET condition on the bus the advantage is the address doesn't change. > > 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? 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. > > 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. 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? I think we need some entity which takes responsibility to manage the device as a whole. We should offer drivers a way to say "I'll do this". If there is no such driver willing to manage the device, usbcore will try it's best for the per-interface drivers like it is doing now. I'm not saying we need to change the device probe model. Maybe it's sufficient to introduce the rule that drivers that have any of USB_DEVICE_ID_MATCH_VENDOR / _PRODUCT or _DEV_* in the match_flags for the probed device get the whole device granted - those with _INT_* only the interface. That would just be a extension of the match_flag semantics. OTOH this might get into conflict with some device-fixup code from usbserial and/or storage... > 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 ;-) Martin ------------------------------------------------------- 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
