--- /dev/null
+From b8da302e2955fe4d41eb9d48199242674d77dbe0 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Marek=20Beh=C3=BAn?= <kabel@kernel.org>
+Date: Thu, 24 Jun 2021 19:14:17 +0200
+Subject: PCI: Call Max Payload Size-related fixup quirks early
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Marek Behún <kabel@kernel.org>
+
+commit b8da302e2955fe4d41eb9d48199242674d77dbe0 upstream.
+
+pci_device_add() calls HEADER fixups after pci_configure_device(), which
+configures Max Payload Size.
+
+Convert MPS-related fixups to EARLY fixups so pci_configure_mps() takes
+them into account.
+
+Fixes: 27d868b5e6cfa ("PCI: Set MPS to match upstream bridge")
+Link: https://lore.kernel.org/r/20210624171418.27194-1-kabel@kernel.org
+Signed-off-by: Marek Behún <kabel@kernel.org>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/quirks.c | 12 ++++++------
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -2994,12 +2994,12 @@ static void fixup_mpss_256(struct pci_de
+ {
+ dev->pcie_mpss = 1; /* 256 bytes */
+ }
+-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SOLARFLARE,
+- PCI_DEVICE_ID_SOLARFLARE_SFC4000A_0, fixup_mpss_256);
+-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SOLARFLARE,
+- PCI_DEVICE_ID_SOLARFLARE_SFC4000A_1, fixup_mpss_256);
+-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SOLARFLARE,
+- PCI_DEVICE_ID_SOLARFLARE_SFC4000B, fixup_mpss_256);
++DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SOLARFLARE,
++ PCI_DEVICE_ID_SOLARFLARE_SFC4000A_0, fixup_mpss_256);
++DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SOLARFLARE,
++ PCI_DEVICE_ID_SOLARFLARE_SFC4000A_1, fixup_mpss_256);
++DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SOLARFLARE,
++ PCI_DEVICE_ID_SOLARFLARE_SFC4000B, fixup_mpss_256);
+
+ /* Intel 5000 and 5100 Memory controllers have an errata with read completion
+ * coalescing (which is enabled by default on some BIOSes) and MPS of 256B.
--- /dev/null
+From a729691b541f6e63043beae72e635635abe5dc09 Mon Sep 17 00:00:00 2001
+From: Paul Gortmaker <paul.gortmaker@windriver.com>
+Date: Sun, 30 May 2021 12:24:47 -0400
+Subject: x86/reboot: Limit Dell Optiplex 990 quirk to early BIOS versions
+
+From: Paul Gortmaker <paul.gortmaker@windriver.com>
+
+commit a729691b541f6e63043beae72e635635abe5dc09 upstream.
+
+When this platform was relatively new in November 2011, with early BIOS
+revisions, a reboot quirk was added in commit 6be30bb7d750 ("x86/reboot:
+Blacklist Dell OptiPlex 990 known to require PCI reboot")
+
+However, this quirk (and several others) are open-ended to all BIOS
+versions and left no automatic expiry if/when the system BIOS fixed the
+issue, meaning that nobody is likely to come along and re-test.
+
+What is really problematic with using PCI reboot as this quirk does, is
+that it causes this platform to do a full power down, wait one second,
+and then power back on. This is less than ideal if one is using it for
+boot testing and/or bisecting kernels when legacy rotating hard disks
+are installed.
+
+It was only by chance that the quirk was noticed in dmesg - and when
+disabled it turned out that it wasn't required anymore (BIOS A24), and a
+default reboot would work fine without the "harshness" of power cycling the
+machine (and disks) down and up like the PCI reboot does.
+
+Doing a bit more research, it seems that the "newest" BIOS for which the
+issue was reported[1] was version A06, however Dell[2] seemed to suggest
+only up to and including version A05, with the A06 having a large number of
+fixes[3] listed.
+
+As is typical with a new platform, the initial BIOS updates come frequently
+and then taper off (and in this case, with a revival for CPU CVEs); a
+search for O990-A<ver>.exe reveals the following dates:
+
+ A02 16 Mar 2011
+ A03 11 May 2011
+ A06 14 Sep 2011
+ A07 24 Oct 2011
+ A10 08 Dec 2011
+ A14 06 Sep 2012
+ A16 15 Oct 2012
+ A18 30 Sep 2013
+ A19 23 Sep 2015
+ A20 02 Jun 2017
+ A23 07 Mar 2018
+ A24 21 Aug 2018
+
+While it's overkill to flash and test each of the above, it would seem
+likely that the issue was contained within A0x BIOS versions, given the
+dates above and the dates of issue reports[4] from distros. So rather than
+just throw out the quirk entirely, limit the scope to just those early BIOS
+versions, in case people are still running systems from 2011 with the
+original as-shipped early A0x BIOS versions.
+
+[1] https://lore.kernel.org/lkml/1320373471-3942-1-git-send-email-trenn@suse.de/
+[2] https://www.dell.com/support/kbdoc/en-ca/000131908/linux-based-operating-systems-stall-upon-reboot-on-optiplex-390-790-990-systems
+[3] https://www.dell.com/support/home/en-ca/drivers/driversdetails?driverid=85j10
+[4] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/768039
+
+Fixes: 6be30bb7d750 ("x86/reboot: Blacklist Dell OptiPlex 990 known to require PCI reboot")
+Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20210530162447.996461-4-paul.gortmaker@windriver.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/reboot.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/reboot.c
++++ b/arch/x86/kernel/reboot.c
+@@ -389,10 +389,11 @@ static struct dmi_system_id __initdata r
+ },
+ { /* Handle problems with rebooting on the OptiPlex 990. */
+ .callback = set_pci_reboot,
+- .ident = "Dell OptiPlex 990",
++ .ident = "Dell OptiPlex 990 BIOS A0x",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 990"),
++ DMI_MATCH(DMI_BIOS_VERSION, "A0"),
+ },
+ },
+ { /* Handle problems with rebooting on Dell 300's */
projects / thirdparty / kernel / stable-queue.git / commitdiff
