--- /dev/null
+From 4952aa696a9f221c5e34e5961e02fca41ef67ad6 Mon Sep 17 00:00:00 2001
+From: Linus Walleij <linus.walleij@linaro.org>
+Date: Mon, 19 Sep 2022 11:26:08 +0200
+Subject: ARM: dts: integrator: Tag PCI host with device_type
+
+From: Linus Walleij <linus.walleij@linaro.org>
+
+commit 4952aa696a9f221c5e34e5961e02fca41ef67ad6 upstream.
+
+The DT parser is dependent on the PCI device being tagged as
+device_type = "pci" in order to parse memory ranges properly.
+Fix this up.
+
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20220919092608.813511-1-linus.walleij@linaro.org'
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/boot/dts/integratorap.dts | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/arm/boot/dts/integratorap.dts
++++ b/arch/arm/boot/dts/integratorap.dts
+@@ -160,6 +160,7 @@
+
+ pci: pciv3@62000000 {
+ compatible = "arm,integrator-ap-pci", "v3,v360epc-pci";
++ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
--- /dev/null
+From 81d192c2ce74157e717e1fc4b68791f82f7499d4 Mon Sep 17 00:00:00 2001
+From: Marc Kleine-Budde <mkl@pengutronix.de>
+Date: Fri, 23 Sep 2022 13:42:23 +0200
+Subject: can: c_can: don't cache TX messages for C_CAN cores
+
+From: Marc Kleine-Budde <mkl@pengutronix.de>
+
+commit 81d192c2ce74157e717e1fc4b68791f82f7499d4 upstream.
+
+As Jacob noticed, the optimization introduced in 387da6bc7a82 ("can:
+c_can: cache frames to operate as a true FIFO") doesn't properly work
+on C_CAN, but on D_CAN IP cores. The exact reasons are still unknown.
+
+For now disable caching if CAN frames in the TX path for C_CAN cores.
+
+Fixes: 387da6bc7a82 ("can: c_can: cache frames to operate as a true FIFO")
+Link: https://lore.kernel.org/all/20220928083354.1062321-1-mkl@pengutronix.de
+Link: https://lore.kernel.org/all/15a8084b-9617-2da1-6704-d7e39d60643b@gmail.com
+Reported-by: Jacob Kroon <jacob.kroon@gmail.com>
+Tested-by: Jacob Kroon <jacob.kroon@gmail.com>
+Cc: stable@vger.kernel.org # v5.15
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/can/c_can/c_can.h | 17 +++++++++++++++--
+ drivers/net/can/c_can/c_can_main.c | 11 +++++------
+ 2 files changed, 20 insertions(+), 8 deletions(-)
+
+--- a/drivers/net/can/c_can/c_can.h
++++ b/drivers/net/can/c_can/c_can.h
+@@ -235,9 +235,22 @@ static inline u8 c_can_get_tx_tail(const
+ return ring->tail & (ring->obj_num - 1);
+ }
+
+-static inline u8 c_can_get_tx_free(const struct c_can_tx_ring *ring)
++static inline u8 c_can_get_tx_free(const struct c_can_priv *priv,
++ const struct c_can_tx_ring *ring)
+ {
+- return ring->obj_num - (ring->head - ring->tail);
++ u8 head = c_can_get_tx_head(ring);
++ u8 tail = c_can_get_tx_tail(ring);
++
++ if (priv->type == BOSCH_D_CAN)
++ return ring->obj_num - (ring->head - ring->tail);
++
++ /* This is not a FIFO. C/D_CAN sends out the buffers
++ * prioritized. The lowest buffer number wins.
++ */
++ if (head < tail)
++ return 0;
++
++ return ring->obj_num - head;
+ }
+
+ #endif /* C_CAN_H */
+--- a/drivers/net/can/c_can/c_can_main.c
++++ b/drivers/net/can/c_can/c_can_main.c
+@@ -429,7 +429,7 @@ static void c_can_setup_receive_object(s
+ static bool c_can_tx_busy(const struct c_can_priv *priv,
+ const struct c_can_tx_ring *tx_ring)
+ {
+- if (c_can_get_tx_free(tx_ring) > 0)
++ if (c_can_get_tx_free(priv, tx_ring) > 0)
+ return false;
+
+ netif_stop_queue(priv->dev);
+@@ -437,7 +437,7 @@ static bool c_can_tx_busy(const struct c
+ /* Memory barrier before checking tx_free (head and tail) */
+ smp_mb();
+
+- if (c_can_get_tx_free(tx_ring) == 0) {
++ if (c_can_get_tx_free(priv, tx_ring) == 0) {
+ netdev_dbg(priv->dev,
+ "Stopping tx-queue (tx_head=0x%08x, tx_tail=0x%08x, len=%d).\n",
+ tx_ring->head, tx_ring->tail,
+@@ -465,7 +465,7 @@ static netdev_tx_t c_can_start_xmit(stru
+
+ idx = c_can_get_tx_head(tx_ring);
+ tx_ring->head++;
+- if (c_can_get_tx_free(tx_ring) == 0)
++ if (c_can_get_tx_free(priv, tx_ring) == 0)
+ netif_stop_queue(dev);
+
+ if (idx < c_can_get_tx_tail(tx_ring))
+@@ -748,7 +748,7 @@ static void c_can_do_tx(struct net_devic
+ return;
+
+ tx_ring->tail += pkts;
+- if (c_can_get_tx_free(tx_ring)) {
++ if (c_can_get_tx_free(priv, tx_ring)) {
+ /* Make sure that anybody stopping the queue after
+ * this sees the new tx_ring->tail.
+ */
+@@ -760,8 +760,7 @@ static void c_can_do_tx(struct net_devic
+ stats->tx_packets += pkts;
+
+ tail = c_can_get_tx_tail(tx_ring);
+-
+- if (tail == 0) {
++ if (priv->type == BOSCH_D_CAN && tail == 0) {
+ u8 head = c_can_get_tx_head(tx_ring);
+
+ /* Start transmission for all cached messages */
--- /dev/null
+From 6726d552a6912e88cf63fe2bda87b2efa0efc7d0 Mon Sep 17 00:00:00 2001
+From: Aidan MacDonald <aidanmacdonald.0x0@gmail.com>
+Date: Fri, 17 Jun 2022 13:22:54 +0100
+Subject: clk: ingenic-tcu: Properly enable registers before accessing timers
+
+From: Aidan MacDonald <aidanmacdonald.0x0@gmail.com>
+
+commit 6726d552a6912e88cf63fe2bda87b2efa0efc7d0 upstream.
+
+Access to registers is guarded by ingenic_tcu_{enable,disable}_regs()
+so the stop bit can be cleared before accessing a timer channel, but
+those functions did not clear the stop bit on SoCs with a global TCU
+clock gate.
+
+Testing on the X1000 has revealed that the stop bits must be cleared
+_and_ the global TCU clock must be ungated to access timer registers.
+This appears to be the norm on Ingenic SoCs, and is specified in the
+documentation for the X1000 and numerous JZ47xx SoCs.
+
+If the stop bit isn't cleared, register writes don't take effect and
+the system can be left in a broken state, eg. the watchdog timer may
+not run.
+
+The bug probably went unnoticed because stop bits are zeroed when
+the SoC is reset, and the kernel does not set them unless a timer
+gets disabled at runtime. However, it is possible that a bootloader
+or a previous kernel (if using kexec) leaves the stop bits set and
+we should not rely on them being cleared.
+
+Fixing this is easy: have ingenic_tcu_{enable,disable}_regs() always
+clear the stop bit, regardless of the presence of a global TCU gate.
+
+Reviewed-by: Paul Cercueil <paul@crapouillou.net>
+Tested-by: Paul Cercueil <paul@crapouillou.net>
+Fixes: 4f89e4b8f121 ("clk: ingenic: Add driver for the TCU clocks")
+Cc: stable@vger.kernel.org
+Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com>
+Link: https://lore.kernel.org/r/20220617122254.738900-1-aidanmacdonald.0x0@gmail.com
+Signed-off-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/clk/ingenic/tcu.c | 15 +++++----------
+ 1 file changed, 5 insertions(+), 10 deletions(-)
+
+--- a/drivers/clk/ingenic/tcu.c
++++ b/drivers/clk/ingenic/tcu.c
+@@ -101,15 +101,11 @@ static bool ingenic_tcu_enable_regs(stru
+ bool enabled = false;
+
+ /*
+- * If the SoC has no global TCU clock, we must ungate the channel's
+- * clock to be able to access its registers.
+- * If we have a TCU clock, it will be enabled automatically as it has
+- * been attached to the regmap.
++ * According to the programming manual, a timer channel's registers can
++ * only be accessed when the channel's stop bit is clear.
+ */
+- if (!tcu->clk) {
+- enabled = !!ingenic_tcu_is_enabled(hw);
+- regmap_write(tcu->map, TCU_REG_TSCR, BIT(info->gate_bit));
+- }
++ enabled = !!ingenic_tcu_is_enabled(hw);
++ regmap_write(tcu->map, TCU_REG_TSCR, BIT(info->gate_bit));
+
+ return enabled;
+ }
+@@ -120,8 +116,7 @@ static void ingenic_tcu_disable_regs(str
+ const struct ingenic_tcu_clk_info *info = tcu_clk->info;
+ struct ingenic_tcu *tcu = tcu_clk->tcu;
+
+- if (!tcu->clk)
+- regmap_write(tcu->map, TCU_REG_TSSR, BIT(info->gate_bit));
++ regmap_write(tcu->map, TCU_REG_TSSR, BIT(info->gate_bit));
+ }
+
+ static u8 ingenic_tcu_get_parent(struct clk_hw *hw)
--- /dev/null
+From 37dcc673d065d9823576cd9f2484a72531e1cba6 Mon Sep 17 00:00:00 2001
+From: Christoph Hellwig <hch@lst.de>
+Date: Fri, 9 Sep 2022 15:08:29 +0200
+Subject: frontswap: don't call ->init if no ops are registered
+
+From: Christoph Hellwig <hch@lst.de>
+
+commit 37dcc673d065d9823576cd9f2484a72531e1cba6 upstream.
+
+If no frontswap module (i.e. zswap) was registered, frontswap_ops will be
+NULL. In such situation, swapon crashes with the following stack trace:
+
+ Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000
+ Mem abort info:
+ ESR = 0x0000000096000004
+ EC = 0x25: DABT (current EL), IL = 32 bits
+ SET = 0, FnV = 0
+ EA = 0, S1PTW = 0
+ FSC = 0x04: level 0 translation fault
+ Data abort info:
+ ISV = 0, ISS = 0x00000004
+ CM = 0, WnR = 0
+ user pgtable: 4k pages, 48-bit VAs, pgdp=00000020a4fab000
+ [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
+ Internal error: Oops: 96000004 [#1] SMP
+ Modules linked in: zram fsl_dpaa2_eth pcs_lynx phylink ahci_qoriq crct10dif_ce ghash_ce sbsa_gwdt fsl_mc_dpio nvme lm90 nvme_core at803x xhci_plat_hcd rtc_fsl_ftm_alarm xgmac_mdio ahci_platform i2c_imx ip6_tables ip_tables fuse
+ Unloaded tainted modules: cppc_cpufreq():1
+ CPU: 10 PID: 761 Comm: swapon Not tainted 6.0.0-rc2-00454-g22100432cf14 #1
+ Hardware name: SolidRun Ltd. SolidRun CEX7 Platform, BIOS EDK II Jun 21 2022
+ pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
+ pc : frontswap_init+0x38/0x60
+ lr : __do_sys_swapon+0x8a8/0x9f4
+ sp : ffff80000969bcf0
+ x29: ffff80000969bcf0 x28: ffff37bee0d8fc00 x27: ffff80000a7f5000
+ x26: fffffcdefb971e80 x25: ffffaba797453b90 x24: 0000000000000064
+ x23: ffff37c1f209d1a8 x22: ffff37bee880e000 x21: ffffaba797748560
+ x20: ffff37bee0d8fce4 x19: ffffaba797748488 x18: 0000000000000014
+ x17: 0000000030ec029a x16: ffffaba795a479b0 x15: 0000000000000000
+ x14: 0000000000000000 x13: 0000000000000030 x12: 0000000000000001
+ x11: ffff37c63c0aba18 x10: 0000000000000000 x9 : ffffaba7956b8c88
+ x8 : ffff80000969bcd0 x7 : 0000000000000000 x6 : 0000000000000000
+ x5 : 0000000000000001 x4 : 0000000000000000 x3 : ffffaba79730f000
+ x2 : ffff37bee0d8fc00 x1 : 0000000000000000 x0 : 0000000000000000
+ Call trace:
+ frontswap_init+0x38/0x60
+ __do_sys_swapon+0x8a8/0x9f4
+ __arm64_sys_swapon+0x28/0x3c
+ invoke_syscall+0x78/0x100
+ el0_svc_common.constprop.0+0xd4/0xf4
+ do_el0_svc+0x38/0x4c
+ el0_svc+0x34/0x10c
+ el0t_64_sync_handler+0x11c/0x150
+ el0t_64_sync+0x190/0x194
+ Code: d000e283 910003fd f9006c41 f946d461 (f9400021)
+ ---[ end trace 0000000000000000 ]---
+
+Link: https://lkml.kernel.org/r/20220909130829.3262926-1-hch@lst.de
+Fixes: 1da0d94a3ec8 ("frontswap: remove support for multiple ops")
+Reported-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Liu Shixin <liushixin2@huawei.com>
+Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/frontswap.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/mm/frontswap.c
++++ b/mm/frontswap.c
+@@ -125,6 +125,9 @@ void frontswap_init(unsigned type, unsig
+ * p->frontswap set to something valid to work properly.
+ */
+ frontswap_map_set(sis, map);
++
++ if (!frontswap_enabled())
++ return;
+ frontswap_ops->init(type);
+ }
+
--- /dev/null
+From e62563db857f81d75c5726a35bc0180bed6d1540 Mon Sep 17 00:00:00 2001
+From: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
+Date: Tue, 27 Sep 2022 07:15:45 -0700
+Subject: Input: snvs_pwrkey - fix SNVS_HPVIDR1 register address
+
+From: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
+
+commit e62563db857f81d75c5726a35bc0180bed6d1540 upstream.
+
+Both i.MX6 and i.MX8 reference manuals list 0xBF8 as SNVS_HPVIDR1
+(chapters 57.9 and 6.4.5 respectively).
+
+Without this, trying to read the revision number results in 0 on
+all revisions, causing the i.MX6 quirk to apply on all platforms,
+which in turn causes the driver to synthesise power button release
+events instead of passing the real one as they happen even on
+platforms like i.MX8 where that's not wanted.
+
+Fixes: 1a26c920717a ("Input: snvs_pwrkey - send key events for i.MX6 S, DL and Q")
+Tested-by: Martin Kepplinger <martin.kepplinger@puri.sm>
+Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
+Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/4599101.ElGaqSPkdT@pliszka
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/input/keyboard/snvs_pwrkey.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/input/keyboard/snvs_pwrkey.c
++++ b/drivers/input/keyboard/snvs_pwrkey.c
+@@ -20,7 +20,7 @@
+ #include <linux/mfd/syscon.h>
+ #include <linux/regmap.h>
+
+-#define SNVS_HPVIDR1_REG 0xF8
++#define SNVS_HPVIDR1_REG 0xBF8
+ #define SNVS_LPSR_REG 0x4C /* LP Status Register */
+ #define SNVS_LPCR_REG 0x38 /* LP Control Register */
+ #define SNVS_HPSR_REG 0x14
--- /dev/null
+From 797666cd5af041ffb66642fff62f7389f08566a2 Mon Sep 17 00:00:00 2001
+From: Frank Wunderlich <frank-w@public-files.de>
+Date: Mon, 26 Sep 2022 17:07:40 +0200
+Subject: net: usb: qmi_wwan: Add new usb-id for Dell branded EM7455
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Frank Wunderlich <frank-w@public-files.de>
+
+commit 797666cd5af041ffb66642fff62f7389f08566a2 upstream.
+
+Add support for Dell 5811e (EM7455) with USB-id 0x413c:0x81c2.
+
+Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
+Cc: stable@vger.kernel.org
+Acked-by: Bjørn Mork <bjorn@mork.no>
+Link: https://lore.kernel.org/r/20220926150740.6684-3-linux@fw-web.de
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/usb/qmi_wwan.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/usb/qmi_wwan.c
++++ b/drivers/net/usb/qmi_wwan.c
+@@ -1399,6 +1399,7 @@ static const struct usb_device_id produc
+ {QMI_FIXED_INTF(0x413c, 0x81b3, 8)}, /* Dell Wireless 5809e Gobi(TM) 4G LTE Mobile Broadband Card (rev3) */
+ {QMI_FIXED_INTF(0x413c, 0x81b6, 8)}, /* Dell Wireless 5811e */
+ {QMI_FIXED_INTF(0x413c, 0x81b6, 10)}, /* Dell Wireless 5811e */
++ {QMI_FIXED_INTF(0x413c, 0x81c2, 8)}, /* Dell Wireless 5811e */
+ {QMI_FIXED_INTF(0x413c, 0x81cc, 8)}, /* Dell Wireless 5816e */
+ {QMI_FIXED_INTF(0x413c, 0x81d7, 0)}, /* Dell Wireless 5821e */
+ {QMI_FIXED_INTF(0x413c, 0x81d7, 1)}, /* Dell Wireless 5821e preproduction config */
counter-104-quad-8-utilize-iomap-interface.patch
counter-104-quad-8-implement-and-utilize-register-st.patch
counter-104-quad-8-fix-skipped-irq-lines-during-even.patch
+uas-add-no-uas-quirk-for-hiksemi-usb_disk.patch
+usb-storage-add-hiksemi-usb3-fw-to-ignore_uas.patch
+uas-ignore-uas-for-thinkplus-chips.patch
+usb-typec-ucsi-remove-incorrect-warning.patch
+thunderbolt-explicitly-reset-plug-events-delay-back-to-usb4-spec-value.patch
+net-usb-qmi_wwan-add-new-usb-id-for-dell-branded-em7455.patch
+input-snvs_pwrkey-fix-snvs_hpvidr1-register-address.patch
+can-c_can-don-t-cache-tx-messages-for-c_can-cores.patch
+clk-ingenic-tcu-properly-enable-registers-before-accessing-timers.patch
+wifi-mac80211-ensure-vif-queues-are-operational-after-start.patch
+x86-sgx-do-not-fail-on-incomplete-sanitization-on-premature-stop-of-ksgxd.patch
+frontswap-don-t-call-init-if-no-ops-are-registered.patch
+arm-dts-integrator-tag-pci-host-with-device_type.patch
--- /dev/null
+From 31f87f705b3c1635345d8e8a493697099b43e508 Mon Sep 17 00:00:00 2001
+From: Mario Limonciello <mario.limonciello@amd.com>
+Date: Wed, 21 Sep 2022 09:54:32 -0500
+Subject: thunderbolt: Explicitly reset plug events delay back to USB4 spec value
+
+From: Mario Limonciello <mario.limonciello@amd.com>
+
+commit 31f87f705b3c1635345d8e8a493697099b43e508 upstream.
+
+If any software has interacted with the USB4 registers before the Linux
+USB4 CM runs, it may have modified the plug events delay. It has been
+observed that if this value too large, it's possible that hotplugged
+devices will negotiate a fallback mode instead in Linux.
+
+To prevent this, explicitly align the plug events delay with the USB4
+spec value of 10ms.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/thunderbolt/switch.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/thunderbolt/switch.c
++++ b/drivers/thunderbolt/switch.c
+@@ -2413,6 +2413,7 @@ int tb_switch_configure(struct tb_switch
+ * additional capabilities.
+ */
+ sw->config.cmuv = USB4_VERSION_1_0;
++ sw->config.plug_events_delay = 0xa;
+
+ /* Enumerate the switch */
+ ret = tb_sw_write(sw, (u32 *)&sw->config + 1, TB_CFG_SWITCH,
--- /dev/null
+From a625a4b8806cc1e928b7dd2cca1fee709c9de56e Mon Sep 17 00:00:00 2001
+From: Hongling Zeng <zenghongling@kylinos.cn>
+Date: Fri, 23 Sep 2022 10:46:13 +0800
+Subject: uas: add no-uas quirk for Hiksemi usb_disk
+
+From: Hongling Zeng <zenghongling@kylinos.cn>
+
+commit a625a4b8806cc1e928b7dd2cca1fee709c9de56e upstream.
+
+The UAS mode of Hiksemi is reported to fail to work on several platforms
+with the following error message, then after re-connecting the device will
+be offlined and not working at all.
+
+[ 592.518442][ 2] sd 8:0:0:0: [sda] tag#17 uas_eh_abort_handler 0 uas-tag 18
+ inflight: CMD
+[ 592.527575][ 2] sd 8:0:0:0: [sda] tag#17 CDB: Write(10) 2a 00 03 6f 88 00 00
+ 04 00 00
+[ 592.536330][ 2] sd 8:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1
+ inflight: CMD
+[ 592.545266][ 2] sd 8:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 07 44 1a 88 00
+ 00 08 00
+
+These disks have a broken uas implementation, the tag field of the status
+iu-s is not set properly,so we need to fall-back to usb-storage.
+
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Cc: stable <stable@kernel.org>
+Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
+Link: https://lore.kernel.org/r/1663901173-21020-1-git-send-email-zenghongling@kylinos.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/storage/unusual_uas.h | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/usb/storage/unusual_uas.h
++++ b/drivers/usb/storage/unusual_uas.h
+@@ -52,6 +52,13 @@ UNUSUAL_DEV(0x059f, 0x1061, 0x0000, 0x99
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_NO_REPORT_OPCODES | US_FL_NO_SAME),
+
++/* Reported-by: Hongling Zeng <zenghongling@kylinos.cn> */
++UNUSUAL_DEV(0x090c, 0x2000, 0x0000, 0x9999,
++ "Hiksemi",
++ "External HDD",
++ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
++ US_FL_IGNORE_UAS),
++
+ /*
+ * Apricorn USB3 dongle sometimes returns "USBSUSBSUSBS" in response to SCSI
+ * commands in UAS mode. Observed with the 1.28 firmware; are there others?
--- /dev/null
+From 0fb9703a3eade0bb84c635705d9c795345e55053 Mon Sep 17 00:00:00 2001
+From: Hongling Zeng <zenghongling@kylinos.cn>
+Date: Fri, 23 Sep 2022 10:46:35 +0800
+Subject: uas: ignore UAS for Thinkplus chips
+
+From: Hongling Zeng <zenghongling@kylinos.cn>
+
+commit 0fb9703a3eade0bb84c635705d9c795345e55053 upstream.
+
+The UAS mode of Thinkplus(0x17ef, 0x3899) is reported to influence
+performance and trigger kernel panic on several platforms with the
+following error message:
+
+[ 39.702439] xhci_hcd 0000:0c:00.3: ERROR Transfer event for disabled
+ endpoint or incorrect stream ring
+[ 39.702442] xhci_hcd 0000:0c:00.3: @000000026c61f810 00000000 00000000
+ 1b000000 05038000
+
+[ 720.545894][13] Workqueue: usb_hub_wq hub_event
+[ 720.550971][13] ffff88026c143c38 0000000000016300 ffff8802755bb900 ffff880
+ 26cb80000
+[ 720.559673][13] ffff88026c144000 ffff88026ca88100 0000000000000000 ffff880
+ 26cb80000
+[ 720.568374][13] ffff88026cb80000 ffff88026c143c50 ffffffff8186ae25 ffff880
+ 26ca880f8
+[ 720.577076][13] Call Trace:
+[ 720.580201][13] [<ffffffff8186ae25>] schedule+0x35/0x80
+[ 720.586137][13] [<ffffffff8186b0ce>] schedule_preempt_disabled+0xe/0x10
+[ 720.593623][13] [<ffffffff8186cb94>] __mutex_lock_slowpath+0x164/0x1e0
+[ 720.601012][13] [<ffffffff8186cc3f>] mutex_lock+0x2f/0x40
+[ 720.607141][13] [<ffffffff8162b8e9>] usb_disconnect+0x59/0x290
+
+Falling back to USB mass storage can solve this problem, so ignore UAS
+function of this chip.
+
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Cc: stable <stable@kernel.org>
+Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
+Link: https://lore.kernel.org/r/1663902249837086.19.seg@mailgw
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/storage/unusual_uas.h | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/usb/storage/unusual_uas.h
++++ b/drivers/usb/storage/unusual_uas.h
+@@ -132,6 +132,13 @@ UNUSUAL_DEV(0x154b, 0xf00d, 0x0000, 0x99
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_NO_ATA_1X),
+
++/* Reported-by: Hongling Zeng <zenghongling@kylinos.cn> */
++UNUSUAL_DEV(0x17ef, 0x3899, 0x0000, 0x9999,
++ "Thinkplus",
++ "External HDD",
++ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
++ US_FL_IGNORE_UAS),
++
+ /* Reported-by: Hans de Goede <hdegoede@redhat.com> */
+ UNUSUAL_DEV(0x2109, 0x0711, 0x0000, 0x9999,
+ "VIA",
--- /dev/null
+From e00b488e813f0f1ad9f778e771b7cd2fe2877023 Mon Sep 17 00:00:00 2001
+From: Hongling Zeng <zenghongling@kylinos.cn>
+Date: Fri, 23 Sep 2022 10:46:25 +0800
+Subject: usb-storage: Add Hiksemi USB3-FW to IGNORE_UAS
+
+From: Hongling Zeng <zenghongling@kylinos.cn>
+
+commit e00b488e813f0f1ad9f778e771b7cd2fe2877023 upstream.
+
+The UAS mode of Hiksemi USB_HDD is reported to fail to work on several
+platforms with the following error message, then after re-connecting the
+device will be offlined and not working at all.
+
+[ 592.518442][ 2] sd 8:0:0:0: [sda] tag#17 uas_eh_abort_handler 0 uas-tag 18
+ inflight: CMD
+[ 592.527575][ 2] sd 8:0:0:0: [sda] tag#17 CDB: Write(10) 2a 00 03 6f 88 00 00
+ 04 00 00
+[ 592.536330][ 2] sd 8:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1
+ inflight: CMD
+[ 592.545266][ 2] sd 8:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 07 44 1a 88 00
+ 00 08 00
+
+These disks have a broken uas implementation, the tag field of the status
+iu-s is not set properly,so we need to fall-back to usb-storage.
+
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Cc: stable <stable@kernel.org>
+Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
+Link: https://lore.kernel.org/r/1663901185-21067-1-git-send-email-zenghongling@kylinos.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/storage/unusual_uas.h | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/usb/storage/unusual_uas.h
++++ b/drivers/usb/storage/unusual_uas.h
+@@ -83,6 +83,13 @@ UNUSUAL_DEV(0x0bc2, 0x331a, 0x0000, 0x99
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_NO_REPORT_LUNS),
+
++/* Reported-by: Hongling Zeng <zenghongling@kylinos.cn> */
++UNUSUAL_DEV(0x0bda, 0x9210, 0x0000, 0x9999,
++ "Hiksemi",
++ "External HDD",
++ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
++ US_FL_IGNORE_UAS),
++
+ /* Reported-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> */
+ UNUSUAL_DEV(0x13fd, 0x3940, 0x0000, 0x9999,
+ "Initio Corporation",
--- /dev/null
+From 415ba26cb73f7d22a892043301b91b57ae54db02 Mon Sep 17 00:00:00 2001
+From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Date: Thu, 22 Sep 2022 17:59:24 +0300
+Subject: usb: typec: ucsi: Remove incorrect warning
+
+From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+
+commit 415ba26cb73f7d22a892043301b91b57ae54db02 upstream.
+
+Sink only devices do not have any source capabilities, so
+the driver should not warn about that. Also DRP (Dual Role
+Power) capable devices, such as USB Type-C docking stations,
+do not return any source capabilities unless they are
+plugged to a power supply themselves.
+
+Fixes: 1f4642b72be7 ("usb: typec: ucsi: Retrieve all the PDOs instead of just the first 4")
+Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Link: https://lore.kernel.org/r/20220922145924.80667-1-heikki.krogerus@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/typec/ucsi/ucsi.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/drivers/usb/typec/ucsi/ucsi.c
++++ b/drivers/usb/typec/ucsi/ucsi.c
+@@ -588,8 +588,6 @@ static int ucsi_get_pdos(struct ucsi_con
+ num_pdos * sizeof(u32));
+ if (ret < 0 && ret != -ETIMEDOUT)
+ dev_err(ucsi->dev, "UCSI_GET_PDOS failed (%d)\n", ret);
+- if (ret == 0 && offset == 0)
+- dev_warn(ucsi->dev, "UCSI_GET_PDOS returned 0 bytes\n");
+
+ return ret;
+ }
--- /dev/null
+From 527008e5e87600a389feb8a57042c928ecca195d Mon Sep 17 00:00:00 2001
+From: Alexander Wetzel <alexander@wetzel-home.de>
+Date: Thu, 15 Sep 2022 15:09:46 +0200
+Subject: wifi: mac80211: ensure vif queues are operational after start
+
+From: Alexander Wetzel <alexander@wetzel-home.de>
+
+commit 527008e5e87600a389feb8a57042c928ecca195d upstream.
+
+Make sure local->queue_stop_reasons and vif.txqs_stopped stay in sync.
+
+When a new vif is created the queues may end up in an inconsistent state
+and be inoperable:
+Communication not using iTXQ will work, allowing to e.g. complete the
+association. But the 4-way handshake will time out. The sta will not
+send out any skbs queued in iTXQs.
+
+All normal attempts to start the queues will fail when reaching this
+state.
+local->queue_stop_reasons will have marked all queues as operational but
+vif.txqs_stopped will still be set, creating an inconsistent internal
+state.
+
+In reality this seems to be race between the mac80211 function
+ieee80211_do_open() setting SDATA_STATE_RUNNING and the wake_txqs_tasklet:
+Depending on the driver and the timing the queues may end up to be
+operational or not.
+
+Cc: stable@vger.kernel.org
+Fixes: f856373e2f31 ("wifi: mac80211: do not wake queues on a vif that is being stopped")
+Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
+Acked-by: Felix Fietkau <nbd@nbd.name>
+Link: https://lore.kernel.org/r/20220915130946.302803-1-alexander@wetzel-home.de
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mac80211/util.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/net/mac80211/util.c b/net/mac80211/util.c
+index 53826c663723..efcefb2dd882 100644
+--- a/net/mac80211/util.c
++++ b/net/mac80211/util.c
+@@ -301,14 +301,14 @@ static void __ieee80211_wake_txqs(struct ieee80211_sub_if_data *sdata, int ac)
+ local_bh_disable();
+ spin_lock(&fq->lock);
+
++ sdata->vif.txqs_stopped[ac] = false;
++
+ if (!test_bit(SDATA_STATE_RUNNING, &sdata->state))
+ goto out;
+
+ if (sdata->vif.type == NL80211_IFTYPE_AP)
+ ps = &sdata->bss->ps;
+
+- sdata->vif.txqs_stopped[ac] = false;
+-
+ list_for_each_entry_rcu(sta, &local->sta_list, list) {
+ if (sdata != sta->sdata)
+ continue;
+--
+2.37.3
+
--- /dev/null
+From 133e049a3f8c91b175029fb6a59b6039d5e79cba Mon Sep 17 00:00:00 2001
+From: Jarkko Sakkinen <jarkko@kernel.org>
+Date: Tue, 6 Sep 2022 03:02:20 +0300
+Subject: x86/sgx: Do not fail on incomplete sanitization on premature stop of ksgxd
+
+From: Jarkko Sakkinen <jarkko@kernel.org>
+
+commit 133e049a3f8c91b175029fb6a59b6039d5e79cba upstream.
+
+Unsanitized pages trigger WARN_ON() unconditionally, which can panic the
+whole computer, if /proc/sys/kernel/panic_on_warn is set.
+
+In sgx_init(), if misc_register() fails or misc_register() succeeds but
+neither sgx_drv_init() nor sgx_vepc_init() succeeds, then ksgxd will be
+prematurely stopped. This may leave unsanitized pages, which will result a
+false warning.
+
+Refine __sgx_sanitize_pages() to return:
+
+1. Zero when the sanitization process is complete or ksgxd has been
+ requested to stop.
+2. The number of unsanitized pages otherwise.
+
+Fixes: 51ab30eb2ad4 ("x86/sgx: Replace section->init_laundry_list with sgx_dirty_page_list")
+Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
+Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
+Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
+Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/linux-sgx/20220825051827.246698-1-jarkko@kernel.org/T/#u
+Link: https://lkml.kernel.org/r/20220906000221.34286-2-jarkko@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/sgx/main.c | 15 +++++++++------
+ 1 file changed, 9 insertions(+), 6 deletions(-)
+
+--- a/arch/x86/kernel/cpu/sgx/main.c
++++ b/arch/x86/kernel/cpu/sgx/main.c
+@@ -49,9 +49,13 @@ static LIST_HEAD(sgx_dirty_page_list);
+ * Reset post-kexec EPC pages to the uninitialized state. The pages are removed
+ * from the input list, and made available for the page allocator. SECS pages
+ * prepending their children in the input list are left intact.
++ *
++ * Return 0 when sanitization was successful or kthread was stopped, and the
++ * number of unsanitized pages otherwise.
+ */
+-static void __sgx_sanitize_pages(struct list_head *dirty_page_list)
++static unsigned long __sgx_sanitize_pages(struct list_head *dirty_page_list)
+ {
++ unsigned long left_dirty = 0;
+ struct sgx_epc_page *page;
+ LIST_HEAD(dirty);
+ int ret;
+@@ -59,7 +63,7 @@ static void __sgx_sanitize_pages(struct
+ /* dirty_page_list is thread-local, no need for a lock: */
+ while (!list_empty(dirty_page_list)) {
+ if (kthread_should_stop())
+- return;
++ return 0;
+
+ page = list_first_entry(dirty_page_list, struct sgx_epc_page, list);
+
+@@ -92,12 +96,14 @@ static void __sgx_sanitize_pages(struct
+ } else {
+ /* The page is not yet clean - move to the dirty list. */
+ list_move_tail(&page->list, &dirty);
++ left_dirty++;
+ }
+
+ cond_resched();
+ }
+
+ list_splice(&dirty, dirty_page_list);
++ return left_dirty;
+ }
+
+ static bool sgx_reclaimer_age(struct sgx_epc_page *epc_page)
+@@ -440,10 +446,7 @@ static int ksgxd(void *p)
+ * required for SECS pages, whose child pages blocked EREMOVE.
+ */
+ __sgx_sanitize_pages(&sgx_dirty_page_list);
+- __sgx_sanitize_pages(&sgx_dirty_page_list);
+-
+- /* sanity check: */
+- WARN_ON(!list_empty(&sgx_dirty_page_list));
++ WARN_ON(__sgx_sanitize_pages(&sgx_dirty_page_list));
+
+ while (!kthread_should_stop()) {
+ if (try_to_freeze())
projects / thirdparty / kernel / stable-queue.git / commitdiff
