On Mon, Nov 26, 2012 at 01:35:46PM -0500, Alan Stern wrote: > 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. Do I need to stop the polling when the host controller is suspended and restart it when it's resumed? It seems like OHCI does that, but I can't tell if it's host-specific. Or will the USB core just take care of stopping and restarting the hub timer? 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
