lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210112072739.31624-1-mingchuang.qiao@mediatek.com>
Date:   Tue, 12 Jan 2021 15:27:39 +0800
From:   <mingchuang.qiao@...iatek.com>
To:     <bhelgaas@...gle.com>, <matthias.bgg@...il.com>
CC:     <linux-pci@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-mediatek@...ts.infradead.org>,
        <mingchuang.qiao@...iatek.com>, <haijun.liu@...iatek.com>,
        <lambert.wang@...iatek.com>, <kerun.zhu@...iatek.com>
Subject: [PATCH] pci: avoid unsync of LTR mechanism configuration

From: Mingchuang Qiao <mingchuang.qiao@...iatek.com>

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 <mingchuang.qiao@...iatek.com>
---
 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;
-- 
2.18.0

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ