On Mon, 14 Oct 2002 [EMAIL PROTECTED] 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. In fact this is the _only_ way you can switch the configuration without doing a complete port reset or disconnect cycle. To switch from config (value) M to N one has to go M -> 0 -> N. See USB spec 9.4.7. > > * Other than that the only requirement for the configuration value(s) is > > they must be unique for the device. In conclusion, there's nothing wrong > > with a device using configuration values 13, 7, 123 for its three > > configurations - in any order. > > > > * configuration values are known in advance (i.e. before the host needs to > > issue the first SetConfiguration request) from the corresponding > > configuration descriptor. > > > > * configuration descriptors (like all other deescriptors) are referenced > > by a zero-based index 0, 1, ... bNumConfigurations-1 where the number of > > configurations is known from the device descriptor (bNumConfigurations) > > To repeat: These indices refer to the configuration descriptors, not the > > configuration. > > But there's 1:1 correspondence between configuration descriptors > and valid configurations, isn't there? Yes sure. If you are dealing with configurations (in contrast to the corresponding descriptors) it's just they are "named" by the configuration values as given inside the descriptor - not by the descriptor index. This would be impossible because the first config descriptor has index=0 which is not a valid config value (as used by Set/GetConfiguration requests). > > * A priori there is nothing that makes any configuration different or > > preferable compared to any other. The choice is just a matter of user > > selection, policies and system configuration. > > True, but absent user intervention the kernel has to choose a > configuration. Why? If the user isn't using the device, it remains unconfigured. If he does, it's up to the driver and his system setup to find out which one is would be correct. > We'd like to call that the default configuration. IMHO that might be helpful in two possible situations: - if a driver binds to the whole device (not interface), it might have some clue to know what configuration makes sense to use for default. - if a device has only one configuration and there is no driver that wants to get bound to the whole device, usbcore might want to pick up and activate (and lock!) this configuration so it can go on probing drivers on a per-interface basis. > The patches I've sent in aim to make selecting a configuration > through usbfs safe. The possibility itself has been there for a long time. 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). 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. > 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. 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
