Linux v5.5.10

5 files changed, 5 insertions, 364 deletions

diff --git a/0001-driver-code-clarify-and-fix-platform-device-DMA-mask.patch b/0001-driver-code-clarify-and-fix-platform-device-DMA-mask.patch
deleted file mode 100644
index 873509eb0..000000000
--- a/0001-driver-code-clarify-and-fix-platform-device-DMA-mask.patch
+++ /dev/null
@@ -1,136 +0,0 @@
-From e3a36eb6dfaeea8175c05d5915dcf0b939be6dab Mon Sep 17 00:00:00 2001
-From: Christoph Hellwig <hch@lst.de>
-Date: Wed, 11 Mar 2020 17:07:10 +0100
-Subject: [PATCH] driver code: clarify and fix platform device DMA mask
- allocation
-
-This does three inter-related things to clarify the usage of the
-platform device dma_mask field. In the process, fix the bug introduced
-by cdfee5623290 ("driver core: initialize a default DMA mask for
-platform device") that caused Artem Tashkinov's laptop to not boot with
-newer Fedora kernels.
-
-This does:
-
- - First off, rename the field to "platform_dma_mask" to make it
-   greppable.
-
-   We have way too many different random fields called "dma_mask" in
-   various data structures, where some of them are actual masks, and
-   some of them are just pointers to the mask. And the structures all
-   have pointers to each other, or embed each other inside themselves,
-   and "pdev" sometimes means "platform device" and sometimes it means
-   "PCI device".
-
-   So to make it clear in the code when you actually use this new field,
-   give it a unique name (it really should be something even more unique
-   like "platform_device_dma_mask", since it's per platform device, not
-   per platform, but that gets old really fast, and this is unique
-   enough in context).
-
-   To further clarify when the field gets used, initialize it when we
-   actually start using it with the default value.
-
- - Then, use this field instead of the random one-off allocation in
-   platform_device_register_full() that is now unnecessary since we now
-   already have a perfectly fine allocation for it in the platform
-   device structure.
-
- - The above then allows us to fix the actual bug, where the error path
-   of platform_device_register_full() would unconditionally free the
-   platform device DMA allocation with 'kfree()'.
-
-   That kfree() was dont regardless of whether the allocation had been
-   done earlier with the (now removed) kmalloc, or whether
-   setup_pdev_dma_masks() had already been used and the dma_mask pointer
-   pointed to the mask that was part of the platform device.
-
-It seems most people never triggered the error path, or only triggered
-it from a call chain that set an explicit pdevinfo->dma_mask value (and
-thus caused the unnecessary allocation that was "cleaned up" in the
-error path) before calling platform_device_register_full().
-
-Robin Murphy points out that in Artem's case the wdat_wdt driver failed
-in platform_device_add(), and that was the one that had called
-platform_device_register_full() with pdevinfo.dma_mask = 0, and would
-have caused that kfree() of pdev.dma_mask corrupting the heap.
-
-A later unrelated kmalloc() then oopsed due to the heap corruption.
-
-Fixes: cdfee5623290 ("driver core: initialize a default DMA mask for platform device")
-Reported-bisected-and-tested-by:  Artem S. Tashkinov <aros@gmx.com>
-Reviewed-by: Robin Murphy <robin.murphy@arm.com>
-Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-Signed-off-by: Christoph Hellwig <hch@lst.de>
-Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
----
- drivers/base/platform.c         | 25 ++++++-------------------
- include/linux/platform_device.h |  2 +-
- 2 files changed, 7 insertions(+), 20 deletions(-)
-
-diff --git a/drivers/base/platform.c b/drivers/base/platform.c
-index 7fa654f1288b..b5ce7b085795 100644
---- a/drivers/base/platform.c
-+++ b/drivers/base/platform.c
-@@ -363,10 +363,10 @@ static void setup_pdev_dma_masks(struct platform_device *pdev)
- {
- 	if (!pdev->dev.coherent_dma_mask)
- 		pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
--	if (!pdev->dma_mask)
--		pdev->dma_mask = DMA_BIT_MASK(32);
--	if (!pdev->dev.dma_mask)
--		pdev->dev.dma_mask = &pdev->dma_mask;
-+	if (!pdev->dev.dma_mask) {
-+		pdev->platform_dma_mask = DMA_BIT_MASK(32);
-+		pdev->dev.dma_mask = &pdev->platform_dma_mask;
-+	}
- };
- 
- /**
-@@ -662,20 +662,8 @@ struct platform_device *platform_device_register_full(
- 	pdev->dev.of_node_reused = pdevinfo->of_node_reused;
- 
- 	if (pdevinfo->dma_mask) {
--		/*
--		 * This memory isn't freed when the device is put,
--		 * I don't have a nice idea for that though.  Conceptually
--		 * dma_mask in struct device should not be a pointer.
--		 * See http://thread.gmane.org/gmane.linux.kernel.pci/9081
--		 */
--		pdev->dev.dma_mask =
--			kmalloc(sizeof(*pdev->dev.dma_mask), GFP_KERNEL);
--		if (!pdev->dev.dma_mask)
--			goto err;
--
--		kmemleak_ignore(pdev->dev.dma_mask);
--
--		*pdev->dev.dma_mask = pdevinfo->dma_mask;
-+		pdev->platform_dma_mask = pdevinfo->dma_mask;
-+		pdev->dev.dma_mask = &pdev->platform_dma_mask;
- 		pdev->dev.coherent_dma_mask = pdevinfo->dma_mask;
- 	}
- 
-@@ -700,7 +688,6 @@ struct platform_device *platform_device_register_full(
- 	if (ret) {
- err:
- 		ACPI_COMPANION_SET(&pdev->dev, NULL);
--		kfree(pdev->dev.dma_mask);
- 		platform_device_put(pdev);
- 		return ERR_PTR(ret);
- 	}
-diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
-index 276a03c24691..041bfa412aa0 100644
---- a/include/linux/platform_device.h
-+++ b/include/linux/platform_device.h
-@@ -24,7 +24,7 @@ struct platform_device {
- 	int		id;
- 	bool		id_auto;
- 	struct device	dev;
--	u64		dma_mask;
-+	u64		platform_dma_mask;
- 	u32		num_resources;
- 	struct resource	*resource;
- 
--- 
-2.25.1
-
diff --git a/iommu-WARN_TAINT-fixes.patch b/iommu-WARN_TAINT-fixes.patch
deleted file mode 100644
index 34668f9ad..000000000
--- a/iommu-WARN_TAINT-fixes.patch
+++ /dev/null
@@ -1,164 +0,0 @@
-From 2f2265a8cbc6b43deb169c525204ea7df02e9363 Mon Sep 17 00:00:00 2001
-From: Hans de Goede <hdegoede@redhat.com>
-Date: Mon, 9 Mar 2020 13:55:02 +0100
-Subject: [PATCH 1/2] iommu/vt-d: dmar: replace WARN_TAINT with pr_warn +
- add_taint
-
-Quoting from the comment describing the WARN functions in
-include/asm-generic/bug.h:
-
- * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report
- * significant kernel issues that need prompt attention if they should ever
- * appear at runtime.
- *
- * Do not use these macros when checking for invalid external inputs
-
-The (buggy) firmware tables which the dmar code was calling WARN_TAINT
-for really are invalid external inputs. They are not under the kernel's
-control and the issues in them cannot be fixed by a kernel update.
-So logging a backtrace, which invites bug reports to be filed about this,
-is not helpful.
-
-Some distros, e.g. Fedora, have tools watching for the kernel backtraces
-logged by the WARN macros and offer the user an option to file a bug for
-this when these are encountered. The WARN_TAINT in warn_invalid_dmar()
-+ another iommu WARN_TAINT, addressed in another patch, have lead to over
-a 100 bugs being filed this way.
-
-This commit replaces the WARN_TAINT("...") calls, with
-pr_warn(FW_BUG "...") + add_taint(TAINT_FIRMWARE_WORKAROUND, ...) calls
-avoiding the backtrace and thus also avoiding bug-reports being filed
-about this against the kernel.
-
-BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1564895
-Fixes: e625b4a95d50 ("iommu/vt-d: Parse ANDD records")
-Fixes: fd0c8894893c ("intel-iommu: Set a more specific taint flag for invalid BI
-Cc: stable@vger.kernel.org
-Signed-off-by: Hans de Goede <hdegoede@redhat.com>
----
- drivers/iommu/dmar.c | 11 ++++++-----
- 1 file changed, 6 insertions(+), 5 deletions(-)
-
-diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
-index 071bb42bbbc5..87194a46cb0b 100644
---- a/drivers/iommu/dmar.c
-+++ b/drivers/iommu/dmar.c
-@@ -440,12 +440,13 @@ static int __init dmar_parse_one_andd(struct acpi_dmar_header *header,
- 
- 	/* Check for NUL termination within the designated length */
- 	if (strnlen(andd->device_name, header->length - 8) == header->length - 8) {
--		WARN_TAINT(1, TAINT_FIRMWARE_WORKAROUND,
-+		pr_warn(FW_BUG
- 			   "Your BIOS is broken; ANDD object name is not NUL-terminated\n"
- 			   "BIOS vendor: %s; Ver: %s; Product Version: %s\n",
- 			   dmi_get_system_info(DMI_BIOS_VENDOR),
- 			   dmi_get_system_info(DMI_BIOS_VERSION),
- 			   dmi_get_system_info(DMI_PRODUCT_VERSION));
-+		add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
- 		return -EINVAL;
- 	}
- 	pr_info("ANDD device: %x name: %s\n", andd->device_number,
-@@ -471,14 +472,14 @@ static int dmar_parse_one_rhsa(struct acpi_dmar_header *header, void *arg)
- 			return 0;
- 		}
- 	}
--	WARN_TAINT(
--		1, TAINT_FIRMWARE_WORKAROUND,
-+	pr_warn(FW_BUG
- 		"Your BIOS is broken; RHSA refers to non-existent DMAR unit at %llx\n"
- 		"BIOS vendor: %s; Ver: %s; Product Version: %s\n",
- 		drhd->reg_base_addr,
- 		dmi_get_system_info(DMI_BIOS_VENDOR),
- 		dmi_get_system_info(DMI_BIOS_VERSION),
- 		dmi_get_system_info(DMI_PRODUCT_VERSION));
-+	add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
- 
- 	return 0;
- }
-@@ -827,14 +828,14 @@ int __init dmar_table_init(void)
- 
- static void warn_invalid_dmar(u64 addr, const char *message)
- {
--	WARN_TAINT_ONCE(
--		1, TAINT_FIRMWARE_WORKAROUND,
-+	pr_warn_once(FW_BUG
- 		"Your BIOS is broken; DMAR reported at address %llx%s!\n"
- 		"BIOS vendor: %s; Ver: %s; Product Version: %s\n",
- 		addr, message,
- 		dmi_get_system_info(DMI_BIOS_VENDOR),
- 		dmi_get_system_info(DMI_BIOS_VERSION),
- 		dmi_get_system_info(DMI_PRODUCT_VERSION));
-+	add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
- }
- 
- static int __ref
--- 
-2.25.1
-
-From 038ebd8952c5fb3ba3b5e09b0b55a4e617ae22bf Mon Sep 17 00:00:00 2001
-From: Hans de Goede <hdegoede@redhat.com>
-Date: Mon, 9 Mar 2020 14:12:37 +0100
-Subject: [PATCH 2/2] iommu/vt-d: dmar_parse_one_rmrr: replace WARN_TAINT with
- pr_warn + add_taint
-
-Quoting from the comment describing the WARN functions in
-include/asm-generic/bug.h:
-
- * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report
- * significant kernel issues that need prompt attention if they should ever
- * appear at runtime.
- *
- * Do not use these macros when checking for invalid external inputs
-
-The (buggy) firmware tables which the dmar code was calling WARN_TAINT
-for really are invalid external inputs. They are not under the kernel's
-control and the issues in them cannot be fixed by a kernel update.
-So logging a backtrace, which invites bug reports to be filed about this,
-is not helpful.
-
-Some distros, e.g. Fedora, have tools watching for the kernel backtraces
-logged by the WARN macros and offer the user an option to file a bug for
-this when these are encountered. The WARN_TAINT in dmar_parse_one_rmrr
-+ another iommu WARN_TAINT, addressed in another patch, have lead to over
-a 100 bugs being filed this way.
-
-This commit replaces the WARN_TAINT("...") call, with a
-pr_warn(FW_BUG "...") + add_taint(TAINT_FIRMWARE_WORKAROUND, ...) call
-avoiding the backtrace and thus also avoiding bug-reports being filed
-about this against the kernel.
-
-BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1808874
-Fixes: f5a68bb0752e ("iommu/vt-d: Mark firmware tainted if RMRR fails sanity check")
-Cc: Barret Rhoden <brho@google.com>
-Cc: stable@vger.kernel.org
-Signed-off-by: Hans de Goede <hdegoede@redhat.com>
----
- drivers/iommu/intel-iommu.c | 6 ++++--
- 1 file changed, 4 insertions(+), 2 deletions(-)
-
-diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
-index 6fa6de2b6ad5..3857a5cd1a75 100644
---- a/drivers/iommu/intel-iommu.c
-+++ b/drivers/iommu/intel-iommu.c
-@@ -4460,14 +4460,16 @@ int __init dmar_parse_one_rmrr(struct acpi_dmar_header *header, void *arg)
- 	struct dmar_rmrr_unit *rmrru;
- 
- 	rmrr = (struct acpi_dmar_reserved_memory *)header;
--	if (arch_rmrr_sanity_check(rmrr))
--		WARN_TAINT(1, TAINT_FIRMWARE_WORKAROUND,
-+	if (arch_rmrr_sanity_check(rmrr)) {
-+		pr_warn(FW_BUG
- 			   "Your BIOS is broken; bad RMRR [%#018Lx-%#018Lx]\n"
- 			   "BIOS vendor: %s; Ver: %s; Product Version: %s\n",
- 			   rmrr->base_address, rmrr->end_address,
- 			   dmi_get_system_info(DMI_BIOS_VENDOR),
- 			   dmi_get_system_info(DMI_BIOS_VERSION),
- 			   dmi_get_system_info(DMI_PRODUCT_VERSION));
-+		add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
-+	}
- 
- 	rmrru = kzalloc(sizeof(*rmrru), GFP_KERNEL);
- 	if (!rmrru)
--- 
-2.25.1
-
diff --git a/kernel.spec b/kernel.spec
index 14cf131dc..9b8014321 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -89,7 +89,7 @@ Summary: The Linux kernel
 %if 0%{?released_kernel}
 
 # Do we have a -stable update to apply?
-%define stable_update 9
+%define stable_update 10
 # Set rpm version accordingly
 %if 0%{?stable_update}
 %define stablerev %{stable_update}
@@ -864,16 +864,6 @@ Patch508: 20200310_chris_chris_wilson_co_uk.patch
 # Backport vboxsf from 5.6, can be dropped when we move to 5.6
 Patch510: 0001-fs-Add-VirtualBox-guest-shared-folder-vboxsf-support.patch
 
-# rhbz 1800335
-Patch511: v2_20200128_dmoulding_me_com.patch
-
-# Fix backtraces triggered by warnings about buggy BIOS (rhbz 1564895, 1808874)
-# Submitted upstream
-Patch512: iommu-WARN_TAINT-fixes.patch
-
-# Fix some HP x360 models not booting (rhbz 1790115) (in mainline now)
-Patch513: 0001-driver-code-clarify-and-fix-platform-device-DMA-mask.patch
-
 # Fix UCSI oopses, (rhbz 1785972) (in gkh's usb-linus, heading towards mainline)
 Patch514: ucsi-oops-fixes.patch
 
@@ -2906,6 +2896,9 @@ fi
 #
 #
 %changelog
+* Wed Mar 18 2020 Justin M. Forbes <jforbes@fedoraproject.org> - 5.5.10-200
+- Linux v5.5.10
+
 * Sat Mar 14 2020 Hans de Goede <hdegoede@redhat.com>
 - Fix UCSI oopses (rhbz 1785972)
 
diff --git a/sources b/sources
index 4d3dad408..dcd889cb4 100644
--- a/sources
+++ b/sources
@@ -1,3 +1,2 @@
 SHA512 (linux-5.5.tar.xz) = fa74fdabb5e63384a39e54da05b86a9ae9ea16179524b041fbbdffc7177e80b53600ae98d76be127ba216148f9dc55fe07ab20637e22c6d6030cb4aa09eb2f86
-SHA512 (patch-5.5.8.xz) = 8daaea68d2eaa51966bae5de14c253daf6ae6dd65cf0541e2f94459df99031d3d4355f436d182b2b9cea5fbfee3c053ac2bc91030dfa23a9f4575996528fd508
-SHA512 (patch-5.5.9.xz) = 44f26e7bce86c149fb4ddae20306ae58dead5a4797c268409f12284c695de80bde4a1b8bb1492f51db0f36210543d4a277024481e43acda10c3bb03470bf5270
+SHA512 (patch-5.5.10.xz) = 7b83ce898dfab2fe67c8c931890470615b181b2b64b686103c0776a95f302cbca5f4b4e576dbde28af1408692ec6e7c18fb23dbec8f6255e935a137fc0b055d8
diff --git a/v2_20200128_dmoulding_me_com.patch b/v2_20200128_dmoulding_me_com.patch
deleted file mode 100644
index 2cb28be39..000000000
--- a/v2_20200128_dmoulding_me_com.patch
+++ /dev/null
@@ -1,51 +0,0 @@
-From MAILER-DAEMON Mon Feb 24 19:54:49 2020
-From: Dan Moulding <dmoulding@me.com>
-To: linux-wireless@vger.kernel.org
-Cc: johannes.berg@intel.com, emmanuel.grumbach@intel.com, luciano.coelho@intel.com, linuxwifi@intel.com, Dan Moulding <dmoulding@me.com>
-Subject: [PATCH v2 5.5] iwlwifi: mvm: Do not require PHY_SKU NVM section for 3168 devices
-Date: Tue, 28 Jan 2020 02:31:07 -0700
-Message-Id: <20200128093107.9740-1-dmoulding@me.com>
-Sender: linux-wireless-owner@vger.kernel.org
-List-ID: <linux-wireless.vger.kernel.org>
-X-Mailing-List: linux-wireless@vger.kernel.org
-MIME-Version: 1.0
-Content-Type: text/plain; charset="utf-8"
-Content-Transfer-Encoding: 7bit
-
-The logic for checking required NVM sections was recently fixed in
-commit b3f20e098293 ("iwlwifi: mvm: fix NVM check for 3168
-devices"). However, with that fixed the else is now taken for 3168
-devices and within the else clause there is a mandatory check for the
-PHY_SKU section. This causes the parsing to fail for 3168 devices.
-
-The PHY_SKU section is really only mandatory for the IWL_NVM_EXT
-layout (the phy_sku parameter of iwl_parse_nvm_data is only used when
-the NVM type is IWL_NVM_EXT). So this changes the PHY_SKU section
-check so that it's only mandatory for IWL_NVM_EXT.
-
-Fixes: b3f20e098293 ("iwlwifi: mvm: fix NVM check for 3168 devices")
-Signed-off-by: Dan Moulding <dmoulding@me.com>
----
-v2: Fixed incorrect commit title in commit references in the commit message
-
- drivers/net/wireless/intel/iwlwifi/mvm/nvm.c | 3 ++-
- 1 file changed, 2 insertions(+), 1 deletion(-)
-
-diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/nvm.c b/drivers/net/wireless/intel/iwlwifi/mvm/nvm.c
-index 46128a2a9c6e..e98ce380c7b9 100644
---- a/drivers/net/wireless/intel/iwlwifi/mvm/nvm.c
-+++ b/drivers/net/wireless/intel/iwlwifi/mvm/nvm.c
-@@ -308,7 +308,8 @@ iwl_parse_nvm_sections(struct iwl_mvm *mvm)
- 		}
- 
- 		/* PHY_SKU section is mandatory in B0 */
--		if (!mvm->nvm_sections[NVM_SECTION_TYPE_PHY_SKU].data) {
-+		if (mvm->trans->cfg->nvm_type == IWL_NVM_EXT &&
-+		    !mvm->nvm_sections[NVM_SECTION_TYPE_PHY_SKU].data) {
- 			IWL_ERR(mvm,
- 				"Can't parse phy_sku in B0, empty sections\n");
- 			return NULL;
--- 
-2.24.1
-
-