Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
To:     Greg KH <gregkh@linuxfoundation.org>,
        Martin Kepplinger <martin.kepplinger@puri.sm>
Cc:     mathias.nyman@intel.com, kernel@puri.sm, linux-usb@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <20220304113057.1477958-1-martin.kepplinger@puri.sm>
 <YiIfZFPl9ZqPBKvj@kroah.com>
From:   Mathias Nyman <mathias.nyman@linux.intel.com>
Subject: Re: [PATCH] usb: xhci: make XHCI_STOP_EP_CMD_TIMEOUT a module
 parameter
Message-ID: <835b3990-43a6-a985-81b4-b86bddfe951f@linux.intel.com>
Date:   Mon, 7 Mar 2022 10:49:24 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Firefox/78.0 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <YiIfZFPl9ZqPBKvj@kroah.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 4.3.2022 16.17, Greg KH wrote:
> On Fri, Mar 04, 2022 at 12:30:57PM +0100, Martin Kepplinger wrote:
>> On the Librem 5 imx8mq system we've seen the stop endpoint command
>> time out regularly which results in the hub dying.
>>
>> While on the one hand we see "Port resume timed out, port 1-1: 0xfe3"
>> before this and on the other hand driver-comments suggest that the driver
>> might be able to recover instead of dying here, Sarah seemed to have a
>> workaround for this particulator problem in mind already:
>>
>> Make it a module parameter. So while it might not be the root cause for
>> the problem, do this to give users a workaround.
> 
> This is not the 1990's, sorry, please do not add new module parameters.
> They modify code, when you want to modify an individual device.
> 

Agree, I think we really need to find the rootcause here.

There's a known problem with this stop endpoint timeout timer.

For all other commands we start the timer when the controller starts processing the
command, but the stop endpoint timer is started immediately when command is queued.
So it might timeout if some other commend before it failed.

I have a patchseries for this. It's still work in progress but should be testable.
Pushed to a branch named stop_endpoint_fixes

git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git stop_endpoint_fixes
https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=stop_endpoint_fixes

Can you try it out and see if it helps?

Thanks
-Mathias