All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Tangnianyao (ICT)" <tangnianyao@huawei.com>
To: <mathias.nyman@intel.com>, <gregkh@linuxfoundation.org>,
	<linux-usb@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] Question about reset order for xhci controller and pci
Date: Mon, 29 Apr 2019 10:33:08 +0800	[thread overview]
Message-ID: <160fa1ea-2e82-343b-d5d6-2b9adde70cf4@huawei.com> (raw)
In-Reply-To: <4ae9963b-cfc1-7667-6082-a979725af0eb@huawei.com>

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
> 
> 
> .
> 


  reply	other threads:[~2019-04-29  2:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-26  3:07 [RFC] Question about reset order for xhci controller and pci Tangnianyao (ICT)
2019-04-29  2:33 ` Tangnianyao (ICT) [this message]
2019-04-29 14:06   ` Alan Stern
2019-04-30  6:41     ` Tangnianyao (ICT)
2019-04-30 14:17       ` Alan Stern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=160fa1ea-2e82-343b-d5d6-2b9adde70cf4@huawei.com \
    --to=tangnianyao@huawei.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.