On Fri, Aug 25, 2023 at 03:36:36AM +0200, Andrey Konovalov wrote: > So to summarize the issue wrt the 0-length requests: > > 1. UDC drivers must always delay the status stage for 0-length > requests until the gadget driver queues an empty request. Any request, not necessarily empty (although it should be). The request queued by the gadget driver _is_ the Status stage response; in this situation the UDC driver doesn't create one automatically. > 2. Many UDC drivers do not do this, and only delay the status stage > when USB_GADGET_DELAYED_STATUS is returned from ->setup(). Some > drivers also assume that only a SET_CONFIGURATION request can be > delayed. > > 3. All such UDC drivers should be fixed and USB_GADGET_DELAYED_STATUS > should be contained within the composite framework. > > 4. Fixing all such UDC drivers is a non-trivial amount of work, but > this is the goal to strive towards. > > Alan, would it be acceptable if I add custom handling of > USB_GADGET_DELAYED_STATUS to Raw Gadget in the meantime? It would be Sure. It's your driver; do whatever you want with it. :-) > great to keep it at least somewhat working with dwc3. I can also do it > for GadgetFS, if you think it's a good idea. I suspect gadgetfs doesn't need it. But go ahead and look through the code to check for yourself; I might be wrong. > I can also add some clarifying comments for USB_GADGET_DELAYED_STATUS > and ->setup() to hopefully avoid having new UDC drivers being added > with the same issue (e.g. cdns2 and renesas_usbf with the same issue > were added just recently). Good idea, although mistakes like this tend to propagate more through copy-and-paste than by failures of documentation. > Maybe it's also a good idea to add a checkpatch.pl check for using > USB_GADGET_DELAYED_STATUS in UDC drivers. Or maybe ask Greg to keep an > eye out for this? I wouldn't try to modify checkpatch.pl. Alan Stern
