I've spent most of the day adding traces to the usbnet, xhci-ring and ax88179_178a code to try to find out why the link doesn't come up quickly. I've just found out something significant that someone else might like to try and repeat. If I add a trace print to xhci_queue_control_tx() is all seems to work (modulo long delays in anything actually being transmitted). Now the ax88179_set multicast() is called three times in quick succession as part of the original initialisation. Each call queues 2 control requests (it doesn't wait for any completions). If you trace the TD completions you see that the first one completes more or less immediately, but the following ones complete each time another control transfer is added. What appears to happen is that the controller only executes one item from that queue every time the doorbell is rung. The register read/write requests then timeout, the driver doesn't check. Eventually enough of the write transfers must complete for the ring to come up. All the time this is happening the code keeps telling 'netdev' that this link is ok - generating all the extra traces about missing 'link down' events. It might be worth seeing if ringing the bell in the completion function helps. David -- 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
