Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
To:     <mathias.nyman@intel.com>, <gregkh@linuxfoundation.org>,
        <linux-usb@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <tangnianyao@huawei.com>
From:   "Tangnianyao (ICT)" <tangnianyao@huawei.com>
Subject: [RFC] Question about reset order for xhci controller and pci
Message-ID: <4ae9963b-cfc1-7667-6082-a979725af0eb@huawei.com>
Date:   Fri, 26 Apr 2019 11:07:10 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.0
MIME-Version: 1.0
Content-Type: text/plain; charset="gbk"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi,all

I've meet a problem about reset xhci and it may be caused by the
reset order of pci and xhci.
Using xhci-pci, when users send reset command in os(centos or red-hat os),
it would first reset PCI device by pci_reset_function. During this
process, it would disable BME(Bus Master Enable) and set BME=0, and
then enable it and set BME=1.
And then it comes to xhci reset process. First, it would send an
endpoint stop command in xhci_urb_dequeue. However, this stop ep command
fails to finish. The reason is that BME is set to 0 in former process and
xhci RUN/STOP changes to 0, and when BME is set to 1 again, RUN/STOP doesn't
recover to 1.
I've checked BME behavior in xhci spec, it shows that "If the BME bit is set to 0
when xHC is running, the xHC may treat this as a Host Controller Error, asserting
HCE(1) and immediately halt(R/S=0 and HCH=1). Recovery from this state will
require an HCRST." It seems that the stop ep command failure is reasonable.
Maybe I've missed something and please let me know.

linux version:5.0.0-rc3

Thanks,
Nianyao Tang