summaryrefslogtreecommitdiff
path: root/arch/avr32
diff options
context:
space:
mode:
authorKevin Cernekee <cernekee@gmail.com>2012-08-09 11:23:52 +0300
committerFelipe Balbi <balbi@ti.com>2012-08-23 11:04:19 +0300
commit974e9323deefbab923d7aa8f0e4bcf9066c2ec97 (patch)
tree8498d854cb728eddb03b1cf71611e2da6e2c70dc /arch/avr32
parentd3091cfff73ce44c6b0cb61b25074f0ac648604f (diff)
usb: gadget: udc-core: Race between disconnect/unbind and setup
usb_gadget_remove_driver() runs through a four-step sequence to shut down the gadget driver. For the case of a composite gadget + at91 UDC, this would look like: udc->driver->disconnect(udc->gadget); // composite_disconnect() usb_gadget_disconnect(udc->gadget); // at91_pullup(gadget, 0) udc->driver->unbind(udc->gadget); // composite_unbind() usb_gadget_udc_stop(udc->gadget, udc->driver); // at91_stop() The UDC driver can receive SETUP packets from the host up until the point when usb_gadget_disconnect() returns. On rare occasions, the gadget driver may see this sequence: udc->driver->disconnect(udc->gadget); // composite_disconnect() udc->driver->setup(udc->gadget, &ctrl); // composite_setup() udc->driver->unbind(udc->gadget); // composite_unbind() Some gadget drivers, such as composite, assume this will never happen and crash as a result. The fix is to quiesce the UDC hardware (via usb_gadget_disconnect) before running the gadget driver through the disconnect/unbind sequence. Reviewed-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Kevin Cernekee <cernekee@gmail.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
Diffstat (limited to 'arch/avr32')
0 files changed, 0 insertions, 0 deletions