--- /dev/null
+From 0ebd54b4dc2bdc5fd7792a005abdbf664bb6d805 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 24 Aug 2022 12:51:00 +0900
+Subject: drivers/block/zram/zram_drv.c: do not keep dangling zcomp pointer
+ after zram reset
+
+From: Sergey Senozhatsky <senozhatsky@chromium.org>
+
+[ Upstream commit 6d2453c3dbc5f70eafc1c866289a90a1fc57ce18 ]
+
+We do all reset operations under write lock, so we don't need to save
+->disksize and ->comp to stack variables. Another thing is that ->comp is
+freed during zram reset, but comp pointer is not NULL-ed, so zram keeps
+the freed pointer value.
+
+Link: https://lkml.kernel.org/r/20220824035100.971816-1-senozhatsky@chromium.org
+Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
+Cc: Minchan Kim <minchan@kernel.org>
+Cc: Nitin Gupta <ngupta@vflare.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Stable-dep-of: 74363ec674cb ("zram: fix uninitialized ZRAM not releasing backing device")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/block/zram/zram_drv.c | 13 ++++---------
+ 1 file changed, 4 insertions(+), 9 deletions(-)
+
+diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
+index a9f71b27d235..9eed579d02f0 100644
+--- a/drivers/block/zram/zram_drv.c
++++ b/drivers/block/zram/zram_drv.c
+@@ -1695,9 +1695,6 @@ static int zram_rw_page(struct block_device *bdev, sector_t sector,
+
+ static void zram_reset_device(struct zram *zram)
+ {
+- struct zcomp *comp;
+- u64 disksize;
+-
+ down_write(&zram->init_lock);
+
+ zram->limit_pages = 0;
+@@ -1707,18 +1704,16 @@ static void zram_reset_device(struct zram *zram)
+ return;
+ }
+
+- comp = zram->comp;
+- disksize = zram->disksize;
+- zram->disksize = 0;
+-
+ set_capacity_and_notify(zram->disk, 0);
+ part_stat_set_all(zram->disk->part0, 0);
+
+ up_write(&zram->init_lock);
+ /* I/O operation under all of CPU are done so let's free */
+- zram_meta_free(zram, disksize);
++ zram_meta_free(zram, zram->disksize);
++ zram->disksize = 0;
+ memset(&zram->stats, 0, sizeof(zram->stats));
+- zcomp_destroy(comp);
++ zcomp_destroy(zram->comp);
++ zram->comp = NULL;
+ reset_bdev(zram);
+ }
+
+--
+2.39.5
+
x86-hyperv-fix-hv-tsc-page-based-sched_clock-for-hibernation.patch
selinux-ignore-unknown-extended-permissions.patch
tracing-have-process_string-also-allow-arrays.patch
+thunderbolt-add-support-for-intel-raptor-lake.patch
+thunderbolt-add-support-for-intel-meteor-lake.patch
+thunderbolt-add-intel-barlow-ridge-pci-id.patch
+thunderbolt-add-support-for-intel-lunar-lake.patch
+thunderbolt-add-support-for-intel-panther-lake-m-p.patch
+xhci-retry-stop-endpoint-on-buggy-nec-controllers.patch
+usb-xhci-limit-stop-endpoint-retries.patch
+xhci-turn-nec-specific-quirk-for-handling-stop-endpo.patch
+drivers-block-zram-zram_drv.c-do-not-keep-dangling-z.patch
+zram-fix-uninitialized-zram-not-releasing-backing-de.patch
--- /dev/null
+From 7abc0cb4261d208097434a06f900070fceb5031f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 17 Dec 2022 08:35:04 +0200
+Subject: thunderbolt: Add Intel Barlow Ridge PCI ID
+
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+
+[ Upstream commit 6f14a210661ce03988ef4ed3c8402037c8e06539 ]
+
+Intel Barlow Ridge is the first USB4 v2 controller from Intel. The
+controller exposes standard USB4 PCI class ID in typical configurations,
+however there is a way to configure it so that it uses a special class
+ID to allow using s different driver than the Windows inbox one. For
+this reason add the Barlow Ridge PCI ID to the Linux driver too so that
+the driver can attach regardless of the class ID.
+
+Tested-by: Pengfei Xu <pengfei.xu@intel.com>
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Stable-dep-of: 8644b48714dc ("thunderbolt: Add support for Intel Panther Lake-M/P")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/thunderbolt/nhi.c | 2 ++
+ drivers/thunderbolt/nhi.h | 2 ++
+ 2 files changed, 4 insertions(+)
+
+diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
+index 3b47eb2397a1..1350223088d8 100644
+--- a/drivers/thunderbolt/nhi.c
++++ b/drivers/thunderbolt/nhi.c
+@@ -1447,6 +1447,8 @@ static struct pci_device_id nhi_ids[] = {
+ .driver_data = (kernel_ulong_t)&icl_nhi_ops },
+ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_MTL_P_NHI1),
+ .driver_data = (kernel_ulong_t)&icl_nhi_ops },
++ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_BARLOW_RIDGE_HOST_80G_NHI) },
++ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_BARLOW_RIDGE_HOST_40G_NHI) },
+
+ /* Any USB4 compliant host */
+ { PCI_DEVICE_CLASS(PCI_CLASS_SERIAL_USB_USB4, ~0) },
+diff --git a/drivers/thunderbolt/nhi.h b/drivers/thunderbolt/nhi.h
+index b0718020c6f5..c15a0c46c9cf 100644
+--- a/drivers/thunderbolt/nhi.h
++++ b/drivers/thunderbolt/nhi.h
+@@ -75,6 +75,8 @@ extern const struct tb_nhi_ops icl_nhi_ops;
+ #define PCI_DEVICE_ID_INTEL_TITAN_RIDGE_DD_BRIDGE 0x15ef
+ #define PCI_DEVICE_ID_INTEL_ADL_NHI0 0x463e
+ #define PCI_DEVICE_ID_INTEL_ADL_NHI1 0x466d
++#define PCI_DEVICE_ID_INTEL_BARLOW_RIDGE_HOST_80G_NHI 0x5781
++#define PCI_DEVICE_ID_INTEL_BARLOW_RIDGE_HOST_40G_NHI 0x5784
+ #define PCI_DEVICE_ID_INTEL_MTL_M_NHI0 0x7eb2
+ #define PCI_DEVICE_ID_INTEL_MTL_P_NHI0 0x7ec2
+ #define PCI_DEVICE_ID_INTEL_MTL_P_NHI1 0x7ec3
+--
+2.39.5
+
--- /dev/null
+From c5863e6546196c4ebe31750b22ba79d7b8860228 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 20 May 2022 13:47:11 +0300
+Subject: thunderbolt: Add support for Intel Lunar Lake
+
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+
+[ Upstream commit 2cd3da4e37453019e21a486d9de3144f46b4fdf7 ]
+
+Intel Lunar Lake has similar integrated Thunderbolt/USB4 controller as
+Intel Meteor Lake with some small differences in the host router (it has
+3 DP IN adapters for instance). Add the Intel Lunar Lake PCI IDs to the
+driver list of supported devices.
+
+Tested-by: Pengfei Xu <pengfei.xu@intel.com>
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Stable-dep-of: 8644b48714dc ("thunderbolt: Add support for Intel Panther Lake-M/P")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/thunderbolt/nhi.c | 4 ++++
+ drivers/thunderbolt/nhi.h | 2 ++
+ 2 files changed, 6 insertions(+)
+
+diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
+index 1350223088d8..ed028b01f14f 100644
+--- a/drivers/thunderbolt/nhi.c
++++ b/drivers/thunderbolt/nhi.c
+@@ -1447,6 +1447,10 @@ static struct pci_device_id nhi_ids[] = {
+ .driver_data = (kernel_ulong_t)&icl_nhi_ops },
+ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_MTL_P_NHI1),
+ .driver_data = (kernel_ulong_t)&icl_nhi_ops },
++ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_LNL_NHI0),
++ .driver_data = (kernel_ulong_t)&icl_nhi_ops },
++ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_LNL_NHI1),
++ .driver_data = (kernel_ulong_t)&icl_nhi_ops },
+ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_BARLOW_RIDGE_HOST_80G_NHI) },
+ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_BARLOW_RIDGE_HOST_40G_NHI) },
+
+diff --git a/drivers/thunderbolt/nhi.h b/drivers/thunderbolt/nhi.h
+index c15a0c46c9cf..4b0fccf033e1 100644
+--- a/drivers/thunderbolt/nhi.h
++++ b/drivers/thunderbolt/nhi.h
+@@ -88,6 +88,8 @@ extern const struct tb_nhi_ops icl_nhi_ops;
+ #define PCI_DEVICE_ID_INTEL_TGL_H_NHI1 0x9a21
+ #define PCI_DEVICE_ID_INTEL_RPL_NHI0 0xa73e
+ #define PCI_DEVICE_ID_INTEL_RPL_NHI1 0xa76d
++#define PCI_DEVICE_ID_INTEL_LNL_NHI0 0xa833
++#define PCI_DEVICE_ID_INTEL_LNL_NHI1 0xa834
+
+ #define PCI_CLASS_SERIAL_USB_USB4 0x0c0340
+
+--
+2.39.5
+
--- /dev/null
+From 6c78c97ae3ada25df22f9d76712f0270331c244e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 29 Jun 2021 13:32:29 -0700
+Subject: thunderbolt: Add support for Intel Meteor Lake
+
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+
+[ Upstream commit 32249fd8c8cccd7a1ed86c3b6d9b6ae9b4a83623 ]
+
+Intel Meteor Lake has the same integrated Thunderbolt/USB4 controller as
+Intel Alder Lake. Add the Intel Meteor Lake PCI IDs to the driver list
+of supported devices.
+
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Stable-dep-of: 8644b48714dc ("thunderbolt: Add support for Intel Panther Lake-M/P")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/thunderbolt/icm.c | 3 +++
+ drivers/thunderbolt/nhi.c | 6 ++++++
+ drivers/thunderbolt/nhi.h | 3 +++
+ 3 files changed, 12 insertions(+)
+
+diff --git a/drivers/thunderbolt/icm.c b/drivers/thunderbolt/icm.c
+index e4e92f014a8b..e6849a272f8d 100644
+--- a/drivers/thunderbolt/icm.c
++++ b/drivers/thunderbolt/icm.c
+@@ -2513,6 +2513,9 @@ struct tb *icm_probe(struct tb_nhi *nhi)
+ case PCI_DEVICE_ID_INTEL_ADL_NHI1:
+ case PCI_DEVICE_ID_INTEL_RPL_NHI0:
+ case PCI_DEVICE_ID_INTEL_RPL_NHI1:
++ case PCI_DEVICE_ID_INTEL_MTL_M_NHI0:
++ case PCI_DEVICE_ID_INTEL_MTL_P_NHI0:
++ case PCI_DEVICE_ID_INTEL_MTL_P_NHI1:
+ icm->is_supported = icm_tgl_is_supported;
+ icm->driver_ready = icm_icl_driver_ready;
+ icm->set_uuid = icm_icl_set_uuid;
+diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
+index 99faa8a5e9c0..3b47eb2397a1 100644
+--- a/drivers/thunderbolt/nhi.c
++++ b/drivers/thunderbolt/nhi.c
+@@ -1441,6 +1441,12 @@ static struct pci_device_id nhi_ids[] = {
+ .driver_data = (kernel_ulong_t)&icl_nhi_ops },
+ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_RPL_NHI1),
+ .driver_data = (kernel_ulong_t)&icl_nhi_ops },
++ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_MTL_M_NHI0),
++ .driver_data = (kernel_ulong_t)&icl_nhi_ops },
++ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_MTL_P_NHI0),
++ .driver_data = (kernel_ulong_t)&icl_nhi_ops },
++ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_MTL_P_NHI1),
++ .driver_data = (kernel_ulong_t)&icl_nhi_ops },
+
+ /* Any USB4 compliant host */
+ { PCI_DEVICE_CLASS(PCI_CLASS_SERIAL_USB_USB4, ~0) },
+diff --git a/drivers/thunderbolt/nhi.h b/drivers/thunderbolt/nhi.h
+index 01190d9ced16..b0718020c6f5 100644
+--- a/drivers/thunderbolt/nhi.h
++++ b/drivers/thunderbolt/nhi.h
+@@ -75,6 +75,9 @@ extern const struct tb_nhi_ops icl_nhi_ops;
+ #define PCI_DEVICE_ID_INTEL_TITAN_RIDGE_DD_BRIDGE 0x15ef
+ #define PCI_DEVICE_ID_INTEL_ADL_NHI0 0x463e
+ #define PCI_DEVICE_ID_INTEL_ADL_NHI1 0x466d
++#define PCI_DEVICE_ID_INTEL_MTL_M_NHI0 0x7eb2
++#define PCI_DEVICE_ID_INTEL_MTL_P_NHI0 0x7ec2
++#define PCI_DEVICE_ID_INTEL_MTL_P_NHI1 0x7ec3
+ #define PCI_DEVICE_ID_INTEL_ICL_NHI1 0x8a0d
+ #define PCI_DEVICE_ID_INTEL_ICL_NHI0 0x8a17
+ #define PCI_DEVICE_ID_INTEL_TGL_NHI0 0x9a1b
+--
+2.39.5
+
--- /dev/null
+From 9124f951060d07fd3620d5985a84e9593aa8d666 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 14 May 2024 10:15:14 +0300
+Subject: thunderbolt: Add support for Intel Panther Lake-M/P
+
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+
+[ Upstream commit 8644b48714dca8bf2f42a4ff8311de8efc9bd8c3 ]
+
+Intel Panther Lake-M/P has the same integrated Thunderbolt/USB4
+controller as Lunar Lake. Add these PCI IDs to the driver list of
+supported devices.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/thunderbolt/nhi.c | 8 ++++++++
+ drivers/thunderbolt/nhi.h | 4 ++++
+ 2 files changed, 12 insertions(+)
+
+diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
+index ed028b01f14f..1db233c44851 100644
+--- a/drivers/thunderbolt/nhi.c
++++ b/drivers/thunderbolt/nhi.c
+@@ -1451,6 +1451,14 @@ static struct pci_device_id nhi_ids[] = {
+ .driver_data = (kernel_ulong_t)&icl_nhi_ops },
+ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_LNL_NHI1),
+ .driver_data = (kernel_ulong_t)&icl_nhi_ops },
++ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_PTL_M_NHI0),
++ .driver_data = (kernel_ulong_t)&icl_nhi_ops },
++ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_PTL_M_NHI1),
++ .driver_data = (kernel_ulong_t)&icl_nhi_ops },
++ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_PTL_P_NHI0),
++ .driver_data = (kernel_ulong_t)&icl_nhi_ops },
++ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_PTL_P_NHI1),
++ .driver_data = (kernel_ulong_t)&icl_nhi_ops },
+ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_BARLOW_RIDGE_HOST_80G_NHI) },
+ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_BARLOW_RIDGE_HOST_40G_NHI) },
+
+diff --git a/drivers/thunderbolt/nhi.h b/drivers/thunderbolt/nhi.h
+index 4b0fccf033e1..67ecee94d7b9 100644
+--- a/drivers/thunderbolt/nhi.h
++++ b/drivers/thunderbolt/nhi.h
+@@ -90,6 +90,10 @@ extern const struct tb_nhi_ops icl_nhi_ops;
+ #define PCI_DEVICE_ID_INTEL_RPL_NHI1 0xa76d
+ #define PCI_DEVICE_ID_INTEL_LNL_NHI0 0xa833
+ #define PCI_DEVICE_ID_INTEL_LNL_NHI1 0xa834
++#define PCI_DEVICE_ID_INTEL_PTL_M_NHI0 0xe333
++#define PCI_DEVICE_ID_INTEL_PTL_M_NHI1 0xe334
++#define PCI_DEVICE_ID_INTEL_PTL_P_NHI0 0xe433
++#define PCI_DEVICE_ID_INTEL_PTL_P_NHI1 0xe434
+
+ #define PCI_CLASS_SERIAL_USB_USB4 0x0c0340
+
+--
+2.39.5
+
--- /dev/null
+From b30c0733676d6f8e85d5ab6c15e1e4efcef4b80b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 1 Jun 2022 15:41:02 -0700
+Subject: thunderbolt: Add support for Intel Raptor Lake
+
+From: George D Sworo <george.d.sworo@intel.com>
+
+[ Upstream commit 7ec58378a985618909ffae18e4ac0de2ae625f33 ]
+
+Intel Raptor Lake has the same integrated Thunderbolt/USB4 controller as
+Intel Alder Lake. By default it is still using firmware based connection
+manager so we can use most of the Alder Lake flows.
+
+Signed-off-by: George D Sworo <george.d.sworo@intel.com>
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Stable-dep-of: 8644b48714dc ("thunderbolt: Add support for Intel Panther Lake-M/P")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/thunderbolt/icm.c | 2 ++
+ drivers/thunderbolt/nhi.c | 4 ++++
+ drivers/thunderbolt/nhi.h | 2 ++
+ 3 files changed, 8 insertions(+)
+
+diff --git a/drivers/thunderbolt/icm.c b/drivers/thunderbolt/icm.c
+index 11c0207ebd7e..e4e92f014a8b 100644
+--- a/drivers/thunderbolt/icm.c
++++ b/drivers/thunderbolt/icm.c
+@@ -2511,6 +2511,8 @@ struct tb *icm_probe(struct tb_nhi *nhi)
+ case PCI_DEVICE_ID_INTEL_TGL_H_NHI1:
+ case PCI_DEVICE_ID_INTEL_ADL_NHI0:
+ case PCI_DEVICE_ID_INTEL_ADL_NHI1:
++ case PCI_DEVICE_ID_INTEL_RPL_NHI0:
++ case PCI_DEVICE_ID_INTEL_RPL_NHI1:
+ icm->is_supported = icm_tgl_is_supported;
+ icm->driver_ready = icm_icl_driver_ready;
+ icm->set_uuid = icm_icl_set_uuid;
+diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
+index 7341376140eb..99faa8a5e9c0 100644
+--- a/drivers/thunderbolt/nhi.c
++++ b/drivers/thunderbolt/nhi.c
+@@ -1437,6 +1437,10 @@ static struct pci_device_id nhi_ids[] = {
+ .driver_data = (kernel_ulong_t)&icl_nhi_ops },
+ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_ADL_NHI1),
+ .driver_data = (kernel_ulong_t)&icl_nhi_ops },
++ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_RPL_NHI0),
++ .driver_data = (kernel_ulong_t)&icl_nhi_ops },
++ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_RPL_NHI1),
++ .driver_data = (kernel_ulong_t)&icl_nhi_ops },
+
+ /* Any USB4 compliant host */
+ { PCI_DEVICE_CLASS(PCI_CLASS_SERIAL_USB_USB4, ~0) },
+diff --git a/drivers/thunderbolt/nhi.h b/drivers/thunderbolt/nhi.h
+index 5091677b3f4b..01190d9ced16 100644
+--- a/drivers/thunderbolt/nhi.h
++++ b/drivers/thunderbolt/nhi.h
+@@ -81,6 +81,8 @@ extern const struct tb_nhi_ops icl_nhi_ops;
+ #define PCI_DEVICE_ID_INTEL_TGL_NHI1 0x9a1d
+ #define PCI_DEVICE_ID_INTEL_TGL_H_NHI0 0x9a1f
+ #define PCI_DEVICE_ID_INTEL_TGL_H_NHI1 0x9a21
++#define PCI_DEVICE_ID_INTEL_RPL_NHI0 0xa73e
++#define PCI_DEVICE_ID_INTEL_RPL_NHI1 0xa76d
+
+ #define PCI_CLASS_SERIAL_USB_USB4 0x0c0340
+
+--
+2.39.5
+
--- /dev/null
+From 43c44fe527b496720de5a2a41f4079f231fcfdf3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 6 Nov 2024 12:14:57 +0200
+Subject: usb: xhci: Limit Stop Endpoint retries
+
+From: Michal Pecio <michal.pecio@gmail.com>
+
+[ Upstream commit 42b7581376015c1bbcbe5831f043cd0ac119d028 ]
+
+Some host controllers fail to atomically transition an endpoint to the
+Running state on a doorbell ring and enter a hidden "Restarting" state,
+which looks very much like Stopped, with the important difference that
+it will spontaneously transition to Running anytime soon.
+
+A Stop Endpoint command queued in the Restarting state typically fails
+with Context State Error and the completion handler sees the Endpoint
+Context State as either still Stopped or already Running. Even a case
+of Halted was observed, when an error occurred right after the restart.
+
+The Halted state is already recovered from by resetting the endpoint.
+The Running state is handled by retrying Stop Endpoint.
+
+The Stopped state was recognized as a problem on NEC controllers and
+worked around also by retrying, because the endpoint soon restarts and
+then stops for good. But there is a risk: the command may fail if the
+endpoint is "stopped for good" already, and retries will fail forever.
+
+The possibility of this was not realized at the time, but a number of
+cases were discovered later and reproduced. Some proved difficult to
+deal with, and it is outright impossible to predict if an endpoint may
+fail to ever start at all due to a hardware bug. One such bug (albeit
+on ASM3142, not on NEC) was found to be reliably triggered simply by
+toggling an AX88179 NIC up/down in a tight loop for a few seconds.
+
+An endless retries storm is quite nasty. Besides putting needless load
+on the xHC and CPU, it causes URBs never to be given back, paralyzing
+the device and connection/disconnection logic for the whole bus if the
+device is unplugged. User processes waiting for URBs become unkillable,
+drivers and kworker threads lock up and xhci_hcd cannot be reloaded.
+
+For peace of mind, impose a timeout on Stop Endpoint retries in this
+case. If they don't succeed in 100ms, consider the endpoint stopped
+permanently for some reason and just give back the unlinked URBs. This
+failure case is rare already and work is under way to make it rarer.
+
+Start this work today by also handling one simple case of race with
+Reset Endpoint, because it costs just two lines to implement.
+
+Fixes: fd9d55d190c0 ("xhci: retry Stop Endpoint on buggy NEC controllers")
+CC: stable@vger.kernel.org
+Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Link: https://lore.kernel.org/r/20241106101459.775897-32-mathias.nyman@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Stable-dep-of: e21ebe51af68 ("xhci: Turn NEC specific quirk for handling Stop Endpoint errors generic")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/host/xhci-ring.c | 28 ++++++++++++++++++++++++----
+ drivers/usb/host/xhci.c | 2 ++
+ drivers/usb/host/xhci.h | 1 +
+ 3 files changed, 27 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
+index 29faa2d5c766..2694d7bf48a7 100644
+--- a/drivers/usb/host/xhci-ring.c
++++ b/drivers/usb/host/xhci-ring.c
+@@ -52,6 +52,7 @@
+ * endpoint rings; it generates events on the event ring for these.
+ */
+
++#include <linux/jiffies.h>
+ #include <linux/scatterlist.h>
+ #include <linux/slab.h>
+ #include <linux/dma-mapping.h>
+@@ -1150,16 +1151,35 @@ static void xhci_handle_cmd_stop_ep(struct xhci_hcd *xhci, int slot_id,
+ return;
+ case EP_STATE_STOPPED:
+ /*
+- * NEC uPD720200 sometimes sets this state and fails with
+- * Context Error while continuing to process TRBs.
+- * Be conservative and trust EP_CTX_STATE on other chips.
++ * Per xHCI 4.6.9, Stop Endpoint command on a Stopped
++ * EP is a Context State Error, and EP stays Stopped.
++ *
++ * But maybe it failed on Halted, and somebody ran Reset
++ * Endpoint later. EP state is now Stopped and EP_HALTED
++ * still set because Reset EP handler will run after us.
++ */
++ if (ep->ep_state & EP_HALTED)
++ break;
++ /*
++ * On some HCs EP state remains Stopped for some tens of
++ * us to a few ms or more after a doorbell ring, and any
++ * new Stop Endpoint fails without aborting the restart.
++ * This handler may run quickly enough to still see this
++ * Stopped state, but it will soon change to Running.
++ *
++ * Assume this bug on unexpected Stop Endpoint failures.
++ * Keep retrying until the EP starts and stops again, on
++ * chips where this is known to help. Wait for 100ms.
+ */
+ if (!(xhci->quirks & XHCI_NEC_HOST))
+ break;
++ if (time_is_before_jiffies(ep->stop_time + msecs_to_jiffies(100)))
++ break;
+ fallthrough;
+ case EP_STATE_RUNNING:
+ /* Race, HW handled stop ep cmd before ep was running */
+- xhci_dbg(xhci, "Stop ep completion ctx error, ep is running\n");
++ xhci_dbg(xhci, "Stop ep completion ctx error, ctx_state %d\n",
++ GET_EP_CTX_STATE(ep_ctx));
+
+ command = xhci_alloc_command(xhci, false, GFP_ATOMIC);
+ if (!command)
+diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
+index eb12e4c174ea..58483d1e5d3f 100644
+--- a/drivers/usb/host/xhci.c
++++ b/drivers/usb/host/xhci.c
+@@ -8,6 +8,7 @@
+ * Some code borrowed from the Linux EHCI driver.
+ */
+
++#include <linux/jiffies.h>
+ #include <linux/pci.h>
+ #include <linux/iommu.h>
+ #include <linux/iopoll.h>
+@@ -1891,6 +1892,7 @@ static int xhci_urb_dequeue(struct usb_hcd *hcd, struct urb *urb, int status)
+ ret = -ENOMEM;
+ goto done;
+ }
++ ep->stop_time = jiffies;
+ ep->ep_state |= EP_STOP_CMD_PENDING;
+ ep->stop_cmd_timer.expires = jiffies +
+ XHCI_STOP_EP_CMD_TIMEOUT * HZ;
+diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
+index 298938eca163..67d5ef952d6a 100644
+--- a/drivers/usb/host/xhci.h
++++ b/drivers/usb/host/xhci.h
+@@ -717,6 +717,7 @@ struct xhci_virt_ep {
+ /* Bandwidth checking storage */
+ struct xhci_bw_info bw_info;
+ struct list_head bw_endpoint_list;
++ unsigned long stop_time;
+ /* Isoch Frame ID checking storage */
+ int next_frame_id;
+ /* Use new Isoch TRB layout needed for extended TBC support */
+--
+2.39.5
+
--- /dev/null
+From 6094e5dc8fd4b1a5dfc70d75be3995e55717a3f8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 29 Feb 2024 16:14:36 +0200
+Subject: xhci: retry Stop Endpoint on buggy NEC controllers
+
+From: Michal Pecio <michal.pecio@gmail.com>
+
+[ Upstream commit fd9d55d190c0e5fefd3a9165ea361809427885a1 ]
+
+Two NEC uPD720200 adapters have been observed to randomly misbehave:
+a Stop Endpoint command fails with Context Error, the Output Context
+indicates Stopped state, and the endpoint keeps running. Very often,
+Set TR Dequeue Pointer is seen to fail next with Context Error too,
+in addition to problems from unexpectedly completed cancelled work.
+
+The pathology is common on fast running isoc endpoints like uvcvideo,
+but has also been reproduced on a full-speed bulk endpoint of pl2303.
+It seems all EPs are affected, with risk proportional to their load.
+
+Reproduction involves receiving any kind of stream and closing it to
+make the device driver cancel URBs already queued in advance.
+
+Deal with it by retrying the command like in the Running state.
+
+Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Link: https://lore.kernel.org/r/20240229141438.619372-8-mathias.nyman@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Stable-dep-of: e21ebe51af68 ("xhci: Turn NEC specific quirk for handling Stop Endpoint errors generic")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/host/xhci-ring.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
+index 5e880f0bdd8a..29faa2d5c766 100644
+--- a/drivers/usb/host/xhci-ring.c
++++ b/drivers/usb/host/xhci-ring.c
+@@ -1148,6 +1148,15 @@ static void xhci_handle_cmd_stop_ep(struct xhci_hcd *xhci, int slot_id,
+ break;
+ xhci_stop_watchdog_timer_in_irq(xhci, ep);
+ return;
++ case EP_STATE_STOPPED:
++ /*
++ * NEC uPD720200 sometimes sets this state and fails with
++ * Context Error while continuing to process TRBs.
++ * Be conservative and trust EP_CTX_STATE on other chips.
++ */
++ if (!(xhci->quirks & XHCI_NEC_HOST))
++ break;
++ fallthrough;
+ case EP_STATE_RUNNING:
+ /* Race, HW handled stop ep cmd before ep was running */
+ xhci_dbg(xhci, "Stop ep completion ctx error, ep is running\n");
+--
+2.39.5
+
--- /dev/null
+From 4d52912d1fadae5e9cb0e6fee5896384e2bfdc50 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 17 Dec 2024 12:21:21 +0200
+Subject: xhci: Turn NEC specific quirk for handling Stop Endpoint errors
+ generic
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+[ Upstream commit e21ebe51af688eb98fd6269240212a3c7300deea ]
+
+xHC hosts from several vendors have the same issue where endpoints start
+so slowly that a later queued 'Stop Endpoint' command may complete before
+endpoint is up and running.
+
+The 'Stop Endpoint' command fails with context state error as the endpoint
+still appears as stopped.
+
+See commit 42b758137601 ("usb: xhci: Limit Stop Endpoint retries") for
+details
+
+CC: stable@vger.kernel.org
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Link: https://lore.kernel.org/r/20241217102122.2316814-2-mathias.nyman@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/host/xhci-ring.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
+index 2694d7bf48a7..0ff70c859f14 100644
+--- a/drivers/usb/host/xhci-ring.c
++++ b/drivers/usb/host/xhci-ring.c
+@@ -1171,8 +1171,6 @@ static void xhci_handle_cmd_stop_ep(struct xhci_hcd *xhci, int slot_id,
+ * Keep retrying until the EP starts and stops again, on
+ * chips where this is known to help. Wait for 100ms.
+ */
+- if (!(xhci->quirks & XHCI_NEC_HOST))
+- break;
+ if (time_is_before_jiffies(ep->stop_time + msecs_to_jiffies(100)))
+ break;
+ fallthrough;
+--
+2.39.5
+
--- /dev/null
+From b6a138af7438a2eff9fa129de3c3ab8aa04b061a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 Dec 2024 00:57:16 +0800
+Subject: zram: fix uninitialized ZRAM not releasing backing device
+
+From: Kairui Song <kasong@tencent.com>
+
+[ Upstream commit 74363ec674cb172d8856de25776c8f3103f05e2f ]
+
+Setting backing device is done before ZRAM initialization. If we set the
+backing device, then remove the ZRAM module without initializing the
+device, the backing device reference will be leaked and the device will be
+hold forever.
+
+Fix this by always reset the ZRAM fully on rmmod or reset store.
+
+Link: https://lkml.kernel.org/r/20241209165717.94215-3-ryncsn@gmail.com
+Fixes: 013bf95a83ec ("zram: add interface to specif backing device")
+Signed-off-by: Kairui Song <kasong@tencent.com>
+Reported-by: Desheng Wu <deshengwu@tencent.com>
+Suggested-by: Sergey Senozhatsky <senozhatsky@chromium.org>
+Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/block/zram/zram_drv.c | 9 ++++-----
+ 1 file changed, 4 insertions(+), 5 deletions(-)
+
+diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
+index 9eed579d02f0..02efa0ca242a 100644
+--- a/drivers/block/zram/zram_drv.c
++++ b/drivers/block/zram/zram_drv.c
+@@ -1150,12 +1150,16 @@ static void zram_meta_free(struct zram *zram, u64 disksize)
+ size_t num_pages = disksize >> PAGE_SHIFT;
+ size_t index;
+
++ if (!zram->table)
++ return;
++
+ /* Free all pages that are still in this zram device */
+ for (index = 0; index < num_pages; index++)
+ zram_free_page(zram, index);
+
+ zs_destroy_pool(zram->mem_pool);
+ vfree(zram->table);
++ zram->table = NULL;
+ }
+
+ static bool zram_meta_alloc(struct zram *zram, u64 disksize)
+@@ -1699,11 +1703,6 @@ static void zram_reset_device(struct zram *zram)
+
+ zram->limit_pages = 0;
+
+- if (!init_done(zram)) {
+- up_write(&zram->init_lock);
+- return;
+- }
+-
+ set_capacity_and_notify(zram->disk, 0);
+ part_stat_set_all(zram->disk->part0, 0);
+
+--
+2.39.5
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
