On Fri, Nov 02, 2012 at 10:36:49AM -0400, Alan Stern wrote: > On Thu, 1 Nov 2012, Sarah Sharp wrote: > > > On Thu, Nov 01, 2012 at 03:46:37PM -0400, Alan Stern wrote: > > > On Thu, 1 Nov 2012, Sarah Sharp wrote: > > > Anyway, if five resets in a row all fail then we should do our best to > > > ignore the device. Let the user unplug it and try again. Will this > > > patch do that? > > > > I think the patch will leave the port in SS.Inactive (the old code would > > too). The port will stay in that state (even when a device is > > connected) until either the USB core issues a warm port reset, or the > > port is disabled. But if we disable a SuperSpeed port, we don't get > > connect events until we set the link state to RxDetect. So there's > > basically no way to get an automatic notification of a device connect > > when the port goes into this state. > > Even if the device is physically unplugged and plugged back in? Yes. The port state will remain disabled even if a device is unplugged and plugged back in, AFAICT from the downstream port state machine in the USB spec (Figure 10-9) and the description of the disabled state in the xHCI spec (Section 4.19.1.2.1). That's the reason why we don't allow USB 3.0 ports to be disabled in hub_port_disable(). > > Can we set a timer to kick khubd after some amount of time (30 seconds?) > > and make hub_events check for ports in SS.Inactive even if none of the > > change bits are set? > > I don't like that idea. It would be much simpler to put the port back > into a useful state. For example, disable the port, then put it into > RxDetect, then clear any change bits, and set the port's bit in > hub->removed_bits. > > (hub->removed_bits was meant to help implement Windows' "Safely remove > hardware" feature. When a port's bit is set, khubd will ignore any > device attached to that port until it sees a connect-change.) Oh, interesting! I didn't know that. I think putting the device into disabled, then RxDetect and ignoring it is a good solution, however... What exactly does khubd do when it ignores the device? Does it still clear the change bits, but not take any action on them? Or does it ignore the change bits entirely? If khubd completely ignores the port status change bits, I think we have an issue with xHCI. The xHC only generates a port event when all port change bits were previously cleared (see section 4.19.2). So if a port change bit gets set and the port status change event is completely ignored by khubd, the xHC won't generate a port status change event on the disconnect. A port will seem "dead" after a safely remove, if an event like an overcurrent or link state change occurs. Ignoring one port shouldn't have any affect on port status change event generation for other ports, so I think we're ok there. I'll just have to take a look at how khubd deals with the hub->removed_bits. Sarah Sharp -- 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
