> > -----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? > 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? > > -- > Paul > Peter -- 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
