From: Sasha Levin Date: Thu, 5 Aug 2021 01:38:15 +0000 (-0400) Subject: Fixes for 5.13 X-Git-Tag: v4.4.279~32 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=da2f3c9aa8ac62cca07946d8b9526c28ff33b00b;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 5.13 Signed-off-by: Sasha Levin --- diff --git a/queue-5.13/asoc-rt5682-fix-the-issue-of-garbled-recording-after.patch b/queue-5.13/asoc-rt5682-fix-the-issue-of-garbled-recording-after.patch new file mode 100644 index 00000000000..b4295db15ea --- /dev/null +++ b/queue-5.13/asoc-rt5682-fix-the-issue-of-garbled-recording-after.patch @@ -0,0 +1,46 @@ +From 5ba1e26d4d73d28f76c6b70759dffe9ebe0e37ed Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 16 Jul 2021 16:58:53 +0800 +Subject: ASoC: rt5682: Fix the issue of garbled recording after + powerd_dbus_suspend + +From: Oder Chiou + +[ Upstream commit 6a503e1c455316fd0bfd8188c0a62cce7c5525ca ] + +While using the DMIC recording, the garbled data will be captured by the +DMIC. It is caused by the critical power of PLL closed in the jack detect +function. + +Signed-off-by: Oder Chiou +Link: https://lore.kernel.org/r/20210716085853.20170-1-oder_chiou@realtek.com +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + sound/soc/codecs/rt5682.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +diff --git a/sound/soc/codecs/rt5682.c b/sound/soc/codecs/rt5682.c +index e4c91571abae..abcd6f483788 100644 +--- a/sound/soc/codecs/rt5682.c ++++ b/sound/soc/codecs/rt5682.c +@@ -973,10 +973,14 @@ int rt5682_headset_detect(struct snd_soc_component *component, int jack_insert) + rt5682_enable_push_button_irq(component, false); + snd_soc_component_update_bits(component, RT5682_CBJ_CTRL_1, + RT5682_TRIG_JD_MASK, RT5682_TRIG_JD_LOW); +- if (!snd_soc_dapm_get_pin_status(dapm, "MICBIAS")) ++ if (!snd_soc_dapm_get_pin_status(dapm, "MICBIAS") && ++ !snd_soc_dapm_get_pin_status(dapm, "PLL1") && ++ !snd_soc_dapm_get_pin_status(dapm, "PLL2B")) + snd_soc_component_update_bits(component, + RT5682_PWR_ANLG_1, RT5682_PWR_MB, 0); +- if (!snd_soc_dapm_get_pin_status(dapm, "Vref2")) ++ if (!snd_soc_dapm_get_pin_status(dapm, "Vref2") && ++ !snd_soc_dapm_get_pin_status(dapm, "PLL1") && ++ !snd_soc_dapm_get_pin_status(dapm, "PLL2B")) + snd_soc_component_update_bits(component, + RT5682_PWR_ANLG_1, RT5682_PWR_VREF2, 0); + snd_soc_component_update_bits(component, RT5682_PWR_ANLG_3, +-- +2.30.2 + diff --git a/queue-5.13/asoc-ti-j721e-evm-check-for-not-initialized-parent_c.patch b/queue-5.13/asoc-ti-j721e-evm-check-for-not-initialized-parent_c.patch new file mode 100644 index 00000000000..c9acf97332d --- /dev/null +++ b/queue-5.13/asoc-ti-j721e-evm-check-for-not-initialized-parent_c.patch @@ -0,0 +1,36 @@ +From 106041ce6e3d1bbf5ed0ce88c6fae2e1a61b2ece Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 17 Jul 2021 15:28:19 +0300 +Subject: ASoC: ti: j721e-evm: Check for not initialized parent_clk_id + +From: Peter Ujfalusi + +[ Upstream commit 82d28b67f780910f816fe1cfb0f676fc38c4cbb3 ] + +During probe the parent_clk_id is set to -1 which should not be used to +array index within hsdiv_rates[]. + +Signed-off-by: Peter Ujfalusi +Link: https://lore.kernel.org/r/20210717122820.1467-3-peter.ujfalusi@gmail.com +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + sound/soc/ti/j721e-evm.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/sound/soc/ti/j721e-evm.c b/sound/soc/ti/j721e-evm.c +index 017c4ad11ca6..265bbc5a2f96 100644 +--- a/sound/soc/ti/j721e-evm.c ++++ b/sound/soc/ti/j721e-evm.c +@@ -197,7 +197,7 @@ static int j721e_configure_refclk(struct j721e_priv *priv, + return ret; + } + +- if (priv->hsdiv_rates[domain->parent_clk_id] != scki) { ++ if (domain->parent_clk_id == -1 || priv->hsdiv_rates[domain->parent_clk_id] != scki) { + dev_dbg(priv->dev, + "%s configuration for %u Hz: %s, %dxFS (SCKI: %u Hz)\n", + audio_domain == J721E_AUDIO_DOMAIN_CPB ? "CPB" : "IVI", +-- +2.30.2 + diff --git a/queue-5.13/asoc-ti-j721e-evm-fix-unbalanced-domain-activity-tra.patch b/queue-5.13/asoc-ti-j721e-evm-fix-unbalanced-domain-activity-tra.patch new file mode 100644 index 00000000000..fc21e839ae7 --- /dev/null +++ b/queue-5.13/asoc-ti-j721e-evm-fix-unbalanced-domain-activity-tra.patch @@ -0,0 +1,63 @@ +From 5afa4da239d6fe022d138c5921043df9fb83fad0 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 17 Jul 2021 15:28:18 +0300 +Subject: ASoC: ti: j721e-evm: Fix unbalanced domain activity tracking during + startup + +From: Peter Ujfalusi + +[ Upstream commit 78d2a05ef22e7b5863b01e073dd6a06b3979bb00 ] + +In case of an error within j721e_audio_startup() the domain->active must +be decremented to avoid unbalanced counter. + +Signed-off-by: Peter Ujfalusi +Link: https://lore.kernel.org/r/20210717122820.1467-2-peter.ujfalusi@gmail.com +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + sound/soc/ti/j721e-evm.c | 16 +++++++++++----- + 1 file changed, 11 insertions(+), 5 deletions(-) + +diff --git a/sound/soc/ti/j721e-evm.c b/sound/soc/ti/j721e-evm.c +index a7c0484d44ec..017c4ad11ca6 100644 +--- a/sound/soc/ti/j721e-evm.c ++++ b/sound/soc/ti/j721e-evm.c +@@ -278,23 +278,29 @@ static int j721e_audio_startup(struct snd_pcm_substream *substream) + j721e_rule_rate, &priv->rate_range, + SNDRV_PCM_HW_PARAM_RATE, -1); + +- mutex_unlock(&priv->mutex); + + if (ret) +- return ret; ++ goto out; + + /* Reset TDM slots to 32 */ + ret = snd_soc_dai_set_tdm_slot(cpu_dai, 0x3, 0x3, 2, 32); + if (ret && ret != -ENOTSUPP) +- return ret; ++ goto out; + + for_each_rtd_codec_dais(rtd, i, codec_dai) { + ret = snd_soc_dai_set_tdm_slot(codec_dai, 0x3, 0x3, 2, 32); + if (ret && ret != -ENOTSUPP) +- return ret; ++ goto out; + } + +- return 0; ++ if (ret == -ENOTSUPP) ++ ret = 0; ++out: ++ if (ret) ++ domain->active--; ++ mutex_unlock(&priv->mutex); ++ ++ return ret; + } + + static int j721e_audio_hw_params(struct snd_pcm_substream *substream, +-- +2.30.2 + diff --git a/queue-5.13/asoc-tlv320aic31xx-fix-reversed-bclk-wclk-master-bit.patch b/queue-5.13/asoc-tlv320aic31xx-fix-reversed-bclk-wclk-master-bit.patch new file mode 100644 index 00000000000..548646d281a --- /dev/null +++ b/queue-5.13/asoc-tlv320aic31xx-fix-reversed-bclk-wclk-master-bit.patch @@ -0,0 +1,49 @@ +From 73d38d866f03e6e91955981660db017968292e50 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 21 Jun 2021 21:09:41 -0400 +Subject: ASoC: tlv320aic31xx: fix reversed bclk/wclk master bits + +From: Kyle Russell + +[ Upstream commit 9cf76a72af6ab81030dea6481b1d7bdd814fbdaf ] + +These are backwards from Table 7-71 of the TLV320AIC3100 spec [1]. + +This was broken in 12eb4d66ba2e when BCLK_MASTER and WCLK_MASTER +were converted from 0x08 and 0x04 to BIT(2) and BIT(3), respectively. + +-#define AIC31XX_BCLK_MASTER 0x08 +-#define AIC31XX_WCLK_MASTER 0x04 ++#define AIC31XX_BCLK_MASTER BIT(2) ++#define AIC31XX_WCLK_MASTER BIT(3) + +Probably just a typo since the defines were not listed in bit order. + +[1] https://www.ti.com/lit/gpn/tlv320aic3100 + +Signed-off-by: Kyle Russell +Link: https://lore.kernel.org/r/20210622010941.241386-1-bkylerussell@gmail.com +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + sound/soc/codecs/tlv320aic31xx.h | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/sound/soc/codecs/tlv320aic31xx.h b/sound/soc/codecs/tlv320aic31xx.h +index 81952984613d..2513922a0292 100644 +--- a/sound/soc/codecs/tlv320aic31xx.h ++++ b/sound/soc/codecs/tlv320aic31xx.h +@@ -151,8 +151,8 @@ struct aic31xx_pdata { + #define AIC31XX_WORD_LEN_24BITS 0x02 + #define AIC31XX_WORD_LEN_32BITS 0x03 + #define AIC31XX_IFACE1_MASTER_MASK GENMASK(3, 2) +-#define AIC31XX_BCLK_MASTER BIT(2) +-#define AIC31XX_WCLK_MASTER BIT(3) ++#define AIC31XX_BCLK_MASTER BIT(3) ++#define AIC31XX_WCLK_MASTER BIT(2) + + /* AIC31XX_DATA_OFFSET */ + #define AIC31XX_DATA_OFFSET_MASK GENMASK(7, 0) +-- +2.30.2 + diff --git a/queue-5.13/drm-amd-display-fix-comparison-error-in-dcn21-dml.patch b/queue-5.13/drm-amd-display-fix-comparison-error-in-dcn21-dml.patch new file mode 100644 index 00000000000..378cc1471eb --- /dev/null +++ b/queue-5.13/drm-amd-display-fix-comparison-error-in-dcn21-dml.patch @@ -0,0 +1,42 @@ +From 434f0da6798210f315cce920885faa86edecab80 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 24 Jun 2021 11:05:42 -0400 +Subject: drm/amd/display: Fix comparison error in dcn21 DML + +From: Victor Lu + +[ Upstream commit ec3102dc6b36c692104c4a0546d4119de59a3bc1 ] + +[why] +A comparison error made it possible to not iterate through all the +specified prefetch modes. + +[how] +Correct "<" to "<=" + +Reviewed-by: Dmytro Laktyushkin +Reviewed-by: Yongqiang Sun +Acked-by: Rodrigo Siqueira +Signed-off-by: Victor Lu +Signed-off-by: Alex Deucher +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c +index 398210d1af34..f49743929357 100644 +--- a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c ++++ b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c +@@ -4889,7 +4889,7 @@ void dml21_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_l + } + } while ((locals->PrefetchSupported[i][j] != true || locals->VRatioInPrefetchSupported[i][j] != true) + && (mode_lib->vba.NextMaxVStartup != mode_lib->vba.MaxMaxVStartup[0][0] +- || mode_lib->vba.NextPrefetchMode < mode_lib->vba.MaxPrefetchMode)); ++ || mode_lib->vba.NextPrefetchMode <= mode_lib->vba.MaxPrefetchMode)); + + if (locals->PrefetchSupported[i][j] == true && locals->VRatioInPrefetchSupported[i][j] == true) { + mode_lib->vba.BandwidthAvailableForImmediateFlip = locals->ReturnBWPerState[i][0]; +-- +2.30.2 + diff --git a/queue-5.13/drm-amd-display-fix-max-vstartup-calculation-for-mod.patch b/queue-5.13/drm-amd-display-fix-max-vstartup-calculation-for-mod.patch new file mode 100644 index 00000000000..a30aca01870 --- /dev/null +++ b/queue-5.13/drm-amd-display-fix-max-vstartup-calculation-for-mod.patch @@ -0,0 +1,70 @@ +From 2a79a0c5c05e2fd651edf849b5a155386f0c4bd0 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 7 Jul 2021 13:19:14 -0400 +Subject: drm/amd/display: Fix max vstartup calculation for modes with borders + +From: Nicholas Kazlauskas + +[ Upstream commit d7940911fc0754d99b208f0e3098762d39f403a0 ] + +[Why] +Vertical and horizontal borders in timings are treated as increasing the +active area - vblank and hblank actually shrink. + +Our input into DML does not include these borders so it incorrectly +assumes it has more time than available for vstartup and tmdl +calculations for some modes with borders. + +An example of such a timing would be 640x480@72Hz: + +h_total: 832 +h_border_left: 8 +h_addressable: 640 +h_border_right: 8 +h_front_porch: 16 +h_sync_width: 40 +v_total: 520 +v_border_top: 8 +v_addressable: 480 +v_border_bottom: 8 +v_front_porch: 1 +v_sync_width: 3 +pix_clk_100hz: 315000 + +[How] +Include borders as part of destination vactive/hactive. + +This change DCN20+ so it has wide impact, but the destination vactive +and hactive are only really used for vstartup calculation anyway. + +Most modes do not have vertical or horizontal borders. + +Reviewed-by: Dmytro Laktyushkin +Acked-by: Rodrigo Siqueira +Signed-off-by: Nicholas Kazlauskas +Signed-off-by: Alex Deucher +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c +index d7d70b9bb387..81f583733fa8 100644 +--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c ++++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c +@@ -2093,8 +2093,10 @@ int dcn20_populate_dml_pipes_from_context( + - timing->v_border_bottom; + pipes[pipe_cnt].pipe.dest.htotal = timing->h_total; + pipes[pipe_cnt].pipe.dest.vtotal = v_total; +- pipes[pipe_cnt].pipe.dest.hactive = timing->h_addressable; +- pipes[pipe_cnt].pipe.dest.vactive = timing->v_addressable; ++ pipes[pipe_cnt].pipe.dest.hactive = ++ timing->h_addressable + timing->h_border_left + timing->h_border_right; ++ pipes[pipe_cnt].pipe.dest.vactive = ++ timing->v_addressable + timing->v_border_top + timing->v_border_bottom; + pipes[pipe_cnt].pipe.dest.interlaced = timing->flags.INTERLACE; + pipes[pipe_cnt].pipe.dest.pixel_rate_mhz = timing->pix_clk_100hz/10000.0; + if (timing->timing_3d_format == TIMING_3D_FORMAT_HW_FRAME_PACKING) +-- +2.30.2 + diff --git a/queue-5.13/efi-mokvar-reserve-the-table-only-if-it-is-in-boot-s.patch b/queue-5.13/efi-mokvar-reserve-the-table-only-if-it-is-in-boot-s.patch new file mode 100644 index 00000000000..c500dc88faf --- /dev/null +++ b/queue-5.13/efi-mokvar-reserve-the-table-only-if-it-is-in-boot-s.patch @@ -0,0 +1,65 @@ +From cef729a3282d1f80a0d02fd80470716763cebef9 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 20 Jul 2021 09:28:09 +0200 +Subject: efi/mokvar: Reserve the table only if it is in boot services data + +From: Borislav Petkov + +[ Upstream commit 47e1e233e9d822dfda068383fb9a616451bda703 ] + +One of the SUSE QA tests triggered: + + localhost kernel: efi: Failed to lookup EFI memory descriptor for 0x000000003dcf8000 + +which comes from x86's version of efi_arch_mem_reserve() trying to +reserve a memory region. Usually, that function expects +EFI_BOOT_SERVICES_DATA memory descriptors but the above case is for the +MOKvar table which is allocated in the EFI shim as runtime services. + +That lead to a fix changing the allocation of that table to boot services. + +However, that fix broke booting SEV guests with that shim leading to +this kernel fix + + 8d651ee9c71b ("x86/ioremap: Map EFI-reserved memory as encrypted for SEV") + +which extended the ioremap hint to map reserved EFI boot services as +decrypted too. + +However, all that wasn't needed, IMO, because that error message in +efi_arch_mem_reserve() was innocuous in this case - if the MOKvar table +is not in boot services, then it doesn't need to be reserved in the +first place because it is, well, in runtime services which *should* be +reserved anyway. + +So do that reservation for the MOKvar table only if it is allocated +in boot services data. I couldn't find any requirement about where +that table should be allocated in, unlike the ESRT which allocation is +mandated to be done in boot services data by the UEFI spec. + +Signed-off-by: Borislav Petkov +Signed-off-by: Ard Biesheuvel +Signed-off-by: Sasha Levin +--- + drivers/firmware/efi/mokvar-table.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +diff --git a/drivers/firmware/efi/mokvar-table.c b/drivers/firmware/efi/mokvar-table.c +index d8bc01340686..38722d2009e2 100644 +--- a/drivers/firmware/efi/mokvar-table.c ++++ b/drivers/firmware/efi/mokvar-table.c +@@ -180,7 +180,10 @@ void __init efi_mokvar_table_init(void) + pr_err("EFI MOKvar config table is not valid\n"); + return; + } +- efi_mem_reserve(efi.mokvar_table, map_size_needed); ++ ++ if (md.type == EFI_BOOT_SERVICES_DATA) ++ efi_mem_reserve(efi.mokvar_table, map_size_needed); ++ + efi_mokvar_table_size = map_size_needed; + } + +-- +2.30.2 + diff --git a/queue-5.13/io_uring-explicitly-catch-any-illegal-async-queue-at.patch b/queue-5.13/io_uring-explicitly-catch-any-illegal-async-queue-at.patch new file mode 100644 index 00000000000..90173a0bd36 --- /dev/null +++ b/queue-5.13/io_uring-explicitly-catch-any-illegal-async-queue-at.patch @@ -0,0 +1,65 @@ +From 6026bf0c75b4d130625eef3b88ad597bd47f3ad6 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 23 Jul 2021 11:53:54 -0600 +Subject: io_uring: explicitly catch any illegal async queue attempt + +From: Jens Axboe + +[ Upstream commit 991468dcf198bb87f24da330676724a704912b47 ] + +Catch an illegal case to queue async from an unrelated task that got +the ring fd passed to it. This should not be possible to hit, but +better be proactive and catch it explicitly. io-wq is extended to +check for early IO_WQ_WORK_CANCEL being set on a work item as well, +so it can run the request through the normal cancelation path. + +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + fs/io-wq.c | 7 ++++++- + fs/io_uring.c | 11 +++++++++++ + 2 files changed, 17 insertions(+), 1 deletion(-) + +diff --git a/fs/io-wq.c b/fs/io-wq.c +index 60f58efdb5f4..9efecdf025b9 100644 +--- a/fs/io-wq.c ++++ b/fs/io-wq.c +@@ -736,7 +736,12 @@ static void io_wqe_enqueue(struct io_wqe *wqe, struct io_wq_work *work) + int work_flags; + unsigned long flags; + +- if (test_bit(IO_WQ_BIT_EXIT, &wqe->wq->state)) { ++ /* ++ * If io-wq is exiting for this task, or if the request has explicitly ++ * been marked as one that should not get executed, cancel it here. ++ */ ++ if (test_bit(IO_WQ_BIT_EXIT, &wqe->wq->state) || ++ (work->flags & IO_WQ_WORK_CANCEL)) { + io_run_cancel(work, wqe); + return; + } +diff --git a/fs/io_uring.c b/fs/io_uring.c +index 86f609fa761c..32f3df13a812 100644 +--- a/fs/io_uring.c ++++ b/fs/io_uring.c +@@ -1282,6 +1282,17 @@ static void io_queue_async_work(struct io_kiocb *req) + + /* init ->work of the whole link before punting */ + io_prep_async_link(req); ++ ++ /* ++ * Not expected to happen, but if we do have a bug where this _can_ ++ * happen, catch it here and ensure the request is marked as ++ * canceled. That will make io-wq go through the usual work cancel ++ * procedure rather than attempt to run this request (or create a new ++ * worker for it). ++ */ ++ if (WARN_ON_ONCE(!same_thread_group(req->task, current))) ++ req->work.flags |= IO_WQ_WORK_CANCEL; ++ + trace_io_uring_queue_async_work(ctx, io_wq_is_hashed(&req->work), req, + &req->work, req->flags); + io_wq_enqueue(tctx->io_wq, &req->work); +-- +2.30.2 + diff --git a/queue-5.13/io_uring-never-attempt-iopoll-reissue-from-release-p.patch b/queue-5.13/io_uring-never-attempt-iopoll-reissue-from-release-p.patch new file mode 100644 index 00000000000..66e53508774 --- /dev/null +++ b/queue-5.13/io_uring-never-attempt-iopoll-reissue-from-release-p.patch @@ -0,0 +1,101 @@ +From f7f86f7296c83fad4099aeed64e56c9ac92fdfbe Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 23 Jul 2021 11:49:29 -0600 +Subject: io_uring: never attempt iopoll reissue from release path + +From: Jens Axboe + +[ Upstream commit 3c30ef0f78cfb36fdb13753794b0384cf7e37cc9 ] + +There are two reasons why this shouldn't be done: + +1) Ring is exiting, and we're canceling requests anyway. Any request + should be canceled anyway. In theory, this could iterate for a + number of times if someone else is also driving the target block + queue into request starvation, however the likelihood of this + happening is miniscule. + +2) If the original task decided to pass the ring to another task, then + we don't want to be reissuing from this context as it may be an + unrelated task or context. No assumptions should be made about + the context in which ->release() is run. This can only happen for pure + read/write, and we'll get -EFAULT on them anyway. + +Link: https://lore.kernel.org/io-uring/YPr4OaHv0iv0KTOc@zeniv-ca.linux.org.uk/ +Reported-by: Al Viro +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + fs/io_uring.c | 14 +++++++------- + 1 file changed, 7 insertions(+), 7 deletions(-) + +diff --git a/fs/io_uring.c b/fs/io_uring.c +index d465e9997157..86f609fa761c 100644 +--- a/fs/io_uring.c ++++ b/fs/io_uring.c +@@ -2252,7 +2252,7 @@ static inline bool io_run_task_work(void) + * Find and free completed poll iocbs + */ + static void io_iopoll_complete(struct io_ring_ctx *ctx, unsigned int *nr_events, +- struct list_head *done) ++ struct list_head *done, bool resubmit) + { + struct req_batch rb; + struct io_kiocb *req; +@@ -2267,7 +2267,7 @@ static void io_iopoll_complete(struct io_ring_ctx *ctx, unsigned int *nr_events, + req = list_first_entry(done, struct io_kiocb, inflight_entry); + list_del(&req->inflight_entry); + +- if (READ_ONCE(req->result) == -EAGAIN && ++ if (READ_ONCE(req->result) == -EAGAIN && resubmit && + !(req->flags & REQ_F_DONT_REISSUE)) { + req->iopoll_completed = 0; + req_ref_get(req); +@@ -2291,7 +2291,7 @@ static void io_iopoll_complete(struct io_ring_ctx *ctx, unsigned int *nr_events, + } + + static int io_do_iopoll(struct io_ring_ctx *ctx, unsigned int *nr_events, +- long min) ++ long min, bool resubmit) + { + struct io_kiocb *req, *tmp; + LIST_HEAD(done); +@@ -2334,7 +2334,7 @@ static int io_do_iopoll(struct io_ring_ctx *ctx, unsigned int *nr_events, + } + + if (!list_empty(&done)) +- io_iopoll_complete(ctx, nr_events, &done); ++ io_iopoll_complete(ctx, nr_events, &done, resubmit); + + return ret; + } +@@ -2352,7 +2352,7 @@ static void io_iopoll_try_reap_events(struct io_ring_ctx *ctx) + while (!list_empty(&ctx->iopoll_list)) { + unsigned int nr_events = 0; + +- io_do_iopoll(ctx, &nr_events, 0); ++ io_do_iopoll(ctx, &nr_events, 0, false); + + /* let it sleep and repeat later if can't complete a request */ + if (nr_events == 0) +@@ -2410,7 +2410,7 @@ static int io_iopoll_check(struct io_ring_ctx *ctx, long min) + if (list_empty(&ctx->iopoll_list)) + break; + } +- ret = io_do_iopoll(ctx, &nr_events, min); ++ ret = io_do_iopoll(ctx, &nr_events, min, true); + } while (!ret && nr_events < min && !need_resched()); + out: + mutex_unlock(&ctx->uring_lock); +@@ -6804,7 +6804,7 @@ static int __io_sq_thread(struct io_ring_ctx *ctx, bool cap_entries) + + mutex_lock(&ctx->uring_lock); + if (!list_empty(&ctx->iopoll_list)) +- io_do_iopoll(ctx, &nr_events, 0); ++ io_do_iopoll(ctx, &nr_events, 0, true); + + /* + * Don't submit if refs are dying, good for io_uring_register(), +-- +2.30.2 + diff --git a/queue-5.13/net-fix-zero-copy-head-len-calculation.patch b/queue-5.13/net-fix-zero-copy-head-len-calculation.patch new file mode 100644 index 00000000000..e29feac0caf --- /dev/null +++ b/queue-5.13/net-fix-zero-copy-head-len-calculation.patch @@ -0,0 +1,79 @@ +From 8433641cac6b8cadb5de132d1a008a976e412fc5 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 15 Jul 2021 16:59:00 -0700 +Subject: net: Fix zero-copy head len calculation. + +From: Pravin B Shelar + +[ Upstream commit a17ad0961706244dce48ec941f7e476a38c0e727 ] + +In some cases skb head could be locked and entire header +data is pulled from skb. When skb_zerocopy() called in such cases, +following BUG is triggered. This patch fixes it by copying entire +skb in such cases. +This could be optimized incase this is performance bottleneck. + +---8<--- +kernel BUG at net/core/skbuff.c:2961! +invalid opcode: 0000 [#1] SMP PTI +CPU: 2 PID: 0 Comm: swapper/2 Tainted: G OE 5.4.0-77-generic #86-Ubuntu +Hardware name: OpenStack Foundation OpenStack Nova, BIOS 1.13.0-1ubuntu1.1 04/01/2014 +RIP: 0010:skb_zerocopy+0x37a/0x3a0 +RSP: 0018:ffffbcc70013ca38 EFLAGS: 00010246 +Call Trace: + + queue_userspace_packet+0x2af/0x5e0 [openvswitch] + ovs_dp_upcall+0x3d/0x60 [openvswitch] + ovs_dp_process_packet+0x125/0x150 [openvswitch] + ovs_vport_receive+0x77/0xd0 [openvswitch] + netdev_port_receive+0x87/0x130 [openvswitch] + netdev_frame_hook+0x4b/0x60 [openvswitch] + __netif_receive_skb_core+0x2b4/0xc90 + __netif_receive_skb_one_core+0x3f/0xa0 + __netif_receive_skb+0x18/0x60 + process_backlog+0xa9/0x160 + net_rx_action+0x142/0x390 + __do_softirq+0xe1/0x2d6 + irq_exit+0xae/0xb0 + do_IRQ+0x5a/0xf0 + common_interrupt+0xf/0xf + +Code that triggered BUG: +int +skb_zerocopy(struct sk_buff *to, struct sk_buff *from, int len, int hlen) +{ + int i, j = 0; + int plen = 0; /* length of skb->head fragment */ + int ret; + struct page *page; + unsigned int offset; + + BUG_ON(!from->head_frag && !hlen); + +Signed-off-by: Pravin B Shelar +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/core/skbuff.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +diff --git a/net/core/skbuff.c b/net/core/skbuff.c +index 30ca61d91b69..17b93177a68f 100644 +--- a/net/core/skbuff.c ++++ b/net/core/skbuff.c +@@ -3006,8 +3006,11 @@ skb_zerocopy_headlen(const struct sk_buff *from) + + if (!from->head_frag || + skb_headlen(from) < L1_CACHE_BYTES || +- skb_shinfo(from)->nr_frags >= MAX_SKB_FRAGS) ++ skb_shinfo(from)->nr_frags >= MAX_SKB_FRAGS) { + hlen = skb_headlen(from); ++ if (!hlen) ++ hlen = from->len; ++ } + + if (skb_has_frag_list(from)) + hlen = from->len; +-- +2.30.2 + diff --git a/queue-5.13/nvme-fix-nvme_setup_command-metadata-trace-event.patch b/queue-5.13/nvme-fix-nvme_setup_command-metadata-trace-event.patch new file mode 100644 index 00000000000..62f5dd9e2e8 --- /dev/null +++ b/queue-5.13/nvme-fix-nvme_setup_command-metadata-trace-event.patch @@ -0,0 +1,53 @@ +From 892bb44d36fe989fad6649dc70f4960a40565e8e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 19 Jul 2021 09:44:39 -0700 +Subject: nvme: fix nvme_setup_command metadata trace event + +From: Keith Busch + +[ Upstream commit 234211b8dd161fa25f192c78d5a8d2dd6bf920a0 ] + +The metadata address is set after the trace event, so the trace is not +capturing anything useful. Rather than logging the memory address, it's +useful to know if the command carries a metadata payload, so change the +trace event to log that true/false state instead. + +Signed-off-by: Keith Busch +Signed-off-by: Christoph Hellwig +Signed-off-by: Sasha Levin +--- + drivers/nvme/host/trace.h | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +diff --git a/drivers/nvme/host/trace.h b/drivers/nvme/host/trace.h +index daaf700eae79..35bac7a25422 100644 +--- a/drivers/nvme/host/trace.h ++++ b/drivers/nvme/host/trace.h +@@ -56,7 +56,7 @@ TRACE_EVENT(nvme_setup_cmd, + __field(u8, fctype) + __field(u16, cid) + __field(u32, nsid) +- __field(u64, metadata) ++ __field(bool, metadata) + __array(u8, cdw10, 24) + ), + TP_fast_assign( +@@ -66,13 +66,13 @@ TRACE_EVENT(nvme_setup_cmd, + __entry->flags = cmd->common.flags; + __entry->cid = cmd->common.command_id; + __entry->nsid = le32_to_cpu(cmd->common.nsid); +- __entry->metadata = le64_to_cpu(cmd->common.metadata); ++ __entry->metadata = !!blk_integrity_rq(req); + __entry->fctype = cmd->fabrics.fctype; + __assign_disk_name(__entry->disk, req->rq_disk); + memcpy(__entry->cdw10, &cmd->common.cdw10, + sizeof(__entry->cdw10)); + ), +- TP_printk("nvme%d: %sqid=%d, cmdid=%u, nsid=%u, flags=0x%x, meta=0x%llx, cmd=(%s %s)", ++ TP_printk("nvme%d: %sqid=%d, cmdid=%u, nsid=%u, flags=0x%x, meta=0x%x, cmd=(%s %s)", + __entry->ctrl_id, __print_disk_name(__entry->disk), + __entry->qid, __entry->cid, __entry->nsid, + __entry->flags, __entry->metadata, +-- +2.30.2 + diff --git a/queue-5.13/qed-fix-possible-unpaired-spin_-un-lock_bh-in-_qed_m.patch b/queue-5.13/qed-fix-possible-unpaired-spin_-un-lock_bh-in-_qed_m.patch new file mode 100644 index 00000000000..a4a5f95223a --- /dev/null +++ b/queue-5.13/qed-fix-possible-unpaired-spin_-un-lock_bh-in-_qed_m.patch @@ -0,0 +1,114 @@ +From 3ea7fa46147f35b693a6aa99883e4014ca4aea9b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 15 Jul 2021 16:08:21 +0800 +Subject: qed: fix possible unpaired spin_{un}lock_bh in + _qed_mcp_cmd_and_union() + +From: Jia He + +[ Upstream commit 6206b7981a36476f4695d661ae139f7db36a802d ] + +Liajian reported a bug_on hit on a ThunderX2 arm64 server with FastLinQ +QL41000 ethernet controller: + BUG: scheduling while atomic: kworker/0:4/531/0x00000200 + [qed_probe:488()]hw prepare failed + kernel BUG at mm/vmalloc.c:2355! + Internal error: Oops - BUG: 0 [#1] SMP + CPU: 0 PID: 531 Comm: kworker/0:4 Tainted: G W 5.4.0-77-generic #86-Ubuntu + pstate: 00400009 (nzcv daif +PAN -UAO) + Call trace: + vunmap+0x4c/0x50 + iounmap+0x48/0x58 + qed_free_pci+0x60/0x80 [qed] + qed_probe+0x35c/0x688 [qed] + __qede_probe+0x88/0x5c8 [qede] + qede_probe+0x60/0xe0 [qede] + local_pci_probe+0x48/0xa0 + work_for_cpu_fn+0x24/0x38 + process_one_work+0x1d0/0x468 + worker_thread+0x238/0x4e0 + kthread+0xf0/0x118 + ret_from_fork+0x10/0x18 + +In this case, qed_hw_prepare() returns error due to hw/fw error, but in +theory work queue should be in process context instead of interrupt. + +The root cause might be the unpaired spin_{un}lock_bh() in +_qed_mcp_cmd_and_union(), which causes botton half is disabled incorrectly. + +Reported-by: Lijian Zhang +Signed-off-by: Jia He +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/qlogic/qed/qed_mcp.c | 23 +++++++++++++++++------ + 1 file changed, 17 insertions(+), 6 deletions(-) + +diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.c b/drivers/net/ethernet/qlogic/qed/qed_mcp.c +index cd882c453394..caeef25c89bb 100644 +--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.c ++++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.c +@@ -474,14 +474,18 @@ _qed_mcp_cmd_and_union(struct qed_hwfn *p_hwfn, + + spin_lock_bh(&p_hwfn->mcp_info->cmd_lock); + +- if (!qed_mcp_has_pending_cmd(p_hwfn)) ++ if (!qed_mcp_has_pending_cmd(p_hwfn)) { ++ spin_unlock_bh(&p_hwfn->mcp_info->cmd_lock); + break; ++ } + + rc = qed_mcp_update_pending_cmd(p_hwfn, p_ptt); +- if (!rc) ++ if (!rc) { ++ spin_unlock_bh(&p_hwfn->mcp_info->cmd_lock); + break; +- else if (rc != -EAGAIN) ++ } else if (rc != -EAGAIN) { + goto err; ++ } + + spin_unlock_bh(&p_hwfn->mcp_info->cmd_lock); + +@@ -498,6 +502,8 @@ _qed_mcp_cmd_and_union(struct qed_hwfn *p_hwfn, + return -EAGAIN; + } + ++ spin_lock_bh(&p_hwfn->mcp_info->cmd_lock); ++ + /* Send the mailbox command */ + qed_mcp_reread_offsets(p_hwfn, p_ptt); + seq_num = ++p_hwfn->mcp_info->drv_mb_seq; +@@ -524,14 +530,18 @@ _qed_mcp_cmd_and_union(struct qed_hwfn *p_hwfn, + + spin_lock_bh(&p_hwfn->mcp_info->cmd_lock); + +- if (p_cmd_elem->b_is_completed) ++ if (p_cmd_elem->b_is_completed) { ++ spin_unlock_bh(&p_hwfn->mcp_info->cmd_lock); + break; ++ } + + rc = qed_mcp_update_pending_cmd(p_hwfn, p_ptt); +- if (!rc) ++ if (!rc) { ++ spin_unlock_bh(&p_hwfn->mcp_info->cmd_lock); + break; +- else if (rc != -EAGAIN) ++ } else if (rc != -EAGAIN) { + goto err; ++ } + + spin_unlock_bh(&p_hwfn->mcp_info->cmd_lock); + } while (++cnt < max_retries); +@@ -554,6 +564,7 @@ _qed_mcp_cmd_and_union(struct qed_hwfn *p_hwfn, + return -EAGAIN; + } + ++ spin_lock_bh(&p_hwfn->mcp_info->cmd_lock); + qed_mcp_cmd_del_elem(p_hwfn, p_cmd_elem); + spin_unlock_bh(&p_hwfn->mcp_info->cmd_lock); + +-- +2.30.2 + diff --git a/queue-5.13/r8152-fix-a-deadlock-by-doubly-pm-resume.patch b/queue-5.13/r8152-fix-a-deadlock-by-doubly-pm-resume.patch new file mode 100644 index 00000000000..1b290c97675 --- /dev/null +++ b/queue-5.13/r8152-fix-a-deadlock-by-doubly-pm-resume.patch @@ -0,0 +1,112 @@ +From 668420afebb940fd555e4b9fb3d3f14b5d0ebb81 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 14 Jul 2021 19:00:22 +0200 +Subject: r8152: Fix a deadlock by doubly PM resume + +From: Takashi Iwai + +[ Upstream commit 776ac63a986d211286230c4fd70f85390eabedcd ] + +r8152 driver sets up the MAC address at reset-resume, while +rtl8152_set_mac_address() has the temporary autopm get/put. This may +lead to a deadlock as the PM lock has been already taken for the +execution of the runtime PM callback. + +This patch adds the workaround to avoid the superfluous autpm when +called from rtl8152_reset_resume(). + +Link: https://bugzilla.suse.com/show_bug.cgi?id=1186194 +Signed-off-by: Takashi Iwai +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/usb/r8152.c | 27 ++++++++++++++++++--------- + 1 file changed, 18 insertions(+), 9 deletions(-) + +diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c +index 8dcc55e4a5bc..2cf763b4ea84 100644 +--- a/drivers/net/usb/r8152.c ++++ b/drivers/net/usb/r8152.c +@@ -1550,7 +1550,8 @@ static int + rtl8152_set_speed(struct r8152 *tp, u8 autoneg, u32 speed, u8 duplex, + u32 advertising); + +-static int rtl8152_set_mac_address(struct net_device *netdev, void *p) ++static int __rtl8152_set_mac_address(struct net_device *netdev, void *p, ++ bool in_resume) + { + struct r8152 *tp = netdev_priv(netdev); + struct sockaddr *addr = p; +@@ -1559,9 +1560,11 @@ static int rtl8152_set_mac_address(struct net_device *netdev, void *p) + if (!is_valid_ether_addr(addr->sa_data)) + goto out1; + +- ret = usb_autopm_get_interface(tp->intf); +- if (ret < 0) +- goto out1; ++ if (!in_resume) { ++ ret = usb_autopm_get_interface(tp->intf); ++ if (ret < 0) ++ goto out1; ++ } + + mutex_lock(&tp->control); + +@@ -1573,11 +1576,17 @@ static int rtl8152_set_mac_address(struct net_device *netdev, void *p) + + mutex_unlock(&tp->control); + +- usb_autopm_put_interface(tp->intf); ++ if (!in_resume) ++ usb_autopm_put_interface(tp->intf); + out1: + return ret; + } + ++static int rtl8152_set_mac_address(struct net_device *netdev, void *p) ++{ ++ return __rtl8152_set_mac_address(netdev, p, false); ++} ++ + /* Devices containing proper chips can support a persistent + * host system provided MAC address. + * Examples of this are Dell TB15 and Dell WD15 docks +@@ -1696,7 +1705,7 @@ static int determine_ethernet_addr(struct r8152 *tp, struct sockaddr *sa) + return ret; + } + +-static int set_ethernet_addr(struct r8152 *tp) ++static int set_ethernet_addr(struct r8152 *tp, bool in_resume) + { + struct net_device *dev = tp->netdev; + struct sockaddr sa; +@@ -1709,7 +1718,7 @@ static int set_ethernet_addr(struct r8152 *tp) + if (tp->version == RTL_VER_01) + ether_addr_copy(dev->dev_addr, sa.sa_data); + else +- ret = rtl8152_set_mac_address(dev, &sa); ++ ret = __rtl8152_set_mac_address(dev, &sa, in_resume); + + return ret; + } +@@ -8442,7 +8451,7 @@ static int rtl8152_reset_resume(struct usb_interface *intf) + clear_bit(SELECTIVE_SUSPEND, &tp->flags); + tp->rtl_ops.init(tp); + queue_delayed_work(system_long_wq, &tp->hw_phy_work, 0); +- set_ethernet_addr(tp); ++ set_ethernet_addr(tp, true); + return rtl8152_resume(intf); + } + +@@ -9562,7 +9571,7 @@ static int rtl8152_probe(struct usb_interface *intf, + tp->rtl_fw.retry = true; + #endif + queue_delayed_work(system_long_wq, &tp->hw_phy_work, 0); +- set_ethernet_addr(tp); ++ set_ethernet_addr(tp, false); + + usb_set_intfdata(intf, tp); + +-- +2.30.2 + diff --git a/queue-5.13/r8152-fix-potential-pm-refcount-imbalance.patch b/queue-5.13/r8152-fix-potential-pm-refcount-imbalance.patch new file mode 100644 index 00000000000..d32d3020977 --- /dev/null +++ b/queue-5.13/r8152-fix-potential-pm-refcount-imbalance.patch @@ -0,0 +1,40 @@ +From 10465c87c73a71e03c500a26fb49848b5e30948a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 14 Jul 2021 19:00:21 +0200 +Subject: r8152: Fix potential PM refcount imbalance + +From: Takashi Iwai + +[ Upstream commit 9c23aa51477a37f8b56c3c40192248db0663c196 ] + +rtl8152_close() takes the refcount via usb_autopm_get_interface() but +it doesn't release when RTL8152_UNPLUG test hits. This may lead to +the imbalance of PM refcount. This patch addresses it. + +Link: https://bugzilla.suse.com/show_bug.cgi?id=1186194 +Signed-off-by: Takashi Iwai +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/usb/r8152.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c +index e25bfb7021ed..8dcc55e4a5bc 100644 +--- a/drivers/net/usb/r8152.c ++++ b/drivers/net/usb/r8152.c +@@ -6761,9 +6761,10 @@ static int rtl8152_close(struct net_device *netdev) + tp->rtl_ops.down(tp); + + mutex_unlock(&tp->control); ++ } + ++ if (!res) + usb_autopm_put_interface(tp->intf); +- } + + free_all_mem(tp); + +-- +2.30.2 + diff --git a/queue-5.13/regulator-mtk-dvfsrc-fix-wrong-dev-pointer-for-devm_.patch b/queue-5.13/regulator-mtk-dvfsrc-fix-wrong-dev-pointer-for-devm_.patch new file mode 100644 index 00000000000..c6ee1f75b24 --- /dev/null +++ b/queue-5.13/regulator-mtk-dvfsrc-fix-wrong-dev-pointer-for-devm_.patch @@ -0,0 +1,38 @@ +From 0ab8b705dfb268e57f99d90da0152168f9d9558e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 2 Jul 2021 22:21:40 +0800 +Subject: regulator: mtk-dvfsrc: Fix wrong dev pointer for + devm_regulator_register + +From: Axel Lin + +[ Upstream commit ea986908ccfcc53204a03bb0841227e1b26578c4 ] + +If use dev->parent, the regulator_unregister will not be called when this +driver is unloaded. Fix it by using dev instead. + +Signed-off-by: Axel Lin +Link: https://lore.kernel.org/r/20210702142140.2678130-1-axel.lin@ingics.com +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + drivers/regulator/mtk-dvfsrc-regulator.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +diff --git a/drivers/regulator/mtk-dvfsrc-regulator.c b/drivers/regulator/mtk-dvfsrc-regulator.c +index d3d876198d6e..234af3a66c77 100644 +--- a/drivers/regulator/mtk-dvfsrc-regulator.c ++++ b/drivers/regulator/mtk-dvfsrc-regulator.c +@@ -179,8 +179,7 @@ static int dvfsrc_vcore_regulator_probe(struct platform_device *pdev) + for (i = 0; i < regulator_init_data->size; i++) { + config.dev = dev->parent; + config.driver_data = (mt_regulators + i); +- rdev = devm_regulator_register(dev->parent, +- &(mt_regulators + i)->desc, ++ rdev = devm_regulator_register(dev, &(mt_regulators + i)->desc, + &config); + if (IS_ERR(rdev)) { + dev_err(dev, "failed to register %s\n", +-- +2.30.2 + diff --git a/queue-5.13/regulator-rt5033-fix-n_voltages-settings-for-buck-an.patch b/queue-5.13/regulator-rt5033-fix-n_voltages-settings-for-buck-an.patch new file mode 100644 index 00000000000..a9faa531250 --- /dev/null +++ b/queue-5.13/regulator-rt5033-fix-n_voltages-settings-for-buck-an.patch @@ -0,0 +1,48 @@ +From 040fc2e95fb7a08fd3c616ec6dd52d92b904753b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 27 Jun 2021 16:04:18 +0800 +Subject: regulator: rt5033: Fix n_voltages settings for BUCK and LDO + +From: Axel Lin + +[ Upstream commit 6549c46af8551b346bcc0b9043f93848319acd5c ] + +For linear regulators, the n_voltages should be (max - min) / step + 1. + +Buck voltage from 1v to 3V, per step 100mV, and vout mask is 0x1f. +If value is from 20 to 31, the voltage will all be fixed to 3V. +And LDO also, just vout range is different from 1.2v to 3v, step is the +same. If value is from 18 to 31, the voltage will also be fixed to 3v. + +Signed-off-by: Axel Lin +Reviewed-by: ChiYuan Huang +Link: https://lore.kernel.org/r/20210627080418.1718127-1-axel.lin@ingics.com +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + include/linux/mfd/rt5033-private.h | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/include/linux/mfd/rt5033-private.h b/include/linux/mfd/rt5033-private.h +index 2d1895c3efbf..40a0c2dfb80f 100644 +--- a/include/linux/mfd/rt5033-private.h ++++ b/include/linux/mfd/rt5033-private.h +@@ -200,13 +200,13 @@ enum rt5033_reg { + #define RT5033_REGULATOR_BUCK_VOLTAGE_MIN 1000000U + #define RT5033_REGULATOR_BUCK_VOLTAGE_MAX 3000000U + #define RT5033_REGULATOR_BUCK_VOLTAGE_STEP 100000U +-#define RT5033_REGULATOR_BUCK_VOLTAGE_STEP_NUM 32 ++#define RT5033_REGULATOR_BUCK_VOLTAGE_STEP_NUM 21 + + /* RT5033 regulator LDO output voltage uV */ + #define RT5033_REGULATOR_LDO_VOLTAGE_MIN 1200000U + #define RT5033_REGULATOR_LDO_VOLTAGE_MAX 3000000U + #define RT5033_REGULATOR_LDO_VOLTAGE_STEP 100000U +-#define RT5033_REGULATOR_LDO_VOLTAGE_STEP_NUM 32 ++#define RT5033_REGULATOR_LDO_VOLTAGE_STEP_NUM 19 + + /* RT5033 regulator SAFE LDO output voltage uV */ + #define RT5033_REGULATOR_SAFE_LDO_VOLTAGE 4900000U +-- +2.30.2 + diff --git a/queue-5.13/regulator-rtmv20-fix-wrong-mask-for-strobe-polarity-.patch b/queue-5.13/regulator-rtmv20-fix-wrong-mask-for-strobe-polarity-.patch new file mode 100644 index 00000000000..430ac71dc54 --- /dev/null +++ b/queue-5.13/regulator-rtmv20-fix-wrong-mask-for-strobe-polarity-.patch @@ -0,0 +1,37 @@ +From 2d38278d7af62f56032e0b36b148e21eb974d717 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 26 Jun 2021 23:58:32 +0800 +Subject: regulator: rtmv20: Fix wrong mask for strobe-polarity-high + +From: ChiYuan Huang + +[ Upstream commit 2b6a761be079f9fa8abf3157b5679a6f38885db4 ] + +Fix wrong mask for strobe-polarity-high. + +Signed-off-by: ChiYuan Huang +In-reply-to: +Reviewed-by: Axel Lin +Link: https://lore.kernel.org/r/1624723112-26653-1-git-send-email-u0084500@gmail.com +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + drivers/regulator/rtmv20-regulator.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/regulator/rtmv20-regulator.c b/drivers/regulator/rtmv20-regulator.c +index 4bca64de0f67..2ee334174e2b 100644 +--- a/drivers/regulator/rtmv20-regulator.c ++++ b/drivers/regulator/rtmv20-regulator.c +@@ -37,7 +37,7 @@ + #define RTMV20_WIDTH2_MASK GENMASK(7, 0) + #define RTMV20_LBPLVL_MASK GENMASK(3, 0) + #define RTMV20_LBPEN_MASK BIT(7) +-#define RTMV20_STROBEPOL_MASK BIT(1) ++#define RTMV20_STROBEPOL_MASK BIT(0) + #define RTMV20_VSYNPOL_MASK BIT(1) + #define RTMV20_FSINEN_MASK BIT(7) + #define RTMV20_ESEN_MASK BIT(6) +-- +2.30.2 + diff --git a/queue-5.13/series b/queue-5.13/series index 8e18762bf4d..57d463c8e26 100644 --- a/queue-5.13/series +++ b/queue-5.13/series @@ -11,3 +11,21 @@ net-dsa-sja1105-fix-address-learning-getting-disable.patch asoc-intel-boards-handle-hda-dsp-common-as-a-module.patch asoc-intel-boards-create-sof-maxim-common-module.patch asoc-intel-boards-fix-xrun-issue-on-platform-with-ma.patch +regulator-rtmv20-fix-wrong-mask-for-strobe-polarity-.patch +regulator-rt5033-fix-n_voltages-settings-for-buck-an.patch +spi-stm32h7-fix-full-duplex-irq-handler-handling.patch +asoc-tlv320aic31xx-fix-reversed-bclk-wclk-master-bit.patch +regulator-mtk-dvfsrc-fix-wrong-dev-pointer-for-devm_.patch +r8152-fix-potential-pm-refcount-imbalance.patch +r8152-fix-a-deadlock-by-doubly-pm-resume.patch +qed-fix-possible-unpaired-spin_-un-lock_bh-in-_qed_m.patch +asoc-rt5682-fix-the-issue-of-garbled-recording-after.patch +net-fix-zero-copy-head-len-calculation.patch +asoc-ti-j721e-evm-fix-unbalanced-domain-activity-tra.patch +asoc-ti-j721e-evm-check-for-not-initialized-parent_c.patch +efi-mokvar-reserve-the-table-only-if-it-is-in-boot-s.patch +nvme-fix-nvme_setup_command-metadata-trace-event.patch +drm-amd-display-fix-comparison-error-in-dcn21-dml.patch +drm-amd-display-fix-max-vstartup-calculation-for-mod.patch +io_uring-never-attempt-iopoll-reissue-from-release-p.patch +io_uring-explicitly-catch-any-illegal-async-queue-at.patch diff --git a/queue-5.13/spi-stm32h7-fix-full-duplex-irq-handler-handling.patch b/queue-5.13/spi-stm32h7-fix-full-duplex-irq-handler-handling.patch new file mode 100644 index 00000000000..88d68b986ee --- /dev/null +++ b/queue-5.13/spi-stm32h7-fix-full-duplex-irq-handler-handling.patch @@ -0,0 +1,58 @@ +From 7bab3ece5ef75c14394343769bc12811a421b663 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 30 Jun 2021 10:45:19 +0200 +Subject: spi: stm32h7: fix full duplex irq handler handling + +From: Alain Volmat + +[ Upstream commit e4a5c19888a5f8a9390860ca493e643be58c8791 ] + +In case of Full-Duplex mode, DXP flag is set when RXP and TXP flags are +set. But to avoid 2 different handlings, just add TXP and RXP flag in +the mask instead of DXP, and then keep the initial handling of TXP and +RXP events. +Also rephrase comment about EOTIE which is one of the interrupt enable +bits. It is not triggered by any event. + +Signed-off-by: Amelie Delaunay +Signed-off-by: Alain Volmat +Reviewed-by: Amelie Delaunay +Link: https://lore.kernel.org/r/1625042723-661-3-git-send-email-alain.volmat@foss.st.com +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + drivers/spi/spi-stm32.c | 15 +++++++++------ + 1 file changed, 9 insertions(+), 6 deletions(-) + +diff --git a/drivers/spi/spi-stm32.c b/drivers/spi/spi-stm32.c +index a92a28933edb..05618a618939 100644 +--- a/drivers/spi/spi-stm32.c ++++ b/drivers/spi/spi-stm32.c +@@ -884,15 +884,18 @@ static irqreturn_t stm32h7_spi_irq_thread(int irq, void *dev_id) + ier = readl_relaxed(spi->base + STM32H7_SPI_IER); + + mask = ier; +- /* EOTIE is triggered on EOT, SUSP and TXC events. */ ++ /* ++ * EOTIE enables irq from EOT, SUSP and TXC events. We need to set ++ * SUSP to acknowledge it later. TXC is automatically cleared ++ */ ++ + mask |= STM32H7_SPI_SR_SUSP; + /* +- * When TXTF is set, DXPIE and TXPIE are cleared. So in case of +- * Full-Duplex, need to poll RXP event to know if there are remaining +- * data, before disabling SPI. ++ * DXPIE is set in Full-Duplex, one IT will be raised if TXP and RXP ++ * are set. So in case of Full-Duplex, need to poll TXP and RXP event. + */ +- if (spi->rx_buf && !spi->cur_usedma) +- mask |= STM32H7_SPI_SR_RXP; ++ if ((spi->cur_comm == SPI_FULL_DUPLEX) && !spi->cur_usedma) ++ mask |= STM32H7_SPI_SR_TXP | STM32H7_SPI_SR_RXP; + + if (!(sr & mask)) { + dev_warn(spi->dev, "spurious IT (sr=0x%08x, ier=0x%08x)\n", +-- +2.30.2 +