--- /dev/null
+From 788449ae57f4273111b779bbcaad552b67f517d5 Mon Sep 17 00:00:00 2001
+From: dengxiang <dengxiang@nfschina.com>
+Date: Thu, 3 Aug 2023 10:44:37 +0800
+Subject: ALSA: usb-audio: Add support for Mythware XA001AU capture and playback interfaces.
+
+From: dengxiang <dengxiang@nfschina.com>
+
+commit 788449ae57f4273111b779bbcaad552b67f517d5 upstream.
+
+This patch adds a USB quirk for Mythware XA001AU USB interface.
+
+Signed-off-by: dengxiang <dengxiang@nfschina.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20230803024437.370069-1-dengxiang@nfschina.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
--- /dev/null
+From ebceec271e552a2b05e47d8ef0597052b1a39449 Mon Sep 17 00:00:00 2001
+From: Yogesh Hegde <yogi.kernel@gmail.com>
+Date: Tue, 18 Jul 2023 22:09:41 +0530
+Subject: arm64: dts: rockchip: Fix Wifi/Bluetooth on ROCK Pi 4 boards
+
+From: Yogesh Hegde <yogi.kernel@gmail.com>
+
+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 <yogi.kernel@gmail.com>
+Link: https://lore.kernel.org/r/ZLbATQRjOl09aLAp@zephyrusG14
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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>;
--- /dev/null
+From c984ff1423ae9f70b1f28ce811856db0d9c99021 Mon Sep 17 00:00:00 2001
+From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
+Date: Thu, 17 Aug 2023 10:15:56 -0400
+Subject: blk-crypto: dynamically allocate fallback profile
+
+From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
+
+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 <sweettea-kernel@dorminy.me>
+Reviewed-by: Eric Biggers <ebiggers@google.com>
+Link: https://lore.kernel.org/r/20230817141615.15387-1-sweettea-kernel@dorminy.me
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+
--- /dev/null
+From 69513dd669e243928f7450893190915a88f84a2b Mon Sep 17 00:00:00 2001
+From: Russell Harmon via samba-technical <samba-technical@lists.samba.org>
+Date: Thu, 10 Aug 2023 00:19:22 -0700
+Subject: cifs: Release folio lock on fscache read hit.
+
+From: Russell Harmon via samba-technical <samba-technical@lists.samba.org>
+
+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 <russ@har.mn>
+Acked-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
+Reviewed-by: David Howells <dhowells@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
--- /dev/null
+From 4b430d4ac99750ee2ae2f893f1055c7af1ec3dc5 Mon Sep 17 00:00:00 2001
+From: Yibin Ding <yibin.ding@unisoc.com>
+Date: Wed, 2 Aug 2023 10:30:23 +0800
+Subject: mmc: block: Fix in_flight[issue_type] value error
+
+From: Yibin Ding <yibin.ding@unisoc.com>
+
+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 <yibin.ding@unisoc.com>
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Link: https://lore.kernel.org/r/20230802023023.1318134-1-yunlong.xing@unisoc.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
--- /dev/null
+From d83035433701919ac6db15f7737cbf554c36c1a6 Mon Sep 17 00:00:00 2001
+From: Yang Yingliang <yangyingliang@huawei.com>
+Date: Mon, 7 Aug 2023 20:44:42 +0800
+Subject: mmc: wbsd: fix double mmc_free_host() in wbsd_init()
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+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 <yangyingliang@huawei.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20230807124443.3431366-1-yangyingliang@huawei.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
--- /dev/null
+From ca09f772cccaeec4cd05a21528c37a260aa2dd2c Mon Sep 17 00:00:00 2001
+From: Mingzheng Xing <xingmingzheng@iscas.ac.cn>
+Date: Thu, 10 Aug 2023 00:56:48 +0800
+Subject: riscv: Handle zicsr/zifencei issue between gcc and binutils
+
+From: Mingzheng Xing <xingmingzheng@iscas.ac.cn>
+
+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 <conor.dooley@microchip.com>
+Acked-by: Guo Ren <guoren@kernel.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Mingzheng Xing <xingmingzheng@iscas.ac.cn>
+Link: https://lore.kernel.org/r/20230809165648.21071-1-xingmingzheng@iscas.ac.cn
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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.
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
--- /dev/null
+From 2c507ce90e02cd78d00fd4b0fe26c8641873c13f Mon Sep 17 00:00:00 2001
+From: Hawkins Jiawei <yin31149@gmail.com>
+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 <yin31149@gmail.com>
+
+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 <andrew@daynix.com>
+Cc: stable@vger.kernel.org
+Fixes: c7114b1249fa ("drivers/net/virtio_net: Added basic RSS support.")
+Signed-off-by: Hawkins Jiawei <yin31149@gmail.com>
+Acked-by: Jason Wang <jasowang@redhat.com>
+Acked-by: Eugenio Pérez <eperezma@redhat.com>
+Acked-by: Michael S. Tsirkin <mst@redhat.com>
+Message-Id: <20230810110405.25558-1-yin31149@gmail.com>
+Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
+Acked-by: Jason Wang <jasowang@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
projects / thirdparty / kernel / stable-queue.git / commitdiff
