From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750907AbdGZFTd (ORCPT ); Wed, 26 Jul 2017 01:19:33 -0400 Received: from mga06.intel.com ([134.134.136.31]:31566 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750710AbdGZFTc (ORCPT ); Wed, 26 Jul 2017 01:19:32 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,413,1496127600"; d="scan'208";a="1155447832" Subject: Re: [PATCH 1/1] usb: xhci: Handle USB transaction error on address command To: "Xing, Zhengjun" , Mathias Nyman References: <1500959389-19099-1-git-send-email-baolu.lu@linux.intel.com> Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org From: Lu Baolu Message-ID: <59782657.5050809@linux.intel.com> Date: Wed, 26 Jul 2017 13:19:19 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 07/26/2017 01:11 PM, Xing, Zhengjun wrote: > > > On 7/25/2017 1:09 PM, Lu Baolu wrote: >> Xhci driver handles USB transaction errors on transfer events, >> but transaction errors are possible on address device command >> completion events as well. >> >> The xHCI specification (section 4.6.5) says: A USB Transaction >> Error Completion Code for an Address Device Command may be due >> to a Stall response from a device. Software should issue a Disable >> Slot Command for the Device Slot then an Enable Slot Command to >> recover from this error. >> >> This patch handles USB transaction errors on address command >> completion events. The related discussion threads can be found >> through below links. >> >> http://marc.info/?l=linux-usb&m=149362010728921&w=2 >> http://marc.info/?l=linux-usb&m=149252752825755&w=2 >> >> Suggested-by: Mathias Nyman >> Signed-off-by: Lu Baolu >> --- >> drivers/usb/host/xhci.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c >> index b2ff1ff..9cc56cd 100644 >> --- a/drivers/usb/host/xhci.c >> +++ b/drivers/usb/host/xhci.c >> @@ -3836,6 +3836,12 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct usb_device *udev, >> ret = -EINVAL; >> break; >> case COMP_USB_TRANSACTION_ERROR: >> + xhci_free_virt_device(xhci, udev->slot_id); > > In xhci_free_virt_device xhci->devs[slot_id]will be set to NULL. > >> + ret = xhci_disable_slot(xhci, command, udev->slot_id); > > When xhci_disable_slot check xhci->devs[slot_id] is NULL, just return -EINVAL, the slot will not be disabled. Yes, really. I don't think xhci_disable_slot() should return directly when the virtual device structure is not allocated. This function is also used to issue a disable slot command when the virtual device data allocation fails in xhci_alloc_dev(). I will develop v2 patch with a fix for xhci_disable_slot(). Best regards, Lu Baolu