From patchwork Tue Jan 12 07:27:39 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mingchuang Qiao X-Patchwork-Id: 1425012 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=23.128.96.18; helo=vger.kernel.org; envelope-from=linux-pci-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=mediatek.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=mediatek.com header.i=@mediatek.com header.a=rsa-sha256 header.s=dk header.b=YnEnpfKL; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by ozlabs.org (Postfix) with ESMTP id 4DFN2v0vc3z9sWK for ; Tue, 12 Jan 2021 18:47:34 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732979AbhALHrC (ORCPT ); Tue, 12 Jan 2021 02:47:02 -0500 Received: from Mailgw01.mediatek.com ([1.203.163.78]:16999 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1728301AbhALHrC (ORCPT ); Tue, 12 Jan 2021 02:47:02 -0500 X-UUID: 24e798f4b0ea4cce96fdcb61e9f4df16-20210112 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:CC:To:From; bh=QbDUDErbElo9ALLdM2zsuGqQjEHnckJhZ/HcIVbACVo=; b=YnEnpfKLUzlzFsCJU57SyXdYsE9u2kGaw4zQUU9hv5NepmInCSsBPM61BKKX8vgB0pkh70SVJHN3TWjDORay/xscQayvc2dRqgnlDKDNnmfUzi16AgOXyeJQSR1ugktU6VjlKgL0sDvGvJgXdUcoQLK0v5WSX+OZMt7FeaIyzXE=; X-UUID: 24e798f4b0ea4cce96fdcb61e9f4df16-20210112 Received: from mtkcas36.mediatek.inc [(172.27.4.253)] by mailgw01.mediatek.com (envelope-from ) (mailgw01.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 297226364; Tue, 12 Jan 2021 15:35:33 +0800 Received: from MTKCAS32.mediatek.inc (172.27.4.184) by MTKMBS31N1.mediatek.inc (172.27.4.69) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 12 Jan 2021 15:35:27 +0800 Received: from mcddlt001.mediatek.inc (10.19.240.15) by MTKCAS32.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Tue, 12 Jan 2021 15:35:26 +0800 From: To: , CC: , , , , , , , Subject: [PATCH] pci: avoid unsync of LTR mechanism configuration Date: Tue, 12 Jan 2021 15:27:39 +0800 Message-ID: <20210112072739.31624-1-mingchuang.qiao@mediatek.com> X-Mailer: git-send-email 2.18.0 MIME-Version: 1.0 X-TM-SNTS-SMTP: 138AEC170CF7C40068F5BD0D97B5ACAE2C5FB55A940A1E8A4148BCCA5D1A30852000:8 X-MTK: N Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org From: Mingchuang Qiao In pci bus scan flow, the LTR mechanism enable bit of DEVCTL2 register is configured in pci_configure_ltr(). If device and it's bridge both support LTR mechanism, LTR mechanism of device and it's bridge will be enabled in DEVCTL2 register. And the flag pci_dev->ltr_path will be set as 1. For some pcie products, pcie link becomes down when device reset. And then the LTR mechanism enable bit of bridge will become 0 based on description in PCIE r4.0, sec 7.8.16. However, the pci_dev->ltr_path value of bridge is still 1. Remove and rescan flow could be triggered to recover after device reset. In the bus rescan flow, the LTR mechanism of device will be enabled in pci_configure_ltr() due to ltr_path of its bridge is still 1. When device's LTR mechanism is enabled, device will send LTR message to bridge. Bridge receives the device's LTR message and found bridge's LTR mechanism is disabled. Then the bridge will generate unsupported request and other error handling flow will be triggered such as AER Non-Fatal error handling. This patch is used to avoid this unsupported request and make the bridge's ltr_path value is aligned with DEVCTL2 register value. Check bridge register value if aligned with ltr_path in pci_configure_ltr(). If register value is disable and the ltr_path is 1, we need configure the register value as enable. Signed-off-by: Mingchuang Qiao --- drivers/pci/probe.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 953f15abc850..49355cf4af54 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -2132,9 +2132,21 @@ static void pci_configure_ltr(struct pci_dev *dev) * Complex and all intermediate Switches indicate support for LTR. * PCIe r4.0, sec 6.18. */ - if (pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT || - ((bridge = pci_upstream_bridge(dev)) && - bridge->ltr_path)) { + if (pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT) { + pcie_capability_set_word(dev, PCI_EXP_DEVCTL2, + PCI_EXP_DEVCTL2_LTR_EN); + dev->ltr_path = 1; + return; + } + + bridge = pci_upstream_bridge(dev); + if (bridge && bridge->ltr_path) { + pcie_capability_read_dword(bridge, PCI_EXP_DEVCTL2, &ctl); + if (!(ctl & PCI_EXP_DEVCTL2_LTR_EN)) { + pcie_capability_set_word(bridge, PCI_EXP_DEVCTL2, + PCI_EXP_DEVCTL2_LTR_EN); + } + pcie_capability_set_word(dev, PCI_EXP_DEVCTL2, PCI_EXP_DEVCTL2_LTR_EN); dev->ltr_path = 1;