From: Greg Kroah-Hartman Date: Mon, 21 Aug 2023 11:46:07 +0000 (+0200) Subject: 6.1-stable patches X-Git-Tag: v6.4.12~55 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=f56654ce56191bd25d4b7eab948c0753e14c587e;p=thirdparty%2Fkernel%2Fstable-queue.git 6.1-stable patches added patches: alsa-usb-audio-add-support-for-mythware-xa001au-capture-and-playback-interfaces.patch arm64-dts-rockchip-fix-wifi-bluetooth-on-rock-pi-4-boards.patch blk-crypto-dynamically-allocate-fallback-profile.patch cifs-release-folio-lock-on-fscache-read-hit.patch mmc-block-fix-in_flight-value-error.patch mmc-wbsd-fix-double-mmc_free_host-in-wbsd_init.patch riscv-handle-zicsr-zifencei-issue-between-gcc-and-binutils.patch virtio-net-zero-max_tx_vq-field-for-virtio_net_ctrl_mq_hash_config-case.patch --- diff --git a/queue-6.1/alsa-usb-audio-add-support-for-mythware-xa001au-capture-and-playback-interfaces.patch b/queue-6.1/alsa-usb-audio-add-support-for-mythware-xa001au-capture-and-playback-interfaces.patch new file mode 100644 index 00000000000..d1cfddd887a --- /dev/null +++ b/queue-6.1/alsa-usb-audio-add-support-for-mythware-xa001au-capture-and-playback-interfaces.patch @@ -0,0 +1,58 @@ +From 788449ae57f4273111b779bbcaad552b67f517d5 Mon Sep 17 00:00:00 2001 +From: dengxiang +Date: Thu, 3 Aug 2023 10:44:37 +0800 +Subject: ALSA: usb-audio: Add support for Mythware XA001AU capture and playback interfaces. + +From: dengxiang + +commit 788449ae57f4273111b779bbcaad552b67f517d5 upstream. + +This patch adds a USB quirk for Mythware XA001AU USB interface. + +Signed-off-by: dengxiang +Cc: +Link: https://lore.kernel.org/r/20230803024437.370069-1-dengxiang@nfschina.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/usb/quirks-table.h | 29 +++++++++++++++++++++++++++++ + 1 file changed, 29 insertions(+) + +--- a/sound/usb/quirks-table.h ++++ b/sound/usb/quirks-table.h +@@ -4507,6 +4507,35 @@ YAMAHA_DEVICE(0x7010, "UB99"), + } + } + }, ++{ ++ /* Advanced modes of the Mythware XA001AU. ++ * For the standard mode, Mythware XA001AU has ID ffad:a001 ++ */ ++ USB_DEVICE_VENDOR_SPEC(0xffad, 0xa001), ++ .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) { ++ .vendor_name = "Mythware", ++ .product_name = "XA001AU", ++ .ifnum = QUIRK_ANY_INTERFACE, ++ .type = QUIRK_COMPOSITE, ++ .data = (const struct snd_usb_audio_quirk[]) { ++ { ++ .ifnum = 0, ++ .type = QUIRK_IGNORE_INTERFACE, ++ }, ++ { ++ .ifnum = 1, ++ .type = QUIRK_AUDIO_STANDARD_INTERFACE, ++ }, ++ { ++ .ifnum = 2, ++ .type = QUIRK_AUDIO_STANDARD_INTERFACE, ++ }, ++ { ++ .ifnum = -1 ++ } ++ } ++ } ++}, + + #undef USB_DEVICE_VENDOR_SPEC + #undef USB_AUDIO_DEVICE diff --git a/queue-6.1/arm64-dts-rockchip-fix-wifi-bluetooth-on-rock-pi-4-boards.patch b/queue-6.1/arm64-dts-rockchip-fix-wifi-bluetooth-on-rock-pi-4-boards.patch new file mode 100644 index 00000000000..54a14295261 --- /dev/null +++ b/queue-6.1/arm64-dts-rockchip-fix-wifi-bluetooth-on-rock-pi-4-boards.patch @@ -0,0 +1,43 @@ +From ebceec271e552a2b05e47d8ef0597052b1a39449 Mon Sep 17 00:00:00 2001 +From: Yogesh Hegde +Date: Tue, 18 Jul 2023 22:09:41 +0530 +Subject: arm64: dts: rockchip: Fix Wifi/Bluetooth on ROCK Pi 4 boards + +From: Yogesh Hegde + +commit ebceec271e552a2b05e47d8ef0597052b1a39449 upstream. + +This patch fixes an issue affecting the Wifi/Bluetooth connectivity on +ROCK Pi 4 boards. Commit f471b1b2db08 ("arm64: dts: rockchip: Fix Bluetooth +on ROCK Pi 4 boards") introduced a problem with the clock configuration. +Specifically, the clock-names property of the sdio-pwrseq node was not +updated to 'lpo', causing the driver to wait indefinitely for the wrong clock +signal 'ext_clock' instead of the expected one 'lpo'. This prevented the proper +initialization of Wifi/Bluetooth chip on ROCK Pi 4 boards. + +To address this, this patch updates the clock-names property of the +sdio-pwrseq node to "lpo" to align with the changes made to the bluetooth node. + +This patch has been tested on ROCK Pi 4B. + +Fixes: f471b1b2db08 ("arm64: dts: rockchip: Fix Bluetooth on ROCK Pi 4 boards") +Cc: stable@vger.kernel.org +Signed-off-by: Yogesh Hegde +Link: https://lore.kernel.org/r/ZLbATQRjOl09aLAp@zephyrusG14 +Signed-off-by: Heiko Stuebner +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi ++++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi +@@ -45,7 +45,7 @@ + sdio_pwrseq: sdio-pwrseq { + compatible = "mmc-pwrseq-simple"; + clocks = <&rk808 1>; +- clock-names = "ext_clock"; ++ clock-names = "lpo"; + pinctrl-names = "default"; + pinctrl-0 = <&wifi_enable_h>; + reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>; diff --git a/queue-6.1/blk-crypto-dynamically-allocate-fallback-profile.patch b/queue-6.1/blk-crypto-dynamically-allocate-fallback-profile.patch new file mode 100644 index 00000000000..ea7b764b6ac --- /dev/null +++ b/queue-6.1/blk-crypto-dynamically-allocate-fallback-profile.patch @@ -0,0 +1,134 @@ +From c984ff1423ae9f70b1f28ce811856db0d9c99021 Mon Sep 17 00:00:00 2001 +From: Sweet Tea Dorminy +Date: Thu, 17 Aug 2023 10:15:56 -0400 +Subject: blk-crypto: dynamically allocate fallback profile + +From: Sweet Tea Dorminy + +commit c984ff1423ae9f70b1f28ce811856db0d9c99021 upstream. + +blk_crypto_profile_init() calls lockdep_register_key(), which warns and +does not register if the provided memory is a static object. +blk-crypto-fallback currently has a static blk_crypto_profile and calls +blk_crypto_profile_init() thereupon, resulting in the warning and +failure to register. + +Fortunately it is simple enough to use a dynamically allocated profile +and make lockdep function correctly. + +Fixes: 2fb48d88e77f ("blk-crypto: use dynamic lock class for blk_crypto_profile::lock") +Cc: stable@vger.kernel.org +Signed-off-by: Sweet Tea Dorminy +Reviewed-by: Eric Biggers +Link: https://lore.kernel.org/r/20230817141615.15387-1-sweettea-kernel@dorminy.me +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + block/blk-crypto-fallback.c | 36 +++++++++++++++++++++++------------- + 1 file changed, 23 insertions(+), 13 deletions(-) + +diff --git a/block/blk-crypto-fallback.c b/block/blk-crypto-fallback.c +index ad9844c5b40c..e6468eab2681 100644 +--- a/block/blk-crypto-fallback.c ++++ b/block/blk-crypto-fallback.c +@@ -78,7 +78,7 @@ static struct blk_crypto_fallback_keyslot { + struct crypto_skcipher *tfms[BLK_ENCRYPTION_MODE_MAX]; + } *blk_crypto_keyslots; + +-static struct blk_crypto_profile blk_crypto_fallback_profile; ++static struct blk_crypto_profile *blk_crypto_fallback_profile; + static struct workqueue_struct *blk_crypto_wq; + static mempool_t *blk_crypto_bounce_page_pool; + static struct bio_set crypto_bio_split; +@@ -292,7 +292,7 @@ static bool blk_crypto_fallback_encrypt_bio(struct bio **bio_ptr) + * Get a blk-crypto-fallback keyslot that contains a crypto_skcipher for + * this bio's algorithm and key. + */ +- blk_st = blk_crypto_get_keyslot(&blk_crypto_fallback_profile, ++ blk_st = blk_crypto_get_keyslot(blk_crypto_fallback_profile, + bc->bc_key, &slot); + if (blk_st != BLK_STS_OK) { + src_bio->bi_status = blk_st; +@@ -395,7 +395,7 @@ static void blk_crypto_fallback_decrypt_bio(struct work_struct *work) + * Get a blk-crypto-fallback keyslot that contains a crypto_skcipher for + * this bio's algorithm and key. + */ +- blk_st = blk_crypto_get_keyslot(&blk_crypto_fallback_profile, ++ blk_st = blk_crypto_get_keyslot(blk_crypto_fallback_profile, + bc->bc_key, &slot); + if (blk_st != BLK_STS_OK) { + bio->bi_status = blk_st; +@@ -499,7 +499,7 @@ bool blk_crypto_fallback_bio_prep(struct bio **bio_ptr) + return false; + } + +- if (!__blk_crypto_cfg_supported(&blk_crypto_fallback_profile, ++ if (!__blk_crypto_cfg_supported(blk_crypto_fallback_profile, + &bc->bc_key->crypto_cfg)) { + bio->bi_status = BLK_STS_NOTSUPP; + return false; +@@ -526,7 +526,7 @@ bool blk_crypto_fallback_bio_prep(struct bio **bio_ptr) + + int blk_crypto_fallback_evict_key(const struct blk_crypto_key *key) + { +- return __blk_crypto_evict_key(&blk_crypto_fallback_profile, key); ++ return __blk_crypto_evict_key(blk_crypto_fallback_profile, key); + } + + static bool blk_crypto_fallback_inited; +@@ -534,7 +534,6 @@ static int blk_crypto_fallback_init(void) + { + int i; + int err; +- struct blk_crypto_profile *profile = &blk_crypto_fallback_profile; + + if (blk_crypto_fallback_inited) + return 0; +@@ -545,18 +544,27 @@ static int blk_crypto_fallback_init(void) + if (err) + goto out; + +- err = blk_crypto_profile_init(profile, blk_crypto_num_keyslots); +- if (err) ++ /* Dynamic allocation is needed because of lockdep_register_key(). */ ++ blk_crypto_fallback_profile = ++ kzalloc(sizeof(*blk_crypto_fallback_profile), GFP_KERNEL); ++ if (!blk_crypto_fallback_profile) { ++ err = -ENOMEM; + goto fail_free_bioset; ++ } ++ ++ err = blk_crypto_profile_init(blk_crypto_fallback_profile, ++ blk_crypto_num_keyslots); ++ if (err) ++ goto fail_free_profile; + err = -ENOMEM; + +- profile->ll_ops = blk_crypto_fallback_ll_ops; +- profile->max_dun_bytes_supported = BLK_CRYPTO_MAX_IV_SIZE; ++ blk_crypto_fallback_profile->ll_ops = blk_crypto_fallback_ll_ops; ++ blk_crypto_fallback_profile->max_dun_bytes_supported = BLK_CRYPTO_MAX_IV_SIZE; + + /* All blk-crypto modes have a crypto API fallback. */ + for (i = 0; i < BLK_ENCRYPTION_MODE_MAX; i++) +- profile->modes_supported[i] = 0xFFFFFFFF; +- profile->modes_supported[BLK_ENCRYPTION_MODE_INVALID] = 0; ++ blk_crypto_fallback_profile->modes_supported[i] = 0xFFFFFFFF; ++ blk_crypto_fallback_profile->modes_supported[BLK_ENCRYPTION_MODE_INVALID] = 0; + + blk_crypto_wq = alloc_workqueue("blk_crypto_wq", + WQ_UNBOUND | WQ_HIGHPRI | +@@ -597,7 +605,9 @@ static int blk_crypto_fallback_init(void) + fail_free_wq: + destroy_workqueue(blk_crypto_wq); + fail_destroy_profile: +- blk_crypto_profile_destroy(profile); ++ blk_crypto_profile_destroy(blk_crypto_fallback_profile); ++fail_free_profile: ++ kfree(blk_crypto_fallback_profile); + fail_free_bioset: + bioset_exit(&crypto_bio_split); + out: +-- +2.41.0 + diff --git a/queue-6.1/cifs-release-folio-lock-on-fscache-read-hit.patch b/queue-6.1/cifs-release-folio-lock-on-fscache-read-hit.patch new file mode 100644 index 00000000000..81365c0ed7e --- /dev/null +++ b/queue-6.1/cifs-release-folio-lock-on-fscache-read-hit.patch @@ -0,0 +1,65 @@ +From 69513dd669e243928f7450893190915a88f84a2b Mon Sep 17 00:00:00 2001 +From: Russell Harmon via samba-technical +Date: Thu, 10 Aug 2023 00:19:22 -0700 +Subject: cifs: Release folio lock on fscache read hit. + +From: Russell Harmon via samba-technical + +commit 69513dd669e243928f7450893190915a88f84a2b upstream. + +Under the current code, when cifs_readpage_worker is called, the call +contract is that the callee should unlock the page. This is documented +in the read_folio section of Documentation/filesystems/vfs.rst as: + +> The filesystem should unlock the folio once the read has completed, +> whether it was successful or not. + +Without this change, when fscache is in use and cache hit occurs during +a read, the page lock is leaked, producing the following stack on +subsequent reads (via mmap) to the page: + +$ cat /proc/3890/task/12864/stack +[<0>] folio_wait_bit_common+0x124/0x350 +[<0>] filemap_read_folio+0xad/0xf0 +[<0>] filemap_fault+0x8b1/0xab0 +[<0>] __do_fault+0x39/0x150 +[<0>] do_fault+0x25c/0x3e0 +[<0>] __handle_mm_fault+0x6ca/0xc70 +[<0>] handle_mm_fault+0xe9/0x350 +[<0>] do_user_addr_fault+0x225/0x6c0 +[<0>] exc_page_fault+0x84/0x1b0 +[<0>] asm_exc_page_fault+0x27/0x30 + +This requires a reboot to resolve; it is a deadlock. + +Note however that the call to cifs_readpage_from_fscache does mark the +page clean, but does not free the folio lock. This happens in +__cifs_readpage_from_fscache on success. Releasing the lock at that +point however is not appropriate as cifs_readahead also calls +cifs_readpage_from_fscache and *does* unconditionally release the lock +after its return. This change therefore effectively makes +cifs_readpage_worker work like cifs_readahead. + +Signed-off-by: Russell Harmon +Acked-by: Paulo Alcantara (SUSE) +Reviewed-by: David Howells +Cc: stable@vger.kernel.org +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + fs/smb/client/file.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/smb/client/file.c ++++ b/fs/smb/client/file.c +@@ -4885,9 +4885,9 @@ static int cifs_readpage_worker(struct f + + io_error: + kunmap(page); +- unlock_page(page); + + read_complete: ++ unlock_page(page); + return rc; + } + diff --git a/queue-6.1/mmc-block-fix-in_flight-value-error.patch b/queue-6.1/mmc-block-fix-in_flight-value-error.patch new file mode 100644 index 00000000000..3707717459f --- /dev/null +++ b/queue-6.1/mmc-block-fix-in_flight-value-error.patch @@ -0,0 +1,75 @@ +From 4b430d4ac99750ee2ae2f893f1055c7af1ec3dc5 Mon Sep 17 00:00:00 2001 +From: Yibin Ding +Date: Wed, 2 Aug 2023 10:30:23 +0800 +Subject: mmc: block: Fix in_flight[issue_type] value error + +From: Yibin Ding + +commit 4b430d4ac99750ee2ae2f893f1055c7af1ec3dc5 upstream. + +For a completed request, after the mmc_blk_mq_complete_rq(mq, req) +function is executed, the bitmap_tags corresponding to the +request will be cleared, that is, the request will be regarded as +idle. If the request is acquired by a different type of process at +this time, the issue_type of the request may change. It further +caused the value of mq->in_flight[issue_type] to be abnormal, +and a large number of requests could not be sent. + +p1: p2: +mmc_blk_mq_complete_rq + blk_mq_free_request + blk_mq_get_request + blk_mq_rq_ctx_init +mmc_blk_mq_dec_in_flight + mmc_issue_type(mq, req) + +This strategy can ensure the consistency of issue_type +before and after executing mmc_blk_mq_complete_rq. + +Fixes: 81196976ed94 ("mmc: block: Add blk-mq support") +Cc: stable@vger.kernel.org +Signed-off-by: Yibin Ding +Acked-by: Adrian Hunter +Link: https://lore.kernel.org/r/20230802023023.1318134-1-yunlong.xing@unisoc.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/core/block.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +--- a/drivers/mmc/core/block.c ++++ b/drivers/mmc/core/block.c +@@ -2097,14 +2097,14 @@ static void mmc_blk_mq_poll_completion(s + mmc_blk_urgent_bkops(mq, mqrq); + } + +-static void mmc_blk_mq_dec_in_flight(struct mmc_queue *mq, struct request *req) ++static void mmc_blk_mq_dec_in_flight(struct mmc_queue *mq, enum mmc_issue_type issue_type) + { + unsigned long flags; + bool put_card; + + spin_lock_irqsave(&mq->lock, flags); + +- mq->in_flight[mmc_issue_type(mq, req)] -= 1; ++ mq->in_flight[issue_type] -= 1; + + put_card = (mmc_tot_in_flight(mq) == 0); + +@@ -2117,6 +2117,7 @@ static void mmc_blk_mq_dec_in_flight(str + static void mmc_blk_mq_post_req(struct mmc_queue *mq, struct request *req, + bool can_sleep) + { ++ enum mmc_issue_type issue_type = mmc_issue_type(mq, req); + struct mmc_queue_req *mqrq = req_to_mmc_queue_req(req); + struct mmc_request *mrq = &mqrq->brq.mrq; + struct mmc_host *host = mq->card->host; +@@ -2136,7 +2137,7 @@ static void mmc_blk_mq_post_req(struct m + blk_mq_complete_request(req); + } + +- mmc_blk_mq_dec_in_flight(mq, req); ++ mmc_blk_mq_dec_in_flight(mq, issue_type); + } + + void mmc_blk_mq_recovery(struct mmc_queue *mq) diff --git a/queue-6.1/mmc-wbsd-fix-double-mmc_free_host-in-wbsd_init.patch b/queue-6.1/mmc-wbsd-fix-double-mmc_free_host-in-wbsd_init.patch new file mode 100644 index 00000000000..4f4c10fbdf8 --- /dev/null +++ b/queue-6.1/mmc-wbsd-fix-double-mmc_free_host-in-wbsd_init.patch @@ -0,0 +1,33 @@ +From d83035433701919ac6db15f7737cbf554c36c1a6 Mon Sep 17 00:00:00 2001 +From: Yang Yingliang +Date: Mon, 7 Aug 2023 20:44:42 +0800 +Subject: mmc: wbsd: fix double mmc_free_host() in wbsd_init() + +From: Yang Yingliang + +commit d83035433701919ac6db15f7737cbf554c36c1a6 upstream. + +mmc_free_host() has already be called in wbsd_free_mmc(), +remove the mmc_free_host() in error path in wbsd_init(). + +Fixes: dc5b9b50fc9d ("mmc: wbsd: fix return value check of mmc_add_host()") +Signed-off-by: Yang Yingliang +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20230807124443.3431366-1-yangyingliang@huawei.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/host/wbsd.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/drivers/mmc/host/wbsd.c ++++ b/drivers/mmc/host/wbsd.c +@@ -1705,8 +1705,6 @@ static int wbsd_init(struct device *dev, + + wbsd_release_resources(host); + wbsd_free_mmc(dev); +- +- mmc_free_host(mmc); + return ret; + } + diff --git a/queue-6.1/riscv-handle-zicsr-zifencei-issue-between-gcc-and-binutils.patch b/queue-6.1/riscv-handle-zicsr-zifencei-issue-between-gcc-and-binutils.patch new file mode 100644 index 00000000000..03620de4faa --- /dev/null +++ b/queue-6.1/riscv-handle-zicsr-zifencei-issue-between-gcc-and-binutils.patch @@ -0,0 +1,111 @@ +From ca09f772cccaeec4cd05a21528c37a260aa2dd2c Mon Sep 17 00:00:00 2001 +From: Mingzheng Xing +Date: Thu, 10 Aug 2023 00:56:48 +0800 +Subject: riscv: Handle zicsr/zifencei issue between gcc and binutils + +From: Mingzheng Xing + +commit ca09f772cccaeec4cd05a21528c37a260aa2dd2c upstream. + +Binutils-2.38 and GCC-12.1.0 bumped[0][1] the default ISA spec to the newer +20191213 version which moves some instructions from the I extension to the +Zicsr and Zifencei extensions. So if one of the binutils and GCC exceeds +that version, we should explicitly specifying Zicsr and Zifencei via -march +to cope with the new changes. but this only occurs when binutils >= 2.36 +and GCC >= 11.1.0. It's a different story when binutils < 2.36. + +binutils-2.36 supports the Zifencei extension[2] and splits Zifencei and +Zicsr from I[3]. GCC-11.1.0 is particular[4] because it add support Zicsr +and Zifencei extension for -march. binutils-2.35 does not support the +Zifencei extension, and does not need to specify Zicsr and Zifencei when +working with GCC >= 12.1.0. + +To make our lives easier, let's relax the check to binutils >= 2.36 in +CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI. For the other two cases, +where clang < 17 or GCC < 11.1.0, we will deal with them in +CONFIG_TOOLCHAIN_NEEDS_OLD_ISA_SPEC. + +For more information, please refer to: +commit 6df2a016c0c8 ("riscv: fix build with binutils 2.38") +commit e89c2e815e76 ("riscv: Handle zicsr/zifencei issues between clang and binutils") + +Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=aed44286efa8ae8717a77d94b51ac3614e2ca6dc [0] +Link: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98416dbb0a62579d4a7a4a76bab51b5b52fec2cd [1] +Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=5a1b31e1e1cee6e9f1c92abff59cdcfff0dddf30 [2] +Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=729a53530e86972d1143553a415db34e6e01d5d2 [3] +Link: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b03be74bad08c382da47e048007a78fa3fb4ef49 [4] +Link: https://lore.kernel.org/all/20230308220842.1231003-1-conor@kernel.org +Link: https://lore.kernel.org/all/20230223220546.52879-1-conor@kernel.org +Reviewed-by: Conor Dooley +Acked-by: Guo Ren +Cc: +Signed-off-by: Mingzheng Xing +Link: https://lore.kernel.org/r/20230809165648.21071-1-xingmingzheng@iscas.ac.cn +Signed-off-by: Palmer Dabbelt +Signed-off-by: Greg Kroah-Hartman +--- + arch/riscv/Kconfig | 28 +++++++++++++++++----------- + arch/riscv/kernel/compat_vdso/Makefile | 8 +++++++- + 2 files changed, 24 insertions(+), 12 deletions(-) + +--- a/arch/riscv/Kconfig ++++ b/arch/riscv/Kconfig +@@ -447,24 +447,30 @@ config TOOLCHAIN_HAS_ZIHINTPAUSE + config TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI + def_bool y + # https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=aed44286efa8ae8717a77d94b51ac3614e2ca6dc +- depends on AS_IS_GNU && AS_VERSION >= 23800 ++ # https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98416dbb0a62579d4a7a4a76bab51b5b52fec2cd ++ depends on AS_IS_GNU && AS_VERSION >= 23600 + help +- Newer binutils versions default to ISA spec version 20191213 which +- moves some instructions from the I extension to the Zicsr and Zifencei +- extensions. ++ Binutils-2.38 and GCC-12.1.0 bumped the default ISA spec to the newer ++ 20191213 version, which moves some instructions from the I extension to ++ the Zicsr and Zifencei extensions. This requires explicitly specifying ++ Zicsr and Zifencei when binutils >= 2.38 or GCC >= 12.1.0. Zicsr ++ and Zifencei are supported in binutils from version 2.36 onwards. ++ To make life easier, and avoid forcing toolchains that default to a ++ newer ISA spec to version 2.2, relax the check to binutils >= 2.36. ++ For clang < 17 or GCC < 11.1.0, for which this is not possible, this is ++ dealt with in CONFIG_TOOLCHAIN_NEEDS_OLD_ISA_SPEC. + + config TOOLCHAIN_NEEDS_OLD_ISA_SPEC + def_bool y + depends on TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI + # https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16 +- depends on CC_IS_CLANG && CLANG_VERSION < 170000 ++ # https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b03be74bad08c382da47e048007a78fa3fb4ef49 ++ depends on (CC_IS_CLANG && CLANG_VERSION < 170000) || (CC_IS_GCC && GCC_VERSION < 110100) + help +- Certain versions of clang do not support zicsr and zifencei via -march +- but newer versions of binutils require it for the reasons noted in the +- help text of CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI. This +- option causes an older ISA spec compatible with these older versions +- of clang to be passed to GAS, which has the same result as passing zicsr +- and zifencei to -march. ++ Certain versions of clang and GCC do not support zicsr and zifencei via ++ -march. This option causes an older ISA spec compatible with these older ++ versions of clang and GCC to be passed to GAS, which has the same result ++ as passing zicsr and zifencei to -march. + + config FPU + bool "FPU support" +--- a/arch/riscv/kernel/compat_vdso/Makefile ++++ b/arch/riscv/kernel/compat_vdso/Makefile +@@ -11,7 +11,13 @@ compat_vdso-syms += flush_icache + COMPAT_CC := $(CC) + COMPAT_LD := $(LD) + +-COMPAT_CC_FLAGS := -march=rv32g -mabi=ilp32 ++# binutils 2.35 does not support the zifencei extension, but in the ISA ++# spec 20191213, G stands for IMAFD_ZICSR_ZIFENCEI. ++ifdef CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI ++ COMPAT_CC_FLAGS := -march=rv32g -mabi=ilp32 ++else ++ COMPAT_CC_FLAGS := -march=rv32imafd -mabi=ilp32 ++endif + COMPAT_LD_FLAGS := -melf32lriscv + + # Disable attributes, as they're useless and break the build. diff --git a/queue-6.1/series b/queue-6.1/series index b0766f32784..80685b8d9a5 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -155,3 +155,11 @@ riscv-uaccess-return-the-number-of-bytes-effectively.patch x86-static_call-fix-__static_call_fixup.patch x86-srso-correct-the-mitigation-status-when-smt-is-d.patch serial-8250-fix-oops-for-port-pm-on-uart_change_pm.patch +alsa-usb-audio-add-support-for-mythware-xa001au-capture-and-playback-interfaces.patch +cifs-release-folio-lock-on-fscache-read-hit.patch +riscv-handle-zicsr-zifencei-issue-between-gcc-and-binutils.patch +virtio-net-zero-max_tx_vq-field-for-virtio_net_ctrl_mq_hash_config-case.patch +arm64-dts-rockchip-fix-wifi-bluetooth-on-rock-pi-4-boards.patch +blk-crypto-dynamically-allocate-fallback-profile.patch +mmc-wbsd-fix-double-mmc_free_host-in-wbsd_init.patch +mmc-block-fix-in_flight-value-error.patch diff --git a/queue-6.1/virtio-net-zero-max_tx_vq-field-for-virtio_net_ctrl_mq_hash_config-case.patch b/queue-6.1/virtio-net-zero-max_tx_vq-field-for-virtio_net_ctrl_mq_hash_config-case.patch new file mode 100644 index 00000000000..521222a01b1 --- /dev/null +++ b/queue-6.1/virtio-net-zero-max_tx_vq-field-for-virtio_net_ctrl_mq_hash_config-case.patch @@ -0,0 +1,55 @@ +From 2c507ce90e02cd78d00fd4b0fe26c8641873c13f Mon Sep 17 00:00:00 2001 +From: Hawkins Jiawei +Date: Thu, 10 Aug 2023 19:04:05 +0800 +Subject: virtio-net: Zero max_tx_vq field for VIRTIO_NET_CTRL_MQ_HASH_CONFIG case +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Hawkins Jiawei + +commit 2c507ce90e02cd78d00fd4b0fe26c8641873c13f upstream. + +Kernel uses `struct virtio_net_ctrl_rss` to save command-specific-data +for both the VIRTIO_NET_CTRL_MQ_HASH_CONFIG and +VIRTIO_NET_CTRL_MQ_RSS_CONFIG commands. + +According to the VirtIO standard, "Field reserved MUST contain zeroes. +It is defined to make the structure to match the layout of +virtio_net_rss_config structure, defined in 5.1.6.5.7.". + +Yet for the VIRTIO_NET_CTRL_MQ_HASH_CONFIG command case, the `max_tx_vq` +field in struct virtio_net_ctrl_rss, which corresponds to the +`reserved` field in struct virtio_net_hash_config, is not zeroed, +thereby violating the VirtIO standard. + +This patch solves this problem by zeroing this field in +virtnet_init_default_rss(). + +Cc: Andrew Melnychenko +Cc: stable@vger.kernel.org +Fixes: c7114b1249fa ("drivers/net/virtio_net: Added basic RSS support.") +Signed-off-by: Hawkins Jiawei +Acked-by: Jason Wang +Acked-by: Eugenio Pérez +Acked-by: Michael S. Tsirkin +Message-Id: <20230810110405.25558-1-yin31149@gmail.com> +Signed-off-by: Michael S. Tsirkin +Reviewed-by: Xuan Zhuo +Acked-by: Jason Wang +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/virtio_net.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/virtio_net.c ++++ b/drivers/net/virtio_net.c +@@ -2504,7 +2504,7 @@ static void virtnet_init_default_rss(str + vi->ctrl->rss.indirection_table[i] = indir_val; + } + +- vi->ctrl->rss.max_tx_vq = vi->curr_queue_pairs; ++ vi->ctrl->rss.max_tx_vq = vi->has_rss ? vi->curr_queue_pairs : 0; + vi->ctrl->rss.hash_key_length = vi->rss_key_size; + + netdev_rss_key_fill(vi->ctrl->rss.key, vi->rss_key_size);