[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <160fa1ea-2e82-343b-d5d6-2b9adde70cf4@huawei.com>
Date: Mon, 29 Apr 2019 10:33:08 +0800
From: "Tangnianyao (ICT)" <tangnianyao@...wei.com>
To: <mathias.nyman@...el.com>, <gregkh@...uxfoundation.org>,
<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] Question about reset order for xhci controller and pci
Using command "echo 1 > /sys/bus/pci/devices/0000:7a:02.0/reset"
on centos7.5 system to reset xhci.
On 2019/4/26 11:07, Tangnianyao (ICT) wrote:
> 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
>
>
> .
>
Powered by blists - more mailing lists