From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932248AbcISKXH (ORCPT ); Mon, 19 Sep 2016 06:23:07 -0400 Received: from mail-lf0-f49.google.com ([209.85.215.49]:33267 "EHLO mail-lf0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758403AbcISKWs (ORCPT ); Mon, 19 Sep 2016 06:22:48 -0400 Subject: Re: [RFC PATCH] xhci: do not halt the secondary HCD To: Joel Stanley , linux-usb@vger.kernel.org References: <20160919063545.2055-1-joel@jms.id.au> Cc: linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org From: Sergei Shtylyov Message-ID: Date: Mon, 19 Sep 2016 13:22:46 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160919063545.2055-1-joel@jms.id.au> 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 Hello. On 9/19/2016 9:35 AM, 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. > > Signed-off-by: Joel Stanley > --- > drivers/usb/host/xhci.c | 20 +++++++++++++++----- > 1 file changed, 15 insertions(+), 5 deletions(-) > > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c > index adc169d2fd76..ec92a843325b 100644 > --- a/drivers/usb/host/xhci.c > +++ b/drivers/usb/host/xhci.c > @@ -682,6 +682,21 @@ void xhci_stop(struct usb_hcd *hcd) > > mutex_lock(&xhci->mutex); > > + /* > + * 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. > + */ > + if (!usb_hcd_is_primary_hcd(hcd)) { > + /* The shared_hcd is going to be deallocated shortly (the USB > + * core only calls this function when allocation fails in > + * usb_add_hcd(), or usb_remove_hcd() is called). So we need > + * to unset xHCI's pointer. */ Please format this comment the same way as the comment above it. > + xhci->shared_hcd = NULL; > + mutex_unlock(&xhci->mutex); > + return; > + } > + > if (!(xhci->xhc_state & XHCI_STATE_HALTED)) { > spin_lock_irq(&xhci->lock); > [...] MBR, Sergei