Message ID | 20231101114957.309902-1-jiaxun.yang@flygoat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:abcd:0:b0:403:3b70:6f57 with SMTP id f13csp501799vqx; Wed, 1 Nov 2023 08:28:14 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGAmalT0LExAGxgumRG08+GvQR+YMUgZRmNP9DFfNxxM1+R+R7GDdqyTyZv4g5dsNJzYwnc X-Received: by 2002:a05:6871:4594:b0:1e9:b653:94d with SMTP id nl20-20020a056871459400b001e9b653094dmr18867458oab.1.1698852494625; Wed, 01 Nov 2023 08:28:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698852494; cv=none; d=google.com; s=arc-20160816; b=WPls6r9QDY5Bu86VwmXAXwiGPk1djJgoaXBqlYO7tTKiEo1oFlCiuVxVOn7aS3PHrG fL3bZtiWyH1D0ywomIoUajSFaITuYN9oCJj4EqzWkbEjoSPpliXfBNwOG88NFM5dBrqT 09JkHUSGUJiH4fnvjsPPaZPi4F65UMJEJChQHkRvFXzY2I1hBjgR1qx60Ty6IhbGnrxh WgYoVConPzWXNDZESbMwcFXY/tJCeT8vLMXHHoMEOE83fCGQKzXQNBeMNAyCDAHOOcIf 7GI7go+Cles/VdY422x6I1dEdTrzxj2mho5HlABq4wflQeHU4LtVReb3p/fZa56y6+9v klMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:feedback-id:dkim-signature :dkim-signature; bh=xCnRAnA71025ehVLm6DUJDLfmLjVFEx/xgBZes9V/dA=; fh=ty5JuqHk0Qk00XZ6GNb8HL58/5b15pyqC9qpwOjFr1E=; b=VoO7Iq9yTQEfUgqJ0nfV80jLSsayiNvZT4sq7+rRITt07D1hCoVvdAoCYL9gtr+QKs wieYceDnddpe8r4nBx9NRarqV1R0eoFsUWNudy45MjPQBDzFHEdIjlt0pU4bcY6dZtnS JAvlcm+wdraozDYv2aPWRwbt8VYj6KuonxnExrLRvcr9zT2r/hVp8n/T9Ta/oWhtFAZ9 w0YcNNyctWg/BmBiEFqJeLF1XADIGywI1xwz87UkQ86ajAUtm22VlvmSfVQCoqoRJl0+ rqZBGvkz5cNHI0I/9da7mQ/VoiETURrRYgIpYjsDMhb4N2Aie6IvxVU/4m8E7yONr8+Y ieIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@flygoat.com header.s=fm1 header.b=kBENrH7S; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=qjaQR+W3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=flygoat.com Received: from agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id 82-20020a630155000000b005bd03bdf81asi91588pgb.472.2023.11.01.08.28.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Nov 2023 08:28:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; dkim=pass header.i=@flygoat.com header.s=fm1 header.b=kBENrH7S; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=qjaQR+W3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=flygoat.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 787CA80C5990; Wed, 1 Nov 2023 08:27:45 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234050AbjKAP1J (ORCPT <rfc822;rbbytesnap@gmail.com> + 35 others); Wed, 1 Nov 2023 11:27:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49998 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233988AbjKAP1I (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 1 Nov 2023 11:27:08 -0400 Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7B47310D; Wed, 1 Nov 2023 08:27:00 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id DF8435C0040; Wed, 1 Nov 2023 11:26:59 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Wed, 01 Nov 2023 11:26:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=flygoat.com; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm1; t=1698852419; x=1698938819; bh=xCnRAnA710 25ehVLm6DUJDLfmLjVFEx/xgBZes9V/dA=; b=kBENrH7S2umwB4PdiCaqfVEjkL nKBfOC5EqCyFigYEptqPEReGYTl6QVrhbwN7N4nQ0FS68gLl0IGSLqkoNDRTeDGm OlR8XKMLtVaWrAjM+kk6cPLZ1IodS/5g3HmrSykvvjxquyNDT603gs38c39vbv8c yACp+PJYnj5SL4OunYZ5E1j2PUQ8RPOhVKamQ789cRSls4Q84ba4frpClW8e70p/ Ho+tEfb+OkuCNcpcrPPSxcuJ4tC+9HCmgljukPErtwLtK5lWyxp/qZdP6aQVWCd+ my2XJFO95SrOVIb07jZKTNY34Tioe7IjYkzXgHhzb46bos/1CWG3FtMmJB6Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1698852419; x=1698938819; bh=xCnRAnA71025e hVLm6DUJDLfmLjVFEx/xgBZes9V/dA=; b=qjaQR+W3EXidVbIK1IqFsd28zCbLA WfE1ybQfLajdBbdRTWXML5E6SWNJRWFja6UKc8fMV7wbrZnJC/0JtAY0fitf1OfM AzbGcGDvxzpEjtQymolYdRq+w5iD7kEgjHFm1iEqp55j0aUUpIT1Us1FIyXQ1COw fNltEfnwdh2BHJQXo4x3mko65nzlCurLM3FqG41v2cNVdQwE2X6k5rtVZlZyhlLE Dnu8v2y6RhbXqVsq7ZMd1lCi8SYr/LTNZFUS/o1XUN0JV4mBOvnJ/ruJydfzT20S tyd5M8S/RAzFltWY7a8pX508NGomgC7tnojNRonTxWoZC8hl6/d/Qijow== X-ME-Sender: <xms:Q25CZTcB8cq7Ca3JwoQUOnRCSVH5ElZ0579_QXhlVlUrhlHP6uWvlw> <xme:Q25CZZMKXwjkVQBGfvBPY06XCN692VyocaSdhU27Cp0Idar4O_ypIOcaAxYpqjQzW I14h_fW7PQ3mRDoZQs> X-ME-Received: <xmr:Q25CZcjq2yThEZRgNkCYcaQD48B3uw4AwuYYR-olxgOADBtXVM_NGLKZpAVDN_8djG66ptRoLLE> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddtgedgjeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvfevufffkffoggfgsedtkeertd ertddtnecuhfhrohhmpeflihgrgihunhcujggrnhhguceojhhirgiguhhnrdihrghnghes fhhlhihgohgrthdrtghomheqnecuggftrfgrthhtvghrnhepvdeuteekleeuudfgueethe dtuddthfdtleffgefhieehfeeigedvtdeuveetiedunecuffhomhgrihhnpehkvghrnhgv lhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehjihgrgihunhdrhigrnhhgsehflhihghhorghtrdgtohhm X-ME-Proxy: <xmx:Q25CZU8T1mtLcXLfWLaB5TSydqIBkD_InmISZ4tvbIgnfNGvQ4EXPA> <xmx:Q25CZfv2lspI0jHApafI2BC8fYnknvf8b6ZiwP8XDzFdnZrfk-X1lw> <xmx:Q25CZTFHd767d3dxo8orDSA51nhTu6RlqGaAiR3xzZSalIgYMcD5gA> <xmx:Q25CZTgijUFXCu_0tKGEYzOdBDkjlAIMcsZR096XwjvM4Trf8MV_Vw> Feedback-ID: ifd894703:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 1 Nov 2023 11:26:58 -0400 (EDT) From: Jiaxun Yang <jiaxun.yang@flygoat.com> To: linux-pci@vger.kernel.org Cc: lpieralisi@kernel.org, kw@linux.com, robh@kernel.org, linux-kernel@vger.kernel.org, chenhuacai@kernel.org, Jiaxun Yang <jiaxun.yang@flygoat.com>, stable@vger.kernel.org Subject: [PATCH fixes v4] pci: loongson: Workaround MIPS firmware MRRS settings Date: Wed, 1 Nov 2023 11:49:56 +0000 Message-Id: <20231101114957.309902-1-jiaxun.yang@flygoat.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.2 required=5.0 tests=DATE_IN_PAST_03_06,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Wed, 01 Nov 2023 08:27:45 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781375896841633230 X-GMAIL-MSGID: 1781375953315784517 |
Series |
[fixes,v4] pci: loongson: Workaround MIPS firmware MRRS settings
|
|
Commit Message
Jiaxun Yang
Nov. 1, 2023, 11:49 a.m. UTC
This is a partial revert of commit 8b3517f88ff2 ("PCI:
loongson: Prevent LS7A MRRS increases") for MIPS based Loongson.
There are many MIPS based Loongson systems in wild that
shipped with firmware which does not set maximum MRRS properly.
Limiting MRRS to 256 for all as MIPS Loongson comes with higher
MRRS support is considered rare.
It must be done at device enablement stage because hardware will
reset MRRS to inavlid value if a device got disabled.
Cc: stable@vger.kernel.org
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217680
Fixes: 8b3517f88ff2 ("PCI: loongson: Prevent LS7A MRRS increases")
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
---
v4: Improve commit message
This is a partial revert of the origin quirk so there shouldn't
be any drama.
---
drivers/pci/controller/pci-loongson.c | 38 +++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
Comments
On Wed, Nov 01, 2023 at 11:49:56AM +0000, Jiaxun Yang wrote: > This is a partial revert of commit 8b3517f88ff2 ("PCI: > loongson: Prevent LS7A MRRS increases") for MIPS based Loongson. Thanks for this patch. We're in the v6.7 merge window, so we won't start merging v6.8 content until v6.7-rc1 (probably Nov 12). > There are many MIPS based Loongson systems in wild that > shipped with firmware which does not set maximum MRRS properly. As far as I know, there's no requirement for firmware to set MRRS at all *except* for the "no_inc_mrrs" hack added by 8b3517f88ff2. That hack treats the current MRRS value as a limit to work around the Loongson bug that read requests larger than the limit cause a Completer Abort instead of multiple completions. > Limiting MRRS to 256 for all as MIPS Loongson comes with higher > MRRS support is considered rare. > > It must be done at device enablement stage because hardware will > reset MRRS to inavlid value if a device got disabled. s/inavlid/invalid/ This part isn't clear to me, though. What exactly does "device got disabled" mean? The device got reset? Power cycled? PCI_COMMAND_MASTER was cleared? PCI_FIXUP_ENABLE quirks are run during pci_enable_device(), which basically just turns on PCI_COMMAND_MEMORY and/or PCI_COMMAND_IO. If MRRS gets reset when PCI_COMMAND_MASTER is set or cleared, we don't have a quirk phase that runs during pci_set_master(), which is where PCI_COMMAND_MASTER gets set, so it's not clear that pci_enable_device() is the right place. > Cc: stable@vger.kernel.org > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217680 > Fixes: 8b3517f88ff2 ("PCI: loongson: Prevent LS7A MRRS increases") > Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> We'll look for an ack from the maintainer. Maybe that's you, since you added the driver in the first place? Or maybe it's Huacai? MAINTAINERS currently doesn't list anybody for drivers/pci/controller/pci-loongson.c, and it should. That should be a separate patch. > --- > v4: Improve commit message > > This is a partial revert of the origin quirk so there shouldn't > be any drama. > --- > drivers/pci/controller/pci-loongson.c | 38 +++++++++++++++++++++++++++ > 1 file changed, 38 insertions(+) > > diff --git a/drivers/pci/controller/pci-loongson.c b/drivers/pci/controller/pci-loongson.c > index d45e7b8dc530..d184d7b97e54 100644 > --- a/drivers/pci/controller/pci-loongson.c > +++ b/drivers/pci/controller/pci-loongson.c > @@ -108,6 +108,44 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_LOONGSON, > DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_LOONGSON, > DEV_LS7A_PCIE_PORT6, loongson_mrrs_quirk); > > +#ifdef CONFIG_MIPS > +static void loongson_old_mrrs_quirk(struct pci_dev *pdev) > +{ > + struct pci_bus *bus = pdev->bus; > + struct pci_dev *bridge; > + static const struct pci_device_id bridge_devids[] = { > + { PCI_VDEVICE(LOONGSON, DEV_LS2K_PCIE_PORT0) }, > + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT0) }, > + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT1) }, > + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT2) }, > + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT3) }, > + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT4) }, > + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT5) }, > + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT6) }, This looks like the same list of devices as for loongson_mrrs_quirk(). So I guess the idea is that we need loongson_mrrs_quirk() for Loongarch-based systems, and this loongson_old_mrrs_quirk() for MIPS-based systems? If so, maybe they could be #ifdef'd to show that, e.g., so that only one or the other is compiled? > + { 0, }, > + }; > + > + /* look for the matching bridge */ > + while (!pci_is_root_bus(bus)) { > + bridge = bus->self; > + bus = bus->parent; > + /* > + * There are still some wild MIPS Loongson firmware won't > + * set MRRS properly. Limiting MRRS to 256 as MIPS Loongson > + * comes with higher MRRS support is considered rare. > + */ > + if (pci_match_id(bridge_devids, bridge)) { > + if (pcie_get_readrq(pdev) > 256) { > + pci_info(pdev, "limiting MRRS to 256\n"); > + pcie_set_readrq(pdev, 256); > + } > + break; > + } > + } > +} > +DECLARE_PCI_FIXUP_ENABLE(PCI_ANY_ID, PCI_ANY_ID, loongson_old_mrrs_quirk); > +#endif > + > static void loongson_pci_pin_quirk(struct pci_dev *pdev) > { > pdev->pin = 1 + (PCI_FUNC(pdev->devfn) & 3); > -- > 2.34.1 >
在2023年11月1日十一月 下午10:02,Bjorn Helgaas写道: > On Wed, Nov 01, 2023 at 11:49:56AM +0000, Jiaxun Yang wrote: >> This is a partial revert of commit 8b3517f88ff2 ("PCI: >> loongson: Prevent LS7A MRRS increases") for MIPS based Loongson. > > Thanks for this patch. We're in the v6.7 merge window, so we won't > start merging v6.8 content until v6.7-rc1 (probably Nov 12). > >> There are many MIPS based Loongson systems in wild that >> shipped with firmware which does not set maximum MRRS properly. > > As far as I know, there's no requirement for firmware to set MRRS at > all *except* for the "no_inc_mrrs" hack added by 8b3517f88ff2. That > hack treats the current MRRS value as a limit to work around the > Loongson bug that read requests larger than the limit cause a > Completer Abort instead of multiple completions. Yep, it happens that we can't trust MRRS left by firmware on MIPS Loongson. > >> Limiting MRRS to 256 for all as MIPS Loongson comes with higher >> MRRS support is considered rare. >> >> It must be done at device enablement stage because hardware will >> reset MRRS to inavlid value if a device got disabled. > > s/inavlid/invalid/ > > This part isn't clear to me, though. What exactly does "device got > disabled" mean? The device got reset? Power cycled? > PCI_COMMAND_MASTER was cleared? > > PCI_FIXUP_ENABLE quirks are run during pci_enable_device(), which > basically just turns on PCI_COMMAND_MEMORY and/or PCI_COMMAND_IO. > > If MRRS gets reset when PCI_COMMAND_MASTER is set or cleared, we don't > have a quirk phase that runs during pci_set_master(), which is where > PCI_COMMAND_MASTER gets set, so it's not clear that > pci_enable_device() is the right place. I should make myself clear that MRRS reset actually happens when the PCIe port (i.e. the PCI to PCI bridge) lose it's PCI_COMMAND_MASTER. Since pci_enable_bridge is called by pci_enable_device it is still the best place for such quirk. I'll amend the commit message to make it clear. > >> Cc: stable@vger.kernel.org >> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217680 >> Fixes: 8b3517f88ff2 ("PCI: loongson: Prevent LS7A MRRS increases") >> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> > > We'll look for an ack from the maintainer. Maybe that's you, since > you added the driver in the first place? Or maybe it's Huacai? I'm dumb to ACPI enabled Loongson so I think Huacai must be the maintainer but I'd like to take care of this driver as well, perhaps having two M entry or give me an R entry? Huacai, what's your opinion? > > MAINTAINERS currently doesn't list anybody for > drivers/pci/controller/pci-loongson.c, and it should. That should be > a separate patch. > >> --- >> v4: Improve commit message >> >> This is a partial revert of the origin quirk so there shouldn't >> be any drama. >> --- >> drivers/pci/controller/pci-loongson.c | 38 +++++++++++++++++++++++++++ >> 1 file changed, 38 insertions(+) >> >> diff --git a/drivers/pci/controller/pci-loongson.c b/drivers/pci/controller/pci-loongson.c >> index d45e7b8dc530..d184d7b97e54 100644 >> --- a/drivers/pci/controller/pci-loongson.c >> +++ b/drivers/pci/controller/pci-loongson.c >> @@ -108,6 +108,44 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_LOONGSON, >> DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_LOONGSON, >> DEV_LS7A_PCIE_PORT6, loongson_mrrs_quirk); >> >> +#ifdef CONFIG_MIPS >> +static void loongson_old_mrrs_quirk(struct pci_dev *pdev) >> +{ >> + struct pci_bus *bus = pdev->bus; >> + struct pci_dev *bridge; >> + static const struct pci_device_id bridge_devids[] = { >> + { PCI_VDEVICE(LOONGSON, DEV_LS2K_PCIE_PORT0) }, >> + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT0) }, >> + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT1) }, >> + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT2) }, >> + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT3) }, >> + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT4) }, >> + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT5) }, >> + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT6) }, > > This looks like the same list of devices as for loongson_mrrs_quirk(). > So I guess the idea is that we need loongson_mrrs_quirk() for > Loongarch-based systems, and this loongson_old_mrrs_quirk() for > MIPS-based systems? > > If so, maybe they could be #ifdef'd to show that, e.g., so that only > one or the other is compiled? I think no_inc_mrrs still needs to be set for those devices so I left the "new" quirk enabled for MIPS as well here. But we can also do it in "old" quirk with an extra match, will do in next version. [...]
On Wed, Nov 1, 2023 at 11:27 PM Jiaxun Yang <jiaxun.yang@flygoat.com> wrote: > > This is a partial revert of commit 8b3517f88ff2 ("PCI: > loongson: Prevent LS7A MRRS increases") for MIPS based Loongson. > > There are many MIPS based Loongson systems in wild that > shipped with firmware which does not set maximum MRRS properly. > > Limiting MRRS to 256 for all as MIPS Loongson comes with higher > MRRS support is considered rare. > > It must be done at device enablement stage because hardware will > reset MRRS to inavlid value if a device got disabled. > > Cc: stable@vger.kernel.org > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217680 > Fixes: 8b3517f88ff2 ("PCI: loongson: Prevent LS7A MRRS increases") > Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> > --- > v4: Improve commit message > > This is a partial revert of the origin quirk so there shouldn't > be any drama. > --- > drivers/pci/controller/pci-loongson.c | 38 +++++++++++++++++++++++++++ > 1 file changed, 38 insertions(+) > > diff --git a/drivers/pci/controller/pci-loongson.c b/drivers/pci/controller/pci-loongson.c > index d45e7b8dc530..d184d7b97e54 100644 > --- a/drivers/pci/controller/pci-loongson.c > +++ b/drivers/pci/controller/pci-loongson.c > @@ -108,6 +108,44 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_LOONGSON, > DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_LOONGSON, > DEV_LS7A_PCIE_PORT6, loongson_mrrs_quirk); > > +#ifdef CONFIG_MIPS > +static void loongson_old_mrrs_quirk(struct pci_dev *pdev) > +{ > + struct pci_bus *bus = pdev->bus; > + struct pci_dev *bridge; > + static const struct pci_device_id bridge_devids[] = { > + { PCI_VDEVICE(LOONGSON, DEV_LS2K_PCIE_PORT0) }, > + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT0) }, > + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT1) }, > + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT2) }, > + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT3) }, > + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT4) }, > + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT5) }, > + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT6) }, > + { 0, }, > + }; > + > + /* look for the matching bridge */ > + while (!pci_is_root_bus(bus)) { > + bridge = bus->self; > + bus = bus->parent; > + /* > + * There are still some wild MIPS Loongson firmware won't > + * set MRRS properly. Limiting MRRS to 256 as MIPS Loongson > + * comes with higher MRRS support is considered rare. > + */ > + if (pci_match_id(bridge_devids, bridge)) { > + if (pcie_get_readrq(pdev) > 256) { > + pci_info(pdev, "limiting MRRS to 256\n"); > + pcie_set_readrq(pdev, 256); > + } > + break; > + } > + } > +} > +DECLARE_PCI_FIXUP_ENABLE(PCI_ANY_ID, PCI_ANY_ID, loongson_old_mrrs_quirk); > +#endif Rename it to loongson_set_min_mrrs() and move it before loongson_mrrs_quirk() may be better. Huacai > + > static void loongson_pci_pin_quirk(struct pci_dev *pdev) > { > pdev->pin = 1 + (PCI_FUNC(pdev->devfn) & 3); > -- > 2.34.1 >
diff --git a/drivers/pci/controller/pci-loongson.c b/drivers/pci/controller/pci-loongson.c index d45e7b8dc530..d184d7b97e54 100644 --- a/drivers/pci/controller/pci-loongson.c +++ b/drivers/pci/controller/pci-loongson.c @@ -108,6 +108,44 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_LOONGSON, DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_LOONGSON, DEV_LS7A_PCIE_PORT6, loongson_mrrs_quirk); +#ifdef CONFIG_MIPS +static void loongson_old_mrrs_quirk(struct pci_dev *pdev) +{ + struct pci_bus *bus = pdev->bus; + struct pci_dev *bridge; + static const struct pci_device_id bridge_devids[] = { + { PCI_VDEVICE(LOONGSON, DEV_LS2K_PCIE_PORT0) }, + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT0) }, + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT1) }, + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT2) }, + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT3) }, + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT4) }, + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT5) }, + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT6) }, + { 0, }, + }; + + /* look for the matching bridge */ + while (!pci_is_root_bus(bus)) { + bridge = bus->self; + bus = bus->parent; + /* + * There are still some wild MIPS Loongson firmware won't + * set MRRS properly. Limiting MRRS to 256 as MIPS Loongson + * comes with higher MRRS support is considered rare. + */ + if (pci_match_id(bridge_devids, bridge)) { + if (pcie_get_readrq(pdev) > 256) { + pci_info(pdev, "limiting MRRS to 256\n"); + pcie_set_readrq(pdev, 256); + } + break; + } + } +} +DECLARE_PCI_FIXUP_ENABLE(PCI_ANY_ID, PCI_ANY_ID, loongson_old_mrrs_quirk); +#endif + static void loongson_pci_pin_quirk(struct pci_dev *pdev) { pdev->pin = 1 + (PCI_FUNC(pdev->devfn) & 3);