From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932383AbcITI07 (ORCPT ); Tue, 20 Sep 2016 04:26:59 -0400 Received: from mga06.intel.com ([134.134.136.31]:23099 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751797AbcITI04 (ORCPT ); Tue, 20 Sep 2016 04:26:56 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,366,1470726000"; d="scan'208";a="763643597" Subject: Re: [RFC PATCH] xhci: do not halt the secondary HCD To: Joel Stanley References: <20160919063545.2055-1-joel@jms.id.au> <57DF969B.8030204@linux.intel.com> Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org, Benjamin Herrenschmidt From: Mathias Nyman Message-ID: <57E0F2CD.2000302@linux.intel.com> Date: Tue, 20 Sep 2016 11:26:53 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 19.09.2016 11:23, Joel Stanley wrote: > Hi Mathias, > > On Mon, Sep 19, 2016 at 4:33 PM, Greg KH wrote: >> On Mon, Sep 19, 2016 at 04:05:45PM +0930, Joel Stanley wrote: >>> We can't halt the secondary HCD, because it's also the primary HCD, >>> which will cause problems if we have devices attached to the primary >>> HCD, like a keyboard. >>> >>> We've been carrying this in our Linux-as-a-bootloader environment for a little >>> while now. The machines all have the same TI TUSB73x0 part, and when we kexec >>> the devices don't come back until a system power cycle. >>> >>> I'd like some advice on an acceptable way to upstream the fix, so that the xhci >>> device survives kexec. >> >> Any reason you didn't cc: Mathias? > > Fat fingers - I missed him when grabbing names from get_maintainers. > Thanks for adding him in. > > On Mon, Sep 19, 2016 at 5:11 PM, Mathias Nyman > wrote: >> What kernel version is this? > > This patch is against 4.4.21. I've tested newer releases but haven't > seen any improvement. > >> As Greg said there are fixes in this area in the 4.8 latest rc kernel. >> >> If that doesn't work then we need to figure out what the real issue is. > > No dice on 4.8-rc7 (without any patches). > > Here's 4.8-rc7 loading: > > [ 3.699524] xhci_hcd 0021:09:00.0: xHCI Host Controller > [ 3.699556] xhci_hcd 0021:09:00.0: new USB bus registered, assigned > bus number 1 > [ 3.699640] xhci_hcd 0021:09:00.0: Using 64-bit DMA iommu bypass > [ 3.699697] xhci_hcd 0021:09:00.0: hcc params 0x0270f06d hci > version 0x96 quirks 0x00000000 > [ 3.700286] hub 1-0:1.0: USB hub found > [ 3.700299] hub 1-0:1.0: 4 ports detected > [ 3.700493] xhci_hcd 0021:09:00.0: xHCI Host Controller > [ 3.700522] xhci_hcd 0021:09:00.0: new USB bus registered, assigned > bus number 2 > [ 3.700552] usb usb2: We don't know the algorithms for LPM for this > host, disabling LPM. > [ 3.700733] hub 2-0:1.0: USB hub found > [ 3.700748] hub 2-0:1.0: 4 ports detected > > Then we kexec into the second kernel. Here's what the second kernel > prints when trying to bring the controller up: > > [ 1.588272] xhci_hcd 0021:09:00.0: xHCI Host Controller > [ 1.588282] xhci_hcd 0021:09:00.0: new USB bus registered, assigned > bus number 1 > [ 1.619279] xhci_hcd 0021:09:00.0: Host not halted after 16000 microseconds. > [ 1.619281] xhci_hcd 0021:09:00.0: can't setup: -110 > [ 1.619447] xhci_hcd 0021:09:00.0: USB bus 1 deregistered > [ 1.619457] xhci_hcd 0021:09:00.0: init 0021:09:00.0 fail, -110 > [ 1.619571] xhci_hcd: probe of 0021:09:00.0 failed with error -110 Quick Googling shows that that TI TUSB 73x0 USB3.0 xHCI host has an issue with halting. Errata says host needs 125us to 1ms between the last control transfer and clearing the run/stop bit. (halting the host) Suggested workaround is to wait at least 2ms before halting the host. See issue #10 in: http://www.ti.com/lit/er/sllz076/sllz076.pdf It might just be that the patch works because it forces halting the host to be done later (secondary hcd -> primary hcd), giving it enough time after the last control transfer. >> a first step. >> >> load primary >> load secondary (starts the xhci controller >> ... >> unload secondary (halts the controller) >> unload primary (free memory) Now thinking about it, it doesn't really make sense to halt the host controller hardware before removing the primary hcd. It will just cause devices under the primary (USB2) to be removed uncleanly. So basically the idea of the workaround makes sense, it just needs to be cleaned up from a workaround to intended behavior. We might also need an additional quirk for TI TUSB 73x0 that adds a msleep() before the xhci_halt, even if it's moved to the last hcd removed. -Mathias