From: Greg Kroah-Hartman Date: Sun, 7 May 2023 10:59:22 +0000 (+0200) Subject: 5.15-stable patches X-Git-Tag: v5.15.111~78 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=78cf95dcdec2cfd29dfb19f4a053fba8b684686d;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: clk-rockchip-rk3399-allow-clk_cifout-to-force-clk_cifout_src-to-reparent.patch mailbox-zynqmp-fix-ipi-isr-handling.patch mailbox-zynqmp-fix-typo-in-ipi-documentation.patch md-raid10-fix-null-ptr-deref-in-raid10_sync_request.patch mtd-core-fix-error-path-for-nvmem-provider.patch mtd-core-fix-nvmem-error-reporting.patch mtd-core-provide-unique-name-for-nvmem-device-take-two.patch wifi-rtl8xxxu-rtl8192eu-always-needs-full-init.patch --- diff --git a/queue-5.15/clk-rockchip-rk3399-allow-clk_cifout-to-force-clk_cifout_src-to-reparent.patch b/queue-5.15/clk-rockchip-rk3399-allow-clk_cifout-to-force-clk_cifout_src-to-reparent.patch new file mode 100644 index 00000000000..143f38e5dec --- /dev/null +++ b/queue-5.15/clk-rockchip-rk3399-allow-clk_cifout-to-force-clk_cifout_src-to-reparent.patch @@ -0,0 +1,39 @@ +From 933bf364e152cd60902cf9585c2ba310d593e69f Mon Sep 17 00:00:00 2001 +From: Quentin Schulz +Date: Thu, 17 Nov 2022 13:04:31 +0100 +Subject: clk: rockchip: rk3399: allow clk_cifout to force clk_cifout_src to reparent + +From: Quentin Schulz + +commit 933bf364e152cd60902cf9585c2ba310d593e69f upstream. + +clk_cifout is derived from clk_cifout_src through an integer divider +limited to 32. clk_cifout_src is a child of either cpll, gpll or npll +without any possibility of a divider of any sort. The default clock +parent is cpll. + +Let's allow clk_cifout to ask its parent clk_cifout_src to reparent in +order to find the real closest possible rate for clk_cifout and not one +derived from cpll only. + +Cc: stable@vger.kernel.org # 4.10+ +Fixes: fd8bc829336a ("clk: rockchip: fix the rk3399 cifout clock") +Signed-off-by: Quentin Schulz +Link: https://lore.kernel.org/r/20221117-rk3399-cifout-set-rate-parent-v1-0-432548d04081@theobroma-systems.com +Signed-off-by: Heiko Stuebner +Signed-off-by: Greg Kroah-Hartman +--- + drivers/clk/rockchip/clk-rk3399.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/clk/rockchip/clk-rk3399.c ++++ b/drivers/clk/rockchip/clk-rk3399.c +@@ -1263,7 +1263,7 @@ static struct rockchip_clk_branch rk3399 + RK3399_CLKSEL_CON(56), 6, 2, MFLAGS, + RK3399_CLKGATE_CON(10), 7, GFLAGS), + +- COMPOSITE_NOGATE(SCLK_CIF_OUT, "clk_cifout", mux_clk_cif_p, 0, ++ COMPOSITE_NOGATE(SCLK_CIF_OUT, "clk_cifout", mux_clk_cif_p, CLK_SET_RATE_PARENT, + RK3399_CLKSEL_CON(56), 5, 1, MFLAGS, 0, 5, DFLAGS), + + /* gic */ diff --git a/queue-5.15/mailbox-zynqmp-fix-ipi-isr-handling.patch b/queue-5.15/mailbox-zynqmp-fix-ipi-isr-handling.patch new file mode 100644 index 00000000000..07eab65de26 --- /dev/null +++ b/queue-5.15/mailbox-zynqmp-fix-ipi-isr-handling.patch @@ -0,0 +1,50 @@ +From 74ad37a30ffee3643bc34f9ca7225b20a66abaaf Mon Sep 17 00:00:00 2001 +From: Tanmay Shah +Date: Fri, 10 Mar 2023 17:24:05 -0800 +Subject: mailbox: zynqmp: Fix IPI isr handling + +From: Tanmay Shah + +commit 74ad37a30ffee3643bc34f9ca7225b20a66abaaf upstream. + +Multiple IPI channels are mapped to same interrupt handler. +Current isr implementation handles only one channel per isr. +Fix this behavior by checking isr status bit of all child +mailbox nodes. + +Fixes: 4981b82ba2ff ("mailbox: ZynqMP IPI mailbox controller") +Signed-off-by: Tanmay Shah +Acked-by: Michal Simek +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20230311012407.1292118-3-tanmay.shah@amd.com +Signed-off-by: Mathieu Poirier +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mailbox/zynqmp-ipi-mailbox.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/mailbox/zynqmp-ipi-mailbox.c ++++ b/drivers/mailbox/zynqmp-ipi-mailbox.c +@@ -152,7 +152,7 @@ static irqreturn_t zynqmp_ipi_interrupt( + struct zynqmp_ipi_message *msg; + u64 arg0, arg3; + struct arm_smccc_res res; +- int ret, i; ++ int ret, i, status = IRQ_NONE; + + (void)irq; + arg0 = SMC_IPI_MAILBOX_STATUS_ENQUIRY; +@@ -170,11 +170,11 @@ static irqreturn_t zynqmp_ipi_interrupt( + memcpy_fromio(msg->data, mchan->req_buf, + msg->len); + mbox_chan_received_data(chan, (void *)msg); +- return IRQ_HANDLED; ++ status = IRQ_HANDLED; + } + } + } +- return IRQ_NONE; ++ return status; + } + + /** diff --git a/queue-5.15/mailbox-zynqmp-fix-typo-in-ipi-documentation.patch b/queue-5.15/mailbox-zynqmp-fix-typo-in-ipi-documentation.patch new file mode 100644 index 00000000000..73ca4a43939 --- /dev/null +++ b/queue-5.15/mailbox-zynqmp-fix-typo-in-ipi-documentation.patch @@ -0,0 +1,34 @@ +From 79963fbfc233759bd8a43462f120d15a1bd4f4fa Mon Sep 17 00:00:00 2001 +From: Tanmay Shah +Date: Fri, 10 Mar 2023 17:24:06 -0800 +Subject: mailbox: zynqmp: Fix typo in IPI documentation + +From: Tanmay Shah + +commit 79963fbfc233759bd8a43462f120d15a1bd4f4fa upstream. + +Xilinx IPI message buffers allows 32-byte data transfer. +Fix documentation that says 12 bytes + +Fixes: 4981b82ba2ff ("mailbox: ZynqMP IPI mailbox controller") +Signed-off-by: Tanmay Shah +Acked-by: Michal Simek +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20230311012407.1292118-4-tanmay.shah@amd.com +Signed-off-by: Mathieu Poirier +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/mailbox/zynqmp-ipi-message.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/include/linux/mailbox/zynqmp-ipi-message.h ++++ b/include/linux/mailbox/zynqmp-ipi-message.h +@@ -9,7 +9,7 @@ + * @data: message payload + * + * This is the structure for data used in mbox_send_message +- * the maximum length of data buffer is fixed to 12 bytes. ++ * the maximum length of data buffer is fixed to 32 bytes. + * Client is supposed to be aware of this. + */ + struct zynqmp_ipi_message { diff --git a/queue-5.15/md-raid10-fix-null-ptr-deref-in-raid10_sync_request.patch b/queue-5.15/md-raid10-fix-null-ptr-deref-in-raid10_sync_request.patch new file mode 100644 index 00000000000..98ea3fb2a7f --- /dev/null +++ b/queue-5.15/md-raid10-fix-null-ptr-deref-in-raid10_sync_request.patch @@ -0,0 +1,64 @@ +From a405c6f0229526160aa3f177f65e20c86fce84c5 Mon Sep 17 00:00:00 2001 +From: Li Nan +Date: Wed, 22 Feb 2023 12:10:00 +0800 +Subject: md/raid10: fix null-ptr-deref in raid10_sync_request + +From: Li Nan + +commit a405c6f0229526160aa3f177f65e20c86fce84c5 upstream. + +init_resync() inits mempool and sets conf->have_replacemnt at the beginning +of sync, close_sync() frees the mempool when sync is completed. + +After [1] recovery might be skipped and init_resync() is called but +close_sync() is not. null-ptr-deref occurs with r10bio->dev[i].repl_bio. + +The following is one way to reproduce the issue. + + 1) create a array, wait for resync to complete, mddev->recovery_cp is set + to MaxSector. + 2) recovery is woken and it is skipped. conf->have_replacement is set to + 0 in init_resync(). close_sync() not called. + 3) some io errors and rdev A is set to WantReplacement. + 4) a new device is added and set to A's replacement. + 5) recovery is woken, A have replacement, but conf->have_replacemnt is + 0. r10bio->dev[i].repl_bio will not be alloced and null-ptr-deref + occurs. + +Fix it by not calling init_resync() if recovery skipped. + +[1] commit 7e83ccbecd60 ("md/raid10: Allow skipping recovery when clean arrays are assembled") +Fixes: 7e83ccbecd60 ("md/raid10: Allow skipping recovery when clean arrays are assembled") +Cc: stable@vger.kernel.org +Signed-off-by: Li Nan +Signed-off-by: Song Liu +Link: https://lore.kernel.org/r/20230222041000.3341651-3-linan666@huaweicloud.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/raid10.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/md/raid10.c ++++ b/drivers/md/raid10.c +@@ -3278,10 +3278,6 @@ static sector_t raid10_sync_request(stru + sector_t chunk_mask = conf->geo.chunk_mask; + int page_idx = 0; + +- if (!mempool_initialized(&conf->r10buf_pool)) +- if (init_resync(conf)) +- return 0; +- + /* + * Allow skipping a full rebuild for incremental assembly + * of a clean array, like RAID1 does. +@@ -3297,6 +3293,10 @@ static sector_t raid10_sync_request(stru + return mddev->dev_sectors - sector_nr; + } + ++ if (!mempool_initialized(&conf->r10buf_pool)) ++ if (init_resync(conf)) ++ return 0; ++ + skipped: + max_sector = mddev->dev_sectors; + if (test_bit(MD_RECOVERY_SYNC, &mddev->recovery) || diff --git a/queue-5.15/mtd-core-fix-error-path-for-nvmem-provider.patch b/queue-5.15/mtd-core-fix-error-path-for-nvmem-provider.patch new file mode 100644 index 00000000000..e60c8046b20 --- /dev/null +++ b/queue-5.15/mtd-core-fix-error-path-for-nvmem-provider.patch @@ -0,0 +1,60 @@ +From e0489f6e221f5ddee6cb3bd51b992b790c5fa4b9 Mon Sep 17 00:00:00 2001 +From: Michael Walle +Date: Wed, 8 Mar 2023 09:20:20 +0100 +Subject: mtd: core: fix error path for nvmem provider + +From: Michael Walle + +commit e0489f6e221f5ddee6cb3bd51b992b790c5fa4b9 upstream. + +If mtd_otp_nvmem_add() fails, the partitions won't be removed +because there is simply no call to del_mtd_partitions(). +Unfortunately, add_mtd_partitions() will print all partitions to +the kernel console. If mtd_otp_nvmem_add() returns -EPROBE_DEFER +this would print the partitions multiple times to the kernel +console. Instead move mtd_otp_nvmem_add() to the beginning of the +function. + +Fixes: 4b361cfa8624 ("mtd: core: add OTP nvmem provider support") +Cc: stable@vger.kernel.org +Signed-off-by: Michael Walle +Signed-off-by: Miquel Raynal +Link: https://lore.kernel.org/linux-mtd/20230308082021.870459-3-michael@walle.cc +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mtd/mtdcore.c | 13 ++++++++++--- + 1 file changed, 10 insertions(+), 3 deletions(-) + +--- a/drivers/mtd/mtdcore.c ++++ b/drivers/mtd/mtdcore.c +@@ -964,10 +964,14 @@ int mtd_device_parse_register(struct mtd + + mtd_set_dev_defaults(mtd); + ++ ret = mtd_otp_nvmem_add(mtd); ++ if (ret) ++ goto out; ++ + if (IS_ENABLED(CONFIG_MTD_PARTITIONED_MASTER)) { + ret = add_mtd_device(mtd); + if (ret) +- return ret; ++ goto out; + } + + /* Prefer parsed partitions over driver-provided fallback */ +@@ -1002,9 +1006,12 @@ int mtd_device_parse_register(struct mtd + register_reboot_notifier(&mtd->reboot_notifier); + } + +- ret = mtd_otp_nvmem_add(mtd); +- + out: ++ if (ret) { ++ nvmem_unregister(mtd->otp_user_nvmem); ++ nvmem_unregister(mtd->otp_factory_nvmem); ++ } ++ + if (ret && device_is_registered(&mtd->dev)) + del_mtd_device(mtd); + diff --git a/queue-5.15/mtd-core-fix-nvmem-error-reporting.patch b/queue-5.15/mtd-core-fix-nvmem-error-reporting.patch new file mode 100644 index 00000000000..bf511a8dd7e --- /dev/null +++ b/queue-5.15/mtd-core-fix-nvmem-error-reporting.patch @@ -0,0 +1,52 @@ +From 8bd1d24e6ca3c599dd455b0e1b22f77bab8290eb Mon Sep 17 00:00:00 2001 +From: Michael Walle +Date: Wed, 8 Mar 2023 09:20:19 +0100 +Subject: mtd: core: fix nvmem error reporting + +From: Michael Walle + +commit 8bd1d24e6ca3c599dd455b0e1b22f77bab8290eb upstream. + +The master MTD will only have an associated device if +CONFIG_MTD_PARTITIONED_MASTER is set, thus we cannot use dev_err() on +mtd->dev. Instead use the parent device which is the physical flash +memory. + +Fixes: 4b361cfa8624 ("mtd: core: add OTP nvmem provider support") +Cc: stable@vger.kernel.org +Signed-off-by: Michael Walle +Signed-off-by: Miquel Raynal +Link: https://lore.kernel.org/linux-mtd/20230308082021.870459-2-michael@walle.cc +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mtd/mtdcore.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/mtd/mtdcore.c ++++ b/drivers/mtd/mtdcore.c +@@ -879,6 +879,7 @@ static int mtd_nvmem_fact_otp_reg_read(v + + static int mtd_otp_nvmem_add(struct mtd_info *mtd) + { ++ struct device *dev = mtd->dev.parent; + struct nvmem_device *nvmem; + ssize_t size; + int err; +@@ -892,7 +893,7 @@ static int mtd_otp_nvmem_add(struct mtd_ + nvmem = mtd_otp_nvmem_register(mtd, "user-otp", size, + mtd_nvmem_user_otp_reg_read); + if (IS_ERR(nvmem)) { +- dev_err(&mtd->dev, "Failed to register OTP NVMEM device\n"); ++ dev_err(dev, "Failed to register OTP NVMEM device\n"); + return PTR_ERR(nvmem); + } + mtd->otp_user_nvmem = nvmem; +@@ -910,7 +911,7 @@ static int mtd_otp_nvmem_add(struct mtd_ + nvmem = mtd_otp_nvmem_register(mtd, "factory-otp", size, + mtd_nvmem_fact_otp_reg_read); + if (IS_ERR(nvmem)) { +- dev_err(&mtd->dev, "Failed to register OTP NVMEM device\n"); ++ dev_err(dev, "Failed to register OTP NVMEM device\n"); + err = PTR_ERR(nvmem); + goto err; + } diff --git a/queue-5.15/mtd-core-provide-unique-name-for-nvmem-device-take-two.patch b/queue-5.15/mtd-core-provide-unique-name-for-nvmem-device-take-two.patch new file mode 100644 index 00000000000..522a1f636c4 --- /dev/null +++ b/queue-5.15/mtd-core-provide-unique-name-for-nvmem-device-take-two.patch @@ -0,0 +1,48 @@ +From 1cd9ceaa5282ff10ea20a7fbadde5a476a1cc99e Mon Sep 17 00:00:00 2001 +From: Michael Walle +Date: Wed, 8 Mar 2023 09:20:18 +0100 +Subject: mtd: core: provide unique name for nvmem device, take two + +From: Michael Walle + +commit 1cd9ceaa5282ff10ea20a7fbadde5a476a1cc99e upstream. + +Commit c048b60d39e1 ("mtd: core: provide unique name for nvmem device") +tries to give the nvmem device a unique name, but fails badly if the mtd +device doesn't have a "struct device" associated with it, i.e. if +CONFIG_MTD_PARTITIONED_MASTER is not set. This will result in the name +"(null)-user-otp", which is not unique. It seems the best we can do is +to use the compatible name together with a unique identifier added by +the nvmem subsystem by using NVMEM_DEVID_AUTO. + +Fixes: c048b60d39e1 ("mtd: core: provide unique name for nvmem device") +Cc: stable@vger.kernel.org +Signed-off-by: Michael Walle +Signed-off-by: Miquel Raynal +Link: https://lore.kernel.org/linux-mtd/20230308082021.870459-1-michael@walle.cc +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mtd/mtdcore.c | 5 ++--- + 1 file changed, 2 insertions(+), 3 deletions(-) + +--- a/drivers/mtd/mtdcore.c ++++ b/drivers/mtd/mtdcore.c +@@ -828,8 +828,8 @@ static struct nvmem_device *mtd_otp_nvme + + /* OTP nvmem will be registered on the physical device */ + config.dev = mtd->dev.parent; +- config.name = kasprintf(GFP_KERNEL, "%s-%s", dev_name(&mtd->dev), compatible); +- config.id = NVMEM_DEVID_NONE; ++ config.name = compatible; ++ config.id = NVMEM_DEVID_AUTO; + config.owner = THIS_MODULE; + config.type = NVMEM_TYPE_OTP; + config.root_only = true; +@@ -845,7 +845,6 @@ static struct nvmem_device *mtd_otp_nvme + nvmem = NULL; + + of_node_put(np); +- kfree(config.name); + + return nvmem; + } diff --git a/queue-5.15/series b/queue-5.15/series index e583b919f70..c75b3a09cd5 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -357,3 +357,11 @@ alsa-usb-audio-add-quirk-for-pioneer-ddj-800.patch alsa-hda-realtek-add-quirk-for-asus-um3402yar-using-cs35l41.patch nilfs2-do-not-write-dirty-data-after-degenerating-to-read-only.patch nilfs2-fix-infinite-loop-in-nilfs_mdt_get_block.patch +md-raid10-fix-null-ptr-deref-in-raid10_sync_request.patch +mtd-core-provide-unique-name-for-nvmem-device-take-two.patch +mtd-core-fix-nvmem-error-reporting.patch +mtd-core-fix-error-path-for-nvmem-provider.patch +mailbox-zynqmp-fix-ipi-isr-handling.patch +mailbox-zynqmp-fix-typo-in-ipi-documentation.patch +wifi-rtl8xxxu-rtl8192eu-always-needs-full-init.patch +clk-rockchip-rk3399-allow-clk_cifout-to-force-clk_cifout_src-to-reparent.patch diff --git a/queue-5.15/wifi-rtl8xxxu-rtl8192eu-always-needs-full-init.patch b/queue-5.15/wifi-rtl8xxxu-rtl8192eu-always-needs-full-init.patch new file mode 100644 index 00000000000..0bdd4cc00be --- /dev/null +++ b/queue-5.15/wifi-rtl8xxxu-rtl8192eu-always-needs-full-init.patch @@ -0,0 +1,43 @@ +From d46e04ccd40457a0119b76e11ab64a2ad403e138 Mon Sep 17 00:00:00 2001 +From: Bitterblue Smith +Date: Mon, 13 Mar 2023 15:42:59 +0200 +Subject: wifi: rtl8xxxu: RTL8192EU always needs full init + +From: Bitterblue Smith + +commit d46e04ccd40457a0119b76e11ab64a2ad403e138 upstream. + +Always run the entire init sequence (rtl8xxxu_init_device()) for +RTL8192EU. It's what the vendor driver does too. + +This fixes a bug where the device is unable to connect after +rebooting: + +wlp3s0f3u2: send auth to ... (try 1/3) +wlp3s0f3u2: send auth to ... (try 2/3) +wlp3s0f3u2: send auth to ... (try 3/3) +wlp3s0f3u2: authentication with ... timed out + +Rebooting leaves the device powered on (partially? at least the +firmware is still running), but not really in a working state. + +Cc: stable@vger.kernel.org +Signed-off-by: Bitterblue Smith +Acked-by: Jes Sorensen +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/4eb111a9-d4c4-37d0-b376-4e202de7153c@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c ++++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c +@@ -1700,6 +1700,7 @@ struct rtl8xxxu_fileops rtl8192eu_fops = + .rx_desc_size = sizeof(struct rtl8xxxu_rxdesc24), + .has_s0s1 = 0, + .gen2_thermal_meter = 1, ++ .needs_full_init = 1, + .adda_1t_init = 0x0fc01616, + .adda_1t_path_on = 0x0fc01616, + .adda_2t_path_on_a = 0x0fc01616,