Den 02.06.2020 13.46, skrev Noralf Trønnes: > > > Den 02.06.2020 04.32, skrev Alan Stern: >> On Tue, Jun 02, 2020 at 12:12:07AM +0000, Peter Stuge wrote: >> >> ... >> >>> The way I read composite_setup() after try_fun_setup: it calls f->setup() >>> when available, and that can return < 0 to stall. >>> >>> I expect that composite_setup() and thus f->setup() run when the >>> SETUP packet has arrived, thus before the data packet arrives, and if >>> composite_setup() stalls then the device/function should never see the >>> data packet. >>> >>> For an OUT transaction I think the host controller might still send >>> the DATA packet, but the device controllers that I know don't make it >>> visible to the application in that case. >> >> ... >> >> Are you guys interested in comments from other people who know more >> about the kernel and how it works with USB? > > Absolutely, I want something thats works well in the kernel and doesn't > look odd to kernel USB people. > >> Your messages have been >> far too long to go into in any detail, but I will address this one issue. >> >> The USB protocol forbids a device from sending a STALL response to a >> SETUP packet. The only valid response is ACK. Thus, there is no way >> to prevent the host from sending its DATA packet for a control-OUT >> transfer. >> >> A gadget driver can STALL in response to a control-OUT data packet, >> but only before it has seen the packet. Once the driver knows what >> the data packet contains, the gadget API doesn't provide any way to >> STALL the status stage. There has been a proposal to change the API >> to make this possible, but so far it hasn't gone forward. >> > > This confirms what I have seen in the kernel and the reason I added a > status request so I can know the result of the operation the device has > performed. > > I have a problem that I've encountered with this status request. > In my first version the gadget would usb_ep_queue() the status value > when the operation was done and as long as this happended within the > host timeout (5s) everything worked fine. > > Then I hit a 10s timeout in the gadget when performing a display modeset > operation (wait on missing vblank). The result of this was that the host > timed out and moved on. The gadget however didn't know that the host > gave up, so it queued up the status value. The result of this was that > all further requests from the host would time out. > Do you know a solution to this? > My work around is to just poll on the status request, which returns a > value immediately, until there's a result. The udc driver I use is dwc2. > I have now tried this on a Beaglebone Black (musb udc driver) and it works just fine there (it displays an error message on the next request). So it has to be a dwc2 driver problem. I will try and chase down this problem when I get the time. This means I don't need this status request polling in my host driver. Noralf.
