Message-ID: <55DEF1F5.6010907@linux.intel.com>
Date: Thu, 27 Aug 2015 14:18:13 +0300
From: Mathias Nyman <mathias.nyman@linux.intel.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: Roger Quadros <rogerq@ti.com>, mathias.nyman@intel.com
CC: balbi@ti.com, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/5] usb: xhci: Fix breakage on dual-role case
References: <1439894354-6160-1-git-send-email-rogerq@ti.com> <55D57D29.1040702@ti.com>
In-Reply-To: <55D57D29.1040702@ti.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1827
Lines: 52

On 20.08.2015 10:09, Roger Quadros wrote:
> Hi Mathias,

Hi

>
> On 18/08/15 13:39, Roger Quadros wrote:
>> Hi,
>>
>> Plugging and unplugging a USB-OTG adapter with a USB device into a
>> am437x-gp-evm dual-role port (USB1) causes XHCI to malfunction
>> and USB device to be no longer detected after a few iterations.
>>
>> The triggering case is so
>> 1) USB1 in peripheal mode
>> 2) plug OTG adapter with USB device
>> 3) USB1 switches to host mode
>> 4) Detects new USB device
>> 5) unplug OTG adapter
>> 6) OTG core tries to remove host controller while new device
>> is being processed.
>>
>> At 6 some races are observed in the XHCI driver causing it to
>> malfunction. See kernel log at the end of this mail.
>>
>> This series tries to address some of the issues.
>> Althouth it is not 100% fool proof yet and XHCI can still get
>> stuck up for a few seconds occasionally, it did recover always
>> in a max of 10 seconds and the USB device was enumerated after
>> that.
>>
>> During a dual-role switch, usb_remove_hcd() and usb_add_hcd()
>> will be called consecutively for both Shared and Primary
>> HCDs. This can happen asynchronously and we have to be prepared
>> for it.
>>
>
> Even after this series I do occasionally see a delay of 5 seconds
> during adapter detach. (please see kernel log below).
>
> Is it possible to further optimize so that when xhci_stop is called
> we don't depend entirely on timeout timers to stop queued commands?

Yes, sounds reasonable. Command timer and ring could probably be stopped,
remaining commands aborted and returned.
  
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/