From: Greg Kroah-Hartman Date: Wed, 12 May 2021 08:57:16 +0000 (+0200) Subject: 4.19-stable patches X-Git-Tag: v5.4.119~86 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=f76bdfdb9b5b49531b0f92f8a4e91eb47c9c2673;p=thirdparty%2Fkernel%2Fstable-queue.git 4.19-stable patches added patches: asoc-samsung-tm2_wm5110-check-of-of_parse-return-value.patch fddi-defxx-bail-out-gracefully-with-unassigned-pci-resource-for-csr.patch iio-accel-adis16201-fix-wrong-axis-assignment-that-prevents-loading.patch md-bitmap-wait-for-external-bitmap-writes-to-complete-during-tear-down.patch mips-pci-mt7620-fix-pll-lock-check.patch mips-pci-rt2880-fix-slot-0-configuration.patch misc-lis3lv02d-fix-false-positive-warn-on-various-hp-models.patch misc-vmw_vmci-explicitly-initialize-vmci_datagram-payload.patch misc-vmw_vmci-explicitly-initialize-vmci_notify_bm_set_msg-struct.patch --- diff --git a/queue-4.19/asoc-samsung-tm2_wm5110-check-of-of_parse-return-value.patch b/queue-4.19/asoc-samsung-tm2_wm5110-check-of-of_parse-return-value.patch new file mode 100644 index 00000000000..a091dfbc030 --- /dev/null +++ b/queue-4.19/asoc-samsung-tm2_wm5110-check-of-of_parse-return-value.patch @@ -0,0 +1,54 @@ +From d58970da324732686529655c21791cef0ee547c4 Mon Sep 17 00:00:00 2001 +From: Pierre-Louis Bossart +Date: Fri, 12 Mar 2021 12:02:30 -0600 +Subject: ASoC: samsung: tm2_wm5110: check of of_parse return value + +From: Pierre-Louis Bossart + +commit d58970da324732686529655c21791cef0ee547c4 upstream. + +cppcheck warning: + +sound/soc/samsung/tm2_wm5110.c:605:6: style: Variable 'ret' is +reassigned a value before the old one has been +used. [redundantAssignment] + ret = devm_snd_soc_register_component(dev, &tm2_component, + ^ +sound/soc/samsung/tm2_wm5110.c:554:7: note: ret is assigned + ret = of_parse_phandle_with_args(dev->of_node, "i2s-controller", + ^ +sound/soc/samsung/tm2_wm5110.c:605:6: note: ret is overwritten + ret = devm_snd_soc_register_component(dev, &tm2_component, + ^ + +The args is a stack variable, so it could have junk (uninitialized) +therefore args.np could have a non-NULL and random value even though +property was missing. Later could trigger invalid pointer dereference. + +There's no need to check for args.np because args.np won't be +initialized on errors. + +Fixes: 8d1513cef51a ("ASoC: samsung: Add support for HDMI audio on TM2 board") +Cc: +Suggested-by: Krzysztof Kozlowski +Reviewed-by: Krzysztof Kozlowski +Reviewed-by: Sylwester Nawrocki +Signed-off-by: Pierre-Louis Bossart +Link: https://lore.kernel.org/r/20210312180231.2741-2-pierre-louis.bossart@linux.intel.com +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + sound/soc/samsung/tm2_wm5110.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/sound/soc/samsung/tm2_wm5110.c ++++ b/sound/soc/samsung/tm2_wm5110.c +@@ -541,7 +541,7 @@ static int tm2_probe(struct platform_dev + + ret = of_parse_phandle_with_args(dev->of_node, "i2s-controller", + cells_name, i, &args); +- if (!args.np) { ++ if (ret) { + dev_err(dev, "i2s-controller property parse error: %d\n", i); + ret = -EINVAL; + goto dai_node_put; diff --git a/queue-4.19/fddi-defxx-bail-out-gracefully-with-unassigned-pci-resource-for-csr.patch b/queue-4.19/fddi-defxx-bail-out-gracefully-with-unassigned-pci-resource-for-csr.patch new file mode 100644 index 00000000000..3853982c341 --- /dev/null +++ b/queue-4.19/fddi-defxx-bail-out-gracefully-with-unassigned-pci-resource-for-csr.patch @@ -0,0 +1,193 @@ +From f626ca682912fab55dff15469ce893ae16b65c7e Mon Sep 17 00:00:00 2001 +From: "Maciej W. Rozycki" +Date: Wed, 10 Mar 2021 13:03:09 +0100 +Subject: FDDI: defxx: Bail out gracefully with unassigned PCI resource for CSR + +From: Maciej W. Rozycki + +commit f626ca682912fab55dff15469ce893ae16b65c7e upstream. + +Recent versions of the PCI Express specification have deprecated support +for I/O transactions and actually some PCIe host bridges, such as Power +Systems Host Bridge 4 (PHB4), do not implement them. + +For those systems the PCI BARs that request a mapping in the I/O space +have the length recorded in the corresponding PCI resource set to zero, +which makes it unassigned: + +# lspci -s 0031:02:04.0 -v +0031:02:04.0 FDDI network controller: Digital Equipment Corporation PCI-to-PDQ Interface Chip [PFI] FDDI (DEFPA) (rev 02) + Subsystem: Digital Equipment Corporation FDDIcontroller/PCI (DEFPA) + Flags: bus master, medium devsel, latency 136, IRQ 57, NUMA node 8 + Memory at 620c080020000 (32-bit, non-prefetchable) [size=128] + I/O ports at [disabled] + Memory at 620c080030000 (32-bit, non-prefetchable) [size=64K] + Capabilities: [50] Power Management version 2 + Kernel driver in use: defxx + Kernel modules: defxx + +# + +Regardless the driver goes ahead and requests it (here observed with a +Raptor Talos II POWER9 system), resulting in an odd /proc/ioport entry: + +# cat /proc/ioports +00000000-ffffffffffffffff : 0031:02:04.0 +# + +Furthermore, the system gets confused as the driver actually continues +and pokes at those locations, causing a flood of messages being output +to the system console by the underlying system firmware, like: + +defxx: v1.11 2014/07/01 Lawrence V. Stefani and others +defxx 0031:02:04.0: enabling device (0140 -> 0142) +LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010000 +IPMI: dropping non severe PEL event +LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014 +IPMI: dropping non severe PEL event +LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014 +IPMI: dropping non severe PEL event + +and so on and so on (possibly intermixed actually, as there's no locking +between the kernel and the firmware in console port access with this +particular system, but cleaned up above for clarity), and once some 10k +of such pairs of the latter two messages have been produced an interace +eventually shows up in a useless state: + +0031:02:04.0: DEFPA at I/O addr = 0x0, IRQ = 57, Hardware addr = 00-00-00-00-00-00 + +This was not expected to happen as resource handling was added to the +driver a while ago, because it was not known at that time that a PCI +system would be possible that cannot assign port I/O resources, and +oddly enough `request_region' does not fail, which would have caught it. + +Correct the problem then by checking for the length of zero for the CSR +resource and bail out gracefully refusing to register an interface if +that turns out to be the case, producing messages like: + +defxx: v1.11 2014/07/01 Lawrence V. Stefani and others +0031:02:04.0: Cannot use I/O, no address set, aborting +0031:02:04.0: Recompile driver with "CONFIG_DEFXX_MMIO=y" + +Keep the original check for the EISA MMIO resource as implemented, +because in that case the length is hardwired to 0x400 as a consequence +of how the compare/mask address decoding works in the ESIC chip and it +is only the base address that is set to zero if MMIO has been disabled +for the adapter in EISA configuration, which in turn could be a valid +bus address in a legacy-free system implementing PCI, especially for +port I/O. + +Where the EISA MMIO resource has been disabled for the adapter in EISA +configuration this arrangement keeps producing messages like: + +eisa 00:05: EISA: slot 5: DEC3002 detected +defxx: v1.11 2014/07/01 Lawrence V. Stefani and others +00:05: Cannot use MMIO, no address set, aborting +00:05: Recompile driver with "CONFIG_DEFXX_MMIO=n" +00:05: Or run ECU and set adapter's MMIO location + +with the last two lines now swapped for easier handling in the driver. + +There is no need to check for and catch the case of a port I/O resource +not having been assigned for EISA as the adapter uses the slot-specific +I/O space, which gets assigned by how EISA has been specified and maps +directly to the particular slot an option card has been placed in. And +the EISA variant of the adapter has additional registers that are only +accessible via the port I/O space anyway. + +While at it factor out the error message calls into helpers and fix an +argument order bug with the `pr_err' call now in `dfx_register_res_err'. + +Signed-off-by: Maciej W. Rozycki +Fixes: 4d0438e56a8f ("defxx: Clean up DEFEA resource management") +Cc: stable@vger.kernel.org # v3.19+ +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/fddi/defxx.c | 47 ++++++++++++++++++++++++++++++----------------- + 1 file changed, 30 insertions(+), 17 deletions(-) + +--- a/drivers/net/fddi/defxx.c ++++ b/drivers/net/fddi/defxx.c +@@ -495,6 +495,25 @@ static const struct net_device_ops dfx_n + .ndo_set_mac_address = dfx_ctl_set_mac_address, + }; + ++static void dfx_register_res_alloc_err(const char *print_name, bool mmio, ++ bool eisa) ++{ ++ pr_err("%s: Cannot use %s, no address set, aborting\n", ++ print_name, mmio ? "MMIO" : "I/O"); ++ pr_err("%s: Recompile driver with \"CONFIG_DEFXX_MMIO=%c\"\n", ++ print_name, mmio ? 'n' : 'y'); ++ if (eisa && mmio) ++ pr_err("%s: Or run ECU and set adapter's MMIO location\n", ++ print_name); ++} ++ ++static void dfx_register_res_err(const char *print_name, bool mmio, ++ unsigned long start, unsigned long len) ++{ ++ pr_err("%s: Cannot reserve %s resource 0x%lx @ 0x%lx, aborting\n", ++ print_name, mmio ? "MMIO" : "I/O", len, start); ++} ++ + /* + * ================ + * = dfx_register = +@@ -568,15 +587,12 @@ static int dfx_register(struct device *b + dev_set_drvdata(bdev, dev); + + dfx_get_bars(bdev, bar_start, bar_len); +- if (dfx_bus_eisa && dfx_use_mmio && bar_start[0] == 0) { +- pr_err("%s: Cannot use MMIO, no address set, aborting\n", +- print_name); +- pr_err("%s: Run ECU and set adapter's MMIO location\n", +- print_name); +- pr_err("%s: Or recompile driver with \"CONFIG_DEFXX_MMIO=n\"" +- "\n", print_name); ++ if (bar_len[0] == 0 || ++ (dfx_bus_eisa && dfx_use_mmio && bar_start[0] == 0)) { ++ dfx_register_res_alloc_err(print_name, dfx_use_mmio, ++ dfx_bus_eisa); + err = -ENXIO; +- goto err_out; ++ goto err_out_disable; + } + + if (dfx_use_mmio) +@@ -585,18 +601,16 @@ static int dfx_register(struct device *b + else + region = request_region(bar_start[0], bar_len[0], print_name); + if (!region) { +- pr_err("%s: Cannot reserve %s resource 0x%lx @ 0x%lx, " +- "aborting\n", dfx_use_mmio ? "MMIO" : "I/O", print_name, +- (long)bar_len[0], (long)bar_start[0]); ++ dfx_register_res_err(print_name, dfx_use_mmio, ++ bar_start[0], bar_len[0]); + err = -EBUSY; + goto err_out_disable; + } + if (bar_start[1] != 0) { + region = request_region(bar_start[1], bar_len[1], print_name); + if (!region) { +- pr_err("%s: Cannot reserve I/O resource " +- "0x%lx @ 0x%lx, aborting\n", print_name, +- (long)bar_len[1], (long)bar_start[1]); ++ dfx_register_res_err(print_name, 0, ++ bar_start[1], bar_len[1]); + err = -EBUSY; + goto err_out_csr_region; + } +@@ -604,9 +618,8 @@ static int dfx_register(struct device *b + if (bar_start[2] != 0) { + region = request_region(bar_start[2], bar_len[2], print_name); + if (!region) { +- pr_err("%s: Cannot reserve I/O resource " +- "0x%lx @ 0x%lx, aborting\n", print_name, +- (long)bar_len[2], (long)bar_start[2]); ++ dfx_register_res_err(print_name, 0, ++ bar_start[2], bar_len[2]); + err = -EBUSY; + goto err_out_bh_region; + } diff --git a/queue-4.19/iio-accel-adis16201-fix-wrong-axis-assignment-that-prevents-loading.patch b/queue-4.19/iio-accel-adis16201-fix-wrong-axis-assignment-that-prevents-loading.patch new file mode 100644 index 00000000000..948d5b2f347 --- /dev/null +++ b/queue-4.19/iio-accel-adis16201-fix-wrong-axis-assignment-that-prevents-loading.patch @@ -0,0 +1,47 @@ +From 4e102429f3dc62dce546f6107e34a4284634196d Mon Sep 17 00:00:00 2001 +From: Jonathan Cameron +Date: Sun, 21 Mar 2021 18:29:56 +0000 +Subject: iio:accel:adis16201: Fix wrong axis assignment that prevents loading +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Jonathan Cameron + +commit 4e102429f3dc62dce546f6107e34a4284634196d upstream. + +Whilst running some basic tests as part of writing up the dt-bindings for +this driver (to follow), it became clear it doesn't actually load +currently. + +iio iio:device1: tried to double register : in_incli_x_index +adis16201 spi0.0: Failed to create buffer sysfs interfaces +adis16201: probe of spi0.0 failed with error -16 + +Looks like a cut and paste / update bug. Fixes tag obviously not accurate +but we don't want to bother carry thing back to before the driver moved +out of staging. + +Fixes: 591298e54cea ("Staging: iio: accel: adis16201: Move adis16201 driver out of staging") +Signed-off-by: Jonathan Cameron +Cc: +Cc: Himanshu Jha +Cc: Nuno Sá +Reviewed-by: Alexandru Ardelean +Link: https://lore.kernel.org/r/20210321182956.844652-1-jic23@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/accel/adis16201.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/iio/accel/adis16201.c ++++ b/drivers/iio/accel/adis16201.c +@@ -216,7 +216,7 @@ static const struct iio_chan_spec adis16 + ADIS_AUX_ADC_CHAN(ADIS16201_AUX_ADC_REG, ADIS16201_SCAN_AUX_ADC, 0, 12), + ADIS_INCLI_CHAN(X, ADIS16201_XINCL_OUT_REG, ADIS16201_SCAN_INCLI_X, + BIT(IIO_CHAN_INFO_CALIBBIAS), 0, 14), +- ADIS_INCLI_CHAN(X, ADIS16201_YINCL_OUT_REG, ADIS16201_SCAN_INCLI_Y, ++ ADIS_INCLI_CHAN(Y, ADIS16201_YINCL_OUT_REG, ADIS16201_SCAN_INCLI_Y, + BIT(IIO_CHAN_INFO_CALIBBIAS), 0, 14), + IIO_CHAN_SOFT_TIMESTAMP(7) + }; diff --git a/queue-4.19/md-bitmap-wait-for-external-bitmap-writes-to-complete-during-tear-down.patch b/queue-4.19/md-bitmap-wait-for-external-bitmap-writes-to-complete-during-tear-down.patch new file mode 100644 index 00000000000..5fb91e39ecc --- /dev/null +++ b/queue-4.19/md-bitmap-wait-for-external-bitmap-writes-to-complete-during-tear-down.patch @@ -0,0 +1,105 @@ +From 404a8ef512587b2460107d3272c17a89aef75edf Mon Sep 17 00:00:00 2001 +From: Sudhakar Panneerselvam +Date: Tue, 13 Apr 2021 04:08:29 +0000 +Subject: md/bitmap: wait for external bitmap writes to complete during tear down + +From: Sudhakar Panneerselvam + +commit 404a8ef512587b2460107d3272c17a89aef75edf upstream. + +NULL pointer dereference was observed in super_written() when it tries +to access the mddev structure. + +[The below stack trace is from an older kernel, but the problem described +in this patch applies to the mainline kernel.] + +[ 1194.474861] task: ffff8fdd20858000 task.stack: ffffb99d40790000 +[ 1194.488000] RIP: 0010:super_written+0x29/0xe1 +[ 1194.499688] RSP: 0018:ffff8ffb7fcc3c78 EFLAGS: 00010046 +[ 1194.512477] RAX: 0000000000000000 RBX: ffff8ffb7bf4a000 RCX: ffff8ffb78991048 +[ 1194.527325] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff8ffb56b8a200 +[ 1194.542576] RBP: ffff8ffb7fcc3c90 R08: 000000000000000b R09: 0000000000000000 +[ 1194.558001] R10: ffff8ffb56b8a298 R11: 0000000000000000 R12: ffff8ffb56b8a200 +[ 1194.573070] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 +[ 1194.588117] FS: 0000000000000000(0000) GS:ffff8ffb7fcc0000(0000) knlGS:0000000000000000 +[ 1194.604264] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 1194.617375] CR2: 00000000000002b8 CR3: 00000021e040a002 CR4: 00000000007606e0 +[ 1194.632327] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[ 1194.647865] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +[ 1194.663316] PKRU: 55555554 +[ 1194.674090] Call Trace: +[ 1194.683735] +[ 1194.692948] bio_endio+0xae/0x135 +[ 1194.703580] blk_update_request+0xad/0x2fa +[ 1194.714990] blk_update_bidi_request+0x20/0x72 +[ 1194.726578] __blk_end_bidi_request+0x2c/0x4d +[ 1194.738373] __blk_end_request_all+0x31/0x49 +[ 1194.749344] blk_flush_complete_seq+0x377/0x383 +[ 1194.761550] flush_end_io+0x1dd/0x2a7 +[ 1194.772910] blk_finish_request+0x9f/0x13c +[ 1194.784544] scsi_end_request+0x180/0x25c +[ 1194.796149] scsi_io_completion+0xc8/0x610 +[ 1194.807503] scsi_finish_command+0xdc/0x125 +[ 1194.818897] scsi_softirq_done+0x81/0xde +[ 1194.830062] blk_done_softirq+0xa4/0xcc +[ 1194.841008] __do_softirq+0xd9/0x29f +[ 1194.851257] irq_exit+0xe6/0xeb +[ 1194.861290] do_IRQ+0x59/0xe3 +[ 1194.871060] common_interrupt+0x1c6/0x382 +[ 1194.881988] +[ 1194.890646] RIP: 0010:cpuidle_enter_state+0xdd/0x2a5 +[ 1194.902532] RSP: 0018:ffffb99d40793e68 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff43 +[ 1194.917317] RAX: ffff8ffb7fce27c0 RBX: ffff8ffb7fced800 RCX: 000000000000001f +[ 1194.932056] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000000 +[ 1194.946428] RBP: ffffb99d40793ea0 R08: 0000000000000004 R09: 0000000000002ed2 +[ 1194.960508] R10: 0000000000002664 R11: 0000000000000018 R12: 0000000000000003 +[ 1194.974454] R13: 000000000000000b R14: ffffffff925715a0 R15: 0000011610120d5a +[ 1194.988607] ? cpuidle_enter_state+0xcc/0x2a5 +[ 1194.999077] cpuidle_enter+0x17/0x19 +[ 1195.008395] call_cpuidle+0x23/0x3a +[ 1195.017718] do_idle+0x172/0x1d5 +[ 1195.026358] cpu_startup_entry+0x73/0x75 +[ 1195.035769] start_secondary+0x1b9/0x20b +[ 1195.044894] secondary_startup_64+0xa5/0xa5 +[ 1195.084921] RIP: super_written+0x29/0xe1 RSP: ffff8ffb7fcc3c78 +[ 1195.096354] CR2: 00000000000002b8 + +bio in the above stack is a bitmap write whose completion is invoked after +the tear down sequence sets the mddev structure to NULL in rdev. + +During tear down, there is an attempt to flush the bitmap writes, but for +external bitmaps, there is no explicit wait for all the bitmap writes to +complete. For instance, md_bitmap_flush() is called to flush the bitmap +writes, but the last call to md_bitmap_daemon_work() in md_bitmap_flush() +could generate new bitmap writes for which there is no explicit wait to +complete those writes. The call to md_bitmap_update_sb() will return +simply for external bitmaps and the follow-up call to md_update_sb() is +conditional and may not get called for external bitmaps. This results in a +kernel panic when the completion routine, super_written() is called which +tries to reference mddev in the rdev that has been set to +NULL(in unbind_rdev_from_array() by tear down sequence). + +The solution is to call md_super_wait() for external bitmaps after the +last call to md_bitmap_daemon_work() in md_bitmap_flush() to ensure there +are no pending bitmap writes before proceeding with the tear down. + +Cc: stable@vger.kernel.org +Signed-off-by: Sudhakar Panneerselvam +Reviewed-by: Zhao Heming +Signed-off-by: Song Liu +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/md-bitmap.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/md/md-bitmap.c ++++ b/drivers/md/md-bitmap.c +@@ -1725,6 +1725,8 @@ void md_bitmap_flush(struct mddev *mddev + md_bitmap_daemon_work(mddev); + bitmap->daemon_lastrun -= sleep; + md_bitmap_daemon_work(mddev); ++ if (mddev->bitmap_info.external) ++ md_super_wait(mddev); + md_bitmap_update_sb(bitmap); + } + diff --git a/queue-4.19/mips-pci-mt7620-fix-pll-lock-check.patch b/queue-4.19/mips-pci-mt7620-fix-pll-lock-check.patch new file mode 100644 index 00000000000..2ccc08fee36 --- /dev/null +++ b/queue-4.19/mips-pci-mt7620-fix-pll-lock-check.patch @@ -0,0 +1,55 @@ +From c15b99ae2ba9ea30da3c7cd4765b8a4707e530a6 Mon Sep 17 00:00:00 2001 +From: Ilya Lipnitskiy +Date: Sat, 6 Mar 2021 20:17:24 -0800 +Subject: MIPS: pci-mt7620: fix PLL lock check + +From: Ilya Lipnitskiy + +commit c15b99ae2ba9ea30da3c7cd4765b8a4707e530a6 upstream. + +Upstream a long-standing OpenWrt patch [0] that fixes MT7620 PCIe PLL +lock check. The existing code checks the wrong register bit: PPLL_SW_SET +is not defined in PPLL_CFG1 and bit 31 of PPLL_CFG1 is marked as reserved +in the MT7620 Programming Guide. The correct bit to check for PLL lock +is PPLL_LD (bit 23). + +Also reword the error message for clarity. + +Without this change it is unlikely that this driver ever worked with +mainline kernel. + +[0]: https://lists.infradead.org/pipermail/lede-commits/2017-July/004441.html + +Signed-off-by: Ilya Lipnitskiy +Cc: John Crispin +Cc: linux-mips@vger.kernel.org +Cc: linux-mediatek@lists.infradead.org +Cc: linux-kernel@vger.kernel.org +Cc: stable@vger.kernel.org +Signed-off-by: Thomas Bogendoerfer +Signed-off-by: Greg Kroah-Hartman +--- + arch/mips/pci/pci-mt7620.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/arch/mips/pci/pci-mt7620.c ++++ b/arch/mips/pci/pci-mt7620.c +@@ -33,6 +33,7 @@ + #define RALINK_GPIOMODE 0x60 + + #define PPLL_CFG1 0x9c ++#define PPLL_LD BIT(23) + + #define PPLL_DRV 0xa0 + #define PDRV_SW_SET BIT(31) +@@ -242,8 +243,8 @@ static int mt7620_pci_hw_init(struct pla + rt_sysc_m32(0, RALINK_PCIE0_CLK_EN, RALINK_CLKCFG1); + mdelay(100); + +- if (!(rt_sysc_r32(PPLL_CFG1) & PDRV_SW_SET)) { +- dev_err(&pdev->dev, "MT7620 PPLL unlock\n"); ++ if (!(rt_sysc_r32(PPLL_CFG1) & PPLL_LD)) { ++ dev_err(&pdev->dev, "pcie PLL not locked, aborting init\n"); + reset_control_assert(rstpcie0); + rt_sysc_m32(RALINK_PCIE0_CLK_EN, 0, RALINK_CLKCFG1); + return -1; diff --git a/queue-4.19/mips-pci-rt2880-fix-slot-0-configuration.patch b/queue-4.19/mips-pci-rt2880-fix-slot-0-configuration.patch new file mode 100644 index 00000000000..6ee65d1bf25 --- /dev/null +++ b/queue-4.19/mips-pci-rt2880-fix-slot-0-configuration.patch @@ -0,0 +1,104 @@ +From 8e98b697006d749d745d3b174168a877bb96c500 Mon Sep 17 00:00:00 2001 +From: Ilya Lipnitskiy +Date: Tue, 13 Apr 2021 20:12:33 -0700 +Subject: MIPS: pci-rt2880: fix slot 0 configuration + +From: Ilya Lipnitskiy + +commit 8e98b697006d749d745d3b174168a877bb96c500 upstream. + +pci_fixup_irqs() used to call pcibios_map_irq on every PCI device, which +for RT2880 included bus 0 slot 0. After pci_fixup_irqs() got removed, +only slots/funcs with devices attached would be called. While arguably +the right thing, that left no chance for this driver to ever initialize +slot 0, effectively bricking PCI and USB on RT2880 devices such as the +Belkin F5D8235-4 v1. + +Slot 0 configuration needs to happen after PCI bus enumeration, but +before any device at slot 0x11 (func 0 or 1) is talked to. That was +determined empirically by testing on a Belkin F5D8235-4 v1 device. A +minimal BAR 0 config write followed by read, then setting slot 0 +PCI_COMMAND to MASTER | IO | MEMORY is all that seems to be required for +proper functionality. + +Tested by ensuring that full- and high-speed USB devices get enumerated +on the Belkin F5D8235-4 v1 (with an out of tree DTS file from OpenWrt). + +Fixes: 04c81c7293df ("MIPS: PCI: Replace pci_fixup_irqs() call with host bridge IRQ mapping hooks") +Signed-off-by: Ilya Lipnitskiy +Cc: Lorenzo Pieralisi +Cc: Tobias Wolf +Cc: # v4.14+ +Signed-off-by: Thomas Bogendoerfer +Signed-off-by: Greg Kroah-Hartman +--- + arch/mips/pci/pci-rt2880.c | 37 ++++++++++++++++++++++++------------- + 1 file changed, 24 insertions(+), 13 deletions(-) + +--- a/arch/mips/pci/pci-rt2880.c ++++ b/arch/mips/pci/pci-rt2880.c +@@ -183,7 +183,6 @@ static inline void rt2880_pci_write_u32( + + int pcibios_map_irq(const struct pci_dev *dev, u8 slot, u8 pin) + { +- u16 cmd; + int irq = -1; + + if (dev->bus->number != 0) +@@ -191,8 +190,6 @@ int pcibios_map_irq(const struct pci_dev + + switch (PCI_SLOT(dev->devfn)) { + case 0x00: +- rt2880_pci_write_u32(PCI_BASE_ADDRESS_0, 0x08000000); +- (void) rt2880_pci_read_u32(PCI_BASE_ADDRESS_0); + break; + case 0x11: + irq = RT288X_CPU_IRQ_PCI; +@@ -204,16 +201,6 @@ int pcibios_map_irq(const struct pci_dev + break; + } + +- pci_write_config_byte((struct pci_dev *) dev, +- PCI_CACHE_LINE_SIZE, 0x14); +- pci_write_config_byte((struct pci_dev *) dev, PCI_LATENCY_TIMER, 0xFF); +- pci_read_config_word((struct pci_dev *) dev, PCI_COMMAND, &cmd); +- cmd |= PCI_COMMAND_MASTER | PCI_COMMAND_IO | PCI_COMMAND_MEMORY | +- PCI_COMMAND_INVALIDATE | PCI_COMMAND_FAST_BACK | +- PCI_COMMAND_SERR | PCI_COMMAND_WAIT | PCI_COMMAND_PARITY; +- pci_write_config_word((struct pci_dev *) dev, PCI_COMMAND, cmd); +- pci_write_config_byte((struct pci_dev *) dev, PCI_INTERRUPT_LINE, +- dev->irq); + return irq; + } + +@@ -252,6 +239,30 @@ static int rt288x_pci_probe(struct platf + + int pcibios_plat_dev_init(struct pci_dev *dev) + { ++ static bool slot0_init; ++ ++ /* ++ * Nobody seems to initialize slot 0, but this platform requires it, so ++ * do it once when some other slot is being enabled. The PCI subsystem ++ * should configure other slots properly, so no need to do anything ++ * special for those. ++ */ ++ if (!slot0_init && dev->bus->number == 0) { ++ u16 cmd; ++ u32 bar0; ++ ++ slot0_init = true; ++ ++ pci_bus_write_config_dword(dev->bus, 0, PCI_BASE_ADDRESS_0, ++ 0x08000000); ++ pci_bus_read_config_dword(dev->bus, 0, PCI_BASE_ADDRESS_0, ++ &bar0); ++ ++ pci_bus_read_config_word(dev->bus, 0, PCI_COMMAND, &cmd); ++ cmd |= PCI_COMMAND_MASTER | PCI_COMMAND_IO | PCI_COMMAND_MEMORY; ++ pci_bus_write_config_word(dev->bus, 0, PCI_COMMAND, cmd); ++ } ++ + return 0; + } + diff --git a/queue-4.19/misc-lis3lv02d-fix-false-positive-warn-on-various-hp-models.patch b/queue-4.19/misc-lis3lv02d-fix-false-positive-warn-on-various-hp-models.patch new file mode 100644 index 00000000000..1f5c1d3472f --- /dev/null +++ b/queue-4.19/misc-lis3lv02d-fix-false-positive-warn-on-various-hp-models.patch @@ -0,0 +1,101 @@ +From 3641762c1c9c7cfd84a7061a0a73054f09b412e3 Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Wed, 17 Feb 2021 11:24:59 +0100 +Subject: misc: lis3lv02d: Fix false-positive WARN on various HP models + +From: Hans de Goede + +commit 3641762c1c9c7cfd84a7061a0a73054f09b412e3 upstream. + +Before this commit lis3lv02d_get_pwron_wait() had a WARN_ONCE() to catch +a potential divide by 0. WARN macros should only be used to catch internal +kernel bugs and that is not the case here. We have been receiving a lot of +bug reports about kernel backtraces caused by this WARN. + +The div value being checked comes from the lis3->odrs[] array. Which +is sized to be a power-of-2 matching the number of bits in lis3->odr_mask. + +The only lis3 model where this array is not entirely filled with non zero +values. IOW the only model where we can hit the div == 0 check is the +3dc ("8 bits 3DC sensor") model: + +int lis3_3dc_rates[16] = {0, 1, 10, 25, 50, 100, 200, 400, 1600, 5000}; + +Note the 0 value at index 0, according to the datasheet an odr index of 0 +means "Power-down mode". HP typically uses a lis3 accelerometer for HDD +fall protection. What I believe is happening here is that on newer +HP devices, which only contain a SDD, the BIOS is leaving the lis3 device +powered-down since it is not used for HDD fall protection. + +Note that the lis3_3dc_rates array initializer only specifies 10 values, +which matches the datasheet. So it also contains 6 zero values at the end. + +Replace the WARN with a normal check, which treats an odr index of 0 +as power-down and uses a normal dev_err() to report the error in case +odr index point past the initialized part of the array. + +Fixes: 1510dd5954be ("lis3lv02d: avoid divide by zero due to unchecked") +Cc: stable@vger.kernel.org +Signed-off-by: Hans de Goede +BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=785814 +BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1817027 +BugLink: https://bugs.centos.org/view.php?id=10720 +Link: https://lore.kernel.org/r/20210217102501.31758-1-hdegoede@redhat.com +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman +--- + drivers/misc/lis3lv02d/lis3lv02d.c | 21 ++++++++++++++++----- + 1 file changed, 16 insertions(+), 5 deletions(-) + +--- a/drivers/misc/lis3lv02d/lis3lv02d.c ++++ b/drivers/misc/lis3lv02d/lis3lv02d.c +@@ -221,7 +221,7 @@ static int lis3_3dc_rates[16] = {0, 1, 1 + static int lis3_3dlh_rates[4] = {50, 100, 400, 1000}; + + /* ODR is Output Data Rate */ +-static int lis3lv02d_get_odr(struct lis3lv02d *lis3) ++static int lis3lv02d_get_odr_index(struct lis3lv02d *lis3) + { + u8 ctrl; + int shift; +@@ -229,15 +229,23 @@ static int lis3lv02d_get_odr(struct lis3 + lis3->read(lis3, CTRL_REG1, &ctrl); + ctrl &= lis3->odr_mask; + shift = ffs(lis3->odr_mask) - 1; +- return lis3->odrs[(ctrl >> shift)]; ++ return (ctrl >> shift); + } + + static int lis3lv02d_get_pwron_wait(struct lis3lv02d *lis3) + { +- int div = lis3lv02d_get_odr(lis3); ++ int odr_idx = lis3lv02d_get_odr_index(lis3); ++ int div = lis3->odrs[odr_idx]; + +- if (WARN_ONCE(div == 0, "device returned spurious data")) ++ if (div == 0) { ++ if (odr_idx == 0) { ++ /* Power-down mode, not sampling no need to sleep */ ++ return 0; ++ } ++ ++ dev_err(&lis3->pdev->dev, "Error unknown odrs-index: %d\n", odr_idx); + return -ENXIO; ++ } + + /* LIS3 power on delay is quite long */ + msleep(lis3->pwron_delay / div); +@@ -820,9 +828,12 @@ static ssize_t lis3lv02d_rate_show(struc + struct device_attribute *attr, char *buf) + { + struct lis3lv02d *lis3 = dev_get_drvdata(dev); ++ int odr_idx; + + lis3lv02d_sysfs_poweron(lis3); +- return sprintf(buf, "%d\n", lis3lv02d_get_odr(lis3)); ++ ++ odr_idx = lis3lv02d_get_odr_index(lis3); ++ return sprintf(buf, "%d\n", lis3->odrs[odr_idx]); + } + + static ssize_t lis3lv02d_rate_set(struct device *dev, diff --git a/queue-4.19/misc-vmw_vmci-explicitly-initialize-vmci_datagram-payload.patch b/queue-4.19/misc-vmw_vmci-explicitly-initialize-vmci_datagram-payload.patch new file mode 100644 index 00000000000..79bd00a30d5 --- /dev/null +++ b/queue-4.19/misc-vmw_vmci-explicitly-initialize-vmci_datagram-payload.patch @@ -0,0 +1,92 @@ +From b2192cfeba8481224da0a4ec3b4a7ccd80b1623b Mon Sep 17 00:00:00 2001 +From: Tetsuo Handa +Date: Fri, 2 Apr 2021 21:17:42 +0900 +Subject: misc: vmw_vmci: explicitly initialize vmci_datagram payload + +From: Tetsuo Handa + +commit b2192cfeba8481224da0a4ec3b4a7ccd80b1623b upstream. + +KMSAN complains that vmci_check_host_caps() left the payload part of +check_msg uninitialized. + + ===================================================== + BUG: KMSAN: uninit-value in kmsan_check_memory+0xd/0x10 + CPU: 1 PID: 1 Comm: swapper/0 Tainted: G B 5.11.0-rc7+ #4 + Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020 + Call Trace: + dump_stack+0x21c/0x280 + kmsan_report+0xfb/0x1e0 + kmsan_internal_check_memory+0x202/0x520 + kmsan_check_memory+0xd/0x10 + iowrite8_rep+0x86/0x380 + vmci_guest_probe_device+0xf0b/0x1e70 + pci_device_probe+0xab3/0xe70 + really_probe+0xd16/0x24d0 + driver_probe_device+0x29d/0x3a0 + device_driver_attach+0x25a/0x490 + __driver_attach+0x78c/0x840 + bus_for_each_dev+0x210/0x340 + driver_attach+0x89/0xb0 + bus_add_driver+0x677/0xc40 + driver_register+0x485/0x8e0 + __pci_register_driver+0x1ff/0x350 + vmci_guest_init+0x3e/0x41 + vmci_drv_init+0x1d6/0x43f + do_one_initcall+0x39c/0x9a0 + do_initcall_level+0x1d7/0x259 + do_initcalls+0x127/0x1cb + do_basic_setup+0x33/0x36 + kernel_init_freeable+0x29a/0x3ed + kernel_init+0x1f/0x840 + ret_from_fork+0x1f/0x30 + + Uninit was created at: + kmsan_internal_poison_shadow+0x5c/0xf0 + kmsan_slab_alloc+0x8d/0xe0 + kmem_cache_alloc+0x84f/0xe30 + vmci_guest_probe_device+0xd11/0x1e70 + pci_device_probe+0xab3/0xe70 + really_probe+0xd16/0x24d0 + driver_probe_device+0x29d/0x3a0 + device_driver_attach+0x25a/0x490 + __driver_attach+0x78c/0x840 + bus_for_each_dev+0x210/0x340 + driver_attach+0x89/0xb0 + bus_add_driver+0x677/0xc40 + driver_register+0x485/0x8e0 + __pci_register_driver+0x1ff/0x350 + vmci_guest_init+0x3e/0x41 + vmci_drv_init+0x1d6/0x43f + do_one_initcall+0x39c/0x9a0 + do_initcall_level+0x1d7/0x259 + do_initcalls+0x127/0x1cb + do_basic_setup+0x33/0x36 + kernel_init_freeable+0x29a/0x3ed + kernel_init+0x1f/0x840 + ret_from_fork+0x1f/0x30 + + Bytes 28-31 of 36 are uninitialized + Memory access of size 36 starts at ffff8881675e5f00 + ===================================================== + +Fixes: 1f166439917b69d3 ("VMCI: guest side driver implementation.") +Cc: +Signed-off-by: Tetsuo Handa +Link: https://lore.kernel.org/r/20210402121742.3917-2-penguin-kernel@I-love.SAKURA.ne.jp +Signed-off-by: Greg Kroah-Hartman +--- + drivers/misc/vmw_vmci/vmci_guest.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/misc/vmw_vmci/vmci_guest.c ++++ b/drivers/misc/vmw_vmci/vmci_guest.c +@@ -169,7 +169,7 @@ static int vmci_check_host_caps(struct p + VMCI_UTIL_NUM_RESOURCES * sizeof(u32); + struct vmci_datagram *check_msg; + +- check_msg = kmalloc(msg_size, GFP_KERNEL); ++ check_msg = kzalloc(msg_size, GFP_KERNEL); + if (!check_msg) { + dev_err(&pdev->dev, "%s: Insufficient memory\n", __func__); + return -ENOMEM; diff --git a/queue-4.19/misc-vmw_vmci-explicitly-initialize-vmci_notify_bm_set_msg-struct.patch b/queue-4.19/misc-vmw_vmci-explicitly-initialize-vmci_notify_bm_set_msg-struct.patch new file mode 100644 index 00000000000..436f061c64b --- /dev/null +++ b/queue-4.19/misc-vmw_vmci-explicitly-initialize-vmci_notify_bm_set_msg-struct.patch @@ -0,0 +1,74 @@ +From 376565b9717c30cd58ad33860fa42697615fa2e4 Mon Sep 17 00:00:00 2001 +From: Tetsuo Handa +Date: Fri, 2 Apr 2021 21:17:41 +0900 +Subject: misc: vmw_vmci: explicitly initialize vmci_notify_bm_set_msg struct + +From: Tetsuo Handa + +commit 376565b9717c30cd58ad33860fa42697615fa2e4 upstream. + +KMSAN complains that the vmci_use_ppn64() == false path in +vmci_dbell_register_notification_bitmap() left upper 32bits of +bitmap_set_msg.bitmap_ppn64 member uninitialized. + + ===================================================== + BUG: KMSAN: uninit-value in kmsan_check_memory+0xd/0x10 + CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.11.0-rc7+ #4 + Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020 + Call Trace: + dump_stack+0x21c/0x280 + kmsan_report+0xfb/0x1e0 + kmsan_internal_check_memory+0x484/0x520 + kmsan_check_memory+0xd/0x10 + iowrite8_rep+0x86/0x380 + vmci_send_datagram+0x150/0x280 + vmci_dbell_register_notification_bitmap+0x133/0x1e0 + vmci_guest_probe_device+0xcab/0x1e70 + pci_device_probe+0xab3/0xe70 + really_probe+0xd16/0x24d0 + driver_probe_device+0x29d/0x3a0 + device_driver_attach+0x25a/0x490 + __driver_attach+0x78c/0x840 + bus_for_each_dev+0x210/0x340 + driver_attach+0x89/0xb0 + bus_add_driver+0x677/0xc40 + driver_register+0x485/0x8e0 + __pci_register_driver+0x1ff/0x350 + vmci_guest_init+0x3e/0x41 + vmci_drv_init+0x1d6/0x43f + do_one_initcall+0x39c/0x9a0 + do_initcall_level+0x1d7/0x259 + do_initcalls+0x127/0x1cb + do_basic_setup+0x33/0x36 + kernel_init_freeable+0x29a/0x3ed + kernel_init+0x1f/0x840 + ret_from_fork+0x1f/0x30 + + Local variable ----bitmap_set_msg@vmci_dbell_register_notification_bitmap created at: + vmci_dbell_register_notification_bitmap+0x50/0x1e0 + vmci_dbell_register_notification_bitmap+0x50/0x1e0 + + Bytes 28-31 of 32 are uninitialized + Memory access of size 32 starts at ffff88810098f570 + ===================================================== + +Fixes: 83e2ec765be03e8a ("VMCI: doorbell implementation.") +Cc: +Signed-off-by: Tetsuo Handa +Link: https://lore.kernel.org/r/20210402121742.3917-1-penguin-kernel@I-love.SAKURA.ne.jp +Signed-off-by: Greg Kroah-Hartman +--- + drivers/misc/vmw_vmci/vmci_doorbell.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/misc/vmw_vmci/vmci_doorbell.c ++++ b/drivers/misc/vmw_vmci/vmci_doorbell.c +@@ -334,7 +334,7 @@ int vmci_dbell_host_context_notify(u32 s + bool vmci_dbell_register_notification_bitmap(u32 bitmap_ppn) + { + int result; +- struct vmci_notify_bm_set_msg bitmap_set_msg; ++ struct vmci_notify_bm_set_msg bitmap_set_msg = { }; + + bitmap_set_msg.hdr.dst = vmci_make_handle(VMCI_HYPERVISOR_CONTEXT_ID, + VMCI_SET_NOTIFY_BITMAP); diff --git a/queue-4.19/series b/queue-4.19/series index 93e5b41d3e6..d208c85d309 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -129,3 +129,12 @@ bluetooth-verify-amp-hci_chan-before-amp_destroy.patch hsr-use-netdev_err-instead-of-warn_once.patch bluetooth-eliminate-the-potential-race-condition-when-removing-the-hci-controller.patch net-nfc-fix-use-after-free-llcp_sock_bind-connect.patch +asoc-samsung-tm2_wm5110-check-of-of_parse-return-value.patch +mips-pci-mt7620-fix-pll-lock-check.patch +mips-pci-rt2880-fix-slot-0-configuration.patch +fddi-defxx-bail-out-gracefully-with-unassigned-pci-resource-for-csr.patch +iio-accel-adis16201-fix-wrong-axis-assignment-that-prevents-loading.patch +misc-lis3lv02d-fix-false-positive-warn-on-various-hp-models.patch +misc-vmw_vmci-explicitly-initialize-vmci_notify_bm_set_msg-struct.patch +misc-vmw_vmci-explicitly-initialize-vmci_datagram-payload.patch +md-bitmap-wait-for-external-bitmap-writes-to-complete-during-tear-down.patch