linux-kernel - [PATCH 3.16 005/217] PCI: imx6: Move link up check into imx6_pcie_wait_for

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <lsq.1461711741.602859208@decadent.org.uk>
Date:	Wed, 27 Apr 2016 01:02:21 +0200
From:	Ben Hutchings <ben@...adent.org.uk>
To:	linux-kernel@...r.kernel.org, stable@...r.kernel.org
CC:	akpm@...ux-foundation.org, "Bjorn Helgaas" <bhelgaas@...gle.com>,
	"Lucas Stach" <l.stach@...gutronix.de>
Subject: [PATCH 3.16 005/217] PCI: imx6: Move link up check into
 imx6_pcie_wait_for_link()

3.16.35-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: Lucas Stach <l.stach@...gutronix.de>

commit 4d107d3b5a686b5834e533a00b73bf7b1cf59df7 upstream.

imx6_pcie_link_up() previously used usleep_range() to wait for the link to
come up.  Since it may be called while holding the config spinlock, the
sleep causes a "BUG: scheduling while atomic" error.

Instead of waiting for the link to come up in imx6_pcie_link_up(), do the
waiting in imx6_pcie_wait_for_link(), where we're not holding a lock and
sleeping is allowed.

[bhelgaas: changelog, references to bugzilla and f95d3ae77191]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=100031
Fixes: f95d3ae77191 ("PCI: imx6: Wait for retraining")
Signed-off-by: Lucas Stach <l.stach@...gutronix.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@...gle.com>
[bwh: Backported to 3.16: also update the retry loop in
 imx6_pcie_wait_for_link() as done upstream in commit 6cbb247e85eb
 ("PCI: designware: Wait for link to come up with consistent style")]
Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
---
 drivers/pci/host/pci-imx6.c | 60 +++++++++++++++++----------------------------
 1 file changed, 22 insertions(+), 38 deletions(-)

--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -298,17 +298,33 @@ static void imx6_pcie_init_phy(struct pc
 
 static int imx6_pcie_wait_for_link(struct pcie_port *pp)
 {
-	int count = 200;
+	unsigned int retries;
 
-	while (!dw_pcie_link_up(pp)) {
-		usleep_range(100, 1000);
-		if (--count)
-			continue;
-
-		return -EINVAL;
+	/*
+	 * Test if the PHY reports that the link is up and also that the LTSSM
+	 * training finished. There are three possible states of the link when
+	 * this code is called:
+	 * 1) The link is DOWN (unlikely)
+	 *    The link didn't come up yet for some reason. This usually means
+	 *    we have a real problem somewhere, if it happens with a peripheral
+	 *    connected. This state calls for inspection of the DEBUG registers.
+	 * 2) The link is UP, but still in LTSSM training
+	 *    Wait for the training to finish, which should take a very short
+	 *    time. If the training does not finish, we have a problem and we
+	 *    need to inspect the DEBUG registers. If the training does finish,
+	 *    the link is up and operating correctly.
+	 * 3) The link is UP and no longer in LTSSM training
+	 *    The link is up and operating correctly.
+	 */
+	for (retries = 0; retries < 200; retries++) {
+		u32 reg = readl(pp->dbi_base + PCIE_PHY_DEBUG_R1);
+		if ((reg & PCIE_PHY_DEBUG_R1_XMLH_LINK_UP) &&
+		    !(reg & PCIE_PHY_DEBUG_R1_XMLH_LINK_IN_TRAINING))
+			return 0;
+		usleep_range(1000, 2000);
 	}
 
-	return 0;
+	return -EINVAL;
 }
 
 static irqreturn_t imx6_pcie_msi_handler(int irq, void *arg)