On Sat, Jun 15, 2024 at 4:12 AM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > Yeah, this is a known weakness of the Gadget API. There's no way to do > it at present. Ack. > usbfs allows the user to send a complete transfer, not a partial one > (i.e., just the SETUP transaction). Besides, it's not possible for a > device to stall a SETUP packet -- the USB-2.0 spec requires devices to > respond to SETUP with ACK every time (section 8.5.3) -- so this approach > won't solve the problem anyway. And even if it did, you'd still have to > handle the situation where the proxy device accepts the SETUP packet and > the data but then stalls during the Status stage of the transfer. Ah, so dealing with this on the usbfs side is impossible. > There has been a patch posted to support UDC drivers that don't > automatically acknowledge non-zero-length control-OUT transfers. But > the patch hasn't been merged, and even if it were, all the existing UDC > drivers would still need to be updated. This series below is the one you're referring to, right? https://lore.kernel.org/linux-kernel/20190124030228.19840-1-paul.elder@xxxxxxxxxxxxxxxx/ Do you know why it wasn't merged? (CC Paul). There are no comments on the latest version I managed to find. Also, just to check my understanding: with that series in place and assuming the UDC drivers are updated, a gadget driver would need to first do usb_ep_queue with the proper length and explicit_status == true to get the data for the control OUT request, and then either do usb_ep_queue again with length 0 to ack or do usb_ep_set_halt to stall? Thank you!
