On Sat, May 31, 2014 at 04:45:01PM +0200, Bjørn Mork wrote: > Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes: > > > ffff8800da9be6c0 3444255124 S Ci:2:067:0 s 80 06 0100 0000 0012 18 < > > ffff8800da9be6c0 3444255418 C Ci:2:067:0 0 18 = 12010002 00000008 f3048900 1300040e 0001 > > So you are successfully reading the device descriptor in hub_port_init() > > > ffff88020b7a76c0 3444255485 S Ci:2:067:0 s 80 06 0600 0000 000a 10 < > > ffff88020b7a76c0 3444255548 C Ci:2:067:0 -32 0 > > ffff88020b7a76c0 3444255612 S Ci:2:067:0 s 80 06 0600 0000 000a 10 < > > ffff88020b7a76c0 3446360388 C Ci:2:067:0 -71 0 > > ffff88020b7a76c0 3446360451 S Ci:2:067:0 s 80 06 0600 0000 000a 10 < > > ffff88020b7a76c0 3446360539 C Ci:2:067:0 -71 0 > > > Then you hit this part of hub_port_connect_change(): > > /* check for devices running slower than they could */ > if (le16_to_cpu(udev->descriptor.bcdUSB) >= 0x0200 > && udev->speed == USB_SPEED_FULL > && highspeed_hubs != 0) > check_highspeed (hub, udev, port1); > > > And check_highspeed() calls usb_get_descriptor() to get the > USB_DT_DEVICE_QUALIFIER descriptor, but this device doesn't like that > and stalls. usb_get_descriptor() still tries 3 times before giving up, > but it looks like the stall isn't cleared like it should be? Yeah, that doesn't make sense, the device really doesn't like that call. So I stopped making that call to it and it now works a bit better, but is constantly disconnecting itself from the bus now and reconnecting itself. I'll work on this more later on today, thanks for the initial push... greg k-h -- 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
