Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3699463yba; Mon, 29 Apr 2019 07:08:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqw0FCfaHlQNrTx2ki/3JJiT0usVDPeLjRZWJgDDkvivlJfINZO6/j/PkxAMBxkFI8HkBODj X-Received: by 2002:a63:1b04:: with SMTP id b4mr56504163pgb.305.1556546891528; Mon, 29 Apr 2019 07:08:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556546891; cv=none; d=google.com; s=arc-20160816; b=msqQ2wmxsGOVbC3k7WktEZmmoHuCS9F+IyF1OLXEwUpLdEQZh6dssGP0FWZwqOtwCj V/sHYjtSL3maVya5dDVZNMt6t0BUIe0HeNm337l7MZA9tH5bzXRZfA3kyZ9sVL37FXBY 3xWkhHcZl2KBZLmYAP5515Vy9uXbjbXbhatxVHsMN64LwwtQQBNqlLyirp69DjInlpGT I2vHUJAAalh0CHJJGRadKSVuXtlDYYe6lPKrDzGPbDr8LADJ18tvqv4pF32/PsolT+nN EWGO2cs95nducPzI/lSOYtTMCn2U2TJ0OgLayvUzRqENwKG0/MPLReSDLTJ9lf67HFF4 vVCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date; bh=z04KH9rcFGNnkHIiB5ruA+oqPjiXcjlPmvo4/l4HHW4=; b=W7A98NAtgu88YcgyPExk3lU+0EKuARPekGM8fs7yNozyLKgPTMmjtMB9Ve/mh2Rb8R gld4lfWpDEQwtqyHRGBgp8IUB2fvWjk3pSsFIm1j+M6yi74pjjFUjQ/ueLKongp+Kl75 UCYyiju7k4pINeR5ZF8hG5BPtD48Tt0hCblibi17eQz1xI+FgGbtf2AkS23d06J3xjHt 0dTol964mJZmm1Tuez4RjGs8+asrv57ukwMDQ4L7hoV+c0lMlQJRi4omYr7cfk9n1TVo oA0wH9Afjwezuxpl3EPS4NzqUBiNGEgOaLFoEr6xPV49WStNPzfs/3Luc69cbiN7dojv 8KKg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s3si3213039plq.53.2019.04.29.07.07.46; Mon, 29 Apr 2019 07:08:11 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728349AbfD2OGG (ORCPT + 99 others); Mon, 29 Apr 2019 10:06:06 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:54100 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1728343AbfD2OGF (ORCPT ); Mon, 29 Apr 2019 10:06:05 -0400 Received: (qmail 1756 invoked by uid 2102); 29 Apr 2019 10:06:04 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 29 Apr 2019 10:06:04 -0400 Date: Mon, 29 Apr 2019 10:06:04 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: "Tangnianyao (ICT)" cc: mathias.nyman@intel.com, , , Subject: Re: [RFC] Question about reset order for xhci controller and pci In-Reply-To: <160fa1ea-2e82-343b-d5d6-2b9adde70cf4@huawei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 29 Apr 2019, Tangnianyao (ICT) wrote: > 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. Your email subject says "Question about...". What is the question? Also, given that your question concerns what happens when you write to /sys/bus/pci/..., perhaps you should consider mailing it to some PCI maintainers as well as to the USB maintainers. Perhaps the reset was not meant to be used the way you are doing it. A more conservative approach would be to unbind xhci-hcd from the device before doing the reset and then rebind it afterward. Alan Stern