Hi, Thanks for your explanation indeed! 2012/1/9 Felipe Balbi <balbi@xxxxxx>: > Hi, > > On Mon, Jan 09, 2012 at 05:13:26PM +0800, Yu Xu wrote: >> >> I'm now trying to write the usb3 controller driver. As you said, the >> >> usb set config request has two stage, one is setup stage which is >> >> handled in composite.c, and the other is status stage. >> > >> > The way it works is like this: >> > >> > UDC is required to receive the SETUP packet (from the SETUP Stage), >> > handle what it can (which is USB_REQ_SET_ADDRES, USB_REQ_SET_FEATURE and >> > USB_REQ_CLEAR_FEATURE) and bounce the rest to gadget driver/composite.c, >> > by calling driver->setup(). >> > >> > driver->setup() has to handle the Setup Packet and either queue a >> > request or return an error, in which case, UDC will reply with a Stall. >> > >> > When everything goes fine and gadget driver queues a request, that >> > request could be your Data phase (for any request which has a data >> > phase) or the zero-length Status Stage. >> > >> > Clearly, when there's Data stage usb_ep_queue(), UDC driver will have to >> > be responsible of finishing by sending Status Stage to host. >> > >> >> For usb2, the status stage is handled by usb_ep_queue to send ZLP. But >> >> for usb3, it's different. >> > >> > Why is it different ? It follows the same code path ;-) >> >> OK. I see. I mean the difference is the status stage between usb3 and usb2. >> usb2 is IN->data->ACK transaction. And usb3 is STATUS TP->ACK TP. >> So I need to implement it in usb_ep_queue(), and code path of request handling >> is the same, right? > > Ok hehe, now I get it. That part is handled by the HW. All you should > need to do is start a transfer on the physical ep0in. The difference > between a ACK and a ACK TP should be handled by the HW ;-) > > So yes, usb_ep_queue() will queue a request to USB ep0 and you need to > start that transfer on the correct physical endpoint. > > -- > balbi -- 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
