From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com ([134.134.136.100]:16142 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752530AbdDJHCC (ORCPT ); Mon, 10 Apr 2017 03:02:02 -0400 From: Felipe Balbi To: Thinh Nguyen , linux-usb@vger.kernel.org Cc: John Youn , Thinh Nguyen , stable@vger.kernel.org Subject: Re: [PATCH 2/3] usb: dwc3: gadget: Fix early exit in set/clear ep halt In-Reply-To: References: Date: Mon, 10 Apr 2017 10:01:38 +0300 Message-ID: <8760icg2zx.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 Hi, Thinh Nguyen writes: > This patch fixes a commit that causes a hang from device waiting for > data with the wrong sequence number. The commit ffb80fc672c3 ("usb: > dwc3: gadget: skip Set/Clear Halt when invalid") adds a check to return > early depending on DWC3_EP_STALL is set or not, prevent sending the ep > halt command to HW endpoint to do CLEAR_FEATURE(ENDPOINT_HALT) request. > This was to workaround the issue for macOS where the device hangs from > sending DWC3 clear stall command. > > In USB 3.1 spec, 9.4.5, CLEAR_FEATURE(ENDPOINT_HALT) request always > results in the data sequence being reinitialized to zero regardless > whether the endpoint has been halted or not. Some device class depends > on this feature for its protocol. For instance, in mass storage class, > there is MSC reset protocol that does CLEAR_FEATURE(ENDPOINT_HALT) on > bulk endpoints. This protocol reinitializes the data sequence and > ensures that whatever pending data requested from previous CBW will be > reset. Otherwise this will cause a hang as the device can wait for the > data with the wrong sequence number from the previous CBW. We found this > failure in USB CV: MSC Error Recovery Test with f_mass_storage. > > This patch fixes this issue by checking to see whether the set/halt ep > call is a protocol call before early exit to make sure that set/clear > halt endpoint command can go through if it is a device class protocol. > > Fixes: ffb80fc672c3 ("usb: dwc3: gadget: skip Set/Clear Halt when invalid= ") > Signed-off-by: Thinh Nguyen this will regress the macOS case I wrote that commit for. We need to FIRST figure out why ClearStall command times out. Have you done that? Do you have a testcase which constantly issues ClearFeature(ENDPOINT_HALT) to a single endpoint and can verify that it doesn't time out? Why does it timeout on macOS? =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEElLzh7wn96CXwjh2IzL64meEamQYFAljrLdIACgkQzL64meEa mQYYsg/+KWBSq9knoDvf/wfASiWUyTbee1Oxkhtoha/eRfwces43MlecTnZrPdVC FQQFf56GlYCgB8qXre7rWDRqyqPhWvbtZx59oFB4NSABa9pVDa6sUt98lYZ4h85N z6h/FE31pTnNRbwmsSoZLzP2NkwYNJ5VwMZPweZdAWkJejIQCkcBf7B2eHKgVkYW aqx1l7rP/1cd2jllYblMDmcf30WSyAHuXTibUzd97tQ4CzE711SjKvYUcJLSTc75 cvU2RhTjQua5m5gMhnVT8VCSxS7ASieaSg1MyTIhJBioMPU4aD8cGWvece7m9Egv 20Cid/U9hal+KU3QnUlkXoBsn/scj8WCPiUrzsHaLqm0K38ChiPe2Ir/3fHctnGW p0nJgBuYun40kyG88JwjNDZ8lF4SjspEiz1Ux1qiAcKAlzty95XetGw3gjtJKoFP aJGOgqsBVtfltRAw+hALc3UST94oHGd/sbsSnN1vTicbm4QOJ3uI/mP7RiFdtoof Kd19mygmPJ4WABTfyaj3xYNqHXJuGBziFkcRkV3Ljer2SPBGfGanW9OxF6UEZqXq gqJietkrOK9UDfVBPBOloONcIeyqKmcCFOHfMePOjF2db65cmeZ6mRmBgs6yPzm7 kICfVT0C+bo9CO4ERe/lqB/MLpDyIhcSPc5VTiUWYZLJ9PB5ao8= =NYut -----END PGP SIGNATURE----- --=-=-=--