From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtprelay4.synopsys.com ([198.182.47.9]:36730 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752042AbdDKDV5 (ORCPT ); Mon, 10 Apr 2017 23:21:57 -0400 Subject: Re: [PATCH 2/3] usb: dwc3: gadget: Fix early exit in set/clear ep halt To: Felipe Balbi , Thinh Nguyen , CC: John Youn , References: <8760icg2zx.fsf@linux.intel.com> <8737dgg2w8.fsf@linux.intel.com> From: Thinh Nguyen Message-ID: <20e1cce1-d3b7-e126-88aa-b2c823cc4b8b@synopsys.com> Date: Mon, 10 Apr 2017 20:21:55 -0700 MIME-Version: 1.0 In-Reply-To: <8737dgg2w8.fsf@linux.intel.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org List-ID: Hi Felipe, On 4/10/2017 12:04 AM, Felipe Balbi wrote: > > Hi again, > > 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 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 > > 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. > This patch is for the regression we have. Can you provide more information for the macOS? I'm not sure if this is the case for macOS, but maybe there is still pending transfer when it tries to send the request? (There shouldn't be any before issuing ClearStall command). Do you see Starttransfer command after clear transfer? BR, Thinh Nguyen