> > Hello Peter, > 30.01.2012 5:45, Chen Peter-B29397: > >> Is it normal that a gadget driver after creating a few IN endpoints > does > >> not start feeding any Tx data to some of them? > > Yes, it is possible. It is gadget itself behave, it can call - > >ep_enable to > > create class endpoints after receiving SetInterface(1,1), then - > >ep_enqueue > > is triggered by application. > > > >> > >> I'm asking because I thought it is strange but specifically g_serial > as > >> of 2.6.34 (can't test this on any newer yet) by default and while no- > one > >> opens any ports yet (just cable plugged in), does this: > >> > >> 1. creates IN1 bulk, IN2 intr. (I'm omitting OUTs here) > >> 2. enqueues something to IN2, but _never_ enqueues anything to IN1 as > >> far as I can see. > >> > >> As soon as a token for IN1 arrives from the host, device driver gets > >> stuck waiting indefinitely because it has nothing to send. What should > >> it do in such case? > > " waiting indefinitely" what do you mean? If there is no data to send, > the > > controller will send NAK automatically. > > Ups, sorry, meant "infinitely" of course. > But how would the (device) driver destinguish between gadget not willing > to send any more data (intentionally) and not being fast enough to > finish preparing the appropriate request just yet? For specific usb transfer, there is related class spec, for bulk transfer, it may include command stage and data stage, if the command stage has not completed, it will NOT go to data stage. For your question, if the class driver is not fast enough to reply command at command stage, it will not prepare usb request. The gadget driver decides when to send the data, the udc driver only supply callback function ->queue to help prepare the request to hardware. > Also, what should host do if it did not receive neither NAK nor data? > There has to be some timeout probably? I've noticed that occasional 3 > second delays still do not harm the transfer here (other than slowing it > down). > The host will do related operation according to usb class spec. > > Thank you. > Nikolai > > > > >> > >> > >> Thank you. > >> Nikolai > >> -- > >> 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 > > > > > > > > > -- 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
