On Thu, 11 Oct 2012, Elric Fu wrote: > Hi all, > > I recently found a strange issue on a embedded platform and don't know > how to fix it. Please give me some suggestions. > > The platform is ar9331. The issue is if we attach a usb audio device to > the host on ar9331 directly or via a usb 1.1 hub the usb audio works fine, > but if we attach it via usb 2.0 hub the undermentioned message will be > reported. Moreover, when the usb audio was attached to the host on X86 > via usb 2.0 hub it worked fine too. > > ~ # usb 1-1.3: new full speed USB device using ar7240-ehci and address 3 > usb 1-1.3: unable to read config index 0 descriptor/start: -145 > usb 1-1.3: chopping to 0 config(s) > usb 1-1.3: string descriptor 0 read error: -145 > usb 1-1.3: New USB device found, idVendor=040d, idProduct=3400 > usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > usb 1-1.3: no configuration chosen from 0 choices > > I tracked the issue and found the usb audio had a strange issue. It is a > usb 1.1 device and works at full speed. But the interesting thing is the > bcdUSB field of device descriptor is 0x0200. That means it is a USB-2.0 device, not USB-1.1. > So the > hub_port_connect_change() will involke the check_highspeed() which > would get device qualifier descriptor. > > The correct case is the device doesn't have the device qualifier descriptor That's okay. It means the device doesn't support high-speed operation, only full speed. > and usb_get_descriptor() will retry 3 times and return -32. But now > usb_get_descriptor() will return -145 at the second time. Then when the What is error -145 on your platform? Is it -ETIMEDOUT? > usb core send a get configuration descriptor request, but the control transfer > will be timeout again. > > I used the usb analyzer to capture the trace and found host just sent one > get-device-qualifier-descriptor control transfer and the device return a > STALL. But at the second time, actually, the host even didn't send the setup > packet. I don't know why. Since the transfer uses aplit transactions, the host doesn't send any SETUP packets at all. The intervening hub sends them. Maybe there's something wrong with the hub. Can you use your analyzer to capture the traffic between the computer and the hub, rather than between the hub and the device? > My opinion is the split transactions to the device which has a 0x0200 bcdUSB > but is actually a full speed device have some issues. I would > appreciate any ideas. What happens if you use both the device and the same hub with a regular PC? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
