Commit e610257e authored by Jerry Zhang's avatar Jerry Zhang Committed by Felipe Balbi

usb: gadget: f_fs: Only return delayed status when len is 0

Commit 1b9ba000 ("Allow function drivers to pause control
transfers") states that USB_GADGET_DELAYED_STATUS is only
supported if data phase is 0 bytes.

It seems that when the length is not 0 bytes, there is no
need to explicitly delay the data stage since the transfer
is not completed until the user responds. However, when the
length is 0, there is no data stage and the transfer is
finished once setup() returns, hence there is a need to
explicitly delay completion.

This manifests as the following bugs:

Prior to 946ef68a ('Let setup() return
USB_GADGET_DELAYED_STATUS'), when setup is 0 bytes, ffs
would require user to queue a 0 byte request in order to
clear setup state. However, that 0 byte request was actually
not needed and would hang and cause errors in other setup
requests.

After the above commit, 0 byte setups work since the gadget
now accepts empty queues to ep0 to clear the delay, but all
other setups hang.

Fixes: 946ef68a ("Let setup() return USB_GADGET_DELAYED_STATUS")
Signed-off-by: default avatarJerry Zhang <zhangjerry@google.com>
Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
parent d7af78b9
...@@ -3263,7 +3263,7 @@ static int ffs_func_setup(struct usb_function *f, ...@@ -3263,7 +3263,7 @@ static int ffs_func_setup(struct usb_function *f,
__ffs_event_add(ffs, FUNCTIONFS_SETUP); __ffs_event_add(ffs, FUNCTIONFS_SETUP);
spin_unlock_irqrestore(&ffs->ev.waitq.lock, flags); spin_unlock_irqrestore(&ffs->ev.waitq.lock, flags);
return USB_GADGET_DELAYED_STATUS; return creq->wLength == 0 ? USB_GADGET_DELAYED_STATUS : 0;
} }
static bool ffs_func_req_match(struct usb_function *f, static bool ffs_func_req_match(struct usb_function *f,
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment