On Thu, 12 Apr 2012, Sarah Sharp wrote: > The issue I was thinking of would happen on some pre-release Intel xHCI > hosts. When the user disconnected a device, the host would report an > "Inactive" state. Then the USB core would issue a warm port reset, > which would timeout before the warm port reset change bit was set. We > missed a spot in the hub status handler that was supposed to look for > the warm port reset change bit, and so the port was suspended while the > bit was set. In other words, the bit got set but you had stopped looking at it, so it never got cleared. Right? > Since the xHCI host doesn't interrupt again when a previous port status > change bit is still set, we would never get an interrupt when a device > signaled a remote wakeup. In fact, we would never get reports of > disconnects or connects from the port ever again. So the port would > seem "dead" after the device was removed. > > With the current change to the USB core hub status handler, I think I > can just return an error code whenever a port status change bit is set. > Then the port will never be suspended with no way to know when a device > resumes. I don't see how that would help. You'd still have the problem of not clearing the status-change bit after you had stopped looking at it. > But that only handles the case of a lost port resume change bit. We > still need to handle other types of lost port status change bit > interrupts. I believe we had the discussion some time ago that I should > set the polling bit when any port status change bit is still set at the > end of any of the hub functions. That way, if we miss clearing a change > bit somewhere deep in the hub code, the USB core will know it needs to > poll the status later. It's better to fix mistakes than to paper over them. And polling should be used only when interrupts won't do the job. If you miss clearing a change bit then it will never get cleared. Thus you would never stop polling. That's not a good approach. If you can detect that a status bit should have been cleared but wasn't, then you should just issue a WARN_ON. That would call your attention to the problem, allowing it to get fixed quickly. 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
