Most recent kernel where this bug did not occur: Distribution:2.6.17 Hardware Environment: When testing USB gadget File backup storage driver. Software Environment: Host is another Linux 2.6 PC. Problem Description: The usb gadget file backup storage driver sends wrong informaion about the version of USB. It is hard coded to send USB 2.0 as default. But If the device doesnt support 2.0 and the host supports 2.0 then the problem comes. It happend with me my device supports only 1.1 and the standard linux host(2.6 kernel) supports 2.0. and the kernel started sending usb 2.0 commands, for which the device does'nt support. And the result is error 4454927.601000] usb 2-2: new full speed USB device using uhci_hcd and address 6 [4454932.696000] usb 2-2: unable to read config index 0 descriptor/start [4454932.696000] usb 2-2: can't read configurations, error -110 [4454932.758000] usb 2-2: new full speed USB device using uhci_hcd and address 7 [4454937.853000] usb 2-2: unable to read config index 0 descriptor/start [4454937.853000] usb 2-2: can't read configurations, error -110 [4454937.915000] usb 2-2: new full speed USB device using uhci_hcd and address 8 [4454942.945000] usb 2-2: unable to read config index 0 descriptor/start [4454942.945000] usb 2-2: can't read configurations, error -110 [4454943.007000] usb 2-2: new full speed USB device using uhci_hcd and address 9 [4454948.037000] usb 2-2: unable to read config index 0 descriptor/start [4454948.037000] usb 2-2: can't read configurations, error -110 Steps to reproduce:1) Take a device which supports only 1.1 and install the module g_file_storage.ko then try to plug it in 2.6 kernel PC. it dumps messages instead of enumerating it. I have the fix for this problem to just put the versioning of USB 2.0 info in the preprocessor in two places. #ifdef CONFIG_USB_GADGET_DUALSPEED .bcdUSB = __constant_cpu_to_le16(0x0200), #else .bcdUSB = __constant_cpu_to_le16(0x0110), #endif
It's perfectly valid for low or full speed devices to report themselves as supporting USB 2.0 ... and Linux hosts don't really care. Problems reading descriptors don't relate to that issue, in any case. They're separate. You didn't say what peripheral controller your device is using. I'll speculate the true bug is that its driver doesn't issue protocol stalls (on ep0) correctly.