> -----Original Message----- > From: Chen Peter-B29397 [mailto:B29397@xxxxxxxxxxxxx] > Sent: Tuesday, February 07, 2012 5:27 PM > > > > -----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, > It is done by software, not the "fake" complete interrupt from the hardware, correct? No, it is done by the hardware. > > 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. > Do you mean maintain ep0 transfer status at udc, like below: > /* ep0 transfer state */ > #define WAIT_FOR_SETUP 0 > #define DATA_STATE_XMIT 1 > #define DATA_STATE_NEED_ZLP 2 > #define WAIT_FOR_OUT_STATUS 3 > #define DATA_STATE_RECV 4 > > But when the first one at WAIT_FOR_OUT_STATUS, and the second setup is coming, > how do you deal with it, you should not cancel the second one, > as it is the host really waiting one, beside how do you know the status sending request > from composite driver is the first one but not the second one? If you do need to do this in software, it should be pretty easy. Only one control transfer can be active at a time, so any request from the gadget driver is for the last setup that the UDC passed to it. If the UDC receives another setup packet in the meantime, then it knows the one in progress should be canceled. It can hold onto the second setup packet until the gadget completes all phases of the previous one (and the UDC just throws away those commands instead of acting on them) before sending the second setup packet to the gadget. The only problem would be a control write with a data stage. Then you would have the problem of what data to send to the gadget for the data stage. All zeroes maybe? But I don't think any 3-stage control write transfers exist in any of the current protocols, so it may not be an issue. -- 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
