On Mon, 30 Jan 2012, Nikolai Zhubr wrote: > 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? It doesn't distinguish. In both cases the UDC driver does the same thing: It tells the hardware not to accept the packet (i.e., to reply with NAK). > 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). If there is no response at all (neither NAK nor data) then the host retries the transfer. After 3 attempts the host gives up. This is quite typical; it happens whenever somebody unplugs a USB cable in the middle of a transfer. Alan Stern -- 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
