Re: dwc3: unusual handling of setup requests with wLength == 0

[Thinh Nguyen]

Hi,

On Fri, Aug 18, 2023, Andrey Konovalov wrote:
> Hi Alan and Thinh,
> 
> I have been testing Raw Gadget with the dwc3 UDC driver and stumbled
> upon an issue related to how dwc3 handles setup requests with wLength
> == 0.
> 
> When running a simple Raw Gadget-based keyboard emulator [1],
> everything works as expected until the point when the host sends a
> SET_CONFIGURATION request, which has wLength == 0.
> 
> For setup requests with wLength != 0, just like the other UDC drivers
> I tested, dwc3 calls the gadget driver's ->setup() callback and then
> waits until the gadget driver queues an URB to EP0 as a response.

For the lack of better term, can we use "request" or "usb_request"
instead of URB for gadget side, I get confused with the host side
whenever we mention URB.

> 
> However, for a setup request with wLength == 0, dwc3 does not wait
> until the gadget driver queues an URB to ack the transfer. It appears
> that dwc3 just acks the request internally and then proceeds with
> calling the ->setup() callback for the next request received from the

It depends on the bRequest. It should not proceed to ->setup() unless
the gadget driver already setups the request for it.

> host. This confuses Raw Gadget, as it does not expect to get a new
> ->setup() call before it explicitly acks the previous one by queuing
> an URB. As a result, the emulation fails.

If the host intent is to send a 3-stage control request with a 0-length
data packet, the gadget driver needs to return USB_GADGET_DELAYED_STATUS
to prepare a 0-length request. For SET_CONFIGURATION, we don't expect
a data phase, why should the gadget driver queue a 0-length data?

> 
> I suspect this issue has not been observed with other gadget drivers,
> as they queue an URB immediately after receiving a ->setup() call:
> dwc3 appears to somehow correctly handle this internally even though
> it acks the transfer by itself. But the timings with Raw Gadget are
> different, as it requires userspace to ack the transfer. Sometimes
> though, the Raw Gadget-based emulator also manages to queue an URB
> before the next request is received from the host and the enumeration
> continues properly (until the next request with wLength == 0).
> 
> What do you think would be the best approach to deal with this?

The communication should be clearly defined. That is, the dwc3 needs to
know if this is a 3-stage or 2-stage control transfer. It knows about
the standard requests, but not the vendor/non-standard ones. If the raw
gadget defined some unknown OUT request, it needs to tell dwc3 whether
it should expect the data stage or not.

BR,
Thinh

> 
> Can this be considered a bug in dwc3 that should be fixed? There's a
> seemingly related comment in dwc3 code [2], but I'm not familiar
> enough with its internals to understand whether this is what leads to
> the issue I'm seeing.
> 
> Or should I adapt Raw Gadget to handle this unusual dwc3 behavior?
> This might be tricky to do, as I cannot change the existing userspace
> API.
> 
> On a side note, as an experiment, I tried returning
> USB_GADGET_DELAYED_STATUS from the Raw Gadget's ->setup() callback if
> the UDC driver calls it too early: some UDC drivers, including dwc3,
> appear to contain a special handling for this return value. However,
> that didn't work out. Perhaps, I misunderstand the meaning of this
> value.
> 
> Thank you!
> 
> [1] https://urldefense.com/v3/__https://github.com/xairy/raw-gadget/blob/master/examples/keyboard.c__;!!A4F2R9G_pg!fsksN9-eooWS7Uui8MfCcBkff8awG2ovwl6UaPuJ4_v50Ny5s-WQ4YuQht1ACRl6eDYZ4o-gkVlF6l82C8UT58e7$ 
> [2] https://urldefense.com/v3/__https://elixir.bootlin.com/linux/v6.5-rc6/source/drivers/usb/dwc3/ep0.c*L145__;Iw!!A4F2R9G_pg!fsksN9-eooWS7Uui8MfCcBkff8awG2ovwl6UaPuJ4_v50Ny5s-WQ4YuQht1ACRl6eDYZ4o-gkVlF6l82C6Q3wZfW$