> -----Original Message----- > From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb-owner@xxxxxxxxxxxxxxx] On Behalf Of Peter Chen > Sent: Tuesday, February 07, 2012 1:55 AM > > On Mon, Feb 06, 2012 at 03:14:10PM -0500, Alan Stern wrote: > > > What is wrong processing one setup packet after the other? > > > > Suppose the host sends a Set-Interface request, and you delay handling > > it. If the delay is too long, the host will time out and cancel the > > request. Then the host sends some completely different request, such > > as Set-Feature. If your delayed response goes back now, the host will > > think you accepted the Set-Feature request and not realize that you > > really carried out the Set-Interface. In addition, the response to the > > Set-Feature request will remain sitting in the ep0 FIFO and never get > > sent, because the host won't ask for it. > > The prepare status stage for Set-Interface at usb_composite_setup_continue > should not be sent to udc at this situation, we should cancel it if we > receive another setup packet. > Maybe We can add judgement at composite_setup and composite_delayed_setup. > > At composite_setup > If (cdev->delay_status > 0 && !(ctrl->bRequest == USB_REQ_SET_INTERFACE | > ctrl->bRequest == USB_REQ_SET_CONFIGURATION)) { > /* last one is delayed_one, but current one is non delayed_one. > * We should cancel work item for set_interface and set_configuration > * handle. > */ > cdev->delay_status = 0; > } > At work item composite_delayed_setup > if (cdev->delay_status == 0) > return; /* do noop */ > else (cdev->delay_status == 2) { > cdev->delay_status--; > return; /* Cancel current delayed setup handle, > * will handle the next setup handle. > */ > } I think it is better to have this logic in the UDC. For example, the DWC USB3 controller handles this case automatically. If it receives another setup packet before the first control transfer completes, it will "fake" the completion of the first one to the software, accepting the data and status phase commands from the driver but not actually sending anything on the bus. So in the case of the DWC3 driver, nothing should need to be done to make this work correctly. -- Paul -- 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
