From patchwork Thu Jun 24 22:26:17 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Pali_Roh=C3=A1r?= X-Patchwork-Id: 12343299 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-17.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 588B5C49EA6 for ; Thu, 24 Jun 2021 22:29:47 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 28DCC61164 for ; Thu, 24 Jun 2021 22:29:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 28DCC61164 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=DGPoUBp7mjgHaomRSNW53cxmr/vMRQdOKvUpI8/hbYA=; b=L6vXL4bJTki51w rBTx/dY5bZxkIePw9S2IU8yfjPp+mXFono2QT8vQVli9UGY9tvklPCla9+WvvpHkYwgn3AMq/Ae1E sY7XXbWxDXV0PgzY5t5s5DVu5Q5pYP6j7BicHzlvUV2CLYQIclypWMvzZk2O9EIW0RXWY4zEkMVeP iAFcJdQgO1mDrawdA9+SsBMGoEveA6tfFQRYzII7CzuhrQabrjlz7Gp67fntkHfdQu2iUCRJfXerp B996DuaIbunSGhcJvDakBWWy4Lp4xS4MEfteBxjYm79vFg489zdqOxB1TSHfdrC5lzRxRQPuFHgct Y/KsCB2uI3xtGs4vtfjg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwXp0-00GVBH-Jy; Thu, 24 Jun 2021 22:27:42 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwXoT-00GV5u-Ed for linux-arm-kernel@lists.infradead.org; Thu, 24 Jun 2021 22:27:11 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id DAD0B613A9; Thu, 24 Jun 2021 22:27:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1624573629; bh=RKd6WSxPflFV4iU1Jbt44gtPpekgNq50zK7XkvGEvT4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fmtnli5W81cVsuE2TKROHjhp5VId3adOaZE2HYuaZhx7n4IFQjjdblz+cCTSpmDPI SKsO0XH+xSZTWoLSiF5SFC362OD1vGA2p/wITaSO6HY99slUG9SbHi7BU5cG6ga651 jmc9b9oyT6To1Kk6leWwER8HLjzZksOuKbTeBfyvAzEs9TZAWQg9uUQJ5qqyyQbZjU myWLobza0nHyscJaw9n1Sfjqpb6U4JACuPqNchZpeUATu8dEx9mLMEV6P0nK5mZTrg DxTuwrN2zZ4WBqhR47ocqfgwKVRRUOGNYLhubOTjgFCI/cze8ustS5zQTUFRaOGDX9 Va9wQH7uiNSaw== Received: by pali.im (Postfix) id 0315096D; Fri, 25 Jun 2021 00:27:07 +0200 (CEST) From: =?utf-8?q?Pali_Roh=C3=A1r?= To: Lorenzo Pieralisi , Thomas Petazzoni , Bjorn Helgaas , Rob Herring , Gregory Clement Cc: =?utf-8?q?Marek_Beh=C3=BAn?= , "Remi Pommarel" , Xogium , "Tomasz Maciej Nowak" , Nadav Haklai , Kostya Porotchkin , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [RESEND PATCH 1/5] PCI: aardvark: Fix link training Date: Fri, 25 Jun 2021 00:26:17 +0200 Message-Id: <20210624222621.4776-2-pali@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20210624222621.4776-1-pali@kernel.org> References: <20210624222621.4776-1-pali@kernel.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210624_152709_579167_989A99AD X-CRM114-Status: GOOD ( 37.61 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Fix multiple link training issues in aardvark driver. The main reason of these issues was misunderstanding of what certain registers do, since their names and comments were misleading: before commit 96be36dbffac ("PCI: aardvark: Replace custom macros by standard linux/pci_regs.h macros"), the pci-aardvark.c driver used custom macros for accessing standard PCIe Root Bridge registers, and misleading comments did not help to understand what the code was really doing. After doing more tests and experiments I've come to the conclusion that the SPEED_GEN register in aardvark sets the PCIe revision / generation compliance and forces maximal link speed. Both GEN3 and GEN2 values set the read-only PCI_EXP_FLAGS_VERS bits (PCIe capabilities version of Root Bridge) to value 2, while GEN1 value sets PCI_EXP_FLAGS_VERS to 1, which matches with PCI Express specifications revision 3, 2 and 1, respectively. Changing SPEED_GEN also sets the read-only bits PCI_EXP_LNKCAP_SLS and PCI_EXP_LNKCAP2_SLS to corresponding speed. Note that PCI Express rev 1 specification does not define PCI_EXP_LNKCAP2 and PCI_EXP_LNKCTL2 registers and when SPEED_GEN is set to GEN1 (which also sets PCI_EXP_FLAGS_VERS set to 1), lspci cannot access PCI_EXP_LNKCAP2 and PCI_EXP_LNKCTL2 registers. Changing PCIe link speed can be done via PCI_EXP_LNKCTL2_TLS bits of PCI_EXP_LNKCTL2 register. Armada 3700 Functional Specifications says that the default value of PCI_EXP_LNKCTL2_TLS is based on SPEED_GEN value, but tests showed that the default value is always 8.0 GT/s, independently of speed set by SPEED_GEN. So after setting SPEED_GEN, we must also set value in PCI_EXP_LNKCTL2 register via PCI_EXP_LNKCTL2_TLS bits. Triggering PCI_EXP_LNKCTL_RL bit immediately after setting LINK_TRAINING_EN bit actually doesn't do anything. Tests have shown that a delay is needed after enabling LINK_TRAINING_EN bit. As triggering PCI_EXP_LNKCTL_RL currently does nothing, remove it. Commit 43fc679ced18 ("PCI: aardvark: Improve link training") introduced code which sets SPEED_GEN register based on negotiated link speed from PCI_EXP_LNKSTA_CLS bits of PCI_EXP_LNKSTA register. This code was added to fix detection of Compex WLE900VX (Atheros QCA9880) WiFi GEN1 PCIe cards, as otherwise these cards were "invisible" on PCIe bus (probably because they crashed). But apparently more people reported the same issues with these cards also with other PCIe controllers [1] and I was able to reproduce this issue also with other "noname" WiFi cards based on Atheros QCA9890 chip (with the same PCI vendor/device ids as Atheros QCA9880). So this is not an issue in aardvark but rather issue in Atheros QCA98xx chips. Also, this issue only exists if the kernel is compiled with PCIe ASPM support, and a generic workaround for this is to change PCIe Bridge to 2.5 GT/s link speed via PCI_EXP_LNKCTL2_TLS_2_5GT bits in PCI_EXP_LNKCTL2 register [2], before triggering PCI_EXP_LNKCTL_RL bit. This workaround also works when SPEED_GEN is set to value GEN2 (5 GT/s). So remove this hack completely in the aardvark driver and always set SPEED_GEN to value from 'max-link-speed' DT property. Fix for Atheros QCA98xx chips is handled separately by patch [2]. These two things (code for triggering PCI_EXP_LNKCTL_RL bit and changing SPEED_GEN value) also explain why commit 6964494582f5 ("PCI: aardvark: Train link immediately after enabling training") somehow fixed detection of those problematic Compex cards with Atheros chips: if triggering link retraining (via PCI_EXP_LNKCTL_RL bit) was done immediately after enabling link training (via LINK_TRAINING_EN), it did nothing. If there was a specific delay, aardvark HW already initialized PCIe link and therefore triggering link retraining caused the above issue. Compex cards triggered link down event and disappeared from the PCIe bus. Commit f4c7d053d7f7 ("PCI: aardvark: Wait for endpoint to be ready before training link") added 100ms sleep before calling 'Start link training' command and explained that it is a requirement of PCI Express specification. But the code after this 100ms sleep was not doing 'Start link training', rather it triggered PCI_EXP_LNKCTL_RL bit via PCIe Root Bridge to put link into Recovery state. The required delay after fundamental reset is already done in function advk_pcie_wait_for_link() which also check when PCIe link is up. So after removing the code which triggers PCI_EXP_LNKCTL_RL bit on PCIe Root Bridge, there is no need to wait 100ms again. Remove the extra msleep() call and update comment about the delay required by the PCI Express specification. According to Marvell Armada 3700 Functional Specifications, Link training should be enabled via aardvark register LINK_TRAINING_EN after selecting PCIe generation and x1 lane. There is no need to disable it prior resetting card via PERST# signal. This disabling code was introduced in commit 5169a9851daa ("PCI: aardvark: Issue PERST via GPIO") as a workaround for some Atheros cards. It turns out that this also is Atheros specific issue and affects any PCIe controller, not only aardvark. Moreover this Atheros issue was triggered by juggling with PCI_EXP_LNKCTL_RL, LINK_TRAINING_EN and SPEED_GEN bits interleaved with sleeps. Now, after removing triggering PCI_EXP_LNKCTL_RL, there is no need to explicitly disable LINK_TRAINING_EN bit. So remove this code too. The problematic Compex cards described in previous git commits are correctly detected in advk_pcie_train_link() function even after applying all these changes. Note that with this patch, and also prior this patch, some NVMe disks which support PCIe GEN3 with 8 GT/s speed are negotiated only at the lowest link speed 2.5 GT/s, independently of SPEED_GEN value. After manually triggering PCI_EXP_LNKCTL_RL bit (e.g. from userspace via setpci), these NVMe disks change link speed to 5 GT/s when SPEED_GEN was configured to GEN2. This issue first needs to be properly investigated. I will send a fix in the future. On the other hand, some other GEN2 PCIe cards with 5 GT/s speed are autonomously by HW autonegotiated at full 5 GT/s speed without need of any software interaction. Armada 3700 Functional Specifications describes the following steps for link training: set SPEED_GEN to GEN2, enable LINK_TRAINING_EN, poll until link training is complete, trigger PCI_EXP_LNKCTL_RL, poll until signal rate is 5 GT/s, poll until link training is complete, enable ASPM L0s. The requirement for triggering PCI_EXP_LNKCTL_RL can be explained by the need to achieve 5 GT/s speed (as changing link speed is done by throw to recovery state entered by PCI_EXP_LNKCTL_RL) or maybe as a part of enabling ASPM L0s (but in this case ASPM L0s should have been enabled prior PCI_EXP_LNKCTL_RL). It is unknown why the original pci-aardvark.c driver was triggering PCI_EXP_LNKCTL_RL bit before waiting for the link to be up. This does not align with neither PCIe base specifications nor with Armada 3700 Functional Specification. (Note that in older versions of aardvark, this bit was called incorrectly PCIE_CORE_LINK_TRAINING, so this may be the reason.) It is also unknown why Armada 3700 Functional Specification says that it is needed to trigger PCI_EXP_LNKCTL_RL for GEN2 mode, as according to PCIe base specification 5 GT/s speed negotiation is supposed to be entirely autonomous, even if initial speed is 2.5 GT/s. [1] - https://lore.kernel.org/linux-pci/87h7l8axqp.fsf@toke.dk/ [2] - https://lore.kernel.org/linux-pci/20210326124326.21163-1-pali@kernel.org/ Signed-off-by: Pali Rohár Reviewed-by: Marek Behún Cc: stable@vger.kernel.org # f4c7d053d7f7 ("PCI: aardvark: Wait for endpoint to be ready before training link") Cc: stable@vger.kernel.org # 6964494582f5 ("PCI: aardvark: Train link immediately after enabling training") Cc: stable@vger.kernel.org # 43fc679ced18 ("PCI: aardvark: Improve link training") Cc: stable@vger.kernel.org # 5169a9851daa ("PCI: aardvark: Issue PERST via GPIO") Cc: stable@vger.kernel.org # 96be36dbffac ("PCI: aardvark: Replace custom macros by standard linux/pci_regs.h macros") Cc: stable@vger.kernel.org # d0c6a3475b03 ("PCI: aardvark: Move PCIe reset card code to advk_pcie_train_link()") Cc: stable@vger.kernel.org # 1d1cd163d0de ("PCI: aardvark: Update comment about disabling link training") --- drivers/pci/controller/pci-aardvark.c | 117 ++++++++------------------ 1 file changed, 34 insertions(+), 83 deletions(-) diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c index b4da496360f0..11368d23b612 100644 --- a/drivers/pci/controller/pci-aardvark.c +++ b/drivers/pci/controller/pci-aardvark.c @@ -256,11 +256,6 @@ static inline u32 advk_readl(struct advk_pcie *pcie, u64 reg) return readl(pcie->base + reg); } -static inline u16 advk_read16(struct advk_pcie *pcie, u64 reg) -{ - return advk_readl(pcie, (reg & ~0x3)) >> ((reg & 0x3) * 8); -} - static int advk_pcie_link_up(struct advk_pcie *pcie) { u32 val, ltssm_state; @@ -298,23 +293,9 @@ static void advk_pcie_wait_for_retrain(struct advk_pcie *pcie) static void advk_pcie_issue_perst(struct advk_pcie *pcie) { - u32 reg; - if (!pcie->reset_gpio) return; - /* - * As required by PCI Express spec (PCI Express Base Specification, REV. - * 4.0 PCI Express, February 19 2014, 6.6.1 Conventional Reset) a delay - * for at least 100ms after de-asserting PERST# signal is needed before - * link training is enabled. So ensure that link training is disabled - * prior de-asserting PERST# signal to fulfill that PCI Express spec - * requirement. - */ - reg = advk_readl(pcie, PCIE_CORE_CTRL0_REG); - reg &= ~LINK_TRAINING_EN; - advk_writel(pcie, reg, PCIE_CORE_CTRL0_REG); - /* 10ms delay is needed for some cards */ dev_info(&pcie->pdev->dev, "issuing PERST via reset GPIO for 10ms\n"); gpiod_set_value_cansleep(pcie->reset_gpio, 1); @@ -322,53 +303,46 @@ static void advk_pcie_issue_perst(struct advk_pcie *pcie) gpiod_set_value_cansleep(pcie->reset_gpio, 0); } -static int advk_pcie_train_at_gen(struct advk_pcie *pcie, int gen) +static void advk_pcie_train_link(struct advk_pcie *pcie) { - int ret, neg_gen; + struct device *dev = &pcie->pdev->dev; u32 reg; + int ret; - /* Setup link speed */ + /* + * Setup PCIe rev / gen compliance based on device tree property + * 'max-link-speed' which also forces maximal link speed. + */ reg = advk_readl(pcie, PCIE_CORE_CTRL0_REG); reg &= ~PCIE_GEN_SEL_MSK; - if (gen == 3) + if (pcie->link_gen == 3) reg |= SPEED_GEN_3; - else if (gen == 2) + else if (pcie->link_gen == 2) reg |= SPEED_GEN_2; else reg |= SPEED_GEN_1; advk_writel(pcie, reg, PCIE_CORE_CTRL0_REG); /* - * Enable link training. This is not needed in every call to this - * function, just once suffices, but it does not break anything either. + * Set maximal link speed value also into PCIe Link Control 2 register. + * Armada 3700 Functional Specification says that default value is based + * on SPEED_GEN but tests showed that default value is always 8.0 GT/s. */ + reg = advk_readl(pcie, PCIE_CORE_PCIEXP_CAP + PCI_EXP_LNKCTL2); + reg &= ~PCI_EXP_LNKCTL2_TLS; + if (pcie->link_gen == 3) + reg |= PCI_EXP_LNKCTL2_TLS_8_0GT; + else if (pcie->link_gen == 2) + reg |= PCI_EXP_LNKCTL2_TLS_5_0GT; + else + reg |= PCI_EXP_LNKCTL2_TLS_2_5GT; + advk_writel(pcie, reg, PCIE_CORE_PCIEXP_CAP + PCI_EXP_LNKCTL2); + + /* Enable link training after selecting PCIe generation */ reg = advk_readl(pcie, PCIE_CORE_CTRL0_REG); reg |= LINK_TRAINING_EN; advk_writel(pcie, reg, PCIE_CORE_CTRL0_REG); - /* - * Start link training immediately after enabling it. - * This solves problems for some buggy cards. - */ - reg = advk_readl(pcie, PCIE_CORE_PCIEXP_CAP + PCI_EXP_LNKCTL); - reg |= PCI_EXP_LNKCTL_RL; - advk_writel(pcie, reg, PCIE_CORE_PCIEXP_CAP + PCI_EXP_LNKCTL); - - ret = advk_pcie_wait_for_link(pcie); - if (ret) - return ret; - - reg = advk_read16(pcie, PCIE_CORE_PCIEXP_CAP + PCI_EXP_LNKSTA); - neg_gen = reg & PCI_EXP_LNKSTA_CLS; - - return neg_gen; -} - -static void advk_pcie_train_link(struct advk_pcie *pcie) -{ - struct device *dev = &pcie->pdev->dev; - int neg_gen = -1, gen; - /* * Reset PCIe card via PERST# signal. Some cards are not detected * during link training when they are in some non-initial state. @@ -379,41 +353,18 @@ static void advk_pcie_train_link(struct advk_pcie *pcie) * PERST# signal could have been asserted by pinctrl subsystem before * probe() callback has been called or issued explicitly by reset gpio * function advk_pcie_issue_perst(), making the endpoint going into - * fundamental reset. As required by PCI Express spec a delay for at - * least 100ms after such a reset before link training is needed. - */ - msleep(PCI_PM_D3COLD_WAIT); - - /* - * Try link training at link gen specified by device tree property - * 'max-link-speed'. If this fails, iteratively train at lower gen. - */ - for (gen = pcie->link_gen; gen > 0; --gen) { - neg_gen = advk_pcie_train_at_gen(pcie, gen); - if (neg_gen > 0) - break; - } - - if (neg_gen < 0) - goto err; - - /* - * After successful training if negotiated gen is lower than requested, - * train again on negotiated gen. This solves some stability issues for - * some buggy gen1 cards. + * fundamental reset. As required by PCI Express spec (PCI Express + * Base Specification, REV. 4.0 PCI Express, February 19 2014, 6.6.1 + * Conventional Reset) a delay for at least 100ms after such a reset + * before sending a Configuration Request to the device is needed. + * So wait until PCIe link is up. Function advk_pcie_wait_for_link() + * waits for link at least 900ms. */ - if (neg_gen < gen) { - gen = neg_gen; - neg_gen = advk_pcie_train_at_gen(pcie, gen); - } - - if (neg_gen == gen) { - dev_info(dev, "link up at gen %i\n", gen); - return; - } - -err: - dev_err(dev, "link never came up\n"); + ret = advk_pcie_wait_for_link(pcie); + if (ret < 0) + dev_err(dev, "link never came up\n"); + else + dev_info(dev, "link up\n"); } /* From patchwork Thu Jun 24 22:26:18 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Pali_Roh=C3=A1r?= X-Patchwork-Id: 12343295 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-17.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9E7C5C49EA6 for ; Thu, 24 Jun 2021 22:29:23 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 65BE7610A0 for ; Thu, 24 Jun 2021 22:29:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 65BE7610A0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=yDgTAgfhxQgAITCHUed5A3xTNG1y7CEeOPOB3vWks8I=; b=tyGFZLQe2pTOJT Nz+wpdyTMyOphdWu9fmfan4vV4pc9Rjr4yWznusHSSYJxHw7M/5v/n0QPKfI2fnPsX8AeHYGPPLH2 bYzIaBnQu/Fze7RVrNS5NeqPKJlN9fUqzRQ5LcE4Qm2FLqtrdQcCJa9wmtNLrgCSDyJRFDaZQuB6f 4bvlq7gXaw6nT+ZhgCCf9Ru+KQS+n88qUwFPi67C0Zm7/nuqJQ0at4oJnwVTb2gE5cgw9nRz8bpOj /ugY8Gv8gAU8HXMWoKM4/ra6BOdLB0Fnn91bUgSDGU1DIMB161icsXXtlo5E68xIsnRAucDqZ1Ytv xxuqAe9zCIZW6kUIfpDg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwXoq-00GVA4-Ac; Thu, 24 Jun 2021 22:27:32 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwXoU-00GV6Z-Gv for linux-arm-kernel@lists.infradead.org; Thu, 24 Jun 2021 22:27:11 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id E16606137D; Thu, 24 Jun 2021 22:27:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1624573630; bh=bSHnjsAOWAaXk6MagAsbXeDOrNG/Ncxs7ohUVA+0BuE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uRWhlRafjZbl+wBmI/y7AraGDR5rU9KdfJQc0ku6xPvkckDKJaijFM1CSZ4TWQ67V zK796sQS6yGypRB1t39rp+IpMkVj45LRUykEo//kvDaqx4+1RH/Q3LKPQketQ5Cmx8 XGHmSi/K2oKN4c/vtWjglLIQKKMskPYntKoKzieo+32Pz2u9b7WtXEFiC6FZmndBac nQP3C/tr5J79qEi6ipmCR1hjUr+rFOM21VyBVQo9XWfj1FvCL433RD6WoNGJVjjEB+ LDO9EO1ObUoMxC9T4mk/mWE8Luizo/NQugBARVa2NXgIikTcJlEm8g8cRTnDvKIBY3 DgECG4jXtwYXw== Received: by pali.im (Postfix) id 1717FBFC; Fri, 25 Jun 2021 00:27:08 +0200 (CEST) From: =?utf-8?q?Pali_Roh=C3=A1r?= To: Lorenzo Pieralisi , Thomas Petazzoni , Bjorn Helgaas , Rob Herring , Gregory Clement Cc: =?utf-8?q?Marek_Beh=C3=BAn?= , "Remi Pommarel" , Xogium , "Tomasz Maciej Nowak" , Nadav Haklai , Kostya Porotchkin , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [RESEND PATCH 2/5] PCI: Add PCI_EXP_DEVCTL_PAYLOAD_* macros Date: Fri, 25 Jun 2021 00:26:18 +0200 Message-Id: <20210624222621.4776-3-pali@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20210624222621.4776-1-pali@kernel.org> References: <20210624222621.4776-1-pali@kernel.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210624_152710_615111_4DF689A7 X-CRM114-Status: UNSURE ( 7.97 ) X-CRM114-Notice: Please train this message. X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Define a macro PCI_EXP_DEVCTL_PAYLOAD_* for every possible Max Payload Size in linux/pci_regs.h, in the same style as PCI_EXP_DEVCTL_READRQ_*. Signed-off-by: Pali Rohár Reviewed-by: Marek Behún Acked-by: Bjorn Helgaas --- include/uapi/linux/pci_regs.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h index e709ae8235e7..ff6ccbc6efe9 100644 --- a/include/uapi/linux/pci_regs.h +++ b/include/uapi/linux/pci_regs.h @@ -504,6 +504,12 @@ #define PCI_EXP_DEVCTL_URRE 0x0008 /* Unsupported Request Reporting En. */ #define PCI_EXP_DEVCTL_RELAX_EN 0x0010 /* Enable relaxed ordering */ #define PCI_EXP_DEVCTL_PAYLOAD 0x00e0 /* Max_Payload_Size */ +#define PCI_EXP_DEVCTL_PAYLOAD_128B 0x0000 /* 128 Bytes */ +#define PCI_EXP_DEVCTL_PAYLOAD_256B 0x0020 /* 256 Bytes */ +#define PCI_EXP_DEVCTL_PAYLOAD_512B 0x0040 /* 512 Bytes */ +#define PCI_EXP_DEVCTL_PAYLOAD_1024B 0x0060 /* 1024 Bytes */ +#define PCI_EXP_DEVCTL_PAYLOAD_2048B 0x0080 /* 2048 Bytes */ +#define PCI_EXP_DEVCTL_PAYLOAD_4096B 0x00a0 /* 4096 Bytes */ #define PCI_EXP_DEVCTL_EXT_TAG 0x0100 /* Extended Tag Field Enable */ #define PCI_EXP_DEVCTL_PHANTOM 0x0200 /* Phantom Functions Enable */ #define PCI_EXP_DEVCTL_AUX_PME 0x0400 /* Auxiliary Power PM Enable */ From patchwork Thu Jun 24 22:26:19 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Pali_Roh=C3=A1r?= X-Patchwork-Id: 12343293 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,UNWANTED_LANGUAGE_BODY,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E710CC49EA7 for ; Thu, 24 Jun 2021 22:29:19 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B7C5F6138C for ; Thu, 24 Jun 2021 22:29:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B7C5F6138C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=4D6ETEbfGKWlUYGL3uaR9BL4cST3zASF8FaKvgKBHrQ=; b=qD4vPaiQJxM7mF 0UKw4dm2T+3pty88xtE0lCQ501dxXiaMHfx6b4GYZfrtko1yCxGib1LKIt0QSNowU0jWr9rIy8CGr x9K/pIq6EMdrIbpioyz4tX3iHaaNxv+7LSuxrKKE6wdnq67NFVygkIqzt8mudPwmQw6oRBignT2y1 GYHExvsFMK9L1QjRwVhySrkLxbVt5BVXXjbGTqH+iOISCkWcnB4PEvykNegblTKQc9//JlswcVo/A 6O6tLtaLjLmRSR2e+4zV9CFPxvSUxrFTH1E9fOJKf/8V8kAlBQqWn7GK2pc6cRcFcyzkoFxiFuXeM BdFTb8vTjkomhiI/mbAQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwXog-00GV93-EZ; Thu, 24 Jun 2021 22:27:22 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwXoT-00GV6A-TA for linux-arm-kernel@lists.infradead.org; Thu, 24 Jun 2021 22:27:11 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 74F9E613AD; Thu, 24 Jun 2021 22:27:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1624573629; bh=aZA6UgY1/SzRgcP8YOY86cgw0pyUiDGpoMTA23VVvCU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jqdUJhytpHrkARYoowBbNkAMTY767sqMR56OgZ1+fce0yzYY9PxhTHA46hvd1bLq+ isxE4iqlFqvb0MWIPJEfWUR9Z20M5TevMkNIZw5rpi+r7tYUkGhIt5PWJsVAmCTrJY XeS8Y5eYGOn+Ir1GTWpJ9YgW5Lt5MD25IrBN/65WruvEmDaDPpS7uRCxznXhLCbUaO WdalJD2uhocY747ObhnpUBlWWdnrglWNBu556hFG36gO4LZty7Mf1yLPhH9EkOiNk6 OWY8Dk2dxbzlgaVgAnpup4QIBBMKyZCVYAgEppxfkFWKoE3fhUdzqrrldqUCi18f4y ypNI0P0dRsKjA== Received: by pali.im (Postfix) id 33DBE8A3; Fri, 25 Jun 2021 00:27:09 +0200 (CEST) From: =?utf-8?q?Pali_Roh=C3=A1r?= To: Lorenzo Pieralisi , Thomas Petazzoni , Bjorn Helgaas , Rob Herring , Gregory Clement Cc: =?utf-8?q?Marek_Beh=C3=BAn?= , "Remi Pommarel" , Xogium , "Tomasz Maciej Nowak" , Nadav Haklai , Kostya Porotchkin , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [RESEND PATCH 3/5] PCI: aardvark: Fix PCIe Max Payload Size setting Date: Fri, 25 Jun 2021 00:26:19 +0200 Message-Id: <20210624222621.4776-4-pali@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20210624222621.4776-1-pali@kernel.org> References: <20210624222621.4776-1-pali@kernel.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210624_152709_997129_9709F579 X-CRM114-Status: UNSURE ( 9.55 ) X-CRM114-Notice: Please train this message. X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Change PCIe Max Payload Size setting in PCIe Device Control register to 512 bytes to align with PCIe Link Initialization sequence as defined in Marvell Armada 3700 Functional Specification. According to the specification, maximal Max Payload Size supported by this device is 512 bytes. Without this kernel prints suspicious line: pci 0000:01:00.0: Upstream bridge's Max Payload Size set to 256 (was 16384, max 512) With this change it changes to: pci 0000:01:00.0: Upstream bridge's Max Payload Size set to 256 (was 512, max 512) Signed-off-by: Pali Rohár Reviewed-by: Marek Behún Cc: stable@vger.kernel.org --- drivers/pci/controller/pci-aardvark.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c index 11368d23b612..397431d641f6 100644 --- a/drivers/pci/controller/pci-aardvark.c +++ b/drivers/pci/controller/pci-aardvark.c @@ -428,8 +428,9 @@ static void advk_pcie_setup_hw(struct advk_pcie *pcie) reg = advk_readl(pcie, PCIE_CORE_PCIEXP_CAP + PCI_EXP_DEVCTL); reg &= ~PCI_EXP_DEVCTL_RELAX_EN; reg &= ~PCI_EXP_DEVCTL_NOSNOOP_EN; + reg &= ~PCI_EXP_DEVCTL_PAYLOAD; reg &= ~PCI_EXP_DEVCTL_READRQ; - reg |= PCI_EXP_DEVCTL_PAYLOAD; /* Set max payload size */ + reg |= PCI_EXP_DEVCTL_PAYLOAD_512B; reg |= PCI_EXP_DEVCTL_READRQ_512B; advk_writel(pcie, reg, PCIE_CORE_PCIEXP_CAP + PCI_EXP_DEVCTL); From patchwork Thu Jun 24 22:26:20 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Pali_Roh=C3=A1r?= X-Patchwork-Id: 12343297 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-17.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 43063C49EA6 for ; Thu, 24 Jun 2021 22:29:41 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1048061164 for ; Thu, 24 Jun 2021 22:29:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1048061164 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=IziO7y0YsuOKItmmb1eDyMor8I7uldEGcKjw/5RvI3A=; b=dO78ikz1DG4Ix0 xHLZpH3ZuPN32F2HJYB4yOTnUAyGJ9N4/bgJu8XStA0UvN23KKuRbgPbtQVoWW/CeSTdbD+l36aXk lcFwA18rJ5hYKF6UduYEoM+sX7KN7cQDlbP3IDYn+KNQEImjjAlnlfq5V4ltdM+lSkNVijtmDK26K 4wgy3UIO+wCE2AQaBWY/aqVeGHJUQtWRyzJMGGk72xaHy7BGlky8ROgXdTrV4jCPrGVYSHcl1Lox+ hl16FRSCZEmGkTAIvBGXUE3ihiIvtiyMtnpkxaqh84hTSg0JS9Bk3VoZJb1ajE9DcnP97po2nYSXv 2dpTXFBjNWvHW0SgdNug==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwXpC-00GVDC-5y; Thu, 24 Jun 2021 22:27:54 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwXoV-00GV6m-2R for linux-arm-kernel@lists.infradead.org; Thu, 24 Jun 2021 22:27:12 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id A635E613AB; Thu, 24 Jun 2021 22:27:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1624573630; bh=Abh9XGgE1ipE6laKxqtRrQbaboUN5YYNzU9KrJVJ4A4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QPb9HZhfiRsegh08jXRFFjTY7QMb5lQk8SmScz+r8HO8aR6VTOvDijtiU8YVjDz5W M3y9WSYIgv/cQwe0uHVmo1AscxNAkMQGHuvjEwGLGJ2ecIp44c9ORpcW18awGuwQsP Dvd7hLFlkAJP3eqdfye+s6goRTsa7W0JoqhcdzA7AEfbuPOGLTp6p1ONZdzsR1BTCG 1HDKO0H1nE/WdFzZLSduvzdnk4o0IiXArDZ4SgMnMjhJK7yAF9n8eybAmhYO2toQCW z4uUi6cQAPAdBsCmsZ1rq+LYECN0wYxhtG1x+rYrhR3yg2oEehXxYUF2h5jcvnEPJM fqOopr45O+Xqg== Received: by pali.im (Postfix) id 64C9C8A3; Fri, 25 Jun 2021 00:27:10 +0200 (CEST) From: =?utf-8?q?Pali_Roh=C3=A1r?= To: Lorenzo Pieralisi , Thomas Petazzoni , Bjorn Helgaas , Rob Herring , Gregory Clement Cc: =?utf-8?q?Marek_Beh=C3=BAn?= , "Remi Pommarel" , Xogium , "Tomasz Maciej Nowak" , Nadav Haklai , Kostya Porotchkin , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [RESEND PATCH 4/5] PCI: aardvark: Implement workaround for the readback value of VEND_ID Date: Fri, 25 Jun 2021 00:26:20 +0200 Message-Id: <20210624222621.4776-5-pali@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20210624222621.4776-1-pali@kernel.org> References: <20210624222621.4776-1-pali@kernel.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210624_152711_173873_FA70FA09 X-CRM114-Status: GOOD ( 11.59 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Marvell Armada 3700 Functional Errata, Guidelines, and Restrictions document describes in erratum 4.1 PCIe value of vendor ID (Ref #: 243): The readback value of VEND_ID (RD0070000h [15:0]) is 1B4Bh, while it should read 11ABh. The firmware can write the correct value, 11ABh, through VEND_ID (RD0076044h [15:0]). Implement this workaround in aardvark driver for both PCI vendor id and PCI subsystem vendor id. This change affects and fixes PCI vendor id of emulated PCIe root bridge. After this change emulated PCIe root bridge has correct vendor id. Signed-off-by: Pali Rohár Reviewed-by: Marek Behún Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space") Cc: stable@vger.kernel.org --- drivers/pci/controller/pci-aardvark.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c index 397431d641f6..9ff68abd8d1e 100644 --- a/drivers/pci/controller/pci-aardvark.c +++ b/drivers/pci/controller/pci-aardvark.c @@ -166,6 +166,7 @@ #define LTSSM_MASK 0x3f #define LTSSM_L0 0x10 #define RC_BAR_CONFIG 0x300 +#define VENDOR_ID_REG (LMI_BASE_ADDR + 0x44) /* PCIe core controller registers */ #define CTRL_CORE_BASE_ADDR 0x18000 @@ -417,6 +418,16 @@ static void advk_pcie_setup_hw(struct advk_pcie *pcie) reg |= (IS_RC_MSK << IS_RC_SHIFT); advk_writel(pcie, reg, PCIE_CORE_CTRL0_REG); + /* + * Replace incorrect PCI vendor id value 0x1b4b by correct value 0x11ab. + * VENDOR_ID_REG contains vendor id in low 16 bits and subsystem vendor + * id in high 16 bits. Updating this register changes readback value of + * read-only vendor id bits in PCIE_CORE_DEV_ID_REG register. Workaround + * for erratum 4.1: "The value of device and vendor ID is incorrect". + */ + reg = (PCI_VENDOR_ID_MARVELL << 16) | PCI_VENDOR_ID_MARVELL; + advk_writel(pcie, reg, VENDOR_ID_REG); + /* Set Advanced Error Capabilities and Control PF0 register */ reg = PCIE_CORE_ERR_CAPCTL_ECRC_CHK_TX | PCIE_CORE_ERR_CAPCTL_ECRC_CHK_TX_EN | From patchwork Thu Jun 24 22:26:21 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Pali_Roh=C3=A1r?= X-Patchwork-Id: 12343301 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-17.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C6678C49EA5 for ; Thu, 24 Jun 2021 22:29:48 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8F24B61164 for ; Thu, 24 Jun 2021 22:29:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8F24B61164 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=K/bLS/6UATogCjamv3jrd7z1vMyrQvq7aWdqRkRGovU=; b=ywOldkysFyUV0+ zScjxV5J40l/1QE1er29d08ODkVIT5XLHQt4fo431NWN+7iB6mu8LAZ2w2u9VSQStgPNQA0HxTKhu 4tTpT72F3FXZxMdizUD7DP/Y6MgXZnOI5H0biB74tNKiwMvhLBftmx0WtlDFhNFjq/BVld7oHy/hX hUtgd00evXpVdUQB7FRyaSYprAM267DsiouoJmF5UqdE9KSCAU6grBa3C/ssNjXCqzFmokcAVMFeJ hv3rZ7nKh8YYJgSZBoIgodMyDbFMtex28zrKDRREHC8siHlTjvLs0gevr2L4fYf45UnM3RyO1q19z Ut6mGmlWWrt9v2DXE8eA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwXpN-00GVGe-No; Thu, 24 Jun 2021 22:28:05 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwXoW-00GV6Z-9L for linux-arm-kernel@lists.infradead.org; Thu, 24 Jun 2021 22:27:13 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 06FA561375; Thu, 24 Jun 2021 22:27:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1624573632; bh=jYt5kfZFIc6erlp5/8lvnkSBPgbQ6DNhQvJQ28jGNJ0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kd7vizbDFBauhateivIkhyAS7AStROoZqtwp9gkAiGOj8di81tHkRcunYn1wtYuzh XqDNQnlAa6wyt8vcP0gpp4vSvvPoiorZ3mYKq1glVKQTciW2RU4mkeEVekVbFaOHIB VjdFIvkfmN+SdxOIvmvQuRrVx9Ykkyd83yivSCXPPcFix1t9pNrj3RteUBRnffiri7 95Te6fuY3YMGppRmo5jReHWcsh2ckNXzdzlZ4k5XDnf/BTS3iA+RPHMXX++5NHalIs ivePIe8pYmt4NkbgX4Og9rw+vsbuYJuIdhoMCwuJbjQ80f+wYwrP9Q5oUXx9ejJtlj dAfODsxjJ6Rhg== Received: by pali.im (Postfix) id B87C88A3; Fri, 25 Jun 2021 00:27:11 +0200 (CEST) From: =?utf-8?q?Pali_Roh=C3=A1r?= To: Lorenzo Pieralisi , Thomas Petazzoni , Bjorn Helgaas , Rob Herring , Gregory Clement Cc: =?utf-8?q?Marek_Beh=C3=BAn?= , "Remi Pommarel" , Xogium , "Tomasz Maciej Nowak" , Nadav Haklai , Kostya Porotchkin , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [RESEND PATCH 5/5] PCI: aardvark: Implement workaround for PCIe Completion Timeout Date: Fri, 25 Jun 2021 00:26:21 +0200 Message-Id: <20210624222621.4776-6-pali@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20210624222621.4776-1-pali@kernel.org> References: <20210624222621.4776-1-pali@kernel.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210624_152712_383954_BC7C4577 X-CRM114-Status: GOOD ( 14.54 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Marvell Armada 3700 Functional Errata, Guidelines, and Restrictions document describes in erratum 3.12 PCIe Completion Timeout (Ref #: 251), that PCIe IP does not support a strong-ordered model for inbound posted vs. outbound completion. As a workaround for this erratum, DIS_ORD_CHK flag in Debug Mux Control register must be set. It disables the ordering check in the core between Completions and Posted requests received from the link. It was reported that enabling this workaround fixes instability issues and "Unhandled fault" errors when using 60 GHz WiFi 802.11ad card with Qualcomm QCA6335 chip under significant load which were caused by interrupt status stuck in the outbound CMPLT queue traced back to this erratum. This workaround fixes also kernel panic triggered after some minutes of usage 5 GHz WiFi 802.11ax card with Mediatek MT7915 chip: Internal error: synchronous external abort: 96000210 [#1] SMP Kernel panic - not syncing: Fatal exception in interrupt Signed-off-by: Thomas Petazzoni Signed-off-by: Pali Rohár Cc: stable@vger.kernel.org --- Patch was originally written by Thomas and is already for a long time part of Marvell SDK. I have just re-written/re-applied it on top of mainline kernel and also wrote a new updated commit message. Please note that this patch is questionable as Bjorn has some objections and nobody, including Marvell, was not able to explain erratum nor what is workaround exactly doing. Documentation about this topic is basically missing. We just know that it fixes real kernel crashes when using WiFi cards. --- drivers/pci/controller/pci-aardvark.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c index 9ff68abd8d1e..231f4469d87e 100644 --- a/drivers/pci/controller/pci-aardvark.c +++ b/drivers/pci/controller/pci-aardvark.c @@ -167,6 +167,8 @@ #define LTSSM_L0 0x10 #define RC_BAR_CONFIG 0x300 #define VENDOR_ID_REG (LMI_BASE_ADDR + 0x44) +#define DEBUG_MUX_CTRL_REG (LMI_BASE_ADDR + 0x208) +#define DIS_ORD_CHK BIT(30) /* PCIe core controller registers */ #define CTRL_CORE_BASE_ADDR 0x18000 @@ -450,6 +452,11 @@ static void advk_pcie_setup_hw(struct advk_pcie *pcie) PCIE_CORE_CTRL2_TD_ENABLE; advk_writel(pcie, reg, PCIE_CORE_CTRL2_REG); + /* Disable ordering checks, workaround for erratum 3.12 "PCIe completion timeout" */ + reg = advk_readl(pcie, DEBUG_MUX_CTRL_REG); + reg |= DIS_ORD_CHK; + advk_writel(pcie, reg, DEBUG_MUX_CTRL_REG); + /* Set lane X1 */ reg = advk_readl(pcie, PCIE_CORE_CTRL0_REG); reg &= ~LANE_CNT_MSK;