summaryrefslogtreecommitdiff
path: root/drivers/firewire/sbp2.c
diff options
context:
space:
mode:
authorMichael Grzeschik <m.grzeschik@pengutronix.de>2012-09-12 14:58:04 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2012-09-12 10:58:38 -0700
commitdb89960e50f45274c07dc60926b5a49489b8a7a0 (patch)
tree127e17426a88110ab2585ba18570647047a3df20 /drivers/firewire/sbp2.c
parentad6b1b97fe8504957d017cd6e4168cac8903d3f3 (diff)
usb: chipidea: udc: don't stall endpoint if request list is empty in isr_tr_complete_low
When attaching an imx28 or imx53 in USB gadget mode to a Windows host and starting a rndis connection we see this message every 4-10 seconds: g_ether gadget: high speed config #2: RNDIS Analysis shows that each time this message is printed, the rndis connection is re-establish due to a reset because of a stalled endpoint (ep 0, dir 1). The endpoint is stalled because the reqeust complete bit on that endpoint is set, but in isr_tr_complete_low() the endpoint request list (mEp->qh.queue) is empty. This patch removed this check, because the code doesn't take the following situation into account: The loop over all endpoints in isr_tr_complete_handler() will call ep_nuke() on both ep0/dir0 and ep/dir1 in the first loop. Pending reqeusts will be flushed and completed here. There seems to be a race condition, the request is nuked, but the request complete bit will be set, too. The subsequent check (in ep0/dir1's loop cycle) for endpoint request list (mEp->qh.queue) empty will fail. Both other mainline chipidea drivers (mv_udc_core.c and fsl_udc_core.c) don't have this check. Cc: stable <stable@vger.kernel.org> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/firewire/sbp2.c')
0 files changed, 0 insertions, 0 deletions