Merge remote-tracking branch 'origin/f31' into f31-user-thl-vanilla-fedora

7 files changed, 92 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/0001-locks-fix-a-potential-use-after-free-problem-when-wa.patch b/0001-locks-fix-a-potential-use-after-free-problem-when-wa.patch
new file mode 100644
index 000000000..65c6ba487
--- /dev/null
+++ b/0001-locks-fix-a-potential-use-after-free-problem-when-wa.patch
@@ -0,0 +1,77 @@
+From 6d390e4b5d48ec03bb87e63cf0a2bff5f4e116da Mon Sep 17 00:00:00 2001
+From: yangerkun <yangerkun@huawei.com>
+Date: Wed, 4 Mar 2020 15:25:56 +0800
+Subject: [PATCH] locks: fix a potential use-after-free problem when wakeup a
+ waiter
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+'16306a61d3b7 ("fs/locks: always delete_block after waiting.")' add the
+logic to check waiter->fl_blocker without blocked_lock_lock. And it will
+trigger a UAF when we try to wakeup some waiter：
+
+Thread 1 has create a write flock a on file, and now thread 2 try to
+unlock and delete flock a, thread 3 try to add flock b on the same file.
+
+Thread2                         Thread3
+                                flock syscall(create flock b)
+	                        ...flock_lock_inode_wait
+				    flock_lock_inode(will insert
+				    our fl_blocked_member list
+				    to flock a's fl_blocked_requests)
+				   sleep
+flock syscall(unlock)
+...flock_lock_inode_wait
+    locks_delete_lock_ctx
+    ...__locks_wake_up_blocks
+        __locks_delete_blocks(
+	b->fl_blocker = NULL)
+	...
+                                   break by a signal
+				   locks_delete_block
+				    b->fl_blocker == NULL &&
+				    list_empty(&b->fl_blocked_requests)
+	                            success, return directly
+				 locks_free_lock b
+	wake_up(&b->fl_waiter)
+	trigger UAF
+
+Fix it by remove this logic, and this patch may also fix CVE-2019-19769.
+
+Cc: stable@vger.kernel.org
+Fixes: 16306a61d3b7 ("fs/locks: always delete_block after waiting.")
+Signed-off-by: yangerkun <yangerkun@huawei.com>
+Signed-off-by: Jeff Layton <jlayton@kernel.org>
+---
+ fs/locks.c | 14 --------------
+ 1 file changed, 14 deletions(-)
+
+diff --git a/fs/locks.c b/fs/locks.c
+index 44b6da032842..426b55d333d5 100644
+--- a/fs/locks.c
++++ b/fs/locks.c
+@@ -753,20 +753,6 @@ int locks_delete_block(struct file_lock *waiter)
+ {
+ 	int status = -ENOENT;
+
+-	/*
+-	 * If fl_blocker is NULL, it won't be set again as this thread
+-	 * "owns" the lock and is the only one that might try to claim
+-	 * the lock.  So it is safe to test fl_blocker locklessly.
+-	 * Also if fl_blocker is NULL, this waiter is not listed on
+-	 * fl_blocked_requests for some lock, so no other request can
+-	 * be added to the list of fl_blocked_requests for this
+-	 * request.  So if fl_blocker is NULL, it is safe to
+-	 * locklessly check if fl_blocked_requests is empty.  If both
+-	 * of these checks succeed, there is no need to take the lock.
+-	 */
+-	if (waiter->fl_blocker == NULL &&
+-	    list_empty(&waiter->fl_blocked_requests))
+-		return status;
+ 	spin_lock(&blocked_lock_lock);
+ 	if (waiter->fl_blocker)
+ 		status = 0;
+-- 
+2.25.2
+
diff --git a/efi-secureboot.patch b/efi-secureboot.patch
index cda57a471..227805e8c 100644
--- a/efi-secureboot.patch
+++ b/efi-secureboot.patch
@@ -303,7 +303,7 @@ index 77ea96b794bd..a119e1bc9623 100644
 +
 +#ifdef CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT
 +	if (efi_enabled(EFI_SECURE_BOOT))
-+		security_lock_kernel_down("EFI Secure Boot mode", LOCKDOWN_CONFIDENTIALITY_MAX);
++		security_lock_kernel_down("EFI Secure Boot mode", LOCKDOWN_INTEGRITY_MAX);
 +#endif
 +
  	dmi_setup();
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 02424d3a1..41357f8a6 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -885,19 +885,12 @@ 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
 
+# CVE-2019-19769 rhbz 1786174 1786175
+Patch515: 0001-locks-fix-a-potential-use-after-free-problem-when-wa.patch
+
 # END OF PATCH DEFINITIONS
 
 %endif
@@ -2930,6 +2923,15 @@ fi
 #
 #
 %changelog
+* Fri Mar 20 2020 Jeremy Cline <jcline@redhat.com>
+- Switch Secure Boot to lock down to integrity mode (rhbz 1815571)
+
+* Fri Mar 20 2020 Justin M. Forbes <jforbes@fedoraproject.org>
+- Fix CVE-2019-19769 (rhbz 1786174 1786175)
+
+* 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/s390-Lock-down-the-kernel-when-the-IPL-secure-flag-i.patch b/s390-Lock-down-the-kernel-when-the-IPL-secure-flag-i.patch
index 0779418b4..70e3f76a8 100644
--- a/s390-Lock-down-the-kernel-when-the-IPL-secure-flag-i.patch
+++ b/s390-Lock-down-the-kernel-when-the-IPL-secure-flag-i.patch
@@ -3,7 +3,7 @@ From: Jeremy Cline <jcline@redhat.com>
 Date: Wed, 30 Oct 2019 14:37:49 +0000
 Subject: [PATCH] s390: Lock down the kernel when the IPL secure flag is set
 
-Automatically lock down the kernel to LOCKDOWN_CONFIDENTIALITY_MAX if
+Automatically lock down the kernel to LOCKDOWN_INTEGRITY_MAX if
 the IPL secure flag is set.
 
 Suggested-by: Philipp Rudo <prudo@redhat.com>
@@ -56,7 +56,7 @@ index 9cbf490fd162..0510ecdfc3f6 100644
  	log_component_list();
  
 +	if (ipl_get_secureboot())
-+		security_lock_kernel_down("Secure IPL mode", LOCKDOWN_CONFIDENTIALITY_MAX);
++		security_lock_kernel_down("Secure IPL mode", LOCKDOWN_INTEGRITY_MAX);
 +
  	/* Have one command line that is parsed and saved in /proc/cmdline */
  	/* boot_command_line has been already set up in early.c */
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
-
-