mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2025-03-06 04:07:01 +07:00
f3088e6a12
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>
|
||
|---|---|---|
| .. | ||
| atm | ||
| c67x00 | ||
| cdns3 | ||
| chipidea | ||
| class | ||
| common | ||
| core | ||
| dwc2 | ||
| dwc3 | ||
| early | ||
| gadget | ||
| host | ||
| image | ||
| isp1760 | ||
| misc | ||
| mon | ||
| mtu3 | ||
| musb | ||
| phy | ||
| renesas_usbhs | ||
| roles | ||
| serial | ||
| storage | ||
| typec | ||
| usbip | ||
| Kconfig | ||
| Makefile | ||
| usb-skeleton.c | ||