From: Greg Kroah-Hartman Date: Wed, 12 May 2021 08:57:33 +0000 (+0200) Subject: 5.4-stable patches X-Git-Tag: v5.4.119~85 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=f09f8107de2d70eb3569222eb1909eb0bdffeb27;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: asoc-intel-kbl_da7219_max98927-fix-kabylake_ssp_fixup-function.patch 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 pci-allow-vpd-access-for-qlogic-isp2722.patch phy-cadence-sierra-fix-phy-power_on-sequence.patch usb-typec-tcpm-address-incorrect-values-of-tcpm-psy-for-fixed-supply.patch usb-typec-tcpm-address-incorrect-values-of-tcpm-psy-for-pps-supply.patch usb-typec-tcpm-update-power-supply-once-partner-accepts.patch usb-xhci-mtk-improve-bandwidth-scheduling-with-tt.patch usb-xhci-mtk-remove-or-operator-for-setting-schedule-parameters.patch --- diff --git a/queue-5.4/asoc-intel-kbl_da7219_max98927-fix-kabylake_ssp_fixup-function.patch b/queue-5.4/asoc-intel-kbl_da7219_max98927-fix-kabylake_ssp_fixup-function.patch new file mode 100644 index 00000000000..75ae7392759 --- /dev/null +++ b/queue-5.4/asoc-intel-kbl_da7219_max98927-fix-kabylake_ssp_fixup-function.patch @@ -0,0 +1,101 @@ +From a523ef731ac6674dc07574f31bf44cc5bfa14e4d Mon Sep 17 00:00:00 2001 +From: Lukasz Majczak +Date: Thu, 15 Apr 2021 14:43:47 +0200 +Subject: ASoC: Intel: kbl_da7219_max98927: Fix kabylake_ssp_fixup function + +From: Lukasz Majczak + +commit a523ef731ac6674dc07574f31bf44cc5bfa14e4d upstream. + +kabylake_ssp_fixup function uses snd_soc_dpcm to identify the +codecs DAIs. The HW parameters are changed based on the codec DAI of the +stream. The earlier approach to get snd_soc_dpcm was using container_of() +macro on snd_pcm_hw_params. + +The structures have been modified over time and snd_soc_dpcm does not have +snd_pcm_hw_params as a reference but as a copy. This causes the current +driver to crash when used. + +This patch changes the way snd_soc_dpcm is extracted. snd_soc_pcm_runtime +holds 2 dpcm instances (one for playback and one for capture). 2 codecs +on the SSP are dmic (capture) and speakers (playback). Based on the +stream direction, snd_soc_dpcm is extracted from snd_soc_pcm_runtime. + +Tested for all use cases of the driver. +Based on similar fix in kbl_rt5663_rt5514_max98927.c +from Harsha Priya and +Vamshi Krishna Gopal + +Cc: # 5.4+ +Signed-off-by: Lukasz Majczak +Acked-by: Pierre-Louis Bossart +Link: https://lore.kernel.org/r/20210415124347.475432-1-lma@semihalf.com +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + sound/soc/intel/boards/kbl_da7219_max98927.c | 38 +++++++++++++++++++++------ + 1 file changed, 30 insertions(+), 8 deletions(-) + +--- a/sound/soc/intel/boards/kbl_da7219_max98927.c ++++ b/sound/soc/intel/boards/kbl_da7219_max98927.c +@@ -282,12 +282,34 @@ static int kabylake_ssp_fixup(struct snd + struct snd_interval *channels = hw_param_interval(params, + SNDRV_PCM_HW_PARAM_CHANNELS); + struct snd_mask *fmt = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT); +- struct snd_soc_dpcm *dpcm = container_of( +- params, struct snd_soc_dpcm, hw_params); +- struct snd_soc_dai_link *fe_dai_link = dpcm->fe->dai_link; +- struct snd_soc_dai_link *be_dai_link = dpcm->be->dai_link; ++ struct snd_soc_dpcm *dpcm, *rtd_dpcm = NULL; + + /* ++ * The following loop will be called only for playback stream ++ * In this platform, there is only one playback device on every SSP ++ */ ++ for_each_dpcm_fe(rtd, SNDRV_PCM_STREAM_PLAYBACK, dpcm) { ++ rtd_dpcm = dpcm; ++ break; ++ } ++ ++ /* ++ * This following loop will be called only for capture stream ++ * In this platform, there is only one capture device on every SSP ++ */ ++ for_each_dpcm_fe(rtd, SNDRV_PCM_STREAM_CAPTURE, dpcm) { ++ rtd_dpcm = dpcm; ++ break; ++ } ++ ++ if (!rtd_dpcm) ++ return -EINVAL; ++ ++ /* ++ * The above 2 loops are mutually exclusive based on the stream direction, ++ * thus rtd_dpcm variable will never be overwritten ++ */ ++ /* + * Topology for kblda7219m98373 & kblmax98373 supports only S24_LE, + * where as kblda7219m98927 & kblmax98927 supports S16_LE by default. + * Skipping the port wise FE and BE configuration for kblda7219m98373 & +@@ -309,9 +331,9 @@ static int kabylake_ssp_fixup(struct snd + /* + * The ADSP will convert the FE rate to 48k, stereo, 24 bit + */ +- if (!strcmp(fe_dai_link->name, "Kbl Audio Port") || +- !strcmp(fe_dai_link->name, "Kbl Audio Headset Playback") || +- !strcmp(fe_dai_link->name, "Kbl Audio Capture Port")) { ++ if (!strcmp(rtd_dpcm->fe->dai_link->name, "Kbl Audio Port") || ++ !strcmp(rtd_dpcm->fe->dai_link->name, "Kbl Audio Headset Playback") || ++ !strcmp(rtd_dpcm->fe->dai_link->name, "Kbl Audio Capture Port")) { + rate->min = rate->max = 48000; + channels->min = channels->max = 2; + snd_mask_none(fmt); +@@ -322,7 +344,7 @@ static int kabylake_ssp_fixup(struct snd + * The speaker on the SSP0 supports S16_LE and not S24_LE. + * thus changing the mask here + */ +- if (!strcmp(be_dai_link->name, "SSP0-Codec")) ++ if (!strcmp(rtd_dpcm->be->dai_link->name, "SSP0-Codec")) + snd_mask_set_format(fmt, SNDRV_PCM_FORMAT_S16_LE); + + return 0; diff --git a/queue-5.4/asoc-samsung-tm2_wm5110-check-of-of_parse-return-value.patch b/queue-5.4/asoc-samsung-tm2_wm5110-check-of-of_parse-return-value.patch new file mode 100644 index 00000000000..a581879be8d --- /dev/null +++ b/queue-5.4/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 +@@ -553,7 +553,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-5.4/fddi-defxx-bail-out-gracefully-with-unassigned-pci-resource-for-csr.patch b/queue-5.4/fddi-defxx-bail-out-gracefully-with-unassigned-pci-resource-for-csr.patch new file mode 100644 index 00000000000..3853982c341 --- /dev/null +++ b/queue-5.4/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-5.4/iio-accel-adis16201-fix-wrong-axis-assignment-that-prevents-loading.patch b/queue-5.4/iio-accel-adis16201-fix-wrong-axis-assignment-that-prevents-loading.patch new file mode 100644 index 00000000000..db328701ac7 --- /dev/null +++ b/queue-5.4/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 +@@ -215,7 +215,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-5.4/md-bitmap-wait-for-external-bitmap-writes-to-complete-during-tear-down.patch b/queue-5.4/md-bitmap-wait-for-external-bitmap-writes-to-complete-during-tear-down.patch new file mode 100644 index 00000000000..4d89703b0b8 --- /dev/null +++ b/queue-5.4/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 +@@ -1726,6 +1726,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-5.4/mips-pci-mt7620-fix-pll-lock-check.patch b/queue-5.4/mips-pci-mt7620-fix-pll-lock-check.patch new file mode 100644 index 00000000000..ffbec9b756d --- /dev/null +++ b/queue-5.4/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 +@@ -30,6 +30,7 @@ + #define RALINK_GPIOMODE 0x60 + + #define PPLL_CFG1 0x9c ++#define PPLL_LD BIT(23) + + #define PPLL_DRV 0xa0 + #define PDRV_SW_SET BIT(31) +@@ -239,8 +240,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-5.4/mips-pci-rt2880-fix-slot-0-configuration.patch b/queue-5.4/mips-pci-rt2880-fix-slot-0-configuration.patch new file mode 100644 index 00000000000..9652bddcfcf --- /dev/null +++ b/queue-5.4/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 +@@ -180,7 +180,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) +@@ -188,8 +187,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; +@@ -201,16 +198,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; + } + +@@ -251,6 +238,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-5.4/misc-lis3lv02d-fix-false-positive-warn-on-various-hp-models.patch b/queue-5.4/misc-lis3lv02d-fix-false-positive-warn-on-various-hp-models.patch new file mode 100644 index 00000000000..e41f747c072 --- /dev/null +++ b/queue-5.4/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 +@@ -208,7 +208,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; +@@ -216,15 +216,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); +@@ -807,9 +815,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-5.4/misc-vmw_vmci-explicitly-initialize-vmci_datagram-payload.patch b/queue-5.4/misc-vmw_vmci-explicitly-initialize-vmci_datagram-payload.patch new file mode 100644 index 00000000000..3b44c553af3 --- /dev/null +++ b/queue-5.4/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 +@@ -168,7 +168,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-5.4/misc-vmw_vmci-explicitly-initialize-vmci_notify_bm_set_msg-struct.patch b/queue-5.4/misc-vmw_vmci-explicitly-initialize-vmci_notify_bm_set_msg-struct.patch new file mode 100644 index 00000000000..d035213a65d --- /dev/null +++ b/queue-5.4/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 +@@ -326,7 +326,7 @@ int vmci_dbell_host_context_notify(u32 s + bool vmci_dbell_register_notification_bitmap(u64 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-5.4/pci-allow-vpd-access-for-qlogic-isp2722.patch b/queue-5.4/pci-allow-vpd-access-for-qlogic-isp2722.patch new file mode 100644 index 00000000000..b93536ef40c --- /dev/null +++ b/queue-5.4/pci-allow-vpd-access-for-qlogic-isp2722.patch @@ -0,0 +1,45 @@ +From e00dc69b5f17c444a38cd9745a0f76bc989b3af4 Mon Sep 17 00:00:00 2001 +From: Arun Easi +Date: Fri, 9 Apr 2021 14:51:53 -0700 +Subject: PCI: Allow VPD access for QLogic ISP2722 + +From: Arun Easi + +commit e00dc69b5f17c444a38cd9745a0f76bc989b3af4 upstream. + +0d5370d1d852 ("PCI: Prevent VPD access for QLogic ISP2722") disabled access +to VPD of the ISP2722-based 16/32Gb Fibre Channel to PCIe Adapter because +reading past the end of the VPD caused NMIs. + +104daa71b396 ("PCI: Determine actual VPD size on first access") limits +reads to the actual size of VPD, which should prevent these NMIs. + +104daa71b396 was merged *before* 0d5370d1d852, but we think the testing +that prompted 0d5370d1d852 ("PCI: Prevent VPD access for QLogic ISP2722") +was done with a kernel that lacked 104daa71b396. See [1, 2]. + +Remove the quirk added by 0d5370d1d852 ("PCI: Prevent VPD access for QLogic +ISP2722") so customers can read the HBA VPD. + +[1] https://lore.kernel.org/linux-pci/alpine.LRH.2.21.9999.2012161641230.28924@irv1user01.caveonetworks.com/ +[2] https://lore.kernel.org/linux-pci/alpine.LRH.2.21.9999.2104071535110.13940@irv1user01.caveonetworks.com/ +[bhelgaas: commit log] +Link: https://lore.kernel.org/r/20210409215153.16569-2-aeasi@marvell.com +Signed-off-by: Arun Easi +Signed-off-by: Bjorn Helgaas +Cc: stable@vger.kernel.org # v4.6+ +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/vpd.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/drivers/pci/vpd.c ++++ b/drivers/pci/vpd.c +@@ -570,7 +570,6 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LS + DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005f, quirk_blacklist_vpd); + DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, PCI_ANY_ID, + quirk_blacklist_vpd); +-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_QLOGIC, 0x2261, quirk_blacklist_vpd); + /* + * The Amazon Annapurna Labs 0x0031 device id is reused for other non Root Port + * device types, so the quirk is registered for the PCI_CLASS_BRIDGE_PCI class. diff --git a/queue-5.4/phy-cadence-sierra-fix-phy-power_on-sequence.patch b/queue-5.4/phy-cadence-sierra-fix-phy-power_on-sequence.patch new file mode 100644 index 00000000000..3304192ca57 --- /dev/null +++ b/queue-5.4/phy-cadence-sierra-fix-phy-power_on-sequence.patch @@ -0,0 +1,49 @@ +From 5b4f5757f83be34d1428a1ffbb68d4a1966e9aae Mon Sep 17 00:00:00 2001 +From: Kishon Vijay Abraham I +Date: Fri, 19 Mar 2021 18:11:16 +0530 +Subject: phy: cadence: Sierra: Fix PHY power_on sequence + +From: Kishon Vijay Abraham I + +commit 5b4f5757f83be34d1428a1ffbb68d4a1966e9aae upstream. + +Commit 44d30d622821d ("phy: cadence: Add driver for Sierra PHY") +de-asserts PHY_RESET even before the configurations are loaded in +phy_init(). However PHY_RESET should be de-asserted only after +all the configurations has been initialized, instead of de-asserting +in probe. Fix it here. + +Fixes: 44d30d622821d ("phy: cadence: Add driver for Sierra PHY") +Signed-off-by: Kishon Vijay Abraham I +Cc: # v5.4+ +Reviewed-by: Philipp Zabel +Link: https://lore.kernel.org/r/20210319124128.13308-2-kishon@ti.com +Signed-off-by: Vinod Koul +Signed-off-by: Greg Kroah-Hartman +--- + drivers/phy/cadence/phy-cadence-sierra.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/drivers/phy/cadence/phy-cadence-sierra.c ++++ b/drivers/phy/cadence/phy-cadence-sierra.c +@@ -125,6 +125,12 @@ static int cdns_sierra_phy_on(struct phy + { + struct cdns_sierra_inst *ins = phy_get_drvdata(gphy); + ++ ret = reset_control_deassert(sp->phy_rst); ++ if (ret) { ++ dev_err(dev, "Failed to take the PHY out of reset\n"); ++ return ret; ++ } ++ + /* Take the PHY lane group out of reset */ + return reset_control_deassert(ins->lnk_rst); + } +@@ -271,7 +277,6 @@ static int cdns_sierra_phy_probe(struct + + pm_runtime_enable(dev); + phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate); +- reset_control_deassert(sp->phy_rst); + return PTR_ERR_OR_ZERO(phy_provider); + + put_child: diff --git a/queue-5.4/series b/queue-5.4/series index 0867e5f3c84..615adca510b 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -11,3 +11,20 @@ usb-serial-ti_usb_3410_5052-fix-tiocsserial-permission-check.patch staging-fwserial-fix-tiocsserial-jiffies-conversions.patch tty-moxa-fix-tiocsserial-permission-check.patch staging-fwserial-fix-tiocsserial-permission-check.patch +usb-typec-tcpm-address-incorrect-values-of-tcpm-psy-for-fixed-supply.patch +usb-typec-tcpm-address-incorrect-values-of-tcpm-psy-for-pps-supply.patch +usb-typec-tcpm-update-power-supply-once-partner-accepts.patch +usb-xhci-mtk-remove-or-operator-for-setting-schedule-parameters.patch +usb-xhci-mtk-improve-bandwidth-scheduling-with-tt.patch +asoc-samsung-tm2_wm5110-check-of-of_parse-return-value.patch +asoc-intel-kbl_da7219_max98927-fix-kabylake_ssp_fixup-function.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 +pci-allow-vpd-access-for-qlogic-isp2722.patch +iio-accel-adis16201-fix-wrong-axis-assignment-that-prevents-loading.patch +phy-cadence-sierra-fix-phy-power_on-sequence.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 diff --git a/queue-5.4/usb-typec-tcpm-address-incorrect-values-of-tcpm-psy-for-fixed-supply.patch b/queue-5.4/usb-typec-tcpm-address-incorrect-values-of-tcpm-psy-for-fixed-supply.patch new file mode 100644 index 00000000000..6d5ae827e4a --- /dev/null +++ b/queue-5.4/usb-typec-tcpm-address-incorrect-values-of-tcpm-psy-for-fixed-supply.patch @@ -0,0 +1,76 @@ +From f3dedafb8263ca4791a92a23f5230068f5bde008 Mon Sep 17 00:00:00 2001 +From: Badhri Jagan Sridharan +Date: Wed, 7 Apr 2021 13:07:18 -0700 +Subject: usb: typec: tcpm: Address incorrect values of tcpm psy for fixed supply + +From: Badhri Jagan Sridharan + +commit f3dedafb8263ca4791a92a23f5230068f5bde008 upstream. + +tcpm_pd_build_request overwrites current_limit and supply_voltage +even before port partner accepts the requests. This leaves stale +values in current_limit and supply_voltage that get exported by +"tcpm-source-psy-". Solving this problem by caching the request +values of current limit/supply voltage in req_current_limit +and req_supply_voltage. current_limit/supply_voltage gets updated +once the port partner accepts the request. + +Fixes: f2a8aa053c176 ("typec: tcpm: Represent source supply through power_supply") +Signed-off-by: Badhri Jagan Sridharan +Cc: stable +Reviewed-by: Guenter Roeck +Reviewed-by: Adam Thomson +Reviewed-by: Heikki Krogerus +Link: https://lore.kernel.org/r/20210407200723.1914388-1-badhri@google.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/typec/tcpm/tcpm.c | 17 ++++++++++------- + 1 file changed, 10 insertions(+), 7 deletions(-) + +--- a/drivers/usb/typec/tcpm/tcpm.c ++++ b/drivers/usb/typec/tcpm/tcpm.c +@@ -285,7 +285,10 @@ struct tcpm_port { + unsigned int operating_snk_mw; + bool update_sink_caps; + +- /* Requested current / voltage */ ++ /* Requested current / voltage to the port partner */ ++ u32 req_current_limit; ++ u32 req_supply_voltage; ++ /* Actual current / voltage limit of the local port */ + u32 current_limit; + u32 supply_voltage; + +@@ -1724,8 +1727,8 @@ static void tcpm_pd_ctrl_request(struct + case SNK_TRANSITION_SINK: + if (port->vbus_present) { + tcpm_set_current_limit(port, +- port->current_limit, +- port->supply_voltage); ++ port->req_current_limit, ++ port->req_supply_voltage); + port->explicit_contract = true; + tcpm_set_state(port, SNK_READY, 0); + } else { +@@ -1797,8 +1800,8 @@ static void tcpm_pd_ctrl_request(struct + break; + case SNK_NEGOTIATE_PPS_CAPABILITIES: + port->pps_data.active = true; +- port->supply_voltage = port->pps_data.out_volt; +- port->current_limit = port->pps_data.op_curr; ++ port->req_supply_voltage = port->pps_data.out_volt; ++ port->req_current_limit = port->pps_data.op_curr; + tcpm_set_state(port, SNK_TRANSITION_SINK, 0); + break; + case SOFT_RESET_SEND: +@@ -2402,8 +2405,8 @@ static int tcpm_pd_build_request(struct + flags & RDO_CAP_MISMATCH ? " [mismatch]" : ""); + } + +- port->current_limit = ma; +- port->supply_voltage = mv; ++ port->req_current_limit = ma; ++ port->req_supply_voltage = mv; + + return 0; + } diff --git a/queue-5.4/usb-typec-tcpm-address-incorrect-values-of-tcpm-psy-for-pps-supply.patch b/queue-5.4/usb-typec-tcpm-address-incorrect-values-of-tcpm-psy-for-pps-supply.patch new file mode 100644 index 00000000000..503c9efe9af --- /dev/null +++ b/queue-5.4/usb-typec-tcpm-address-incorrect-values-of-tcpm-psy-for-pps-supply.patch @@ -0,0 +1,226 @@ +From e3a0720224873587954b55d193d5b4abb14f0443 Mon Sep 17 00:00:00 2001 +From: Badhri Jagan Sridharan +Date: Wed, 7 Apr 2021 13:07:19 -0700 +Subject: usb: typec: tcpm: Address incorrect values of tcpm psy for pps supply + +From: Badhri Jagan Sridharan + +commit e3a0720224873587954b55d193d5b4abb14f0443 upstream. + +tcpm_pd_select_pps_apdo overwrites port->pps_data.min_volt, +port->pps_data.max_volt, port->pps_data.max_curr even before +port partner accepts the requests. This leaves incorrect values +in current_limit and supply_voltage that get exported by +"tcpm-source-psy-". Solving this problem by caching the request +values in req_min_volt, req_max_volt, req_max_curr, req_out_volt, +req_op_curr. min_volt, max_volt, max_curr gets updated once the +partner accepts the request. current_limit, supply_voltage gets updated +once local port's tcpm enters SNK_TRANSITION_SINK when the accepted +current_limit and supply_voltage is enforced. + +Fixes: f2a8aa053c176 ("typec: tcpm: Represent source supply through power_supply") +Signed-off-by: Badhri Jagan Sridharan +Cc: stable +Reviewed-by: Adam Thomson +Reviewed-by: Heikki Krogerus +Link: https://lore.kernel.org/r/20210407200723.1914388-2-badhri@google.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/typec/tcpm/tcpm.c | 88 +++++++++++++++++++++++++----------------- + 1 file changed, 53 insertions(+), 35 deletions(-) + +--- a/drivers/usb/typec/tcpm/tcpm.c ++++ b/drivers/usb/typec/tcpm/tcpm.c +@@ -181,12 +181,27 @@ struct pd_mode_data { + struct typec_altmode_desc altmode_desc[ALTMODE_DISCOVERY_MAX]; + }; + ++/* ++ * @min_volt: Actual min voltage at the local port ++ * @req_min_volt: Requested min voltage to the port partner ++ * @max_volt: Actual max voltage at the local port ++ * @req_max_volt: Requested max voltage to the port partner ++ * @max_curr: Actual max current at the local port ++ * @req_max_curr: Requested max current of the port partner ++ * @req_out_volt: Requested output voltage to the port partner ++ * @req_op_curr: Requested operating current to the port partner ++ * @supported: Parter has atleast one APDO hence supports PPS ++ * @active: PPS mode is active ++ */ + struct pd_pps_data { + u32 min_volt; ++ u32 req_min_volt; + u32 max_volt; ++ u32 req_max_volt; + u32 max_curr; +- u32 out_volt; +- u32 op_curr; ++ u32 req_max_curr; ++ u32 req_out_volt; ++ u32 req_op_curr; + bool supported; + bool active; + }; +@@ -1767,8 +1782,8 @@ static void tcpm_pd_ctrl_request(struct + break; + case SNK_NEGOTIATE_PPS_CAPABILITIES: + /* Revert data back from any requested PPS updates */ +- port->pps_data.out_volt = port->supply_voltage; +- port->pps_data.op_curr = port->current_limit; ++ port->pps_data.req_out_volt = port->supply_voltage; ++ port->pps_data.req_op_curr = port->current_limit; + port->pps_status = (type == PD_CTRL_WAIT ? + -EAGAIN : -EOPNOTSUPP); + tcpm_set_state(port, SNK_READY, 0); +@@ -1800,8 +1815,11 @@ static void tcpm_pd_ctrl_request(struct + break; + case SNK_NEGOTIATE_PPS_CAPABILITIES: + port->pps_data.active = true; +- port->req_supply_voltage = port->pps_data.out_volt; +- port->req_current_limit = port->pps_data.op_curr; ++ port->pps_data.min_volt = port->pps_data.req_min_volt; ++ port->pps_data.max_volt = port->pps_data.req_max_volt; ++ port->pps_data.max_curr = port->pps_data.req_max_curr; ++ port->req_supply_voltage = port->pps_data.req_out_volt; ++ port->req_current_limit = port->pps_data.req_op_curr; + tcpm_set_state(port, SNK_TRANSITION_SINK, 0); + break; + case SOFT_RESET_SEND: +@@ -2315,16 +2333,16 @@ static unsigned int tcpm_pd_select_pps_a + src = port->source_caps[src_pdo]; + snk = port->snk_pdo[snk_pdo]; + +- port->pps_data.min_volt = max(pdo_pps_apdo_min_voltage(src), +- pdo_pps_apdo_min_voltage(snk)); +- port->pps_data.max_volt = min(pdo_pps_apdo_max_voltage(src), +- pdo_pps_apdo_max_voltage(snk)); +- port->pps_data.max_curr = min_pps_apdo_current(src, snk); +- port->pps_data.out_volt = min(port->pps_data.max_volt, +- max(port->pps_data.min_volt, +- port->pps_data.out_volt)); +- port->pps_data.op_curr = min(port->pps_data.max_curr, +- port->pps_data.op_curr); ++ port->pps_data.req_min_volt = max(pdo_pps_apdo_min_voltage(src), ++ pdo_pps_apdo_min_voltage(snk)); ++ port->pps_data.req_max_volt = min(pdo_pps_apdo_max_voltage(src), ++ pdo_pps_apdo_max_voltage(snk)); ++ port->pps_data.req_max_curr = min_pps_apdo_current(src, snk); ++ port->pps_data.req_out_volt = min(port->pps_data.max_volt, ++ max(port->pps_data.min_volt, ++ port->pps_data.req_out_volt)); ++ port->pps_data.req_op_curr = min(port->pps_data.max_curr, ++ port->pps_data.req_op_curr); + power_supply_changed(port->psy); + } + +@@ -2452,10 +2470,10 @@ static int tcpm_pd_build_pps_request(str + tcpm_log(port, "Invalid APDO selected!"); + return -EINVAL; + } +- max_mv = port->pps_data.max_volt; +- max_ma = port->pps_data.max_curr; +- out_mv = port->pps_data.out_volt; +- op_ma = port->pps_data.op_curr; ++ max_mv = port->pps_data.req_max_volt; ++ max_ma = port->pps_data.req_max_curr; ++ out_mv = port->pps_data.req_out_volt; ++ op_ma = port->pps_data.req_op_curr; + break; + default: + tcpm_log(port, "Invalid PDO selected!"); +@@ -2502,8 +2520,8 @@ static int tcpm_pd_build_pps_request(str + tcpm_log(port, "Requesting APDO %d: %u mV, %u mA", + src_pdo_index, out_mv, op_ma); + +- port->pps_data.op_curr = op_ma; +- port->pps_data.out_volt = out_mv; ++ port->pps_data.req_op_curr = op_ma; ++ port->pps_data.req_out_volt = out_mv; + + return 0; + } +@@ -4174,7 +4192,7 @@ static int tcpm_try_role(const struct ty + return ret; + } + +-static int tcpm_pps_set_op_curr(struct tcpm_port *port, u16 op_curr) ++static int tcpm_pps_set_op_curr(struct tcpm_port *port, u16 req_op_curr) + { + unsigned int target_mw; + int ret; +@@ -4192,22 +4210,22 @@ static int tcpm_pps_set_op_curr(struct t + goto port_unlock; + } + +- if (op_curr > port->pps_data.max_curr) { ++ if (req_op_curr > port->pps_data.max_curr) { + ret = -EINVAL; + goto port_unlock; + } + +- target_mw = (op_curr * port->pps_data.out_volt) / 1000; ++ target_mw = (req_op_curr * port->supply_voltage) / 1000; + if (target_mw < port->operating_snk_mw) { + ret = -EINVAL; + goto port_unlock; + } + + /* Round down operating current to align with PPS valid steps */ +- op_curr = op_curr - (op_curr % RDO_PROG_CURR_MA_STEP); ++ req_op_curr = req_op_curr - (req_op_curr % RDO_PROG_CURR_MA_STEP); + + reinit_completion(&port->pps_complete); +- port->pps_data.op_curr = op_curr; ++ port->pps_data.req_op_curr = req_op_curr; + port->pps_status = 0; + port->pps_pending = true; + tcpm_set_state(port, SNK_NEGOTIATE_PPS_CAPABILITIES, 0); +@@ -4229,7 +4247,7 @@ swap_unlock: + return ret; + } + +-static int tcpm_pps_set_out_volt(struct tcpm_port *port, u16 out_volt) ++static int tcpm_pps_set_out_volt(struct tcpm_port *port, u16 req_out_volt) + { + unsigned int target_mw; + int ret; +@@ -4247,23 +4265,23 @@ static int tcpm_pps_set_out_volt(struct + goto port_unlock; + } + +- if (out_volt < port->pps_data.min_volt || +- out_volt > port->pps_data.max_volt) { ++ if (req_out_volt < port->pps_data.min_volt || ++ req_out_volt > port->pps_data.max_volt) { + ret = -EINVAL; + goto port_unlock; + } + +- target_mw = (port->pps_data.op_curr * out_volt) / 1000; ++ target_mw = (port->current_limit * req_out_volt) / 1000; + if (target_mw < port->operating_snk_mw) { + ret = -EINVAL; + goto port_unlock; + } + + /* Round down output voltage to align with PPS valid steps */ +- out_volt = out_volt - (out_volt % RDO_PROG_VOLT_MV_STEP); ++ req_out_volt = req_out_volt - (req_out_volt % RDO_PROG_VOLT_MV_STEP); + + reinit_completion(&port->pps_complete); +- port->pps_data.out_volt = out_volt; ++ port->pps_data.req_out_volt = req_out_volt; + port->pps_status = 0; + port->pps_pending = true; + tcpm_set_state(port, SNK_NEGOTIATE_PPS_CAPABILITIES, 0); +@@ -4312,8 +4330,8 @@ static int tcpm_pps_activate(struct tcpm + + /* Trigger PPS request or move back to standard PDO contract */ + if (activate) { +- port->pps_data.out_volt = port->supply_voltage; +- port->pps_data.op_curr = port->current_limit; ++ port->pps_data.req_out_volt = port->supply_voltage; ++ port->pps_data.req_op_curr = port->current_limit; + tcpm_set_state(port, SNK_NEGOTIATE_PPS_CAPABILITIES, 0); + } else { + tcpm_set_state(port, SNK_NEGOTIATE_CAPABILITIES, 0); diff --git a/queue-5.4/usb-typec-tcpm-update-power-supply-once-partner-accepts.patch b/queue-5.4/usb-typec-tcpm-update-power-supply-once-partner-accepts.patch new file mode 100644 index 00000000000..cfd04c16376 --- /dev/null +++ b/queue-5.4/usb-typec-tcpm-update-power-supply-once-partner-accepts.patch @@ -0,0 +1,55 @@ +From 4050f2683f2c3151dc3dd1501ac88c57caf810ff Mon Sep 17 00:00:00 2001 +From: Badhri Jagan Sridharan +Date: Wed, 7 Apr 2021 13:07:20 -0700 +Subject: usb: typec: tcpm: update power supply once partner accepts + +From: Badhri Jagan Sridharan + +commit 4050f2683f2c3151dc3dd1501ac88c57caf810ff upstream. + +power_supply_changed needs to be called to notify clients +after the partner accepts the requested values for the pps +case. + +Also, remove the redundant power_supply_changed at the end +of the tcpm_reset_port as power_supply_changed is already +called right after usb_type is changed. + +Fixes: f2a8aa053c176 ("typec: tcpm: Represent source supply through power_supply") +Signed-off-by: Badhri Jagan Sridharan +Cc: stable +Reviewed-by: Adam Thomson +Reviewed-by: Heikki Krogerus +Link: https://lore.kernel.org/r/20210407200723.1914388-3-badhri@google.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/typec/tcpm/tcpm.c | 4 +--- + 1 file changed, 1 insertion(+), 3 deletions(-) + +--- a/drivers/usb/typec/tcpm/tcpm.c ++++ b/drivers/usb/typec/tcpm/tcpm.c +@@ -1820,6 +1820,7 @@ static void tcpm_pd_ctrl_request(struct + port->pps_data.max_curr = port->pps_data.req_max_curr; + port->req_supply_voltage = port->pps_data.req_out_volt; + port->req_current_limit = port->pps_data.req_op_curr; ++ power_supply_changed(port->psy); + tcpm_set_state(port, SNK_TRANSITION_SINK, 0); + break; + case SOFT_RESET_SEND: +@@ -2343,7 +2344,6 @@ static unsigned int tcpm_pd_select_pps_a + port->pps_data.req_out_volt)); + port->pps_data.req_op_curr = min(port->pps_data.max_curr, + port->pps_data.req_op_curr); +- power_supply_changed(port->psy); + } + + return src_pdo; +@@ -2743,8 +2743,6 @@ static void tcpm_reset_port(struct tcpm_ + port->try_src_count = 0; + port->try_snk_count = 0; + port->usb_type = POWER_SUPPLY_USB_TYPE_C; +- +- power_supply_changed(port->psy); + } + + static void tcpm_detach(struct tcpm_port *port) diff --git a/queue-5.4/usb-xhci-mtk-improve-bandwidth-scheduling-with-tt.patch b/queue-5.4/usb-xhci-mtk-improve-bandwidth-scheduling-with-tt.patch new file mode 100644 index 00000000000..bfee4840573 --- /dev/null +++ b/queue-5.4/usb-xhci-mtk-improve-bandwidth-scheduling-with-tt.patch @@ -0,0 +1,178 @@ +From e19ee44a3d07c232f9241024dab1ebd0748cdf5f Mon Sep 17 00:00:00 2001 +From: Chunfeng Yun +Date: Mon, 8 Mar 2021 10:51:51 +0800 +Subject: usb: xhci-mtk: improve bandwidth scheduling with TT + +From: Chunfeng Yun + +commit e19ee44a3d07c232f9241024dab1ebd0748cdf5f upstream. + +When the USB headset is plug into an external hub, sometimes +can't set config due to not enough bandwidth, so need improve +LS/FS INT/ISOC bandwidth scheduling with TT. + +Fixes: 54f6a8af3722 ("usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints") +Cc: stable +Signed-off-by: Yaqii Wu +Signed-off-by: Chunfeng Yun +Link: https://lore.kernel.org/r/2f30e81400a59afef5f8231c98149169c7520519.1615170625.git.chunfeng.yun@mediatek.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/xhci-mtk-sch.c | 74 ++++++++++++++++++++++++++++++++-------- + drivers/usb/host/xhci-mtk.h | 6 ++- + 2 files changed, 64 insertions(+), 16 deletions(-) + +--- a/drivers/usb/host/xhci-mtk-sch.c ++++ b/drivers/usb/host/xhci-mtk-sch.c +@@ -378,6 +378,31 @@ static void update_bus_bw(struct mu3h_sc + sch_ep->allocated = used; + } + ++static int check_fs_bus_bw(struct mu3h_sch_ep_info *sch_ep, int offset) ++{ ++ struct mu3h_sch_tt *tt = sch_ep->sch_tt; ++ u32 num_esit, tmp; ++ int base; ++ int i, j; ++ ++ num_esit = XHCI_MTK_MAX_ESIT / sch_ep->esit; ++ for (i = 0; i < num_esit; i++) { ++ base = offset + i * sch_ep->esit; ++ ++ /* ++ * Compared with hs bus, no matter what ep type, ++ * the hub will always delay one uframe to send data ++ */ ++ for (j = 0; j < sch_ep->cs_count; j++) { ++ tmp = tt->fs_bus_bw[base + j] + sch_ep->bw_cost_per_microframe; ++ if (tmp > FS_PAYLOAD_MAX) ++ return -ERANGE; ++ } ++ } ++ ++ return 0; ++} ++ + static int check_sch_tt(struct usb_device *udev, + struct mu3h_sch_ep_info *sch_ep, u32 offset) + { +@@ -402,7 +427,7 @@ static int check_sch_tt(struct usb_devic + return -ERANGE; + + for (i = 0; i < sch_ep->cs_count; i++) +- if (test_bit(offset + i, tt->split_bit_map)) ++ if (test_bit(offset + i, tt->ss_bit_map)) + return -ERANGE; + + } else { +@@ -432,7 +457,7 @@ static int check_sch_tt(struct usb_devic + cs_count = 7; /* HW limit */ + + for (i = 0; i < cs_count + 2; i++) { +- if (test_bit(offset + i, tt->split_bit_map)) ++ if (test_bit(offset + i, tt->ss_bit_map)) + return -ERANGE; + } + +@@ -448,24 +473,44 @@ static int check_sch_tt(struct usb_devic + sch_ep->num_budget_microframes = sch_ep->esit; + } + +- return 0; ++ return check_fs_bus_bw(sch_ep, offset); + } + + static void update_sch_tt(struct usb_device *udev, +- struct mu3h_sch_ep_info *sch_ep) ++ struct mu3h_sch_ep_info *sch_ep, bool used) + { + struct mu3h_sch_tt *tt = sch_ep->sch_tt; + u32 base, num_esit; ++ int bw_updated; ++ int bits; + int i, j; + + num_esit = XHCI_MTK_MAX_ESIT / sch_ep->esit; ++ bits = (sch_ep->ep_type == ISOC_OUT_EP) ? sch_ep->cs_count : 1; ++ ++ if (used) ++ bw_updated = sch_ep->bw_cost_per_microframe; ++ else ++ bw_updated = -sch_ep->bw_cost_per_microframe; ++ + for (i = 0; i < num_esit; i++) { + base = sch_ep->offset + i * sch_ep->esit; +- for (j = 0; j < sch_ep->num_budget_microframes; j++) +- set_bit(base + j, tt->split_bit_map); ++ ++ for (j = 0; j < bits; j++) { ++ if (used) ++ set_bit(base + j, tt->ss_bit_map); ++ else ++ clear_bit(base + j, tt->ss_bit_map); ++ } ++ ++ for (j = 0; j < sch_ep->cs_count; j++) ++ tt->fs_bus_bw[base + j] += bw_updated; + } + +- list_add_tail(&sch_ep->tt_endpoint, &tt->ep_list); ++ if (used) ++ list_add_tail(&sch_ep->tt_endpoint, &tt->ep_list); ++ else ++ list_del(&sch_ep->tt_endpoint); + } + + static int check_sch_bw(struct usb_device *udev, +@@ -535,7 +580,7 @@ static int check_sch_bw(struct usb_devic + if (!tt_offset_ok) + return -ERANGE; + +- update_sch_tt(udev, sch_ep); ++ update_sch_tt(udev, sch_ep, 1); + } + + /* update bus bandwidth info */ +@@ -548,15 +593,16 @@ static void destroy_sch_ep(struct usb_de + struct mu3h_sch_bw_info *sch_bw, struct mu3h_sch_ep_info *sch_ep) + { + /* only release ep bw check passed by check_sch_bw() */ +- if (sch_ep->allocated) ++ if (sch_ep->allocated) { + update_bus_bw(sch_bw, sch_ep, 0); ++ if (sch_ep->sch_tt) ++ update_sch_tt(udev, sch_ep, 0); ++ } + +- list_del(&sch_ep->endpoint); +- +- if (sch_ep->sch_tt) { +- list_del(&sch_ep->tt_endpoint); ++ if (sch_ep->sch_tt) + drop_tt(udev); +- } ++ ++ list_del(&sch_ep->endpoint); + kfree(sch_ep); + } + +--- a/drivers/usb/host/xhci-mtk.h ++++ b/drivers/usb/host/xhci-mtk.h +@@ -20,13 +20,15 @@ + #define XHCI_MTK_MAX_ESIT 64 + + /** +- * @split_bit_map: used to avoid split microframes overlay ++ * @ss_bit_map: used to avoid start split microframes overlay ++ * @fs_bus_bw: array to keep track of bandwidth already used for FS + * @ep_list: Endpoints using this TT + * @usb_tt: usb TT related + * @tt_port: TT port number + */ + struct mu3h_sch_tt { +- DECLARE_BITMAP(split_bit_map, XHCI_MTK_MAX_ESIT); ++ DECLARE_BITMAP(ss_bit_map, XHCI_MTK_MAX_ESIT); ++ u32 fs_bus_bw[XHCI_MTK_MAX_ESIT]; + struct list_head ep_list; + struct usb_tt *usb_tt; + int tt_port; diff --git a/queue-5.4/usb-xhci-mtk-remove-or-operator-for-setting-schedule-parameters.patch b/queue-5.4/usb-xhci-mtk-remove-or-operator-for-setting-schedule-parameters.patch new file mode 100644 index 00000000000..9685681db02 --- /dev/null +++ b/queue-5.4/usb-xhci-mtk-remove-or-operator-for-setting-schedule-parameters.patch @@ -0,0 +1,46 @@ +From 5fa5827566e3affa1657ccf9b22706c06a5d021a Mon Sep 17 00:00:00 2001 +From: Chunfeng Yun +Date: Mon, 8 Mar 2021 10:51:50 +0800 +Subject: usb: xhci-mtk: remove or operator for setting schedule parameters + +From: Chunfeng Yun + +commit 5fa5827566e3affa1657ccf9b22706c06a5d021a upstream. + +Side effect may happen if use or operator to set schedule parameters +when the parameters are already set before. Set them directly due to +other bits are reserved. + +Fixes: 54f6a8af3722 ("usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints") +Cc: stable +Signed-off-by: Chunfeng Yun +Link: https://lore.kernel.org/r/d287899e6beb2fc1bfb8900c75a872f628ecde55.1615170625.git.chunfeng.yun@mediatek.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/xhci-mtk-sch.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/usb/host/xhci-mtk-sch.c ++++ b/drivers/usb/host/xhci-mtk-sch.c +@@ -643,7 +643,7 @@ int xhci_mtk_add_ep_quirk(struct usb_hcd + */ + if (usb_endpoint_xfer_int(&ep->desc) + || usb_endpoint_xfer_isoc(&ep->desc)) +- ep_ctx->reserved[0] |= cpu_to_le32(EP_BPKTS(1)); ++ ep_ctx->reserved[0] = cpu_to_le32(EP_BPKTS(1)); + + return 0; + } +@@ -730,10 +730,10 @@ int xhci_mtk_check_bandwidth(struct usb_ + list_move_tail(&sch_ep->endpoint, &sch_bw->bw_ep_list); + + ep_ctx = xhci_get_ep_ctx(xhci, virt_dev->in_ctx, ep_index); +- ep_ctx->reserved[0] |= cpu_to_le32(EP_BPKTS(sch_ep->pkts) ++ ep_ctx->reserved[0] = cpu_to_le32(EP_BPKTS(sch_ep->pkts) + | EP_BCSCOUNT(sch_ep->cs_count) + | EP_BBM(sch_ep->burst_mode)); +- ep_ctx->reserved[1] |= cpu_to_le32(EP_BOFFSET(sch_ep->offset) ++ ep_ctx->reserved[1] = cpu_to_le32(EP_BOFFSET(sch_ep->offset) + | EP_BREPEAT(sch_ep->repeat)); + + xhci_dbg(xhci, " PKTS:%x, CSCOUNT:%x, BM:%x, OFFSET:%x, REPEAT:%x\n",