From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com ([134.134.136.31]:49792 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751888AbdDKHgV (ORCPT ); Tue, 11 Apr 2017 03:36:21 -0400 From: Felipe Balbi To: Thinh Nguyen , Thinh Nguyen , linux-usb@vger.kernel.org Cc: John Youn , stable@vger.kernel.org Subject: Re: [PATCH 2/3] usb: dwc3: gadget: Fix early exit in set/clear ep halt In-Reply-To: <20e1cce1-d3b7-e126-88aa-b2c823cc4b8b@synopsys.com> References: <8760icg2zx.fsf@linux.intel.com> <8737dgg2w8.fsf@linux.intel.com> <20e1cce1-d3b7-e126-88aa-b2c823cc4b8b@synopsys.com> Date: Tue, 11 Apr 2017 10:35:56 +0300 Message-ID: <87o9w3cs6b.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: >> Felipe Balbi writes: >>> 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 th= is >>>> 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 inva= lid") >>>> Signed-off-by: Thinh Nguyen >>> >>> this will regress the macOS case I wrote that commit for. We need to >>=20 >> no wait, it won't regress macOS, but we're still left with the problem >> of host and peripheral being able to get DataToggle/SeqN out of sync. >>=20 > > This patch is for the regression we have. Can you provide more=20 > information for the macOS? I'm not sure if this is the case for macOS,=20 I need to find a way to reproduce it again first. When I first reproduced it was with dwc3 running adb and connecting it to a macOS machine. > but maybe there is still pending transfer when it tries to send the=20 > request? (There shouldn't be any before issuing ClearStall command). Do=20 this could be, I don't remember if I checked this or not :-) Really, the best way here, IMHO, would be to re-verify what's going on with macOS and revert my orignal patch since it's, rather clearly, wrong. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEElLzh7wn96CXwjh2IzL64meEamQYFAljsh1wACgkQzL64meEa mQaqrBAAy07tMrGjh3qkhgJ2dUJuHT1WcwTsbrObnA4zhPWYhJL2I13JCVVMryio tLRnmPneJwMvzIi/vEznnfZLvFJ+M9jgXovd3Jeg+wB3Rh/3hYfZpcjMQwEkN2lB BZ5zmV9mL9N7ewHa62YfSZyA/CJESZol3Ld1b0Dj9022/373roblTujzlR8nuYRy dyDi1zHjuPWNGxlFH0q0qGF4kyzwBbiGr/PmVUggFvIDO9gQHVb9PxHdq3IfDHbV CfLl9w03tQy+EhRWVx6ia8WQqzA//HQxmhSPJ+Hww1d3eZXV31lROs/4tEqrJUE3 lkpEIKL3yXiuve+P23gB+hQRouufeGWRdeVpTsvCNMJT8I9Un2g4DA89erstCuJr nC7r0sTqMh4jInShmaGxEEWXd4zKvcoYaxLyhut0aZw1LBvq/2S+rw442AN8CSRC guIRh6JW0UuGAPbdo+hWPcoGVmG0FaoIYI3VZNI4/GJndiacISzfAoIOQJxL9TFh 9+PwC8w1aWoKyJFMNmeRMPb5BWOiV6Y3UDFBC+S80dXoWy+wUn+0eoUZrWJnT2ZL enspUwhspuyn5q4efrTl9oja1t2MXV5luVW7TRULGqPwVmJtx0Mkv/H5s9NeJKsE NrOZAT6HXzSTONjblLh3GKDOp/yNJLGeKGKyR85thb78DB+dB3Q= =VsE7 -----END PGP SIGNATURE----- --=-=-=--