On 08/29/2011 03:42 PM, Felipe Balbi wrote:
Hi,
Hi,
It is a short transfer in OUT direction. Don't these have to finish
anyway?
the same way dwc3 has a quirk where it won't complete transfers which
aren't aligned on wMaxPacketSize (on OUT direction), there could be
another controller with a different quirk.
quirk? What do you do if the the gadget asks for OUT 5 bytes and you
receive 6 from the host? You throw the one byte away. Shouldn't you at
some point inform the gadget about this misbehavior? It is part of one
USB packet so it can not belong to the "next" transfer.
The core is forcing you to consider this misbehavior as a possibility
by always having to use wMaxPacketSize for OUT transfers.
Too bad musb does not do DMA on ep0. Let me check others :)
Until we know this won't cause problems for anyone else, I rather keep
this workaround on dwc3 driver, since this is purely a dwc3 limitation.
Yes, I'm okay with this workaround beeing dwc3 specific. In the long
term I would prefer not having udc have to work around gadget's bugs.
it's not a bug on the gadget at all. The gadget is doing exactly what
the specification mandates. The bug, lies in dwc_usb3 IP.
Yeah, but what is wrong about to queue bMaxPacketSize0 in this case and
check if the Host is really going to send the length the gadget is
expecting?
Sebastian
--
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
