From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752519AbdHSIZt (ORCPT ); Sat, 19 Aug 2017 04:25:49 -0400 Received: from mga11.intel.com ([192.55.52.93]:20819 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751990AbdHSIZp (ORCPT ); Sat, 19 Aug 2017 04:25:45 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,396,1498546800"; d="scan'208";a="120638656" Subject: Re: [PATCH v3 5/5] usb: xhci: Handle USB transaction error on address command To: Mathias Nyman References: <1502419296-8212-1-git-send-email-baolu.lu@linux.intel.com> <1502419296-8212-6-git-send-email-baolu.lu@linux.intel.com> <5992DB45.80803@linux.intel.com> <5993AAD8.4060106@linux.intel.com> <5996EC36.5020609@linux.intel.com> Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, zhengjun.xing@linux.intel.com From: Lu Baolu Message-ID: <5997F5FD.1080502@linux.intel.com> Date: Sat, 19 Aug 2017 16:25:33 +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: <5996EC36.5020609@linux.intel.com> 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 08/18/2017 09:31 PM, Mathias Nyman wrote: > On 16.08.2017 05:15, Lu Baolu wrote: >> Hi, >> >> On 08/15/2017 07:30 PM, Mathias Nyman wrote: >>> On 11.08.2017 05:41, 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 | 5 +++++ >>>> 1 file changed, 5 insertions(+) >>>> >>>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c >>>> index d6b728d..95780f8 100644 >>>> --- a/drivers/usb/host/xhci.c >>>> +++ b/drivers/usb/host/xhci.c >>>> @@ -3822,6 +3822,11 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct usb_device *udev, >>>> break; >>>> case COMP_USB_TRANSACTION_ERROR: >>>> dev_warn(&udev->dev, "Device not responding to setup %s.\n", act); >>>> + >>>> + ret = xhci_disable_slot(xhci, udev->slot_id); >>>> + if (!ret) >>>> + xhci_alloc_dev(hcd, udev); >>> >>> Might be a xhci->mutex locking issue here, >>> both xhci_setup_device() and xhci_alloc_dev() take xhci->mutex >>> >> >> I will apply xhci->mutex in this patch for code consistency, but I think >> we can drop xhci->mutex (in a separated patch) anyway. >> >> xhci->mutex was introduced to protect two race sources of xhci->slot_id >> and xhci->addr_dev by below commit: >> >> commit a00918d0521df1c7a2ec9143142a3ea998c8526d >> usb: host: xhci: add mutex for non-thread-safe data >> >> >> c2d3d49 usb: xhci: move slot_id from xhci_hcd to xhci_command structure >> 87e44f2 usb: xhci: remove the use of xhci->addr_dev >> >> So we don't need xhci->mutex any more. I will try to do this in a separated >> patch with more tests. For now, I will add xhci->mutex for code consistency. > > Fixing xhci->mutex sounds like a good idea, and you are right, it's no longer > needed for slot_id or addr_dev. > But it's use was extended to protect xhci_stop() and xhci_setup_device() > from racing at fast xhci host hotplug/removes in this patch. > > commit 85ac90f8953a58f6a057b727bc9db97721e3fb8e > Author: Roger Quadros > Date: Mon Sep 21 17:46:12 2015 +0300 > > usb: xhci: lock mutex on xhci_stop > > Else it races with xhci_setup_device > > But I think it's safe to remove xhci->mutex from xhci_alloc_dev() > > There's no huurry with the patch 5/5 so would be nice to get that mutex > cleaned up before. Okay. Best regards, Lu Baolu