On Thu, 12 Apr 2012, Sarah Sharp wrote: > xHCI does a similar thing of only returning a non-zero status when we're > in the middle of resume. I think it does that for both USB 2.0 and USB > 3.0 ports. There are also a couple other port status change events that > we hide from the USB core, because there is no equivalent port status > bit in external hubs. > > Will the USB core now handle a non-zero return status from > hub_status_data() when none of the hub change bits are set? Yes. More precisely, you could always return a non-zero value from hub_status_data with none of the change bits set, but until now that would have no effect. In particular, it wouldn't cause khubd to check any port statuses. With this patch, it's still true that khubd won't check the port statuses if none of the change bits are set. Rather, the effect is to tell usbcore to resume the root hub (assuming you return the non-zero value just after the root hub has been suspended). The idea behind this is simple enough. The HCD generally knows when a port resume (due to a remote-wakeup request) _starts_. But the only way it has to tell the core is by setting the suspend-change status bit, and it's not allowed to do that until the resume _ends_. Now the HCD will be able to say that a port resume is in progress by returning a non-zero value, even though the suspend-change bit isn't set. > If so, that > simplifies the xHCI hub architecture quite a bit. I think that means we > should set the polling bit and return a non-zero value whenever a change > bit is set. You should simply call usb_hcd_poll_rh_status whenever you learn that a status-change bit has been set. Aren't you doing this already? Polling should usually be avoided. The only reason for polling in ehci-hcd is because it uses the poll as an opportunity to turn off reset or resume signalling (and turn on the corresponding status-change bit at the same time). Every other status-change event is detected in the IRQ handler. > That will take care of some of the issues we've been seeing > with xHCI ports seeming "dead" because the xHCI driver didn't clear a > port change bit when it should have. Can you give more details about these issues? This patch wasn't intended to help with problems like that. 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
