On Tue, Mar 16, 2010 at 10:51:50AM -0700, Sarah Sharp wrote: > Why are you only ringing the endpoint doorbell or stopping the endpoint > if the device is configured? It is possible that a driver or the USB > core has placed the device in the addressed mode with a SetAddress 0 > control transfer, and we will want to talk to it when it comes out of > suspend. The USB 2.0 bus spec (section 7.1.7.6) says "Devices can go > into the Suspend state from any powered state." System software triggered port power management will only be called via the sysfs interface which only exists when the device is configured. > It does not hurt to ring the doorbell unconditionally. If there is no > TDs on the ring, then nothing happens, other than the host controller > fetches a TD it doesn't own. > > It also doesn't hurt to issue a stop endpoint command for a disabled > device. The stop endpoint command handler will ignore the status that > comes back for that command completion. In fact, the original code > won't do anything at all unless there are TDs on the cancellation list. > The USB core shouldn't suspend a device unless all URBs are completed > and the device has been idle for a while, so there should never be TDs > on the cancellation list. I think we can avoid any redundent action if possible. If you require unconditionaly do them, I will follow you. > Uh, did you think about the above case in the code? From the way I read > the modified code, the xHCI driver will issue several stop endpoint > commands with the suspend bit set, and then immediately restart them > with a doorbell ring, since the TD cancellation list is empty. > > If that's true, your completion will never get called below. Since > you're using the generic completion in the device slot, you could be > getting a completion from some other command. It's probably better if > you allocate an xhci_command and stash it in the xhci_virt_device > structure. > > So how can this patch work? Am I just reading the code wrong? Let me think, and check. Sarah all others I will follow your suggestion. Thank you for your intensive comments. -- Best Regards, - Crane -- 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
