diff options
author | Chunfeng Yun <chunfeng.yun@mediatek.com> | 2019-10-09 17:05:00 +0800 |
---|---|---|
committer | Felipe Balbi <felipe.balbi@linux.intel.com> | 2019-10-23 09:26:29 +0300 |
commit | f3088e6a12fe516d89cd431877123041235fcd74 (patch) | |
tree | f7cec4ae29c43245265d863837a55753153d3ef2 /drivers/usb/cdns3/cdns3-ti.c | |
parent | 49db427232fe2c357d23a2d62e2db1d431f95051 (diff) |
usb: mtu3: fix race condition about delayed_status
usb_composite_setup_continue() may be called before composite_setup()
return USB_GADGET_DELAYED_STATUS, then the controller driver will
delay status stage after composite_setup() finish, but the class driver
don't ask the controller to continue delayed status anymore, this will
cause control transfer timeout.
happens when use mass storage (also enabled other class driver):
cpu1: cpu2
handle_setup(SET_CONFIG) //gadget driver
unlock (g->lock)
gadget_driver->setup()
composite_setup()
lock(cdev->lock)
set_config()
fsg_set_alt() // maybe some times due to many class are enabled
raise FSG_STATE_CONFIG_CHANGE
return USB_GADGET_DELAYED_STATUS
handle_exception()
usb_composite_setup_continue()
unlock(cdev->lock)
lock(cdev->lock)
ep0_queue()
lock (g->lock)
//no delayed status, nothing todo
unlock (g->lock)
unlock(cdev->lock)
return USB_GADGET_DELAYED_STATUS // composite_setup
lock (g->lock)
get USB_GADGET_DELAYED_STATUS //handle_setup [1]
Try to fix the race condition as following:
After the driver gets USB_GADGET_DELAYED_STATUS at [1], if we find
there is a usb_request in ep0 request list, it means composite already
asked us to continue delayed status by usb_composite_setup_continue(),
so we skip request about delayed_status by composite_setup() and still
do status stage.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Diffstat (limited to 'drivers/usb/cdns3/cdns3-ti.c')
0 files changed, 0 insertions, 0 deletions