From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com ([134.134.136.65]:11026 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751929AbdCHJhI (ORCPT ); Wed, 8 Mar 2017 04:37:08 -0500 From: Felipe Balbi To: Thinh Nguyen Cc: Linux USB , "stable\@vger.kernel.org" , John Youn Subject: RE: [PATCH] usb: dwc3: gadget: skip Set/Clear Halt when invalid In-Reply-To: <87vark15hc.fsf@linux.intel.com> References: <20170119114034.15184-1-felipe.balbi@linux.intel.com> <30102591E157244384E984126FC3CB4F2FF567F3@US01WEMBX2.internal.synopsys.com> <87vark15hc.fsf@linux.intel.com> Date: Wed, 08 Mar 2017 11:33:10 +0200 Message-ID: <87shmo15bd.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: stable-owner@vger.kernel.org List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Felipe Balbi writes: > Hi Thinh, > > Thinh Nguyen writes: >>> drivers/usb/dwc3/gadget.c | 5 +++++ >>> 1 file changed, 5 insertions(+) >>>=20 >>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c >>> index 6faf484e5dfc..0a664d8eba3f 100644 >>> --- a/drivers/usb/dwc3/gadget.c >>> +++ b/drivers/usb/dwc3/gadget.c >>> @@ -1379,6 +1379,9 @@ int __dwc3_gadget_ep_set_halt(struct dwc3_ep >>> *dep, int value, int protocol) >>> unsigned transfer_in_flight; >>> unsigned started; >>>=20 >>> + if (dep->flags & DWC3_EP_STALL) >>> + return 0; >>> + >>> if (dep->number > 1) >>> trb =3D dwc3_ep_prev_trb(dep, dep->trb_enqueue); >>> else >>> @@ -1400,6 +1403,8 @@ int __dwc3_gadget_ep_set_halt(struct dwc3_ep >>> *dep, int value, int protocol) >>> else >>> dep->flags |=3D DWC3_EP_STALL; >>> } else { >>> + if (!(dep->flags & DWC3_EP_STALL)) >>> + return 0; >>>=20 >>> ret =3D dwc3_send_clear_stall_ep_cmd(dep); >>> if (ret) >>> -- >>> 2.11.0.295.gd7dffce1ce >>>=20 >>> -- >> >> I encounter an issue when I test mainline with USB 3 CV MSC test and >> bisected to this patch. >> >> Tester: USB 3 CV test (v2.1.3.0). >> Function Driver: f_mass_storage >> Reproducibility: always=20 >> >> The failure occurs under MSC Error Recovery Test (TD 1.4). >> >> Failure from the test sequence as follow (MSC compliance test spec) : >> 1. Place the device in the desired starting state. >> 2. Issue a Case 9 CBW (see Table 2) but with invalid signature of 0xDEAD= BEEF. >> 3. Issue several In requests to the Bulk-Only Data Interface Bulk In end= point. Verify a >> STALL handshake is returned. If STALL handshake is not returned, skip to= step 11. >> 4. Issue a Get_Status(endpoint) request targeting the Bulk-Only Data Int= erface bulk In >> endpoint. Verify that it completes normally, reports endpoint halt statu= s. >> >> ***After this point the device idles for 10 seconds and resets. *** >> >> Test fails. > > I've been looking at this and based on sniffer and dwc3 tracepoints, it > seems like dwc3 is behaving properly. The real issue seems to be that > g_mass_storage isn't queueing a new request to IN endpoint. > > I'll continue debugging this and try to find a solution that doesn't > involve reverting $subject. oh no, wait. ep2out misses XferInProgress: file-storage-1592 [000] d..1 152.809922: dwc3_ep_queue: ep2out: req = ffff88003cd6ee40 length 0/512 zsI =3D=3D> -115 file-storage-1592 [000] d..1 152.809931: dwc3_prepare_trb: ep2out: 3= /8 trb ffff88003a196050 buf 000000002d5e4000 size 512 ctrl 00000819 (HlcS:s= C:normal) file-storage-1592 [000] d..1 152.809942: dwc3_gadget_ep_cmd: ep2out:= cmd 'Update Transfer' [262151] params 00000000 00000000 00000000 --> statu= s: Successful file-storage-1592 [000] .... 152.809951: usb_ep_queue: ep2out: lengt= h 0/512 sgs 0/0 stream 0 zsI status -115 --> 0 irq/34-dwc3-1593 [001] d..1 152.810212: dwc3_event: event (0000c040= ): ep0out: Transfer Complete [Setup Phase] irq/34-dwc3-1593 [001] d..1 152.810218: dwc3_ctrl_req: bRequestType= 02 bRequest 01 wValue 0000 wIndex 0002 wLength 0 irq/34-dwc3-1593 [001] d..1 152.810228: __dwc3_gadget_ep_set_halt: = ep2out: NOT stalled Sniffer shows me this completing, but I don't see IRQ for this. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEElLzh7wn96CXwjh2IzL64meEamQYFAli/z9YACgkQzL64meEa mQbCJhAAxhV5iXmIBM3kehDbVvrIj+tN81t4OIpJ+F2qKDjmRxQOeOeWLajgxlIy bMUpfK4B3s6y7P7ENRahygJbMqx4g1V4b3cOmnZKyjOUwVoDacpidyJxU7TDzPFx 0o16moXu7IgKrv/enpC+IfGmPbYs3v474FigJVqM1Z8rbZQEHJ3CAkRUWHQbmpwC rXmjfMwkf7wpxWmf1T0azmaJxILvrxmpkVX8LACmjE+ffBRxpnGDU4uMxv5vq2kj hOUOQRArLWUl9R4h8rJDRBmiG3hl8vFLeukpUSvW5OMIn3vy8fQLHlIoSDMnFP1J wZGLIPEJ+FW0WD6K19aqO4PJo+GY3mAEyd+9EIMuRJiwZ3LL3r0yf7rkaJvp0zgz Wk0La8ao9DJMyUW8E3tHWeEIkyfJe4S/nUzko6fDaZbMkvGvjXka8dvG8Rd+LWfe AbRHTa2mQxaZ4BLRCn65cjAn7iLsxxqpirfFOZhwY+gEHP2h9qnFPQHkAoJhqNTE 2LH/xET2Ffwqfag0e1wWrSR0egivupu7P5/8fC1WWgzawI3vrjPHhbfzwz24Fguh 4setJMsDeP2GNhwJJHWkcfct/QywQw/8O/xaanTbmnJnYCpykrwyyOz/5mfvG9NQ NUhJcN9/ZY57h/da+lQW9nqIG/HPnnCGPswSjkgZFXjYWx92U84= =6Pwo -----END PGP SIGNATURE----- --=-=-=--