On Thu, 8 Jan 2015, Hans de Goede wrote: > > Read through this and it seems we really may end up doing a extra reset if > > the hub wq happends to to catch the device in middle of a remote wakeup. > > (i.e. RESUME -> U0, PLC set, but interrupt handler clearing PLC flag not yet run) > > > > reverting a82b76f7 is one option, but then we get back the issue it fixed, so I'd rather > > try to find a fix for both cases before reverting. > > Right, note that I wrote a82b76f7 while seriously stress testing stuff on what is > in essence a laptop with broken firmware which causes it to toggle on/off the vcc of > the usb-port while the kernel is resuming (so after the BIOS has transferred control > back). Even with a82b76f7 some devices still become rather unhappy (and rightfully so) > when the firmware does this. As mentioned in the commit one may (theoretically) see > similar problems with a bad / loose connector, but still this fixes a rather rare > corner case, so if it is causing problems in a more common case it might be best to > revert this for now. If Vcc gets toggled, wouldn't the USB_PORT_STAT_C_CONNECTION bit get set? It seems you should be testing that bit, not USB_PORT_STAT_C_LINK_STATE. But of course, that subroutine already tests the C_CONNECTION bit earlier on. So I tend to agree, it looks like that commit ought to be reverted. On Thu, 8 Jan 2015, Mathias Nyman wrote: > It seems there are other issues with usb3 port states as well, Taegil Bae reported > a re-connect issue: > > http://marc.info/?l=linux-usb&m=142055403029943&w=2 > > Looks like I need to really dig into the usb3 port states and figure out exactly how it is > supposed to work Keep in mind that Taegil Bae's problem is an unusual one. He's using the sysfs "remove" attribute, which is like the Windows "Safely Remove Hardware" button. It unregisters the device, disables the port, and sets a bit in hub->removed_bits. As long as that bit remains set, the hub driver will not initialize any device attached to the port -- the idea is that once you've told the system to remove a device, you have to physically unplug it before the port will work again. So the problem is that the bit in hub->removed_bits gets cleared at the wrong time. A quick search shows that the bit gets cleared in two places, and each time the code tests for !(portstatus & USB_PORT_STAT_CONNECTION) || (portchange & USB_PORT_STAT_C_CONNECTION) Normally that's the right thing to do. But it looks like there's a reset or warm reset messing this up. I'm not sure how. 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
