On Mon, 26 Nov 2012, Sarah Sharp wrote: > > Is port-disabling the only place where this problem occurs? > > Probably not. > > > A more defensive approach would be to copy what ohci-hcd does. When a > > port-change interrupt occurs, the driver switches over to polling for > > root-hub status changes. It doesn't switch back to interrupt-driven > > operation until the hub_status_data routine sees that none of the ports > > have any change bits set. > > Yes, that does sound like a better idea. I'll take a look into it. > > But wouldn't I need to switch to polling in places in the roothub code > other than hub_status_data? For example, the disable port code sets the > port state to disabled without checking the status afterwards. You would need to switch over to polling whenever an interrupt occurs with the port-status-change interrupt flag set -- hub_status_data is where you switch _back_. An extraneous interrupt every now and then won't hurt anything; the issue is to avoid missing events that don't cause an interrupt. > > > + /* Clear all change bits, so that we get a device connect event. */ > > > + port_status |= PORT_CSC | PORT_PEC | PORT_WRC | > > > + PORT_OCC | PORT_RC | PORT_PLC | > > > + PORT_CEC; > > > > What if a connect-change occurred just before this? Would it get lost? > > I think it wouldn't get lost, because the device would have to > re-connect after the port was disabled, and we're atomically clearing > the change bits as we disable the port. But it's a moot point if this > code isn't necessary because I switch the xHCI driver over to polling > when a change bit is set. True. 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
