--- /dev/null
+From cd4aece493f99f95d41edcce32927d70a5dde923 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Wed, 20 Sep 2023 15:05:06 +0200
+Subject: ACPI: EC: Add quirk for the HP Pavilion Gaming 15-dk1xxx
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit cd4aece493f99f95d41edcce32927d70a5dde923 upstream.
+
+Added GPE quirk entry for the HP Pavilion Gaming 15-dk1xxx.
+There is a quirk entry for 2 15-c..... laptops, this is
+for a new version which has 15-dk1xxx as identifier.
+
+This fixes the LID switch and rfkill and brightness hotkeys
+not working.
+
+Closes: https://github.com/systemd/systemd/issues/28942
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/ec.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/drivers/acpi/ec.c
++++ b/drivers/acpi/ec.c
+@@ -1888,6 +1888,17 @@ static const struct dmi_system_id ec_dmi
+ },
+ {
+ /*
++ * HP Pavilion Gaming Laptop 15-dk1xxx
++ * https://github.com/systemd/systemd/issues/28942
++ */
++ .callback = ec_honor_dsdt_gpe,
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "HP"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "HP Pavilion Gaming Laptop 15-dk1xxx"),
++ },
++ },
++ {
++ /*
+ * Samsung hardware
+ * https://bugzilla.kernel.org/show_bug.cgi?id=44161
+ */
--- /dev/null
+From c1ed72171ed580fbf159e703b77685aa4b0d0df5 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Tue, 12 Sep 2023 12:08:27 +0200
+Subject: ACPI: resource: Skip IRQ override on ASUS ExpertBook B1402CBA
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit c1ed72171ed580fbf159e703b77685aa4b0d0df5 upstream.
+
+Like various other ASUS ExpertBook-s, the ASUS ExpertBook B1402CBA
+has an ACPI DSDT table that describes IRQ 1 as ActiveLow while
+the kernel overrides it to EdgeHigh.
+
+This prevents the keyboard from working. To fix this issue, add this laptop
+to the skip_override_table so that the kernel does not override IRQ 1.
+
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217901
+Cc: stable@vger.kernel.org
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/resource.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/acpi/resource.c
++++ b/drivers/acpi/resource.c
+@@ -440,6 +440,13 @@ static const struct dmi_system_id asus_l
+ },
+ },
+ {
++ .ident = "Asus ExpertBook B1402CBA",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_BOARD_NAME, "B1402CBA"),
++ },
++ },
++ {
+ .ident = "Asus ExpertBook B2402CBA",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
--- /dev/null
+From 25389c03c21c9587dd21c768d1cbfa514a3ca211 Mon Sep 17 00:00:00 2001
+From: Macpaul Lin <macpaul.lin@mediatek.com>
+Date: Tue, 3 Oct 2023 13:13:44 +0200
+Subject: arm64: dts: mediatek: mt8195-demo: fix the memory size to 8GB
+
+From: Macpaul Lin <macpaul.lin@mediatek.com>
+
+commit 25389c03c21c9587dd21c768d1cbfa514a3ca211 upstream.
+
+The onboard dram of mt8195-demo board is 8GB.
+
+Cc: stable@vger.kernel.org # 6.1, 6.4, 6.5
+Fixes: 6147314aeedc ("arm64: dts: mediatek: Add device-tree for MT8195 Demo board")
+Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
+Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+Link: https://lore.kernel.org/r/20230905034511.11232-1-macpaul.lin@mediatek.com
+Link: https://lore.kernel.org/r/20231003-mediatek-fixes-v6-7-v1-2-dad7cd62a8ff@collabora.com
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/mediatek/mt8195-demo.dts | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/mediatek/mt8195-demo.dts
++++ b/arch/arm64/boot/dts/mediatek/mt8195-demo.dts
+@@ -48,7 +48,7 @@
+
+ memory@40000000 {
+ device_type = "memory";
+- reg = <0 0x40000000 0 0x80000000>;
++ reg = <0 0x40000000 0x2 0x00000000>;
+ };
+
+ reserved-memory {
--- /dev/null
+From 6cd2a30b96a4b2d270bc1ef1611429dc3fa63327 Mon Sep 17 00:00:00 2001
+From: Macpaul Lin <macpaul.lin@mediatek.com>
+Date: Tue, 3 Oct 2023 13:13:45 +0200
+Subject: arm64: dts: mediatek: mt8195-demo: update and reorder reserved memory regions
+
+From: Macpaul Lin <macpaul.lin@mediatek.com>
+
+commit 6cd2a30b96a4b2d270bc1ef1611429dc3fa63327 upstream.
+
+The dts file of the MediaTek MT8195 demo board has been updated to include
+new reserved memory regions.
+These reserved memory regions are:
+ - SCP
+ - VPU,
+ - Sound DMA
+ - APU.
+
+These regions are defined with the "shared-dma-pool" compatible property.
+In addition, the existing reserved memory regions have been reordered by
+their addresses to improve readability and maintainability of the DTS
+file.
+
+Cc: stable@vger.kernel.org # 6.1, 6.4, 6.5
+Fixes: e4a417520101 ("arm64: dts: mediatek: mt8195-demo: fix the memory size of node secmon")
+Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
+Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+Link: https://lore.kernel.org/r/20230905034511.11232-2-macpaul.lin@mediatek.com
+Link: https://lore.kernel.org/r/20231003-mediatek-fixes-v6-7-v1-3-dad7cd62a8ff@collabora.com
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/mediatek/mt8195-demo.dts | 37 +++++++++++++++++++++------
+ 1 file changed, 30 insertions(+), 7 deletions(-)
+
+--- a/arch/arm64/boot/dts/mediatek/mt8195-demo.dts
++++ b/arch/arm64/boot/dts/mediatek/mt8195-demo.dts
+@@ -56,13 +56,8 @@
+ #size-cells = <2>;
+ ranges;
+
+- /* 2 MiB reserved for ARM Trusted Firmware (BL31) */
+- bl31_secmon_reserved: secmon@54600000 {
+- no-map;
+- reg = <0 0x54600000 0x0 0x200000>;
+- };
+-
+- /* 12 MiB reserved for OP-TEE (BL32)
++ /*
++ * 12 MiB reserved for OP-TEE (BL32)
+ * +-----------------------+ 0x43e0_0000
+ * | SHMEM 2MiB |
+ * +-----------------------+ 0x43c0_0000
+@@ -75,6 +70,34 @@
+ no-map;
+ reg = <0 0x43200000 0 0x00c00000>;
+ };
++
++ scp_mem: memory@50000000 {
++ compatible = "shared-dma-pool";
++ reg = <0 0x50000000 0 0x2900000>;
++ no-map;
++ };
++
++ vpu_mem: memory@53000000 {
++ compatible = "shared-dma-pool";
++ reg = <0 0x53000000 0 0x1400000>; /* 20 MB */
++ };
++
++ /* 2 MiB reserved for ARM Trusted Firmware (BL31) */
++ bl31_secmon_mem: memory@54600000 {
++ no-map;
++ reg = <0 0x54600000 0x0 0x200000>;
++ };
++
++ snd_dma_mem: memory@60000000 {
++ compatible = "shared-dma-pool";
++ reg = <0 0x60000000 0 0x1100000>;
++ no-map;
++ };
++
++ apu_mem: memory@62000000 {
++ compatible = "shared-dma-pool";
++ reg = <0 0x62000000 0 0x1400000>; /* 20 MB */
++ };
+ };
+ };
+
--- /dev/null
+From 15c0a870dc44ed14e01efbdd319d232234ee639f Mon Sep 17 00:00:00 2001
+From: Xiubo Li <xiubli@redhat.com>
+Date: Wed, 6 Sep 2023 14:22:07 +0800
+Subject: ceph: fix incorrect revoked caps assert in ceph_fill_file_size()
+
+From: Xiubo Li <xiubli@redhat.com>
+
+commit 15c0a870dc44ed14e01efbdd319d232234ee639f upstream.
+
+When truncating the inode the MDS will acquire the xlock for the
+ifile Locker, which will revoke the 'Frwsxl' caps from the clients.
+But when the client just releases and flushes the 'Fw' caps to MDS,
+for exmaple, and once the MDS receives the caps flushing msg it
+just thought the revocation has finished. Then the MDS will continue
+truncating the inode and then issued the truncate notification to
+all the clients. While just before the clients receives the cap
+flushing ack they receive the truncation notification, the clients
+will detecte that the 'issued | dirty' is still holding the 'Fw'
+caps.
+
+Cc: stable@vger.kernel.org
+Link: https://tracker.ceph.com/issues/56693
+Fixes: b0d7c2231015 ("ceph: introduce i_truncate_mutex")
+Signed-off-by: Xiubo Li <xiubli@redhat.com>
+Reviewed-by: Milind Changire <mchangir@redhat.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ceph/inode.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/fs/ceph/inode.c
++++ b/fs/ceph/inode.c
+@@ -655,9 +655,7 @@ int ceph_fill_file_size(struct inode *in
+ ci->i_truncate_seq = truncate_seq;
+
+ /* the MDS should have revoked these caps */
+- WARN_ON_ONCE(issued & (CEPH_CAP_FILE_EXCL |
+- CEPH_CAP_FILE_RD |
+- CEPH_CAP_FILE_WR |
++ WARN_ON_ONCE(issued & (CEPH_CAP_FILE_RD |
+ CEPH_CAP_FILE_LAZYIO));
+ /*
+ * If we hold relevant caps, or in the case where we're
--- /dev/null
+From 07bb00ef00ace88dd6f695fadbba76565756e55c Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@linaro.org>
+Date: Sat, 7 Oct 2023 11:52:39 +0300
+Subject: ceph: fix type promotion bug on 32bit systems
+
+From: Dan Carpenter <dan.carpenter@linaro.org>
+
+commit 07bb00ef00ace88dd6f695fadbba76565756e55c upstream.
+
+In this code "ret" is type long and "src_objlen" is unsigned int. The
+problem is that on 32bit systems, when we do the comparison signed longs
+are type promoted to unsigned int. So negative error codes from
+do_splice_direct() are treated as success instead of failure.
+
+Cc: stable@vger.kernel.org
+Fixes: 1b0c3b9f91f0 ("ceph: re-org copy_file_range and fix some error paths")
+Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
+Reviewed-by: Xiubo Li <xiubli@redhat.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ceph/file.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/ceph/file.c
++++ b/fs/ceph/file.c
+@@ -2498,7 +2498,7 @@ static ssize_t __ceph_copy_file_range(st
+ ret = do_splice_direct(src_file, &src_off, dst_file,
+ &dst_off, src_objlen, flags);
+ /* Abort on short copies or on error */
+- if (ret < src_objlen) {
++ if (ret < (long)src_objlen) {
+ dout("Failed partial copy (%zd)\n", ret);
+ goto out;
+ }
--- /dev/null
+From 1ca0b605150501b7dc59f3016271da4eb3e96fce Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Michal=20Koutn=C3=BD?= <mkoutny@suse.com>
+Date: Mon, 9 Oct 2023 15:58:11 +0200
+Subject: cgroup: Remove duplicates in cgroup v1 tasks file
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Michal Koutný <mkoutny@suse.com>
+
+commit 1ca0b605150501b7dc59f3016271da4eb3e96fce upstream.
+
+One PID may appear multiple times in a preloaded pidlist.
+(Possibly due to PID recycling but we have reports of the same
+task_struct appearing with different PIDs, thus possibly involving
+transfer of PID via de_thread().)
+
+Because v1 seq_file iterator uses PIDs as position, it leads to
+a message:
+> seq_file: buggy .next function kernfs_seq_next did not update position index
+
+Conservative and quick fix consists of removing duplicates from `tasks`
+file (as opposed to removing pidlists altogether). It doesn't affect
+correctness (it's sufficient to show a PID once), performance impact
+would be hidden by unconditional sorting of the pidlist already in place
+(asymptotically).
+
+Link: https://lore.kernel.org/r/20230823174804.23632-1-mkoutny@suse.com/
+Suggested-by: Firo Yang <firo.yang@suse.com>
+Signed-off-by: Michal Koutný <mkoutny@suse.com>
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/cgroup/cgroup-v1.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/kernel/cgroup/cgroup-v1.c
++++ b/kernel/cgroup/cgroup-v1.c
+@@ -360,10 +360,9 @@ static int pidlist_array_load(struct cgr
+ }
+ css_task_iter_end(&it);
+ length = n;
+- /* now sort & (if procs) strip out duplicates */
++ /* now sort & strip out duplicates (tgids or recycled thread PIDs) */
+ sort(array, length, sizeof(pid_t), cmppid, NULL);
+- if (type == CGROUP_FILE_PROCS)
+- length = pidlist_uniq(array, length);
++ length = pidlist_uniq(array, length);
+
+ l = cgroup_pidlist_find_create(cgrp, type);
+ if (!l) {
--- /dev/null
+From 3170256d7bc1ef81587caf4b83573eb1f5bb4fb6 Mon Sep 17 00:00:00 2001
+From: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
+Date: Tue, 29 Aug 2023 15:40:22 +0200
+Subject: counter: chrdev: fix getting array extensions
+
+From: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
+
+commit 3170256d7bc1ef81587caf4b83573eb1f5bb4fb6 upstream.
+
+When trying to watch a component array extension, and the array isn't the
+first extended element, it fails as the type comparison is always done on
+the 1st element. Fix it by indexing the 'ext' array.
+
+Example on a dummy struct counter_comp:
+static struct counter_comp dummy[] = {
+ COUNTER_COMP_DIRECTION(..),
+ ...,
+ COUNTER_COMP_ARRAY_CAPTURE(...),
+};
+static struct counter_count dummy_cnt = {
+ ...
+ .ext = dummy,
+ .num_ext = ARRAY_SIZE(dummy),
+}
+
+Currently, counter_get_ext() returns -EINVAL when trying to add a watch
+event on one of the capture array element in such example.
+
+Fixes: d2011be1e22f ("counter: Introduce the COUNTER_COMP_ARRAY component type")
+Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
+Link: https://lore.kernel.org/r/20230829134029.2402868-2-fabrice.gasnier@foss.st.com
+Signed-off-by: William Breathitt Gray <william.gray@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/counter/counter-chrdev.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/counter/counter-chrdev.c b/drivers/counter/counter-chrdev.c
+index 80acdf62794a..afc94d0062b1 100644
+--- a/drivers/counter/counter-chrdev.c
++++ b/drivers/counter/counter-chrdev.c
+@@ -247,8 +247,8 @@ static int counter_get_ext(const struct counter_comp *const ext,
+ if (*id == component_id)
+ return 0;
+
+- if (ext->type == COUNTER_COMP_ARRAY) {
+- element = ext->priv;
++ if (ext[*ext_idx].type == COUNTER_COMP_ARRAY) {
++ element = ext[*ext_idx].priv;
+
+ if (component_id - *id < element->length)
+ return 0;
+--
+2.42.0
+
--- /dev/null
+From df8fdd01c98b99d04915c04f3a5ce73f55456b7c Mon Sep 17 00:00:00 2001
+From: Dharma Balasubiramani <dharma.b@microchip.com>
+Date: Tue, 5 Sep 2023 15:38:35 +0530
+Subject: counter: microchip-tcb-capture: Fix the use of internal GCLK logic
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Dharma Balasubiramani <dharma.b@microchip.com>
+
+commit df8fdd01c98b99d04915c04f3a5ce73f55456b7c upstream.
+
+As per the datasheet, the clock selection Bits 2:0 – TCCLKS[2:0] should
+be set to 0 while using the internal GCLK (TIMER_CLOCK1).
+
+Fixes: 106b104137fd ("counter: Add microchip TCB capture counter")
+Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com>
+Link: https://lore.kernel.org/r/20230905100835.315024-1-dharma.b@microchip.com
+Signed-off-by: William Breathitt Gray <william.gray@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/counter/microchip-tcb-capture.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/counter/microchip-tcb-capture.c
++++ b/drivers/counter/microchip-tcb-capture.c
+@@ -98,7 +98,7 @@ static int mchp_tc_count_function_write(
+ priv->qdec_mode = 0;
+ /* Set highest rate based on whether soc has gclk or not */
+ bmr &= ~(ATMEL_TC_QDEN | ATMEL_TC_POSEN);
+- if (priv->tc_cfg->has_gclk)
++ if (!priv->tc_cfg->has_gclk)
+ cmr |= ATMEL_TC_TIMER_CLOCK2;
+ else
+ cmr |= ATMEL_TC_TIMER_CLOCK1;
--- /dev/null
+From b83ce9cb4a465b8f9a3fa45561b721a9551f60e3 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig@amd.com>
+Date: Fri, 8 Sep 2023 10:27:23 +0200
+Subject: dma-buf: add dma_fence_timestamp helper
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Christian König <christian.koenig@amd.com>
+
+commit b83ce9cb4a465b8f9a3fa45561b721a9551f60e3 upstream.
+
+When a fence signals there is a very small race window where the timestamp
+isn't updated yet. sync_file solves this by busy waiting for the
+timestamp to appear, but on other ocassions didn't handled this
+correctly.
+
+Provide a dma_fence_timestamp() helper function for this and use it in
+all appropriate cases.
+
+Another alternative would be to grab the spinlock when that happens.
+
+v2 by teddy: add a wait parameter to wait for the timestamp to show up, in case
+ the accurate timestamp is needed and/or the timestamp is not based on
+ ktime (e.g. hw timestamp)
+v3 chk: drop the parameter again for unified handling
+
+Signed-off-by: Yunxiang Li <Yunxiang.Li@amd.com>
+Signed-off-by: Christian König <christian.koenig@amd.com>
+Fixes: 1774baa64f93 ("drm/scheduler: Change scheduled fence track v2")
+Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
+CC: stable@vger.kernel.org
+Link: https://patchwork.freedesktop.org/patch/msgid/20230929104725.2358-1-christian.koenig@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/dma-buf/dma-fence-unwrap.c | 13 ++++---------
+ drivers/dma-buf/sync_file.c | 9 +++------
+ drivers/gpu/drm/scheduler/sched_main.c | 2 +-
+ include/linux/dma-fence.h | 19 +++++++++++++++++++
+ 4 files changed, 27 insertions(+), 16 deletions(-)
+
+--- a/drivers/dma-buf/dma-fence-unwrap.c
++++ b/drivers/dma-buf/dma-fence-unwrap.c
+@@ -76,16 +76,11 @@ struct dma_fence *__dma_fence_unwrap_mer
+ dma_fence_unwrap_for_each(tmp, &iter[i], fences[i]) {
+ if (!dma_fence_is_signaled(tmp)) {
+ ++count;
+- } else if (test_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT,
+- &tmp->flags)) {
+- if (ktime_after(tmp->timestamp, timestamp))
+- timestamp = tmp->timestamp;
+ } else {
+- /*
+- * Use the current time if the fence is
+- * currently signaling.
+- */
+- timestamp = ktime_get();
++ ktime_t t = dma_fence_timestamp(tmp);
++
++ if (ktime_after(t, timestamp))
++ timestamp = t;
+ }
+ }
+ }
+--- a/drivers/dma-buf/sync_file.c
++++ b/drivers/dma-buf/sync_file.c
+@@ -268,13 +268,10 @@ static int sync_fill_fence_info(struct d
+ sizeof(info->driver_name));
+
+ info->status = dma_fence_get_status(fence);
+- while (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags) &&
+- !test_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags))
+- cpu_relax();
+ info->timestamp_ns =
+- test_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags) ?
+- ktime_to_ns(fence->timestamp) :
+- ktime_set(0, 0);
++ dma_fence_is_signaled(fence) ?
++ ktime_to_ns(dma_fence_timestamp(fence)) :
++ ktime_set(0, 0);
+
+ return info->status;
+ }
+--- a/drivers/gpu/drm/scheduler/sched_main.c
++++ b/drivers/gpu/drm/scheduler/sched_main.c
+@@ -841,7 +841,7 @@ drm_sched_get_cleanup_job(struct drm_gpu
+
+ if (next) {
+ next->s_fence->scheduled.timestamp =
+- job->s_fence->finished.timestamp;
++ dma_fence_timestamp(&job->s_fence->finished);
+ /* start TO timer for next job */
+ drm_sched_start_timeout(sched);
+ }
+--- a/include/linux/dma-fence.h
++++ b/include/linux/dma-fence.h
+@@ -548,6 +548,25 @@ static inline void dma_fence_set_error(s
+ fence->error = error;
+ }
+
++/**
++ * dma_fence_timestamp - helper to get the completion timestamp of a fence
++ * @fence: fence to get the timestamp from.
++ *
++ * After a fence is signaled the timestamp is updated with the signaling time,
++ * but setting the timestamp can race with tasks waiting for the signaling. This
++ * helper busy waits for the correct timestamp to appear.
++ */
++static inline ktime_t dma_fence_timestamp(struct dma_fence *fence)
++{
++ if (WARN_ON(!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)))
++ return ktime_get();
++
++ while (!test_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags))
++ cpu_relax();
++
++ return fence->timestamp;
++}
++
+ signed long dma_fence_wait_timeout(struct dma_fence *,
+ bool intr, signed long timeout);
+ signed long dma_fence_wait_any_timeout(struct dma_fence **fences,
--- /dev/null
+From 67e13e89742c3b21ce177f612bf9ef32caae6047 Mon Sep 17 00:00:00 2001
+From: Amelie Delaunay <amelie.delaunay@foss.st.com>
+Date: Wed, 4 Oct 2023 17:50:24 +0200
+Subject: dmaengine: stm32-dma: fix residue in case of MDMA chaining
+
+From: Amelie Delaunay <amelie.delaunay@foss.st.com>
+
+commit 67e13e89742c3b21ce177f612bf9ef32caae6047 upstream.
+
+In case of MDMA chaining, DMA is configured in Double-Buffer Mode (DBM)
+with two periods, but if transfer has been prepared with _prep_slave_sg(),
+the transfer is not marked cyclic (=!chan->desc->cyclic). However, as DBM
+is activated for MDMA chaining, residue computation must take into account
+cyclic constraints.
+
+With only two periods in MDMA chaining, and no update due to Transfer
+Complete interrupt masked, n_sg is always 0. If DMA current memory address
+(depending on SxCR.CT and SxM0AR/SxM1AR) does not correspond, it means n_sg
+should be increased.
+Then, the residue of the current period is the one read from SxNDTR and
+should not be overwritten with the full period length.
+
+Fixes: 723795173ce1 ("dmaengine: stm32-dma: add support to trigger STM32 MDMA")
+Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20231004155024.2609531-2-amelie.delaunay@foss.st.com
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/dma/stm32-dma.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
+index 7427acc82259..0b30151fb45c 100644
+--- a/drivers/dma/stm32-dma.c
++++ b/drivers/dma/stm32-dma.c
+@@ -1389,11 +1389,12 @@ static size_t stm32_dma_desc_residue(struct stm32_dma_chan *chan,
+
+ residue = stm32_dma_get_remaining_bytes(chan);
+
+- if (chan->desc->cyclic && !stm32_dma_is_current_sg(chan)) {
++ if ((chan->desc->cyclic || chan->trig_mdma) && !stm32_dma_is_current_sg(chan)) {
+ n_sg++;
+ if (n_sg == chan->desc->num_sgs)
+ n_sg = 0;
+- residue = sg_req->len;
++ if (!chan->trig_mdma)
++ residue = sg_req->len;
+ }
+
+ /*
+@@ -1403,7 +1404,7 @@ static size_t stm32_dma_desc_residue(struct stm32_dma_chan *chan,
+ * residue = remaining bytes from NDTR + remaining
+ * periods/sg to be transferred
+ */
+- if (!chan->desc->cyclic || n_sg != 0)
++ if ((!chan->desc->cyclic && !chan->trig_mdma) || n_sg != 0)
+ for (i = n_sg; i < desc->num_sgs; i++)
+ residue += desc->sg_req[i].len;
+
+--
+2.42.0
+
--- /dev/null
+From 2df467e908ce463cff1431ca1b00f650f7a514b4 Mon Sep 17 00:00:00 2001
+From: Amelie Delaunay <amelie.delaunay@foss.st.com>
+Date: Wed, 4 Oct 2023 17:50:23 +0200
+Subject: dmaengine: stm32-dma: fix stm32_dma_prep_slave_sg in case of MDMA chaining
+
+From: Amelie Delaunay <amelie.delaunay@foss.st.com>
+
+commit 2df467e908ce463cff1431ca1b00f650f7a514b4 upstream.
+
+Current Target (CT) have to be reset when starting an MDMA chaining use
+case, as Double Buffer mode is activated. It ensures the DMA will start
+processing the first memory target (pointed with SxM0AR).
+
+Fixes: 723795173ce1 ("dmaengine: stm32-dma: add support to trigger STM32 MDMA")
+Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20231004155024.2609531-1-amelie.delaunay@foss.st.com
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/dma/stm32-dma.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
+index 5c36811aa134..7427acc82259 100644
+--- a/drivers/dma/stm32-dma.c
++++ b/drivers/dma/stm32-dma.c
+@@ -1113,8 +1113,10 @@ static struct dma_async_tx_descriptor *stm32_dma_prep_slave_sg(
+ chan->chan_reg.dma_scr &= ~STM32_DMA_SCR_PFCTRL;
+
+ /* Activate Double Buffer Mode if DMA triggers STM32 MDMA and more than 1 sg */
+- if (chan->trig_mdma && sg_len > 1)
++ if (chan->trig_mdma && sg_len > 1) {
+ chan->chan_reg.dma_scr |= STM32_DMA_SCR_DBM;
++ chan->chan_reg.dma_scr &= ~STM32_DMA_SCR_CT;
++ }
+
+ for_each_sg(sgl, sg, sg_len, i) {
+ ret = stm32_dma_set_xfer_param(chan, direction, &buswidth,
+--
+2.42.0
+
--- /dev/null
+From 81337b9a72dc58a5fa0ae8a042e8cb59f9bdec4a Mon Sep 17 00:00:00 2001
+From: Amelie Delaunay <amelie.delaunay@foss.st.com>
+Date: Wed, 4 Oct 2023 18:35:28 +0200
+Subject: dmaengine: stm32-mdma: abort resume if no ongoing transfer
+
+From: Amelie Delaunay <amelie.delaunay@foss.st.com>
+
+commit 81337b9a72dc58a5fa0ae8a042e8cb59f9bdec4a upstream.
+
+chan->desc can be null, if transfer is terminated when resume is called,
+leading to a NULL pointer when retrieving the hwdesc.
+To avoid this case, check that chan->desc is not null and channel is
+disabled (transfer previously paused or terminated).
+
+Fixes: a4ffb13c8946 ("dmaengine: Add STM32 MDMA driver")
+Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20231004163531.2864160-1-amelie.delaunay@foss.st.com
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/dma/stm32-mdma.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/dma/stm32-mdma.c
++++ b/drivers/dma/stm32-mdma.c
+@@ -1237,6 +1237,10 @@ static int stm32_mdma_resume(struct dma_
+ unsigned long flags;
+ u32 status, reg;
+
++ /* Transfer can be terminated */
++ if (!chan->desc || (stm32_mdma_read(dmadev, STM32_MDMA_CCR(chan->id)) & STM32_MDMA_CCR_EN))
++ return -EPERM;
++
+ hwdesc = chan->desc->node[chan->curr_hwdesc].hwdesc;
+
+ spin_lock_irqsave(&chan->vchan.lock, flags);
--- /dev/null
+From 584970421725b7805db84714b857851fdf7203a9 Mon Sep 17 00:00:00 2001
+From: Amelie Delaunay <amelie.delaunay@foss.st.com>
+Date: Wed, 4 Oct 2023 18:35:30 +0200
+Subject: dmaengine: stm32-mdma: set in_flight_bytes in case CRQA flag is set
+
+From: Amelie Delaunay <amelie.delaunay@foss.st.com>
+
+commit 584970421725b7805db84714b857851fdf7203a9 upstream.
+
+CRQA flag is set by hardware when the channel request become active and
+the channel is enabled. It is cleared by hardware, when the channel request
+is completed.
+So when it is set, it means MDMA is transferring bytes.
+This information is useful in case of STM32 DMA and MDMA chaining,
+especially when the user pauses DMA before stopping it, to trig one last
+MDMA transfer to get the latest bytes of the SRAM buffer to the
+destination buffer.
+STM32 DCMI driver can then use this to know if the last MDMA transfer in
+case of chaining is done.
+
+Fixes: 696874322771 ("dmaengine: stm32-mdma: add support to be triggered by STM32 DMA")
+Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20231004163531.2864160-3-amelie.delaunay@foss.st.com
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/dma/stm32-mdma.c | 14 +++++++++-----
+ 1 file changed, 9 insertions(+), 5 deletions(-)
+
+--- a/drivers/dma/stm32-mdma.c
++++ b/drivers/dma/stm32-mdma.c
+@@ -1319,7 +1319,8 @@ static int stm32_mdma_slave_config(struc
+
+ static size_t stm32_mdma_desc_residue(struct stm32_mdma_chan *chan,
+ struct stm32_mdma_desc *desc,
+- u32 curr_hwdesc)
++ u32 curr_hwdesc,
++ struct dma_tx_state *state)
+ {
+ struct stm32_mdma_device *dmadev = stm32_mdma_get_dev(chan);
+ struct stm32_mdma_hwdesc *hwdesc;
+@@ -1343,6 +1344,10 @@ static size_t stm32_mdma_desc_residue(st
+ cbndtr = stm32_mdma_read(dmadev, STM32_MDMA_CBNDTR(chan->id));
+ residue += cbndtr & STM32_MDMA_CBNDTR_BNDT_MASK;
+
++ state->in_flight_bytes = 0;
++ if (chan->chan_config.m2m_hw && (cisr & STM32_MDMA_CISR_CRQA))
++ state->in_flight_bytes = cbndtr & STM32_MDMA_CBNDTR_BNDT_MASK;
++
+ if (!chan->mem_burst)
+ return residue;
+
+@@ -1372,11 +1377,10 @@ static enum dma_status stm32_mdma_tx_sta
+
+ vdesc = vchan_find_desc(&chan->vchan, cookie);
+ if (chan->desc && cookie == chan->desc->vdesc.tx.cookie)
+- residue = stm32_mdma_desc_residue(chan, chan->desc,
+- chan->curr_hwdesc);
++ residue = stm32_mdma_desc_residue(chan, chan->desc, chan->curr_hwdesc, state);
+ else if (vdesc)
+- residue = stm32_mdma_desc_residue(chan,
+- to_stm32_mdma_desc(vdesc), 0);
++ residue = stm32_mdma_desc_residue(chan, to_stm32_mdma_desc(vdesc), 0, state);
++
+ dma_set_residue(state, residue);
+
+ spin_unlock_irqrestore(&chan->vchan.lock, flags);
--- /dev/null
+From a4b306eb83579c07b63dc65cd5bae53b7b4019d0 Mon Sep 17 00:00:00 2001
+From: Amelie Delaunay <amelie.delaunay@foss.st.com>
+Date: Wed, 4 Oct 2023 18:35:29 +0200
+Subject: dmaengine: stm32-mdma: use Link Address Register to compute residue
+
+From: Amelie Delaunay <amelie.delaunay@foss.st.com>
+
+commit a4b306eb83579c07b63dc65cd5bae53b7b4019d0 upstream.
+
+Current implementation relies on curr_hwdesc index. But to keep this index
+up to date, Block Transfer interrupt (BTIE) has to be enabled.
+If it is not, curr_hwdesc is not updated, and then residue is not reliable.
+Rely on Link Address Register instead. And disable BTIE interrupt
+in stm32_mdma_setup_xfer() because it is no more needed in case of
+_prep_slave_sg() to maintain curr_hwdesc up to date.
+It avoids extra interrupts and also ensures a reliable residue. These
+improvements are required for STM32 DCMI camera capture use case, which
+need STM32 DMA and MDMA chaining for good performance.
+
+Fixes: 696874322771 ("dmaengine: stm32-mdma: add support to be triggered by STM32 DMA")
+Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20231004163531.2864160-2-amelie.delaunay@foss.st.com
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/dma/stm32-mdma.c | 15 +++++++++++----
+ 1 file changed, 11 insertions(+), 4 deletions(-)
+
+--- a/drivers/dma/stm32-mdma.c
++++ b/drivers/dma/stm32-mdma.c
+@@ -778,8 +778,6 @@ static int stm32_mdma_setup_xfer(struct
+ /* Enable interrupts */
+ ccr &= ~STM32_MDMA_CCR_IRQ_MASK;
+ ccr |= STM32_MDMA_CCR_TEIE | STM32_MDMA_CCR_CTCIE;
+- if (sg_len > 1)
+- ccr |= STM32_MDMA_CCR_BTIE;
+ desc->ccr = ccr;
+
+ return 0;
+@@ -1325,12 +1323,21 @@ static size_t stm32_mdma_desc_residue(st
+ {
+ struct stm32_mdma_device *dmadev = stm32_mdma_get_dev(chan);
+ struct stm32_mdma_hwdesc *hwdesc;
+- u32 cbndtr, residue, modulo, burst_size;
++ u32 cisr, clar, cbndtr, residue, modulo, burst_size;
+ int i;
+
++ cisr = stm32_mdma_read(dmadev, STM32_MDMA_CISR(chan->id));
++
+ residue = 0;
+- for (i = curr_hwdesc + 1; i < desc->count; i++) {
++ /* Get the next hw descriptor to process from current transfer */
++ clar = stm32_mdma_read(dmadev, STM32_MDMA_CLAR(chan->id));
++ for (i = desc->count - 1; i >= 0; i--) {
+ hwdesc = desc->node[i].hwdesc;
++
++ if (hwdesc->clar == clar)
++ break;/* Current transfer found, stop cumulating */
++
++ /* Cumulate residue of unprocessed hw descriptors */
+ residue += STM32_MDMA_CBNDTR_BNDT(hwdesc->cbndtr);
+ }
+ cbndtr = stm32_mdma_read(dmadev, STM32_MDMA_CBNDTR(chan->id));
--- /dev/null
+From 23645bca98304a2772f0de96f97370dd567d0ae6 Mon Sep 17 00:00:00 2001
+From: Daniel Miess <daniel.miess@amd.com>
+Date: Fri, 29 Sep 2023 13:04:33 -0400
+Subject: drm/amd/display: Don't set dpms_off for seamless boot
+
+From: Daniel Miess <daniel.miess@amd.com>
+
+commit 23645bca98304a2772f0de96f97370dd567d0ae6 upstream.
+
+[Why]
+eDPs fail to light up with seamless boot enabled
+
+[How]
+When seamless boot is enabled don't configure dpms_off
+in disable_vbios_mode_if_required.
+
+Reviewed-by: Charlene Liu <charlene.liu@amd.com>
+Cc: Mario Limonciello <mario.limonciello@amd.com>
+Cc: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Acked-by: Tom Chung <chiahsuan.chung@amd.com>
+Signed-off-by: Daniel Miess <daniel.miess@amd.com>
+Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/dc/core/dc.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
++++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
+@@ -1183,6 +1183,9 @@ static void disable_vbios_mode_if_requir
+ if (stream == NULL)
+ continue;
+
++ if (stream->apply_seamless_boot_optimization)
++ continue;
++
+ // only looking for first odm pipe
+ if (pipe->prev_odm_pipe)
+ continue;
--- /dev/null
+From ff89f064dca38e2203790bf876cc7756b8ab2961 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig@amd.com>
+Date: Fri, 6 Oct 2023 14:04:04 +0200
+Subject: drm/amdgpu: add missing NULL check
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Christian König <christian.koenig@amd.com>
+
+commit ff89f064dca38e2203790bf876cc7756b8ab2961 upstream.
+
+bo->tbo.resource can easily be NULL here.
+
+Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2902
+Signed-off-by: Christian König <christian.koenig@amd.com>
+Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+CC: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+@@ -220,7 +220,7 @@ static inline bool amdgpu_bo_in_cpu_visi
+ struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+ struct amdgpu_res_cursor cursor;
+
+- if (bo->tbo.resource->mem_type != TTM_PL_VRAM)
++ if (!bo->tbo.resource || bo->tbo.resource->mem_type != TTM_PL_VRAM)
+ return false;
+
+ amdgpu_res_first(bo->tbo.resource, 0, amdgpu_bo_size(bo), &cursor);
--- /dev/null
+From 2b7947bd32e243c52870d54141d3b4ea6775e63d Mon Sep 17 00:00:00 2001
+From: Simon Ser <contact@emersion.fr>
+Date: Thu, 5 Oct 2023 13:16:32 +0000
+Subject: drm/atomic-helper: relax unregistered connector check
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Simon Ser <contact@emersion.fr>
+
+commit 2b7947bd32e243c52870d54141d3b4ea6775e63d upstream.
+
+The driver might pull connectors which weren't submitted by
+user-space into the atomic state. For instance,
+intel_dp_mst_atomic_master_trans_check() pulls in connectors
+sharing the same DP-MST stream. However, if the connector is
+unregistered, this later fails with:
+
+ [ 559.425658] i915 0000:00:02.0: [drm:drm_atomic_helper_check_modeset] [CONNECTOR:378:DP-7] is not registered
+
+Skip the unregistered connector check to allow user-space to turn
+off connectors one-by-one.
+
+See this wlroots issue:
+https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3407
+
+Previous discussion:
+https://lore.kernel.org/intel-gfx/Y6GX7z17WmDSKwta@ideak-desk.fi.intel.com/
+
+Signed-off-by: Simon Ser <contact@emersion.fr>
+Cc: stable@vger.kernel.org
+Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Reviewed-by: Lyude Paul <lyude@redhat.com>
+Cc: Jani Nikula <jani.nikula@intel.com>
+Cc: Imre Deak <imre.deak@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20231005131623.114379-1-contact@emersion.fr
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/drm_atomic_helper.c | 17 +++++++++++++----
+ 1 file changed, 13 insertions(+), 4 deletions(-)
+
+--- a/drivers/gpu/drm/drm_atomic_helper.c
++++ b/drivers/gpu/drm/drm_atomic_helper.c
+@@ -290,7 +290,8 @@ static int
+ update_connector_routing(struct drm_atomic_state *state,
+ struct drm_connector *connector,
+ struct drm_connector_state *old_connector_state,
+- struct drm_connector_state *new_connector_state)
++ struct drm_connector_state *new_connector_state,
++ bool added_by_user)
+ {
+ const struct drm_connector_helper_funcs *funcs;
+ struct drm_encoder *new_encoder;
+@@ -339,9 +340,13 @@ update_connector_routing(struct drm_atom
+ * there's a chance the connector may have been destroyed during the
+ * process, but it's better to ignore that then cause
+ * drm_atomic_helper_resume() to fail.
++ *
++ * Last, we want to ignore connector registration when the connector
++ * was not pulled in the atomic state by user-space (ie, was pulled
++ * in by the driver, e.g. when updating a DP-MST stream).
+ */
+ if (!state->duplicated && drm_connector_is_unregistered(connector) &&
+- crtc_state->active) {
++ added_by_user && crtc_state->active) {
+ drm_dbg_atomic(connector->dev,
+ "[CONNECTOR:%d:%s] is not registered\n",
+ connector->base.id, connector->name);
+@@ -620,7 +625,10 @@ drm_atomic_helper_check_modeset(struct d
+ struct drm_connector *connector;
+ struct drm_connector_state *old_connector_state, *new_connector_state;
+ int i, ret;
+- unsigned int connectors_mask = 0;
++ unsigned int connectors_mask = 0, user_connectors_mask = 0;
++
++ for_each_oldnew_connector_in_state(state, connector, old_connector_state, new_connector_state, i)
++ user_connectors_mask |= BIT(i);
+
+ for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, new_crtc_state, i) {
+ bool has_connectors =
+@@ -685,7 +693,8 @@ drm_atomic_helper_check_modeset(struct d
+ */
+ ret = update_connector_routing(state, connector,
+ old_connector_state,
+- new_connector_state);
++ new_connector_state,
++ BIT(i) & user_connectors_mask);
+ if (ret)
+ return ret;
+ if (old_connector_state->crtc) {
--- /dev/null
+From 850101b3598277794f92a9e363a60a66e0d42890 Mon Sep 17 00:00:00 2001
+From: Philipp Rossak <embed3d@gmail.com>
+Date: Tue, 5 Sep 2023 00:02:04 +0200
+Subject: iio: adc: imx8qxp: Fix address for command buffer registers
+
+From: Philipp Rossak <embed3d@gmail.com>
+
+commit 850101b3598277794f92a9e363a60a66e0d42890 upstream.
+
+The ADC Command Buffer Register high and low are currently pointing to
+the wrong address and makes it impossible to perform correct
+ADC measurements over all channels.
+
+According to the datasheet of the imx8qxp the ADC_CMDL register starts
+at address 0x100 and the ADC_CMDH register starts at address 0x104.
+
+This bug seems to be in the kernel since the introduction of this
+driver.
+
+This can be observed by checking all raw voltages of the adc and they
+are all nearly identical:
+
+cat /sys/bus/iio/devices/iio\:device0/in_voltage*_raw
+3498
+3494
+3491
+3491
+3489
+3490
+3490
+3490
+
+Fixes: 1e23dcaa1a9fa ("iio: imx8qxp-adc: Add driver support for NXP IMX8QXP ADC")
+Signed-off-by: Philipp Rossak <embed3d@gmail.com>
+Acked-by: Haibo Chen <haibo.chen@nxp.com>
+Link: https://lore.kernel.org/r/20230904220204.23841-1-embed3d@gmail.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/adc/imx8qxp-adc.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/iio/adc/imx8qxp-adc.c
++++ b/drivers/iio/adc/imx8qxp-adc.c
+@@ -38,8 +38,8 @@
+ #define IMX8QXP_ADR_ADC_FCTRL 0x30
+ #define IMX8QXP_ADR_ADC_SWTRIG 0x34
+ #define IMX8QXP_ADR_ADC_TCTRL(tid) (0xc0 + (tid) * 4)
+-#define IMX8QXP_ADR_ADC_CMDH(cid) (0x100 + (cid) * 8)
+-#define IMX8QXP_ADR_ADC_CMDL(cid) (0x104 + (cid) * 8)
++#define IMX8QXP_ADR_ADC_CMDL(cid) (0x100 + (cid) * 8)
++#define IMX8QXP_ADR_ADC_CMDH(cid) (0x104 + (cid) * 8)
+ #define IMX8QXP_ADR_ADC_RESFIFO 0x300
+ #define IMX8QXP_ADR_ADC_TST 0xffc
+
--- /dev/null
+From b120dd3a15582fb7a959cecb05e4d9814fcba386 Mon Sep 17 00:00:00 2001
+From: Antoniu Miclaus <antoniu.miclaus@analog.com>
+Date: Tue, 12 Sep 2023 11:54:21 +0300
+Subject: iio: addac: Kconfig: update ad74413r selections
+
+From: Antoniu Miclaus <antoniu.miclaus@analog.com>
+
+commit b120dd3a15582fb7a959cecb05e4d9814fcba386 upstream.
+
+Building ad74413r without selecting IIO_BUFFER and
+IIO_TRIGGERED_BUFFER generates error with respect to the iio trigger
+functions that are used within the driver.
+Update the Kconfig accordingly.
+
+Fixes: fea251b6a5db ("iio: addac: add AD74413R driver")
+Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
+Link: https://lore.kernel.org/r/20230912085421.51102-1-antoniu.miclaus@analog.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/addac/Kconfig | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/iio/addac/Kconfig
++++ b/drivers/iio/addac/Kconfig
+@@ -10,6 +10,8 @@ config AD74413R
+ depends on GPIOLIB && SPI
+ select REGMAP_SPI
+ select CRC8
++ select IIO_BUFFER
++ select IIO_TRIGGERED_BUFFER
+ help
+ Say yes here to build support for Analog Devices AD74412R/AD74413R
+ quad-channel software configurable input/output solution.
--- /dev/null
+From 287d998af24326b009ae0956820a3188501b34a0 Mon Sep 17 00:00:00 2001
+From: Antoniu Miclaus <antoniu.miclaus@analog.com>
+Date: Mon, 7 Aug 2023 17:38:05 +0300
+Subject: iio: admv1013: add mixer_vgate corner cases
+
+From: Antoniu Miclaus <antoniu.miclaus@analog.com>
+
+commit 287d998af24326b009ae0956820a3188501b34a0 upstream.
+
+Include the corner cases in the computation of the MIXER_VGATE register
+value.
+
+According to the datasheet: The MIXER_VGATE values follows the VCM such
+as, that for a 0V to 1.8V VCM, MIXER_VGATE = 23.89 VCM + 81, and for a >
+1.8V to 2.6V VCM, MIXER_VGATE = 23.75 VCM + 1.25.
+
+Fixes: da35a7b526d9 ("iio: frequency: admv1013: add support for ADMV1013")
+Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
+Reviewed-by: Nuno Sa <nuno.sa@analog.com>
+Link: https://lore.kernel.org/r/20230807143806.6954-1-antoniu.miclaus@analog.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/frequency/admv1013.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/iio/frequency/admv1013.c
++++ b/drivers/iio/frequency/admv1013.c
+@@ -351,9 +351,9 @@ static int admv1013_update_mixer_vgate(s
+ if (vcm < 0)
+ return vcm;
+
+- if (vcm < 1800000)
++ if (vcm <= 1800000)
+ mixer_vgate = (2389 * vcm / 1000000 + 8100) / 100;
+- else if (vcm > 1800000 && vcm < 2600000)
++ else if (vcm > 1800000 && vcm <= 2600000)
+ mixer_vgate = (2375 * vcm / 1000000 + 125) / 100;
+ else
+ return -EINVAL;
--- /dev/null
+From 9a85653ed3b9a9b7b31d95a34b64b990c3d33ca1 Mon Sep 17 00:00:00 2001
+From: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
+Date: Thu, 3 Aug 2023 16:56:23 -0300
+Subject: iio: dac: ad3552r: Correct device IDs
+
+From: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
+
+commit 9a85653ed3b9a9b7b31d95a34b64b990c3d33ca1 upstream.
+
+Device IDs for AD3542R and AD3552R were swapped leading to unintended
+collection of DAC output ranges being used for each design.
+Change device ID values so they are correct for each DAC chip.
+
+Fixes: 8f2b54824b28 ("drivers:iio:dac: Add AD3552R driver support")
+Signed-off-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
+Reported-by: Chandrakant Minajigi <Chandrakant.Minajigi@analog.com>
+Link: https://lore.kernel.org/r/011f480220799fbfabdd53896f8a2f251ad995ad.1691091324.git.marcelo.schmitt1@gmail.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/dac/ad3552r.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/iio/dac/ad3552r.c
++++ b/drivers/iio/dac/ad3552r.c
+@@ -140,8 +140,8 @@ enum ad3552r_ch_vref_select {
+ };
+
+ enum ad3542r_id {
+- AD3542R_ID = 0x4008,
+- AD3552R_ID = 0x4009,
++ AD3542R_ID = 0x4009,
++ AD3552R_ID = 0x4008,
+ };
+
+ enum ad3552r_ch_output_range {
--- /dev/null
+From c9b9cfe7d342683f624a89c3b617be18aff879e8 Mon Sep 17 00:00:00 2001
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Date: Sun, 3 Sep 2023 12:30:52 +0100
+Subject: iio: imu: bno055: Fix missing Kconfig dependencies
+
+From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+
+commit c9b9cfe7d342683f624a89c3b617be18aff879e8 upstream.
+
+This driver uses IIO triggered buffers so it needs to select them in
+Kconfig.
+
+on riscv-32bit:
+
+/opt/crosstool/gcc-13.2.0-nolibc/riscv32-linux/bin/riscv32-linux-ld: drivers/iio/imu/bno055/bno055.o: in function `.L367':
+bno055.c:(.text+0x2c96): undefined reference to `devm_iio_triggered_buffer_setup_ext'
+
+Reported-by: Randy Dunlap <rdunlap@infradead.org>
+Closes: https://lore.kernel.org/linux-next/40566b4b-3950-81fe-ff14-871d8c447627@infradead.org/
+Fixes: 4aefe1c2bd0c ("iio: imu: add Bosch Sensortec BNO055 core driver")
+Cc: Andrea Merello <andrea.merello@iit.it>
+Acked-by: Randy Dunlap <rdunlap@infradead.org>
+Tested-by: Randy Dunlap <rdunlap@infradead.org>
+Link: https://lore.kernel.org/r/20230903113052.846298-1-jic23@kernel.org
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/imu/bno055/Kconfig | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/iio/imu/bno055/Kconfig b/drivers/iio/imu/bno055/Kconfig
+index fa79b1ac4f85..83e53acfbe88 100644
+--- a/drivers/iio/imu/bno055/Kconfig
++++ b/drivers/iio/imu/bno055/Kconfig
+@@ -2,6 +2,8 @@
+
+ config BOSCH_BNO055
+ tristate
++ select IIO_BUFFER
++ select IIO_TRIGGERED_BUFFER
+
+ config BOSCH_BNO055_SERIAL
+ tristate "Bosch BNO055 attached via UART"
+--
+2.42.0
+
--- /dev/null
+From 85dfb43bf69281adb1f345dfd9a39faf2e5a718d Mon Sep 17 00:00:00 2001
+From: Phil Elwell <phil@raspberrypi.com>
+Date: Fri, 11 Aug 2023 16:58:29 +0100
+Subject: iio: pressure: bmp280: Fix NULL pointer exception
+
+From: Phil Elwell <phil@raspberrypi.com>
+
+commit 85dfb43bf69281adb1f345dfd9a39faf2e5a718d upstream.
+
+The bmp085 EOC IRQ support is optional, but the driver's common probe
+function queries the IRQ properties whether or not it exists, which
+can trigger a NULL pointer exception. Avoid any exception by making
+the query conditional on the possession of a valid IRQ.
+
+Fixes: aae953949651 ("iio: pressure: bmp280: add support for BMP085 EOC interrupt")
+Signed-off-by: Phil Elwell <phil@raspberrypi.com>
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Link: https://lore.kernel.org/r/20230811155829.51208-1-phil@raspberrypi.com
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/pressure/bmp280-core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iio/pressure/bmp280-core.c
++++ b/drivers/iio/pressure/bmp280-core.c
+@@ -1786,7 +1786,7 @@ int bmp280_common_probe(struct device *d
+ * however as it happens, the BMP085 shares the chip ID of BMP180
+ * so we look for an IRQ if we have that.
+ */
+- if (irq > 0 || (chip_id == BMP180_CHIP_ID)) {
++ if (irq > 0 && (chip_id == BMP180_CHIP_ID)) {
+ ret = bmp085_fetch_eoc_irq(dev, name, irq, data);
+ if (ret)
+ return ret;
--- /dev/null
+From 901a293fd96fb9bab843ba4cc7be3094a5aa7c94 Mon Sep 17 00:00:00 2001
+From: Lakshmi Yadlapati <lakshmiy@us.ibm.com>
+Date: Tue, 29 Aug 2023 13:02:22 -0500
+Subject: iio: pressure: dps310: Adjust Timeout Settings
+
+From: Lakshmi Yadlapati <lakshmiy@us.ibm.com>
+
+commit 901a293fd96fb9bab843ba4cc7be3094a5aa7c94 upstream.
+
+The DPS310 sensor chip has been encountering intermittent errors while
+reading the sensor device across various system designs. This issue causes
+the chip to become "stuck," preventing the indication of "ready" status
+for pressure and temperature measurements in the MEAS_CFG register.
+
+To address this issue, this commit fixes the timeout settings to improve
+sensor stability:
+- After sending a reset command to the chip, the timeout has been extended
+ from 2.5 ms to 15 ms, aligning with the DPS310 specification.
+- The read timeout value of the MEAS_CFG register has been adjusted from
+ 20ms to 30ms to match the specification.
+
+Signed-off-by: Lakshmi Yadlapati <lakshmiy@us.ibm.com>
+Fixes: 7b4ab4abcea4 ("iio: pressure: dps310: Reset chip after timeout")
+Link: https://lore.kernel.org/r/20230829180222.3431926-2-lakshmiy@us.ibm.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/pressure/dps310.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/iio/pressure/dps310.c
++++ b/drivers/iio/pressure/dps310.c
+@@ -57,8 +57,8 @@
+ #define DPS310_RESET_MAGIC 0x09
+ #define DPS310_COEF_BASE 0x10
+
+-/* Make sure sleep time is <= 20ms for usleep_range */
+-#define DPS310_POLL_SLEEP_US(t) min(20000, (t) / 8)
++/* Make sure sleep time is <= 30ms for usleep_range */
++#define DPS310_POLL_SLEEP_US(t) min(30000, (t) / 8)
+ /* Silently handle error in rate value here */
+ #define DPS310_POLL_TIMEOUT_US(rc) ((rc) <= 0 ? 1000000 : 1000000 / (rc))
+
+@@ -402,8 +402,8 @@ static int dps310_reset_wait(struct dps3
+ if (rc)
+ return rc;
+
+- /* Wait for device chip access: 2.5ms in specification */
+- usleep_range(2500, 12000);
++ /* Wait for device chip access: 15ms in specification */
++ usleep_range(15000, 55000);
+ return 0;
+ }
+
--- /dev/null
+From fd39d9668f2ce9f4b05ad55e8c8d80c098073e0b Mon Sep 17 00:00:00 2001
+From: Alexander Zangerl <az@breathe-safe.com>
+Date: Wed, 20 Sep 2023 10:01:10 +1000
+Subject: iio: pressure: ms5611: ms5611_prom_is_valid false negative bug
+
+From: Alexander Zangerl <az@breathe-safe.com>
+
+commit fd39d9668f2ce9f4b05ad55e8c8d80c098073e0b upstream.
+
+The ms5611 driver falsely rejects lots of MS5607-02BA03-50 chips
+with "PROM integrity check failed" because it doesn't accept a prom crc
+value of zero as legitimate.
+
+According to the datasheet for this chip (and the manufacturer's
+application note about the PROM CRC), none of the possible values for the
+CRC are excluded - but the current code in ms5611_prom_is_valid() ends with
+
+return crc_orig != 0x0000 && crc == crc_orig
+
+Discussed with the driver author (Tomasz Duszynski) and he indicated that
+at that time (2015) he was dealing with some faulty chip samples which
+returned blank data under some circumstances and/or followed example code
+which indicated CRC zero being bad.
+
+As far as I can tell this exception should not be applied anymore; We've
+got a few hundred custom boards here with this chip where large numbers
+of the prom have a legitimate CRC value 0, and do work fine, but which the
+current driver code wrongly rejects.
+
+Signed-off-by: Alexander Zangerl <az@breathe-safe.com>
+Fixes: c0644160a8b5 ("iio: pressure: add support for MS5611 pressure and temperature sensor")
+Link: https://lore.kernel.org/r/2535-1695168070.831792@Ze3y.dhYT.s3fx
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/pressure/ms5611_core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iio/pressure/ms5611_core.c
++++ b/drivers/iio/pressure/ms5611_core.c
+@@ -76,7 +76,7 @@ static bool ms5611_prom_is_valid(u16 *pr
+
+ crc = (crc >> 12) & 0x000F;
+
+- return crc_orig != 0x0000 && crc == crc_orig;
++ return crc == crc_orig;
+ }
+
+ static int ms5611_read_prom(struct iio_dev *indio_dev)
--- /dev/null
+From 423622a90abb243944d1517b9f57db53729e45c4 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Wed, 4 Oct 2023 07:18:31 -0700
+Subject: Input: goodix - ensure int GPIO is in input for gpio_count == 1 && gpio_int_idx == 0 case
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit 423622a90abb243944d1517b9f57db53729e45c4 upstream.
+
+Add a special case for gpio_count == 1 && gpio_int_idx == 0 to
+goodix_add_acpi_gpio_mappings().
+
+It seems that on newer x86/ACPI devices the reset and irq GPIOs are no
+longer listed as GPIO resources instead there is only 1 GpioInt resource
+and _PS0 does the whole reset sequence for us.
+
+This means that we must call acpi_device_fix_up_power() on these devices
+to ensure that the chip is reset before we try to use it.
+
+This part was already fixed in commit 3de93e6ed2df ("Input: goodix - call
+acpi_device_fix_up_power() in some cases") by adding a call to
+acpi_device_fix_up_power() to the generic "Unexpected ACPI resources"
+catch all.
+
+But it turns out that this case on some hw needs some more special
+handling. Specifically the firmware may bootup with the IRQ pin in
+output mode. The reset sequence from ACPI _PS0 (executed by
+acpi_device_fix_up_power()) should put the pin in input mode,
+but the GPIO subsystem has cached the direction at bootup, causing
+request_irq() to fail due to gpiochip_lock_as_irq() failure:
+
+[ 9.119864] Goodix-TS i2c-GDIX1002:00: Unexpected ACPI resources: gpio_count 1, gpio_int_idx 0
+[ 9.317443] Goodix-TS i2c-GDIX1002:00: ID 911, version: 1060
+[ 9.321902] input: Goodix Capacitive TouchScreen as /devices/pci0000:00/0000:00:17.0/i2c_designware.4/i2c-5/i2c-GDIX1002:00/input/input8
+[ 9.327840] gpio gpiochip0: (INT3453:00): gpiochip_lock_as_irq: tried to flag a GPIO set as output for IRQ
+[ 9.327856] gpio gpiochip0: (INT3453:00): unable to lock HW IRQ 26 for IRQ
+[ 9.327861] genirq: Failed to request resources for GDIX1002:00 (irq 131) on irqchip intel-gpio
+[ 9.327912] Goodix-TS i2c-GDIX1002:00: request IRQ failed: -5
+
+Fix this by adding a special case for gpio_count == 1 && gpio_int_idx == 0
+which adds an ACPI GPIO lookup table for the int GPIO even though we cannot
+use it for reset purposes (as there is no reset GPIO).
+
+Adding the lookup will make the gpiod_int = gpiod_get(..., GPIOD_IN) call
+succeed, which will explicitly set the direction to input fixing the issue.
+
+Note this re-uses the acpi_goodix_int_first_gpios[] lookup table, since
+there is only 1 GPIO in the ACPI resources the reset entry in that
+lookup table will amount to a no-op.
+
+Reported-and-tested-by: Michael Smith <1973.mjsmith@gmail.com>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Link: https://lore.kernel.org/r/20231003215144.69527-1-hdegoede@redhat.com
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/input/touchscreen/goodix.c | 19 +++++++++++++++++++
+ 1 file changed, 19 insertions(+)
+
+--- a/drivers/input/touchscreen/goodix.c
++++ b/drivers/input/touchscreen/goodix.c
+@@ -900,6 +900,25 @@ static int goodix_add_acpi_gpio_mappings
+ dev_info(dev, "No ACPI GpioInt resource, assuming that the GPIO order is reset, int\n");
+ ts->irq_pin_access_method = IRQ_PIN_ACCESS_ACPI_GPIO;
+ gpio_mapping = acpi_goodix_int_last_gpios;
++ } else if (ts->gpio_count == 1 && ts->gpio_int_idx == 0) {
++ /*
++ * On newer devices there is only 1 GpioInt resource and _PS0
++ * does the whole reset sequence for us.
++ */
++ acpi_device_fix_up_power(ACPI_COMPANION(dev));
++
++ /*
++ * Before the _PS0 call the int GPIO may have been in output
++ * mode and the call should have put the int GPIO in input mode,
++ * but the GPIO subsys cached state may still think it is
++ * in output mode, causing gpiochip_lock_as_irq() failure.
++ *
++ * Add a mapping for the int GPIO to make the
++ * gpiod_int = gpiod_get(..., GPIOD_IN) call succeed,
++ * which will explicitly set the direction to input.
++ */
++ ts->irq_pin_access_method = IRQ_PIN_ACCESS_NONE;
++ gpio_mapping = acpi_goodix_int_first_gpios;
+ } else {
+ dev_warn(dev, "Unexpected ACPI resources: gpio_count %d, gpio_int_idx %d\n",
+ ts->gpio_count, ts->gpio_int_idx);
--- /dev/null
+From 80f39e1c27ba9e5a1ea7e68e21c569c9d8e46062 Mon Sep 17 00:00:00 2001
+From: Szilard Fabian <szfabian@bluemarch.art>
+Date: Wed, 4 Oct 2023 05:47:01 -0700
+Subject: Input: i8042 - add Fujitsu Lifebook E5411 to i8042 quirk table
+
+From: Szilard Fabian <szfabian@bluemarch.art>
+
+commit 80f39e1c27ba9e5a1ea7e68e21c569c9d8e46062 upstream.
+
+In the initial boot stage the integrated keyboard of Fujitsu Lifebook E5411
+refuses to work and it's not possible to type for example a dm-crypt
+passphrase without the help of an external keyboard.
+
+i8042.nomux kernel parameter resolves this issue but using that a PS/2
+mouse is detected. This input device is unused even when the i2c-hid-acpi
+kernel module is blacklisted making the integrated ELAN touchpad
+(04F3:308A) not working at all.
+
+Since the integrated touchpad is managed by the i2c_designware input
+driver in the Linux kernel and you can't find a PS/2 mouse port on the
+computer I think it's safe to not use the PS/2 mouse port at all.
+
+Signed-off-by: Szilard Fabian <szfabian@bluemarch.art>
+Link: https://lore.kernel.org/r/20231004011749.101789-1-szfabian@bluemarch.art
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/input/serio/i8042-acpipnpio.h | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/input/serio/i8042-acpipnpio.h
++++ b/drivers/input/serio/i8042-acpipnpio.h
+@@ -619,6 +619,14 @@ static const struct dmi_system_id i8042_
+ .driver_data = (void *)(SERIO_QUIRK_NOMUX)
+ },
+ {
++ /* Fujitsu Lifebook E5411 */
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU CLIENT COMPUTING LIMITED"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK E5411"),
++ },
++ .driver_data = (void *)(SERIO_QUIRK_NOAUX)
++ },
++ {
+ /* Gigabyte M912 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
--- /dev/null
+From 5c15c60e7be615f05a45cd905093a54b11f461bc Mon Sep 17 00:00:00 2001
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Date: Fri, 13 Oct 2023 20:11:33 -0700
+Subject: Input: powermate - fix use-after-free in powermate_config_complete
+
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+commit 5c15c60e7be615f05a45cd905093a54b11f461bc upstream.
+
+syzbot has found a use-after-free bug [1] in the powermate driver. This
+happens when the device is disconnected, which leads to a memory free from
+the powermate_device struct. When an asynchronous control message
+completes after the kfree and its callback is invoked, the lock does not
+exist anymore and hence the bug.
+
+Use usb_kill_urb() on pm->config to cancel any in-progress requests upon
+device disconnection.
+
+[1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e
+
+Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Reported-by: syzbot+0434ac83f907a1dbdd1e@syzkaller.appspotmail.com
+Link: https://lore.kernel.org/r/20230916-topic-powermate_use_after_free-v3-1-64412b81a7a2@gmail.com
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/input/misc/powermate.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/input/misc/powermate.c
++++ b/drivers/input/misc/powermate.c
+@@ -425,6 +425,7 @@ static void powermate_disconnect(struct
+ pm->requires_update = 0;
+ usb_kill_urb(pm->irq);
+ input_unregister_device(pm->input);
++ usb_kill_urb(pm->config);
+ usb_free_urb(pm->irq);
+ usb_free_urb(pm->config);
+ powermate_free_buffers(interface_to_usbdev(intf), pm);
--- /dev/null
+From e2cb5cc822b6c9ee72c56ce1d81671b22c05406a Mon Sep 17 00:00:00 2001
+From: Jeffery Miller <jefferymiller@google.com>
+Date: Fri, 13 Oct 2023 15:23:49 -0700
+Subject: Input: psmouse - fix fast_reconnect function for PS/2 mode
+
+From: Jeffery Miller <jefferymiller@google.com>
+
+commit e2cb5cc822b6c9ee72c56ce1d81671b22c05406a upstream.
+
+When the SMBus connection is attempted psmouse_smbus_init() sets
+the fast_reconnect pointer to psmouse_smbus_reconnecti(). If SMBus
+initialization fails, elantech_setup_ps2() and synaptics_init_ps2() will
+fallback to PS/2 mode, replacing the psmouse private data. This can cause
+issues on resume, since psmouse_smbus_reconnect() expects to find an
+instance of struct psmouse_smbus_dev in psmouse->private.
+
+The issue was uncovered when in 92e24e0e57f7 ("Input: psmouse - add
+delay when deactivating for SMBus mode") psmouse_smbus_reconnect()
+started attempting to use more of the data structure. The commit was
+since reverted, not because it was at fault, but because there was found
+a better way of doing what it was attempting to do.
+
+Fix the problem by resetting the fast_reconnect pointer in psmouse
+structure in elantech_setup_ps2() and synaptics_init_ps2() when the PS/2
+mode is used.
+
+Reported-by: Thorsten Leemhuis <linux@leemhuis.info>
+Tested-by: Thorsten Leemhuis <linux@leemhuis.info>
+Signed-off-by: Jeffery Miller <jefferymiller@google.com>
+Fixes: bf232e460a35 ("Input: psmouse-smbus - allow to control psmouse_deactivate")
+Link: https://lore.kernel.org/r/20231005002249.554877-1-jefferymiller@google.com
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/input/mouse/elantech.c | 1 +
+ drivers/input/mouse/synaptics.c | 1 +
+ 2 files changed, 2 insertions(+)
+
+--- a/drivers/input/mouse/elantech.c
++++ b/drivers/input/mouse/elantech.c
+@@ -2114,6 +2114,7 @@ static int elantech_setup_ps2(struct psm
+ psmouse->protocol_handler = elantech_process_byte;
+ psmouse->disconnect = elantech_disconnect;
+ psmouse->reconnect = elantech_reconnect;
++ psmouse->fast_reconnect = NULL;
+ psmouse->pktsize = info->hw_version > 1 ? 6 : 4;
+
+ return 0;
+--- a/drivers/input/mouse/synaptics.c
++++ b/drivers/input/mouse/synaptics.c
+@@ -1623,6 +1623,7 @@ static int synaptics_init_ps2(struct psm
+ psmouse->set_rate = synaptics_set_rate;
+ psmouse->disconnect = synaptics_disconnect;
+ psmouse->reconnect = synaptics_reconnect;
++ psmouse->fast_reconnect = NULL;
+ psmouse->cleanup = synaptics_reset;
+ /* Synaptics can usually stay in sync without extra help */
+ psmouse->resync_time = 0;
--- /dev/null
+From a65cd7ef5a864bdbbe037267c327786b7759d4c6 Mon Sep 17 00:00:00 2001
+From: Matthias Berndt <matthias_berndt@gmx.de>
+Date: Fri, 13 Oct 2023 15:04:36 -0700
+Subject: Input: xpad - add PXN V900 support
+
+From: Matthias Berndt <matthias_berndt@gmx.de>
+
+commit a65cd7ef5a864bdbbe037267c327786b7759d4c6 upstream.
+
+Add VID and PID to the xpad_device table to allow driver to use the PXN
+V900 steering wheel, which is XTYPE_XBOX360 compatible in xinput mode.
+
+Signed-off-by: Matthias Berndt <matthias_berndt@gmx.de>
+Link: https://lore.kernel.org/r/4932699.31r3eYUQgx@fedora
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/input/joystick/xpad.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/input/joystick/xpad.c
++++ b/drivers/input/joystick/xpad.c
+@@ -272,6 +272,7 @@ static const struct xpad_device {
+ { 0x1038, 0x1430, "SteelSeries Stratus Duo", 0, XTYPE_XBOX360 },
+ { 0x1038, 0x1431, "SteelSeries Stratus Duo", 0, XTYPE_XBOX360 },
+ { 0x11c9, 0x55f0, "Nacon GC-100XF", 0, XTYPE_XBOX360 },
++ { 0x11ff, 0x0511, "PXN V900", 0, XTYPE_XBOX360 },
+ { 0x1209, 0x2882, "Ardwiino Controller", 0, XTYPE_XBOX360 },
+ { 0x12ab, 0x0004, "Honey Bee Xbox360 dancepad", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360 },
+ { 0x12ab, 0x0301, "PDP AFTERGLOW AX.1", 0, XTYPE_XBOX360 },
+@@ -474,6 +475,7 @@ static const struct usb_device_id xpad_t
+ XPAD_XBOXONE_VENDOR(0x0f0d), /* Hori Controllers */
+ XPAD_XBOX360_VENDOR(0x1038), /* SteelSeries Controllers */
+ XPAD_XBOX360_VENDOR(0x11c9), /* Nacon GC100XF */
++ XPAD_XBOX360_VENDOR(0x11ff), /* PXN V900 */
+ XPAD_XBOX360_VENDOR(0x1209), /* Ardwiino Controllers */
+ XPAD_XBOX360_VENDOR(0x12ab), /* X-Box 360 dance pads */
+ XPAD_XBOX360_VENDOR(0x1430), /* RedOctane X-Box 360 controllers */
--- /dev/null
+From f43328357defc0dc9d28dbd06dc3361fd2b22e28 Mon Sep 17 00:00:00 2001
+From: Namjae Jeon <linkinjeon@kernel.org>
+Date: Fri, 6 Oct 2023 10:41:36 +0900
+Subject: ksmbd: not allow to open file if delelete on close bit is set
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Namjae Jeon <linkinjeon@kernel.org>
+
+commit f43328357defc0dc9d28dbd06dc3361fd2b22e28 upstream.
+
+Cthon test fail with the following error.
+
+check for proper open/unlink operation
+nfsjunk files before unlink:
+ -rwxr-xr-x 1 root root 0 9월 25 11:03 ./nfs2y8Jm9
+./nfs2y8Jm9 open; unlink ret = 0
+nfsjunk files after unlink:
+ -rwxr-xr-x 1 root root 0 9월 25 11:03 ./nfs2y8Jm9
+data compare ok
+nfsjunk files after close:
+ ls: cannot access './nfs2y8Jm9': No such file or directory
+special tests failed
+
+Cthon expect to second unlink failure when file is already unlinked.
+ksmbd can not allow to open file if flags of ksmbd inode is set with
+S_DEL_ON_CLS flags.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/server/vfs_cache.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/smb/server/vfs_cache.c
++++ b/fs/smb/server/vfs_cache.c
+@@ -105,7 +105,7 @@ int ksmbd_query_inode_status(struct inod
+ ci = __ksmbd_inode_lookup(inode);
+ if (ci) {
+ ret = KSMBD_INODE_STATUS_OK;
+- if (ci->m_flags & S_DEL_PENDING)
++ if (ci->m_flags & (S_DEL_PENDING | S_DEL_ON_CLS))
+ ret = KSMBD_INODE_STATUS_PENDING_DELETE;
+ atomic_dec(&ci->m_count);
+ }
+@@ -115,7 +115,7 @@ int ksmbd_query_inode_status(struct inod
+
+ bool ksmbd_inode_pending_delete(struct ksmbd_file *fp)
+ {
+- return (fp->f_ci->m_flags & S_DEL_PENDING);
++ return (fp->f_ci->m_flags & (S_DEL_PENDING | S_DEL_ON_CLS));
+ }
+
+ void ksmbd_set_inode_pending_delete(struct ksmbd_file *fp)
--- /dev/null
+From 7563cf17dce0a875ba3d872acdc63a78ea344019 Mon Sep 17 00:00:00 2001
+From: Jordan Rife <jrife@google.com>
+Date: Wed, 4 Oct 2023 18:38:27 -0500
+Subject: libceph: use kernel_connect()
+
+From: Jordan Rife <jrife@google.com>
+
+commit 7563cf17dce0a875ba3d872acdc63a78ea344019 upstream.
+
+Direct calls to ops->connect() can overwrite the address parameter when
+used in conjunction with BPF SOCK_ADDR hooks. Recent changes to
+kernel_connect() ensure that callers are insulated from such side
+effects. This patch wraps the direct call to ops->connect() with
+kernel_connect() to prevent unexpected changes to the address passed to
+ceph_tcp_connect().
+
+This change was originally part of a larger patch targeting the net tree
+addressing all instances of unprotected calls to ops->connect()
+throughout the kernel, but this change was split up into several patches
+targeting various trees.
+
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/netdev/20230821100007.559638-1-jrife@google.com/
+Link: https://lore.kernel.org/netdev/9944248dba1bce861375fcce9de663934d933ba9.camel@redhat.com/
+Fixes: d74bad4e74ee ("bpf: Hooks for sys_connect")
+Signed-off-by: Jordan Rife <jrife@google.com>
+Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ceph/messenger.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/net/ceph/messenger.c
++++ b/net/ceph/messenger.c
+@@ -454,8 +454,8 @@ int ceph_tcp_connect(struct ceph_connect
+ set_sock_callbacks(sock, con);
+
+ con_sock_state_connecting(con);
+- ret = sock->ops->connect(sock, (struct sockaddr *)&ss, sizeof(ss),
+- O_NONBLOCK);
++ ret = kernel_connect(sock, (struct sockaddr *)&ss, sizeof(ss),
++ O_NONBLOCK);
+ if (ret == -EINPROGRESS) {
+ dout("connect %s EINPROGRESS sk_state = %u\n",
+ ceph_pr_addr(&con->peer_addr),
--- /dev/null
+From 0f28ada1fbf0054557cddcdb93ad17f767105208 Mon Sep 17 00:00:00 2001
+From: Jorge Sanjuan Garcia <jorge.sanjuangarcia@duagon.com>
+Date: Wed, 6 Sep 2023 11:49:26 +0000
+Subject: mcb: remove is_added flag from mcb_device struct
+
+From: Jorge Sanjuan Garcia <jorge.sanjuangarcia@duagon.com>
+
+commit 0f28ada1fbf0054557cddcdb93ad17f767105208 upstream.
+
+When calling mcb_bus_add_devices(), both mcb devices and the mcb
+bus will attempt to attach a device to a driver because they share
+the same bus_type. This causes an issue when trying to cast the
+container of the device to mcb_device struct using to_mcb_device(),
+leading to a wrong cast when the mcb_bus is added. A crash occurs
+when freing the ida resources as the bus numbering of mcb_bus gets
+confused with the is_added flag on the mcb_device struct.
+
+The only reason for this cast was to keep an is_added flag on the
+mcb_device struct that does not seem necessary. The function
+device_attach() handles already bound devices and the mcb subsystem
+does nothing special with this is_added flag so remove it completely.
+
+Fixes: 18d288198099 ("mcb: Correctly initialize the bus's device")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Jorge Sanjuan Garcia <jorge.sanjuangarcia@duagon.com>
+Co-developed-by: Jose Javier Rodriguez Barbarin <JoseJavier.Rodriguez@duagon.com>
+Signed-off-by: Jose Javier Rodriguez Barbarin <JoseJavier.Rodriguez@duagon.com>
+Link: https://lore.kernel.org/r/20230906114901.63174-2-JoseJavier.Rodriguez@duagon.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mcb/mcb-core.c | 10 +++-------
+ drivers/mcb/mcb-parse.c | 2 --
+ include/linux/mcb.h | 1 -
+ 3 files changed, 3 insertions(+), 10 deletions(-)
+
+--- a/drivers/mcb/mcb-core.c
++++ b/drivers/mcb/mcb-core.c
+@@ -387,17 +387,13 @@ EXPORT_SYMBOL_NS_GPL(mcb_free_dev, MCB);
+
+ static int __mcb_bus_add_devices(struct device *dev, void *data)
+ {
+- struct mcb_device *mdev = to_mcb_device(dev);
+ int retval;
+
+- if (mdev->is_added)
+- return 0;
+-
+ retval = device_attach(dev);
+- if (retval < 0)
++ if (retval < 0) {
+ dev_err(dev, "Error adding device (%d)\n", retval);
+-
+- mdev->is_added = true;
++ return retval;
++ }
+
+ return 0;
+ }
+--- a/drivers/mcb/mcb-parse.c
++++ b/drivers/mcb/mcb-parse.c
+@@ -99,8 +99,6 @@ static int chameleon_parse_gdd(struct mc
+ mdev->mem.end = mdev->mem.start + size - 1;
+ mdev->mem.flags = IORESOURCE_MEM;
+
+- mdev->is_added = false;
+-
+ ret = mcb_device_register(bus, mdev);
+ if (ret < 0)
+ goto err;
+--- a/include/linux/mcb.h
++++ b/include/linux/mcb.h
+@@ -63,7 +63,6 @@ static inline struct mcb_bus *to_mcb_bus
+ struct mcb_device {
+ struct device dev;
+ struct mcb_bus *bus;
+- bool is_added;
+ struct mcb_driver *driver;
+ u16 id;
+ int inst;
--- /dev/null
+From 5093bbfc10ab6636b32728e35813cbd79feb063c Mon Sep 17 00:00:00 2001
+From: Jeremy Kerr <jk@codeconstruct.com.au>
+Date: Mon, 9 Oct 2023 15:56:45 +0800
+Subject: mctp: perform route lookups under a RCU read-side lock
+
+From: Jeremy Kerr <jk@codeconstruct.com.au>
+
+commit 5093bbfc10ab6636b32728e35813cbd79feb063c upstream.
+
+Our current route lookups (mctp_route_lookup and mctp_route_lookup_null)
+traverse the net's route list without the RCU read lock held. This means
+the route lookup is subject to preemption, resulting in an potential
+grace period expiry, and so an eventual kfree() while we still have the
+route pointer.
+
+Add the proper read-side critical section locks around the route
+lookups, preventing premption and a possible parallel kfree.
+
+The remaining net->mctp.routes accesses are already under a
+rcu_read_lock, or protected by the RTNL for updates.
+
+Based on an analysis from Sili Luo <rootlab@huawei.com>, where
+introducing a delay in the route lookup could cause a UAF on
+simultaneous sendmsg() and route deletion.
+
+Reported-by: Sili Luo <rootlab@huawei.com>
+Fixes: 889b7da23abf ("mctp: Add initial routing framework")
+Cc: stable@vger.kernel.org
+Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Link: https://lore.kernel.org/r/29c4b0e67dc1bf3571df3982de87df90cae9b631.1696837310.git.jk@codeconstruct.com.au
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mctp/route.c | 22 ++++++++++++++++------
+ 1 file changed, 16 insertions(+), 6 deletions(-)
+
+--- a/net/mctp/route.c
++++ b/net/mctp/route.c
+@@ -737,6 +737,8 @@ struct mctp_route *mctp_route_lookup(str
+ {
+ struct mctp_route *tmp, *rt = NULL;
+
++ rcu_read_lock();
++
+ list_for_each_entry_rcu(tmp, &net->mctp.routes, list) {
+ /* TODO: add metrics */
+ if (mctp_rt_match_eid(tmp, dnet, daddr)) {
+@@ -747,21 +749,29 @@ struct mctp_route *mctp_route_lookup(str
+ }
+ }
+
++ rcu_read_unlock();
++
+ return rt;
+ }
+
+ static struct mctp_route *mctp_route_lookup_null(struct net *net,
+ struct net_device *dev)
+ {
+- struct mctp_route *rt;
++ struct mctp_route *tmp, *rt = NULL;
++
++ rcu_read_lock();
+
+- list_for_each_entry_rcu(rt, &net->mctp.routes, list) {
+- if (rt->dev->dev == dev && rt->type == RTN_LOCAL &&
+- refcount_inc_not_zero(&rt->refs))
+- return rt;
++ list_for_each_entry_rcu(tmp, &net->mctp.routes, list) {
++ if (tmp->dev->dev == dev && tmp->type == RTN_LOCAL &&
++ refcount_inc_not_zero(&tmp->refs)) {
++ rt = tmp;
++ break;
++ }
+ }
+
+- return NULL;
++ rcu_read_unlock();
++
++ return rt;
+ }
+
+ static int mctp_do_fragment_route(struct mctp_route *rt, struct sk_buff *skb,
--- /dev/null
+From 8f8abb863fa5a4cc18955c6a0e17af0ded3e4a76 Mon Sep 17 00:00:00 2001
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Date: Tue, 10 Oct 2023 00:26:14 +0200
+Subject: net: usb: dm9601: fix uninitialized variable use in dm9601_mdio_read
+
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+commit 8f8abb863fa5a4cc18955c6a0e17af0ded3e4a76 upstream.
+
+syzbot has found an uninit-value bug triggered by the dm9601 driver [1].
+
+This error happens because the variable res is not updated if the call
+to dm_read_shared_word returns an error. In this particular case -EPROTO
+was returned and res stayed uninitialized.
+
+This can be avoided by checking the return value of dm_read_shared_word
+and propagating the error if the read operation failed.
+
+[1] https://syzkaller.appspot.com/bug?extid=1f53a30781af65d2c955
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Reported-and-tested-by: syzbot+1f53a30781af65d2c955@syzkaller.appspotmail.com
+Acked-by: Peter Korsgaard <peter@korsgaard.com>
+Fixes: d0374f4f9c35cdfbee0 ("USB: Davicom DM9601 usbnet driver")
+Link: https://lore.kernel.org/r/20231009-topic-dm9601_uninit_mdio_read-v2-1-f2fe39739b6c@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/usb/dm9601.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/usb/dm9601.c
++++ b/drivers/net/usb/dm9601.c
+@@ -222,13 +222,18 @@ static int dm9601_mdio_read(struct net_d
+ struct usbnet *dev = netdev_priv(netdev);
+
+ __le16 res;
++ int err;
+
+ if (phy_id) {
+ netdev_dbg(dev->net, "Only internal phy supported\n");
+ return 0;
+ }
+
+- dm_read_shared_word(dev, 1, loc, &res);
++ err = dm_read_shared_word(dev, 1, loc, &res);
++ if (err < 0) {
++ netdev_err(dev->net, "MDIO read error: %d\n", err);
++ return err;
++ }
+
+ netdev_dbg(dev->net,
+ "dm9601_mdio_read() phy_id=0x%02x, loc=0x%02x, returns=0x%04x\n",
--- /dev/null
+From 14690995c14109852c7ba6e316045c02e4254272 Mon Sep 17 00:00:00 2001
+From: Yanguo Li <yanguo.li@corigine.com>
+Date: Mon, 9 Oct 2023 13:21:55 +0200
+Subject: nfp: flower: avoid rmmod nfp crash issues
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Yanguo Li <yanguo.li@corigine.com>
+
+commit 14690995c14109852c7ba6e316045c02e4254272 upstream.
+
+When there are CT table entries, and you rmmod nfp, the following
+events can happen:
+
+task1：
+ nfp_net_pci_remove
+ ↓
+ nfp_flower_stop->(asynchronous)tcf_ct_flow_table_cleanup_work(3)
+ ↓
+ nfp_zone_table_entry_destroy(1)
+
+task2：
+ nfp_fl_ct_handle_nft_flow(2)
+
+When the execution order is (1)->(2)->(3), it will crash. Therefore, in
+the function nfp_fl_ct_del_flow, nf_flow_table_offload_del_cb needs to
+be executed synchronously.
+
+At the same time, in order to solve the deadlock problem and the problem
+of rtnl_lock sometimes failing, replace rtnl_lock with the private
+nfp_fl_lock.
+
+Fixes: 7cc93d888df7 ("nfp: flower-ct: remove callback delete deadlock")
+Cc: stable@vger.kernel.org
+Signed-off-by: Yanguo Li <yanguo.li@corigine.com>
+Signed-off-by: Louis Peens <louis.peens@corigine.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/netronome/nfp/flower/cmsg.c | 10 ++++---
+ drivers/net/ethernet/netronome/nfp/flower/conntrack.c | 19 +++++++++-----
+ drivers/net/ethernet/netronome/nfp/flower/main.h | 2 +
+ drivers/net/ethernet/netronome/nfp/flower/metadata.c | 2 +
+ drivers/net/ethernet/netronome/nfp/flower/offload.c | 24 +++++++++++++-----
+ drivers/net/ethernet/netronome/nfp/flower/qos_conf.c | 20 +++++++++------
+ 6 files changed, 54 insertions(+), 23 deletions(-)
+
+--- a/drivers/net/ethernet/netronome/nfp/flower/cmsg.c
++++ b/drivers/net/ethernet/netronome/nfp/flower/cmsg.c
+@@ -210,6 +210,7 @@ nfp_flower_cmsg_merge_hint_rx(struct nfp
+ unsigned int msg_len = nfp_flower_cmsg_get_data_len(skb);
+ struct nfp_flower_cmsg_merge_hint *msg;
+ struct nfp_fl_payload *sub_flows[2];
++ struct nfp_flower_priv *priv;
+ int err, i, flow_cnt;
+
+ msg = nfp_flower_cmsg_get_data(skb);
+@@ -228,14 +229,15 @@ nfp_flower_cmsg_merge_hint_rx(struct nfp
+ return;
+ }
+
+- rtnl_lock();
++ priv = app->priv;
++ mutex_lock(&priv->nfp_fl_lock);
+ for (i = 0; i < flow_cnt; i++) {
+ u32 ctx = be32_to_cpu(msg->flow[i].host_ctx);
+
+ sub_flows[i] = nfp_flower_get_fl_payload_from_ctx(app, ctx);
+ if (!sub_flows[i]) {
+ nfp_flower_cmsg_warn(app, "Invalid flow in merge hint\n");
+- goto err_rtnl_unlock;
++ goto err_mutex_unlock;
+ }
+ }
+
+@@ -244,8 +246,8 @@ nfp_flower_cmsg_merge_hint_rx(struct nfp
+ if (err == -ENOMEM)
+ nfp_flower_cmsg_warn(app, "Flow merge memory fail.\n");
+
+-err_rtnl_unlock:
+- rtnl_unlock();
++err_mutex_unlock:
++ mutex_unlock(&priv->nfp_fl_lock);
+ }
+
+ static void
+--- a/drivers/net/ethernet/netronome/nfp/flower/conntrack.c
++++ b/drivers/net/ethernet/netronome/nfp/flower/conntrack.c
+@@ -1971,8 +1971,6 @@ nfp_fl_ct_offload_nft_flow(struct nfp_fl
+ struct nfp_fl_ct_flow_entry *ct_entry;
+ struct netlink_ext_ack *extack = NULL;
+
+- ASSERT_RTNL();
+-
+ extack = flow->common.extack;
+ switch (flow->command) {
+ case FLOW_CLS_REPLACE:
+@@ -2015,9 +2013,13 @@ int nfp_fl_ct_handle_nft_flow(enum tc_se
+
+ switch (type) {
+ case TC_SETUP_CLSFLOWER:
+- rtnl_lock();
++ while (!mutex_trylock(&zt->priv->nfp_fl_lock)) {
++ if (!zt->nft) /* avoid deadlock */
++ return err;
++ msleep(20);
++ }
+ err = nfp_fl_ct_offload_nft_flow(zt, flow);
+- rtnl_unlock();
++ mutex_unlock(&zt->priv->nfp_fl_lock);
+ break;
+ default:
+ return -EOPNOTSUPP;
+@@ -2045,6 +2047,7 @@ int nfp_fl_ct_del_flow(struct nfp_fl_ct_
+ struct nfp_fl_ct_flow_entry *ct_entry;
+ struct nfp_fl_ct_zone_entry *zt;
+ struct rhashtable *m_table;
++ struct nf_flowtable *nft;
+
+ if (!ct_map_ent)
+ return -ENOENT;
+@@ -2061,8 +2064,12 @@ int nfp_fl_ct_del_flow(struct nfp_fl_ct_
+ nfp_fl_ct_clean_flow_entry(ct_entry);
+ kfree(ct_map_ent);
+
+- if (!zt->pre_ct_count) {
+- zt->nft = NULL;
++ if (!zt->pre_ct_count && zt->nft) {
++ nft = zt->nft;
++ zt->nft = NULL; /* avoid deadlock */
++ nf_flow_table_offload_del_cb(nft,
++ nfp_fl_ct_handle_nft_flow,
++ zt);
+ nfp_fl_ct_clean_nft_entries(zt);
+ }
+ break;
+--- a/drivers/net/ethernet/netronome/nfp/flower/main.h
++++ b/drivers/net/ethernet/netronome/nfp/flower/main.h
+@@ -281,6 +281,7 @@ struct nfp_fl_internal_ports {
+ * @predt_list: List to keep track of decap pretun flows
+ * @neigh_table: Table to keep track of neighbor entries
+ * @predt_lock: Lock to serialise predt/neigh table updates
++ * @nfp_fl_lock: Lock to protect the flow offload operation
+ */
+ struct nfp_flower_priv {
+ struct nfp_app *app;
+@@ -323,6 +324,7 @@ struct nfp_flower_priv {
+ struct list_head predt_list;
+ struct rhashtable neigh_table;
+ spinlock_t predt_lock; /* Lock to serialise predt/neigh table updates */
++ struct mutex nfp_fl_lock; /* Protect the flow operation */
+ };
+
+ /**
+--- a/drivers/net/ethernet/netronome/nfp/flower/metadata.c
++++ b/drivers/net/ethernet/netronome/nfp/flower/metadata.c
+@@ -528,6 +528,8 @@ int nfp_flower_metadata_init(struct nfp_
+ if (err)
+ goto err_free_stats_ctx_table;
+
++ mutex_init(&priv->nfp_fl_lock);
++
+ err = rhashtable_init(&priv->ct_zone_table, &nfp_zone_table_params);
+ if (err)
+ goto err_free_merge_table;
+--- a/drivers/net/ethernet/netronome/nfp/flower/offload.c
++++ b/drivers/net/ethernet/netronome/nfp/flower/offload.c
+@@ -1009,8 +1009,6 @@ int nfp_flower_merge_offloaded_flows(str
+ u64 parent_ctx = 0;
+ int err;
+
+- ASSERT_RTNL();
+-
+ if (sub_flow1 == sub_flow2 ||
+ nfp_flower_is_merge_flow(sub_flow1) ||
+ nfp_flower_is_merge_flow(sub_flow2))
+@@ -1727,19 +1725,30 @@ static int
+ nfp_flower_repr_offload(struct nfp_app *app, struct net_device *netdev,
+ struct flow_cls_offload *flower)
+ {
++ struct nfp_flower_priv *priv = app->priv;
++ int ret;
++
+ if (!eth_proto_is_802_3(flower->common.protocol))
+ return -EOPNOTSUPP;
+
++ mutex_lock(&priv->nfp_fl_lock);
+ switch (flower->command) {
+ case FLOW_CLS_REPLACE:
+- return nfp_flower_add_offload(app, netdev, flower);
++ ret = nfp_flower_add_offload(app, netdev, flower);
++ break;
+ case FLOW_CLS_DESTROY:
+- return nfp_flower_del_offload(app, netdev, flower);
++ ret = nfp_flower_del_offload(app, netdev, flower);
++ break;
+ case FLOW_CLS_STATS:
+- return nfp_flower_get_stats(app, netdev, flower);
++ ret = nfp_flower_get_stats(app, netdev, flower);
++ break;
+ default:
+- return -EOPNOTSUPP;
++ ret = -EOPNOTSUPP;
++ break;
+ }
++ mutex_unlock(&priv->nfp_fl_lock);
++
++ return ret;
+ }
+
+ static int nfp_flower_setup_tc_block_cb(enum tc_setup_type type,
+@@ -1778,6 +1787,7 @@ static int nfp_flower_setup_tc_block(str
+ repr_priv = repr->app_priv;
+ repr_priv->block_shared = f->block_shared;
+ f->driver_block_list = &nfp_block_cb_list;
++ f->unlocked_driver_cb = true;
+
+ switch (f->command) {
+ case FLOW_BLOCK_BIND:
+@@ -1876,6 +1886,8 @@ nfp_flower_setup_indr_tc_block(struct ne
+ nfp_flower_internal_port_can_offload(app, netdev)))
+ return -EOPNOTSUPP;
+
++ f->unlocked_driver_cb = true;
++
+ switch (f->command) {
+ case FLOW_BLOCK_BIND:
+ cb_priv = nfp_flower_indr_block_cb_priv_lookup(app, netdev);
+--- a/drivers/net/ethernet/netronome/nfp/flower/qos_conf.c
++++ b/drivers/net/ethernet/netronome/nfp/flower/qos_conf.c
+@@ -523,25 +523,31 @@ int nfp_flower_setup_qos_offload(struct
+ {
+ struct netlink_ext_ack *extack = flow->common.extack;
+ struct nfp_flower_priv *fl_priv = app->priv;
++ int ret;
+
+ if (!(fl_priv->flower_ext_feats & NFP_FL_FEATS_VF_RLIM)) {
+ NL_SET_ERR_MSG_MOD(extack, "unsupported offload: loaded firmware does not support qos rate limit offload");
+ return -EOPNOTSUPP;
+ }
+
++ mutex_lock(&fl_priv->nfp_fl_lock);
+ switch (flow->command) {
+ case TC_CLSMATCHALL_REPLACE:
+- return nfp_flower_install_rate_limiter(app, netdev, flow,
+- extack);
++ ret = nfp_flower_install_rate_limiter(app, netdev, flow, extack);
++ break;
+ case TC_CLSMATCHALL_DESTROY:
+- return nfp_flower_remove_rate_limiter(app, netdev, flow,
+- extack);
++ ret = nfp_flower_remove_rate_limiter(app, netdev, flow, extack);
++ break;
+ case TC_CLSMATCHALL_STATS:
+- return nfp_flower_stats_rate_limiter(app, netdev, flow,
+- extack);
++ ret = nfp_flower_stats_rate_limiter(app, netdev, flow, extack);
++ break;
+ default:
+- return -EOPNOTSUPP;
++ ret = -EOPNOTSUPP;
++ break;
+ }
++ mutex_unlock(&fl_priv->nfp_fl_lock);
++
++ return ret;
+ }
+
+ /* Offload tc action, currently only for tc police */
--- /dev/null
+From e53899771a02f798d436655efbd9d4b46c0f9265 Mon Sep 17 00:00:00 2001
+From: JP Kobryn <inwardvessel@gmail.com>
+Date: Fri, 6 Oct 2023 11:57:26 -0700
+Subject: perf/x86/lbr: Filter vsyscall addresses
+
+From: JP Kobryn <inwardvessel@gmail.com>
+
+commit e53899771a02f798d436655efbd9d4b46c0f9265 upstream.
+
+We found that a panic can occur when a vsyscall is made while LBR sampling
+is active. If the vsyscall is interrupted (NMI) for perf sampling, this
+call sequence can occur (most recent at top):
+
+ __insn_get_emulate_prefix()
+ insn_get_emulate_prefix()
+ insn_get_prefixes()
+ insn_get_opcode()
+ decode_branch_type()
+ get_branch_type()
+ intel_pmu_lbr_filter()
+ intel_pmu_handle_irq()
+ perf_event_nmi_handler()
+
+Within __insn_get_emulate_prefix() at frame 0, a macro is called:
+
+ peek_nbyte_next(insn_byte_t, insn, i)
+
+Within this macro, this dereference occurs:
+
+ (insn)->next_byte
+
+Inspecting registers at this point, the value of the next_byte field is the
+address of the vsyscall made, for example the location of the vsyscall
+version of gettimeofday() at 0xffffffffff600000. The access to an address
+in the vsyscall region will trigger an oops due to an unhandled page fault.
+
+To fix the bug, filtering for vsyscalls can be done when
+determining the branch type. This patch will return
+a "none" branch if a kernel address if found to lie in the
+vsyscall region.
+
+Suggested-by: Alexei Starovoitov <ast@kernel.org>
+Signed-off-by: JP Kobryn <inwardvessel@gmail.com>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/events/utils.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/events/utils.c
++++ b/arch/x86/events/utils.c
+@@ -1,5 +1,6 @@
+ // SPDX-License-Identifier: GPL-2.0
+ #include <asm/insn.h>
++#include <linux/mm.h>
+
+ #include "perf_event.h"
+
+@@ -132,9 +133,9 @@ static int get_branch_type(unsigned long
+ * The LBR logs any address in the IP, even if the IP just
+ * faulted. This means userspace can control the from address.
+ * Ensure we don't blindly read any address by validating it is
+- * a known text address.
++ * a known text address and not a vsyscall address.
+ */
+- if (kernel_text_address(from)) {
++ if (kernel_text_address(from) && !in_gate_area_no_mm(from)) {
+ addr = (void *)from;
+ /*
+ * Assume we can get the maximum possible size
--- /dev/null
+From c153a4edff6ab01370fcac8e46f9c89cca1060c2 Mon Sep 17 00:00:00 2001
+From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Date: Wed, 20 Sep 2023 11:09:10 -0700
+Subject: pinctrl: avoid unsafe code pattern in find_pinctrl()
+
+From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+
+commit c153a4edff6ab01370fcac8e46f9c89cca1060c2 upstream.
+
+The code in find_pinctrl() takes a mutex and traverses a list of pinctrl
+structures. Later the caller bumps up reference count on the found
+structure. Such pattern is not safe as pinctrl that was found may get
+deleted before the caller gets around to increasing the reference count.
+
+Fix this by taking the reference count in find_pinctrl(), while it still
+holds the mutex.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Link: https://lore.kernel.org/r/ZQs1RgTKg6VJqmPs@google.com
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pinctrl/core.c | 16 +++++++++-------
+ 1 file changed, 9 insertions(+), 7 deletions(-)
+
+--- a/drivers/pinctrl/core.c
++++ b/drivers/pinctrl/core.c
+@@ -1007,17 +1007,20 @@ static int add_setting(struct pinctrl *p
+
+ static struct pinctrl *find_pinctrl(struct device *dev)
+ {
+- struct pinctrl *p;
++ struct pinctrl *entry, *p = NULL;
+
+ mutex_lock(&pinctrl_list_mutex);
+- list_for_each_entry(p, &pinctrl_list, node)
+- if (p->dev == dev) {
+- mutex_unlock(&pinctrl_list_mutex);
+- return p;
++
++ list_for_each_entry(entry, &pinctrl_list, node) {
++ if (entry->dev == dev) {
++ p = entry;
++ kref_get(&p->users);
++ break;
+ }
++ }
+
+ mutex_unlock(&pinctrl_list_mutex);
+- return NULL;
++ return p;
+ }
+
+ static void pinctrl_free(struct pinctrl *p, bool inlist);
+@@ -1126,7 +1129,6 @@ struct pinctrl *pinctrl_get(struct devic
+ p = find_pinctrl(dev);
+ if (p) {
+ dev_dbg(dev, "obtain a copy of previously claimed pinctrl\n");
+- kref_get(&p->users);
+ return p;
+ }
+
--- /dev/null
+From f0eee815babed70a749d2496a7678be5b45b4c14 Mon Sep 17 00:00:00 2001
+From: Michael Ellerman <mpe@ellerman.id.au>
+Date: Tue, 10 Oct 2023 22:47:50 +1100
+Subject: powerpc/47x: Fix 47x syscall return crash
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Michael Ellerman <mpe@ellerman.id.au>
+
+commit f0eee815babed70a749d2496a7678be5b45b4c14 upstream.
+
+Eddie reported that newer kernels were crashing during boot on his 476
+FSP2 system:
+
+ kernel tried to execute user page (b7ee2000) - exploit attempt? (uid: 0)
+ BUG: Unable to handle kernel instruction fetch
+ Faulting instruction address: 0xb7ee2000
+ Oops: Kernel access of bad area, sig: 11 [#1]
+ BE PAGE_SIZE=4K FSP-2
+ Modules linked in:
+ CPU: 0 PID: 61 Comm: mount Not tainted 6.1.55-d23900f.ppcnf-fsp2 #1
+ Hardware name: ibm,fsp2 476fpe 0x7ff520c0 FSP-2
+ NIP: b7ee2000 LR: 8c008000 CTR: 00000000
+ REGS: bffebd83 TRAP: 0400 Not tainted (6.1.55-d23900f.ppcnf-fs p2)
+ MSR: 00000030 <IR,DR> CR: 00001000 XER: 20000000
+ GPR00: c00110ac bffebe63 bffebe7e bffebe88 8c008000 00001000 00000d12 b7ee2000
+ GPR08: 00000033 00000000 00000000 c139df10 48224824 1016c314 10160000 00000000
+ GPR16: 10160000 10160000 00000008 00000000 10160000 00000000 10160000 1017f5b0
+ GPR24: 1017fa50 1017f4f0 1017fa50 1017f740 1017f630 00000000 00000000 1017f4f0
+ NIP [b7ee2000] 0xb7ee2000
+ LR [8c008000] 0x8c008000
+ Call Trace:
+ Instruction dump:
+ XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
+ XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
+ ---[ end trace 0000000000000000 ]---
+
+The problem is in ret_from_syscall where the check for
+icache_44x_need_flush is done. When the flush is needed the code jumps
+out-of-line to do the flush, and then intends to jump back to continue
+the syscall return.
+
+However the branch back to label 1b doesn't return to the correct
+location, instead branching back just prior to the return to userspace,
+causing bogus register values to be used by the rfi.
+
+The breakage was introduced by commit 6f76a01173cc
+("powerpc/syscall: implement system call entry/exit logic in C for PPC32") which
+inadvertently removed the "1" label and reused it elsewhere.
+
+Fix it by adding named local labels in the correct locations. Note that
+the return label needs to be outside the ifdef so that CONFIG_PPC_47x=n
+compiles.
+
+Fixes: 6f76a01173cc ("powerpc/syscall: implement system call entry/exit logic in C for PPC32")
+Cc: stable@vger.kernel.org # v5.12+
+Reported-by: Eddie James <eajames@linux.ibm.com>
+Tested-by: Eddie James <eajames@linux.ibm.com>
+Link: https://lore.kernel.org/linuxppc-dev/fdaadc46-7476-9237-e104-1d2168526e72@linux.ibm.com/
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
+Link: https://msgid.link/20231010114750.847794-1-mpe@ellerman.id.au
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/kernel/entry_32.S | 8 +++++---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+--- a/arch/powerpc/kernel/entry_32.S
++++ b/arch/powerpc/kernel/entry_32.S
+@@ -135,8 +135,9 @@ ret_from_syscall:
+ lis r4,icache_44x_need_flush@ha
+ lwz r5,icache_44x_need_flush@l(r4)
+ cmplwi cr0,r5,0
+- bne- 2f
++ bne- .L44x_icache_flush
+ #endif /* CONFIG_PPC_47x */
++.L44x_icache_flush_return:
+ kuep_unlock
+ lwz r4,_LINK(r1)
+ lwz r5,_CCR(r1)
+@@ -170,10 +171,11 @@ syscall_exit_finish:
+ b 1b
+
+ #ifdef CONFIG_44x
+-2: li r7,0
++.L44x_icache_flush:
++ li r7,0
+ iccci r0,r0
+ stw r7,icache_44x_need_flush@l(r4)
+- b 1b
++ b .L44x_icache_flush_return
+ #endif /* CONFIG_44x */
+
+ .globl ret_from_fork
--- /dev/null
+From a20c4350c6a12405b7f732b3ee6801ffe2cc45ce Mon Sep 17 00:00:00 2001
+From: Peter Wang <peter.wang@mediatek.com>
+Date: Tue, 3 Oct 2023 10:20:02 +0800
+Subject: scsi: ufs: core: Correct clear TM error log
+
+From: Peter Wang <peter.wang@mediatek.com>
+
+commit a20c4350c6a12405b7f732b3ee6801ffe2cc45ce upstream.
+
+The clear TM function error log status was inverted.
+
+Fixes: 4693fad7d6d4 ("scsi: ufs: core: Log error handler activity")
+Signed-off-by: Peter Wang <peter.wang@mediatek.com>
+Link: https://lore.kernel.org/r/20231003022002.25578-1-peter.wang@mediatek.com
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/ufs/core/ufshcd.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/ufs/core/ufshcd.c
++++ b/drivers/ufs/core/ufshcd.c
+@@ -6749,7 +6749,7 @@ static int ufshcd_clear_tm_cmd(struct uf
+ mask, 0, 1000, 1000);
+
+ dev_err(hba->dev, "Clearing task management function with tag %d %s\n",
+- tag, err ? "succeeded" : "failed");
++ tag, err < 0 ? "failed" : "succeeded");
+
+ out:
+ return err;
nfc-nci-assert-requested-protocol-is-valid.patch
workqueue-override-implicit-ordered-attribute-in-wor.patch
tcp-enforce-receive-buffer-memory-limits-by-allowing.patch
+dmaengine-stm32-mdma-abort-resume-if-no-ongoing-transfer.patch
+dmaengine-stm32-dma-fix-stm32_dma_prep_slave_sg-in-case-of-mdma-chaining.patch
+dmaengine-stm32-dma-fix-residue-in-case-of-mdma-chaining.patch
+dmaengine-stm32-mdma-use-link-address-register-to-compute-residue.patch
+dmaengine-stm32-mdma-set-in_flight_bytes-in-case-crqa-flag-is-set.patch
+usb-xhci-xhci-ring-use-sysdev-for-mapping-bounce-buffer.patch
+net-usb-dm9601-fix-uninitialized-variable-use-in-dm9601_mdio_read.patch
+usb-dwc3-soft-reset-phy-on-probe-for-host.patch
+usb-cdns3-modify-the-return-value-of-cdns_set_active-to-void-when-config_pm_sleep-is-disabled.patch
+usb-hub-guard-against-accesses-to-uninitialized-bos-descriptors.patch
+usb-musb-get-the-musb_qh-poniter-after-musb_giveback.patch
+usb-musb-modify-the-hwvers-register-address.patch
+iio-pressure-bmp280-fix-null-pointer-exception.patch
+iio-imu-bno055-fix-missing-kconfig-dependencies.patch
+iio-adc-imx8qxp-fix-address-for-command-buffer-registers.patch
+iio-dac-ad3552r-correct-device-ids.patch
+iio-admv1013-add-mixer_vgate-corner-cases.patch
+iio-pressure-dps310-adjust-timeout-settings.patch
+iio-pressure-ms5611-ms5611_prom_is_valid-false-negative-bug.patch
+iio-addac-kconfig-update-ad74413r-selections.patch
+arm64-dts-mediatek-mt8195-demo-fix-the-memory-size-to-8gb.patch
+arm64-dts-mediatek-mt8195-demo-update-and-reorder-reserved-memory-regions.patch
+drm-atomic-helper-relax-unregistered-connector-check.patch
+drm-amdgpu-add-missing-null-check.patch
+drm-amd-display-don-t-set-dpms_off-for-seamless-boot.patch
+acpi-resource-skip-irq-override-on-asus-expertbook-b1402cba.patch
+acpi-ec-add-quirk-for-the-hp-pavilion-gaming-15-dk1xxx.patch
+ksmbd-not-allow-to-open-file-if-delelete-on-close-bit-is-set.patch
+perf-x86-lbr-filter-vsyscall-addresses.patch
+x86-cpu-fix-amd-erratum-1485-on-zen4-based-cpus.patch
+mcb-remove-is_added-flag-from-mcb_device-struct.patch
+thunderbolt-workaround-an-iommu-fault-on-certain-systems-with-intel-maple-ridge.patch
+thunderbolt-check-that-lane-1-is-in-cl0-before-enabling-lane-bonding.patch
+thunderbolt-restart-xdomain-discovery-handshake-after-failure.patch
+powerpc-47x-fix-47x-syscall-return-crash.patch
+libceph-use-kernel_connect.patch
+ceph-fix-incorrect-revoked-caps-assert-in-ceph_fill_file_size.patch
+ceph-fix-type-promotion-bug-on-32bit-systems.patch
+input-powermate-fix-use-after-free-in-powermate_config_complete.patch
+input-psmouse-fix-fast_reconnect-function-for-ps-2-mode.patch
+input-xpad-add-pxn-v900-support.patch
+input-i8042-add-fujitsu-lifebook-e5411-to-i8042-quirk-table.patch
+input-goodix-ensure-int-gpio-is-in-input-for-gpio_count-1-gpio_int_idx-0-case.patch
+tee-amdtee-fix-use-after-free-vulnerability-in-amdtee_close_session.patch
+mctp-perform-route-lookups-under-a-rcu-read-side-lock.patch
+nfp-flower-avoid-rmmod-nfp-crash-issues.patch
+usb-typec-ucsi-use-get_capability-attributes-data-to-set-power-supply-scope.patch
+cgroup-remove-duplicates-in-cgroup-v1-tasks-file.patch
+dma-buf-add-dma_fence_timestamp-helper.patch
+pinctrl-avoid-unsafe-code-pattern-in-find_pinctrl.patch
+scsi-ufs-core-correct-clear-tm-error-log.patch
+counter-chrdev-fix-getting-array-extensions.patch
+counter-microchip-tcb-capture-fix-the-use-of-internal-gclk-logic.patch
+usb-typec-altmodes-displayport-signal-hpd-low-when-exiting-mode.patch
+usb-typec-ucsi-clear-event_pending-bit-if-ucsi_send_command-fails.patch
+usb-gadget-udc-xilinx-replace-memcpy-with-memcpy_toio.patch
+usb-gadget-ncm-handle-decoding-of-multiple-ntb-s-in-unwrap-call.patch
+usb-cdnsp-fixes-issue-with-dequeuing-not-queued-requests.patch
--- /dev/null
+From f4384b3e54ea813868bb81a861bf5b2406e15d8f Mon Sep 17 00:00:00 2001
+From: Rijo Thomas <Rijo-john.Thomas@amd.com>
+Date: Fri, 29 Sep 2023 12:30:24 +0530
+Subject: tee: amdtee: fix use-after-free vulnerability in amdtee_close_session
+
+From: Rijo Thomas <Rijo-john.Thomas@amd.com>
+
+commit f4384b3e54ea813868bb81a861bf5b2406e15d8f upstream.
+
+There is a potential race condition in amdtee_close_session that may
+cause use-after-free in amdtee_open_session. For instance, if a session
+has refcount == 1, and one thread tries to free this session via:
+
+ kref_put(&sess->refcount, destroy_session);
+
+the reference count will get decremented, and the next step would be to
+call destroy_session(). However, if in another thread,
+amdtee_open_session() is called before destroy_session() has completed
+execution, alloc_session() may return 'sess' that will be freed up
+later in destroy_session() leading to use-after-free in
+amdtee_open_session.
+
+To fix this issue, treat decrement of sess->refcount and removal of
+'sess' from session list in destroy_session() as a critical section, so
+that it is executed atomically.
+
+Fixes: 757cc3e9ff1d ("tee: add AMD-TEE driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: Rijo Thomas <Rijo-john.Thomas@amd.com>
+Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
+Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tee/amdtee/core.c | 10 ++++++----
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+--- a/drivers/tee/amdtee/core.c
++++ b/drivers/tee/amdtee/core.c
+@@ -217,12 +217,12 @@ unlock:
+ return rc;
+ }
+
++/* mutex must be held by caller */
+ static void destroy_session(struct kref *ref)
+ {
+ struct amdtee_session *sess = container_of(ref, struct amdtee_session,
+ refcount);
+
+- mutex_lock(&session_list_mutex);
+ list_del(&sess->list_node);
+ mutex_unlock(&session_list_mutex);
+ kfree(sess);
+@@ -272,7 +272,8 @@ int amdtee_open_session(struct tee_conte
+ if (arg->ret != TEEC_SUCCESS) {
+ pr_err("open_session failed %d\n", arg->ret);
+ handle_unload_ta(ta_handle);
+- kref_put(&sess->refcount, destroy_session);
++ kref_put_mutex(&sess->refcount, destroy_session,
++ &session_list_mutex);
+ goto out;
+ }
+
+@@ -290,7 +291,8 @@ int amdtee_open_session(struct tee_conte
+ pr_err("reached maximum session count %d\n", TEE_NUM_SESSIONS);
+ handle_close_session(ta_handle, session_info);
+ handle_unload_ta(ta_handle);
+- kref_put(&sess->refcount, destroy_session);
++ kref_put_mutex(&sess->refcount, destroy_session,
++ &session_list_mutex);
+ rc = -ENOMEM;
+ goto out;
+ }
+@@ -331,7 +333,7 @@ int amdtee_close_session(struct tee_cont
+ handle_close_session(ta_handle, session_info);
+ handle_unload_ta(ta_handle);
+
+- kref_put(&sess->refcount, destroy_session);
++ kref_put_mutex(&sess->refcount, destroy_session, &session_list_mutex);
+
+ return 0;
+ }
--- /dev/null
+From a9fdf5f933a6f2b358fad0194b1287b67f6704b1 Mon Sep 17 00:00:00 2001
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+Date: Tue, 22 Aug 2023 16:36:18 +0300
+Subject: thunderbolt: Check that lane 1 is in CL0 before enabling lane bonding
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+
+commit a9fdf5f933a6f2b358fad0194b1287b67f6704b1 upstream.
+
+Marek reported that when BlackMagic UltraStudio device is connected the
+kernel repeatedly tries to enable lane bonding without success making
+the device non-functional. It looks like the device does not have lane 1
+connected at all so even though it is enabled we should not try to bond
+the lanes. For this reason check that lane 1 is in fact CL0 (connected,
+active) before attempting to bond the lanes.
+
+Reported-by: Marek Šanta <teslan223@gmail.com>
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217737
+Cc: stable@vger.kernel.org
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/thunderbolt/switch.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/thunderbolt/switch.c
++++ b/drivers/thunderbolt/switch.c
+@@ -2763,6 +2763,13 @@ int tb_switch_lane_bonding_enable(struct
+ !tb_port_is_width_supported(down, 2))
+ return 0;
+
++ /*
++ * Both lanes need to be in CL0. Here we assume lane 0 already be in
++ * CL0 and check just for lane 1.
++ */
++ if (tb_wait_for_port(down->dual_link_port, false) <= 0)
++ return -ENOTCONN;
++
+ ret = tb_port_lane_bonding_enable(up);
+ if (ret) {
+ tb_port_warn(up, "failed to enable lane bonding\n");
--- /dev/null
+From 308092d080852f8997126e5b3507536162416f4a Mon Sep 17 00:00:00 2001
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+Date: Thu, 7 Sep 2023 16:02:30 +0300
+Subject: thunderbolt: Restart XDomain discovery handshake after failure
+
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+
+commit 308092d080852f8997126e5b3507536162416f4a upstream.
+
+Alex reported that after rebooting the other host the peer-to-peer link
+does not come up anymore. The reason for this is that the host that was
+not rebooted tries to send the UUID request only 10 times according to
+the USB4 Inter-Domain spec and gives up if it does not get reply. Then
+when the other side is actually ready it cannot get the link established
+anymore. The USB4 Inter-Domain spec requires that the discovery protocol
+is restarted in that case so implement this now.
+
+Reported-by: Alex Balcanquall <alex@alexbal.com>
+Fixes: 8e1de7042596 ("thunderbolt: Add support for XDomain lane bonding")
+Cc: stable@vger.kernel.org
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/thunderbolt/xdomain.c | 58 +++++++++++++++++++++++++++++-------------
+ 1 file changed, 41 insertions(+), 17 deletions(-)
+
+--- a/drivers/thunderbolt/xdomain.c
++++ b/drivers/thunderbolt/xdomain.c
+@@ -704,6 +704,27 @@ out_unlock:
+ mutex_unlock(&xdomain_lock);
+ }
+
++static void start_handshake(struct tb_xdomain *xd)
++{
++ xd->state = XDOMAIN_STATE_INIT;
++ queue_delayed_work(xd->tb->wq, &xd->state_work,
++ msecs_to_jiffies(XDOMAIN_SHORT_TIMEOUT));
++}
++
++/* Can be called from state_work */
++static void __stop_handshake(struct tb_xdomain *xd)
++{
++ cancel_delayed_work_sync(&xd->properties_changed_work);
++ xd->properties_changed_retries = 0;
++ xd->state_retries = 0;
++}
++
++static void stop_handshake(struct tb_xdomain *xd)
++{
++ cancel_delayed_work_sync(&xd->state_work);
++ __stop_handshake(xd);
++}
++
+ static void tb_xdp_handle_request(struct work_struct *work)
+ {
+ struct xdomain_request_work *xw = container_of(work, typeof(*xw), work);
+@@ -766,6 +787,15 @@ static void tb_xdp_handle_request(struct
+ case UUID_REQUEST:
+ tb_dbg(tb, "%llx: received XDomain UUID request\n", route);
+ ret = tb_xdp_uuid_response(ctl, route, sequence, uuid);
++ /*
++ * If we've stopped the discovery with an error such as
++ * timing out, we will restart the handshake now that we
++ * received UUID request from the remote host.
++ */
++ if (!ret && xd && xd->state == XDOMAIN_STATE_ERROR) {
++ dev_dbg(&xd->dev, "restarting handshake\n");
++ start_handshake(xd);
++ }
+ break;
+
+ case LINK_STATE_STATUS_REQUEST:
+@@ -1522,6 +1552,13 @@ static void tb_xdomain_queue_properties_
+ msecs_to_jiffies(XDOMAIN_SHORT_TIMEOUT));
+ }
+
++static void tb_xdomain_failed(struct tb_xdomain *xd)
++{
++ xd->state = XDOMAIN_STATE_ERROR;
++ queue_delayed_work(xd->tb->wq, &xd->state_work,
++ msecs_to_jiffies(XDOMAIN_DEFAULT_TIMEOUT));
++}
++
+ static void tb_xdomain_state_work(struct work_struct *work)
+ {
+ struct tb_xdomain *xd = container_of(work, typeof(*xd), state_work.work);
+@@ -1548,7 +1585,7 @@ static void tb_xdomain_state_work(struct
+ if (ret) {
+ if (ret == -EAGAIN)
+ goto retry_state;
+- xd->state = XDOMAIN_STATE_ERROR;
++ tb_xdomain_failed(xd);
+ } else {
+ tb_xdomain_queue_properties_changed(xd);
+ if (xd->bonding_possible)
+@@ -1613,7 +1650,7 @@ static void tb_xdomain_state_work(struct
+ if (ret) {
+ if (ret == -EAGAIN)
+ goto retry_state;
+- xd->state = XDOMAIN_STATE_ERROR;
++ tb_xdomain_failed(xd);
+ } else {
+ xd->state = XDOMAIN_STATE_ENUMERATED;
+ }
+@@ -1624,6 +1661,8 @@ static void tb_xdomain_state_work(struct
+ break;
+
+ case XDOMAIN_STATE_ERROR:
++ dev_dbg(&xd->dev, "discovery failed, stopping handshake\n");
++ __stop_handshake(xd);
+ break;
+
+ default:
+@@ -1793,21 +1832,6 @@ static void tb_xdomain_release(struct de
+ kfree(xd);
+ }
+
+-static void start_handshake(struct tb_xdomain *xd)
+-{
+- xd->state = XDOMAIN_STATE_INIT;
+- queue_delayed_work(xd->tb->wq, &xd->state_work,
+- msecs_to_jiffies(XDOMAIN_SHORT_TIMEOUT));
+-}
+-
+-static void stop_handshake(struct tb_xdomain *xd)
+-{
+- cancel_delayed_work_sync(&xd->properties_changed_work);
+- cancel_delayed_work_sync(&xd->state_work);
+- xd->properties_changed_retries = 0;
+- xd->state_retries = 0;
+-}
+-
+ static int __maybe_unused tb_xdomain_suspend(struct device *dev)
+ {
+ stop_handshake(tb_to_xdomain(dev));
--- /dev/null
+From 582620d9f6b352552bc9a3316fe2b1c3acd8742d Mon Sep 17 00:00:00 2001
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+Date: Fri, 18 Aug 2023 15:27:46 +0300
+Subject: thunderbolt: Workaround an IOMMU fault on certain systems with Intel Maple Ridge
+
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+
+commit 582620d9f6b352552bc9a3316fe2b1c3acd8742d upstream.
+
+On some systems the IOMMU blocks the first couple of driver ready
+messages to the connection manager firmware as can be seen in below
+excerpts:
+
+ thunderbolt 0000:06:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0010 address=0xbb0e3400 flags=0x0020]
+
+or
+
+ DMAR: DRHD: handling fault status reg 2
+ DMAR: [DMA Write] Request device [04:00.0] PASID ffffffff fault addr 69974000 [fault reason 05] PTE Write access is not set
+
+The reason is unknown and hard to debug because we were not able to
+reproduce this locally. This only happens on certain systems with Intel
+Maple Ridge Thunderbolt controller. If there is a device connected when
+the driver is loaded the issue does not happen either. Only when there
+is nothing connected (so typically when the system is booted up).
+
+We can work this around by sending the driver ready several times. After
+a couple of retries the message goes through and the controller works
+just fine. For this reason make the number of retries a parameter for
+icm_request() and then for Maple Ridge (and Titan Ridge as they us the
+same function but this should not matter) increase number of retries
+while shortening the timeout accordingly.
+
+Reported-by: Werner Sembach <wse@tuxedocomputers.com>
+Reported-by: Konrad J Hambrick <kjhambrick@gmail.com>
+Reported-by: Calvin Walton <calvin.walton@kepstin.ca>
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=214259
+Cc: stable@vger.kernel.org
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/thunderbolt/icm.c | 40 ++++++++++++++++++++--------------------
+ 1 file changed, 20 insertions(+), 20 deletions(-)
+
+--- a/drivers/thunderbolt/icm.c
++++ b/drivers/thunderbolt/icm.c
+@@ -41,6 +41,7 @@
+ #define PHY_PORT_CS1_LINK_STATE_SHIFT 26
+
+ #define ICM_TIMEOUT 5000 /* ms */
++#define ICM_RETRIES 3
+ #define ICM_APPROVE_TIMEOUT 10000 /* ms */
+ #define ICM_MAX_LINK 4
+
+@@ -296,10 +297,9 @@ static bool icm_copy(struct tb_cfg_reque
+
+ static int icm_request(struct tb *tb, const void *request, size_t request_size,
+ void *response, size_t response_size, size_t npackets,
+- unsigned int timeout_msec)
++ int retries, unsigned int timeout_msec)
+ {
+ struct icm *icm = tb_priv(tb);
+- int retries = 3;
+
+ do {
+ struct tb_cfg_request *req;
+@@ -410,7 +410,7 @@ static int icm_fr_get_route(struct tb *t
+ return -ENOMEM;
+
+ ret = icm_request(tb, &request, sizeof(request), switches,
+- sizeof(*switches), npackets, ICM_TIMEOUT);
++ sizeof(*switches), npackets, ICM_RETRIES, ICM_TIMEOUT);
+ if (ret)
+ goto err_free;
+
+@@ -463,7 +463,7 @@ icm_fr_driver_ready(struct tb *tb, enum
+
+ memset(&reply, 0, sizeof(reply));
+ ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
+- 1, ICM_TIMEOUT);
++ 1, ICM_RETRIES, ICM_TIMEOUT);
+ if (ret)
+ return ret;
+
+@@ -488,7 +488,7 @@ static int icm_fr_approve_switch(struct
+ memset(&reply, 0, sizeof(reply));
+ /* Use larger timeout as establishing tunnels can take some time */
+ ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
+- 1, ICM_APPROVE_TIMEOUT);
++ 1, ICM_RETRIES, ICM_APPROVE_TIMEOUT);
+ if (ret)
+ return ret;
+
+@@ -515,7 +515,7 @@ static int icm_fr_add_switch_key(struct
+
+ memset(&reply, 0, sizeof(reply));
+ ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
+- 1, ICM_TIMEOUT);
++ 1, ICM_RETRIES, ICM_TIMEOUT);
+ if (ret)
+ return ret;
+
+@@ -543,7 +543,7 @@ static int icm_fr_challenge_switch_key(s
+
+ memset(&reply, 0, sizeof(reply));
+ ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
+- 1, ICM_TIMEOUT);
++ 1, ICM_RETRIES, ICM_TIMEOUT);
+ if (ret)
+ return ret;
+
+@@ -577,7 +577,7 @@ static int icm_fr_approve_xdomain_paths(
+
+ memset(&reply, 0, sizeof(reply));
+ ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
+- 1, ICM_TIMEOUT);
++ 1, ICM_RETRIES, ICM_TIMEOUT);
+ if (ret)
+ return ret;
+
+@@ -1022,7 +1022,7 @@ icm_tr_driver_ready(struct tb *tb, enum
+
+ memset(&reply, 0, sizeof(reply));
+ ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
+- 1, 20000);
++ 1, 10, 2000);
+ if (ret)
+ return ret;
+
+@@ -1055,7 +1055,7 @@ static int icm_tr_approve_switch(struct
+
+ memset(&reply, 0, sizeof(reply));
+ ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
+- 1, ICM_APPROVE_TIMEOUT);
++ 1, ICM_RETRIES, ICM_APPROVE_TIMEOUT);
+ if (ret)
+ return ret;
+
+@@ -1083,7 +1083,7 @@ static int icm_tr_add_switch_key(struct
+
+ memset(&reply, 0, sizeof(reply));
+ ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
+- 1, ICM_TIMEOUT);
++ 1, ICM_RETRIES, ICM_TIMEOUT);
+ if (ret)
+ return ret;
+
+@@ -1112,7 +1112,7 @@ static int icm_tr_challenge_switch_key(s
+
+ memset(&reply, 0, sizeof(reply));
+ ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
+- 1, ICM_TIMEOUT);
++ 1, ICM_RETRIES, ICM_TIMEOUT);
+ if (ret)
+ return ret;
+
+@@ -1146,7 +1146,7 @@ static int icm_tr_approve_xdomain_paths(
+
+ memset(&reply, 0, sizeof(reply));
+ ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
+- 1, ICM_TIMEOUT);
++ 1, ICM_RETRIES, ICM_TIMEOUT);
+ if (ret)
+ return ret;
+
+@@ -1172,7 +1172,7 @@ static int icm_tr_xdomain_tear_down(stru
+
+ memset(&reply, 0, sizeof(reply));
+ ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
+- 1, ICM_TIMEOUT);
++ 1, ICM_RETRIES, ICM_TIMEOUT);
+ if (ret)
+ return ret;
+
+@@ -1498,7 +1498,7 @@ icm_ar_driver_ready(struct tb *tb, enum
+
+ memset(&reply, 0, sizeof(reply));
+ ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
+- 1, ICM_TIMEOUT);
++ 1, ICM_RETRIES, ICM_TIMEOUT);
+ if (ret)
+ return ret;
+
+@@ -1524,7 +1524,7 @@ static int icm_ar_get_route(struct tb *t
+
+ memset(&reply, 0, sizeof(reply));
+ ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
+- 1, ICM_TIMEOUT);
++ 1, ICM_RETRIES, ICM_TIMEOUT);
+ if (ret)
+ return ret;
+
+@@ -1545,7 +1545,7 @@ static int icm_ar_get_boot_acl(struct tb
+
+ memset(&reply, 0, sizeof(reply));
+ ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
+- 1, ICM_TIMEOUT);
++ 1, ICM_RETRIES, ICM_TIMEOUT);
+ if (ret)
+ return ret;
+
+@@ -1606,7 +1606,7 @@ static int icm_ar_set_boot_acl(struct tb
+
+ memset(&reply, 0, sizeof(reply));
+ ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
+- 1, ICM_TIMEOUT);
++ 1, ICM_RETRIES, ICM_TIMEOUT);
+ if (ret)
+ return ret;
+
+@@ -1628,7 +1628,7 @@ icm_icl_driver_ready(struct tb *tb, enum
+
+ memset(&reply, 0, sizeof(reply));
+ ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
+- 1, 20000);
++ 1, ICM_RETRIES, 20000);
+ if (ret)
+ return ret;
+
+@@ -2300,7 +2300,7 @@ static int icm_usb4_switch_op(struct tb_
+
+ memset(&reply, 0, sizeof(reply));
+ ret = icm_request(tb, &request, sizeof(request), &reply, sizeof(reply),
+- 1, ICM_TIMEOUT);
++ 1, ICM_RETRIES, ICM_TIMEOUT);
+ if (ret)
+ return ret;
+
--- /dev/null
+From 9f35d612da5592f1bf1cae44ec1e023df37bea12 Mon Sep 17 00:00:00 2001
+From: Xiaolei Wang <xiaolei.wang@windriver.com>
+Date: Tue, 26 Sep 2023 15:53:33 +0800
+Subject: usb: cdns3: Modify the return value of cdns_set_active () to void when CONFIG_PM_SLEEP is disabled
+
+From: Xiaolei Wang <xiaolei.wang@windriver.com>
+
+commit 9f35d612da5592f1bf1cae44ec1e023df37bea12 upstream.
+
+The return type of cdns_set_active () is inconsistent
+depending on whether CONFIG_PM_SLEEP is enabled, so the
+return value is modified to void type.
+
+Reported-by: Pavel Machek <pavel@denx.de>
+Closes: https://lore.kernel.org/all/ZP7lIKUzD68XA91j@duo.ucw.cz/
+Fixes: 2319b9c87fe2 ("usb: cdns3: Put the cdns set active part outside the spin lock")
+Cc: stable@vger.kernel.org
+Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
+Reviewed-by: Pavel Machek <pavel@denx.de>
+Reviewed-by: Roger Quadros <rogerq@kernel.org>
+Acked-by: Peter Chen <peter.chen@kernel.org>
+Link: https://lore.kernel.org/r/20230926075333.1791011-1-xiaolei.wang@windriver.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/cdns3/core.h | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/usb/cdns3/core.h
++++ b/drivers/usb/cdns3/core.h
+@@ -131,8 +131,7 @@ void cdns_set_active(struct cdns *cdns,
+ #else /* CONFIG_PM_SLEEP */
+ static inline int cdns_resume(struct cdns *cdns)
+ { return 0; }
+-static inline int cdns_set_active(struct cdns *cdns, u8 set_active)
+-{ return 0; }
++static inline void cdns_set_active(struct cdns *cdns, u8 set_active) { }
+ static inline int cdns_suspend(struct cdns *cdns)
+ { return 0; }
+ #endif /* CONFIG_PM_SLEEP */
--- /dev/null
+From 34f08eb0ba6e4869bbfb682bf3d7d0494ffd2f87 Mon Sep 17 00:00:00 2001
+From: Pawel Laszczak <pawell@cadence.com>
+Date: Thu, 13 Jul 2023 04:14:29 -0400
+Subject: usb: cdnsp: Fixes issue with dequeuing not queued requests
+
+From: Pawel Laszczak <pawell@cadence.com>
+
+commit 34f08eb0ba6e4869bbfb682bf3d7d0494ffd2f87 upstream.
+
+Gadget ACM while unloading module try to dequeue not queued usb
+request which causes the kernel to crash.
+Patch adds extra condition to check whether usb request is processed
+by CDNSP driver.
+
+cc: stable@vger.kernel.org
+Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
+Signed-off-by: Pawel Laszczak <pawell@cadence.com>
+Acked-by: Peter Chen <peter.chen@kernel.org>
+Link: https://lore.kernel.org/r/20230713081429.326660-1-pawell@cadence.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/cdns3/cdnsp-gadget.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/usb/cdns3/cdnsp-gadget.c
++++ b/drivers/usb/cdns3/cdnsp-gadget.c
+@@ -1125,6 +1125,9 @@ static int cdnsp_gadget_ep_dequeue(struc
+ unsigned long flags;
+ int ret;
+
++ if (request->status != -EINPROGRESS)
++ return 0;
++
+ if (!pep->endpoint.desc) {
+ dev_err(pdev->dev,
+ "%s: can't dequeue to disabled endpoint\n",
--- /dev/null
+From 8bea147dfdf823eaa8d3baeccc7aeb041b41944b Mon Sep 17 00:00:00 2001
+From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+Date: Wed, 13 Sep 2023 00:52:15 +0000
+Subject: usb: dwc3: Soft reset phy on probe for host
+
+From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+
+commit 8bea147dfdf823eaa8d3baeccc7aeb041b41944b upstream.
+
+When there's phy initialization, we need to initiate a soft-reset
+sequence. That's done through USBCMD.HCRST in the xHCI driver and its
+initialization, However, the dwc3 driver may modify core configs before
+the soft-reset. This may result in some connection instability. So,
+ensure the phy is ready before the controller updates the GCTL.PRTCAPDIR
+or other settings by issuing phy soft-reset.
+
+Note that some host-mode configurations may not expose device registers
+to initiate the controller soft-reset (via DCTL.CoreSftRst). So we reset
+through GUSB3PIPECTL and GUSB2PHYCFG instead.
+
+Cc: stable@vger.kernel.org
+Fixes: e835c0a4e23c ("usb: dwc3: don't reset device side if dwc3 was configured as host-only")
+Reported-by: Kenta Sato <tosainu.maple@gmail.com>
+Closes: https://lore.kernel.org/linux-usb/ZPUciRLUcjDywMVS@debian.me/
+Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+Tested-by: Kenta Sato <tosainu.maple@gmail.com>
+Link: https://lore.kernel.org/r/70aea513215d273669152696cc02b20ddcdb6f1a.1694564261.git.Thinh.Nguyen@synopsys.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/dwc3/core.c | 39 ++++++++++++++++++++++++++++++++++++++-
+ 1 file changed, 38 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/dwc3/core.c
++++ b/drivers/usb/dwc3/core.c
+@@ -279,9 +279,46 @@ int dwc3_core_soft_reset(struct dwc3 *dw
+ * XHCI driver will reset the host block. If dwc3 was configured for
+ * host-only mode or current role is host, then we can return early.
+ */
+- if (dwc->dr_mode == USB_DR_MODE_HOST || dwc->current_dr_role == DWC3_GCTL_PRTCAP_HOST)
++ if (dwc->current_dr_role == DWC3_GCTL_PRTCAP_HOST)
+ return 0;
+
++ /*
++ * If the dr_mode is host and the dwc->current_dr_role is not the
++ * corresponding DWC3_GCTL_PRTCAP_HOST, then the dwc3_core_init_mode
++ * isn't executed yet. Ensure the phy is ready before the controller
++ * updates the GCTL.PRTCAPDIR or other settings by soft-resetting
++ * the phy.
++ *
++ * Note: GUSB3PIPECTL[n] and GUSB2PHYCFG[n] are port settings where n
++ * is port index. If this is a multiport host, then we need to reset
++ * all active ports.
++ */
++ if (dwc->dr_mode == USB_DR_MODE_HOST) {
++ u32 usb3_port;
++ u32 usb2_port;
++
++ usb3_port = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
++ usb3_port |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
++ dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), usb3_port);
++
++ usb2_port = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
++ usb2_port |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
++ dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), usb2_port);
++
++ /* Small delay for phy reset assertion */
++ usleep_range(1000, 2000);
++
++ usb3_port &= ~DWC3_GUSB3PIPECTL_PHYSOFTRST;
++ dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), usb3_port);
++
++ usb2_port &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST;
++ dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), usb2_port);
++
++ /* Wait for clock synchronization */
++ msleep(50);
++ return 0;
++ }
++
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ reg |= DWC3_DCTL_CSFTRST;
+ reg &= ~DWC3_DCTL_RUN_STOP;
--- /dev/null
+From 427694cfaafa565a3db5c5ea71df6bc095dca92f Mon Sep 17 00:00:00 2001
+From: Krishna Kurapati <quic_kriskura@quicinc.com>
+Date: Wed, 27 Sep 2023 16:28:58 +0530
+Subject: usb: gadget: ncm: Handle decoding of multiple NTB's in unwrap call
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Krishna Kurapati <quic_kriskura@quicinc.com>
+
+commit 427694cfaafa565a3db5c5ea71df6bc095dca92f upstream.
+
+When NCM is used with hosts like Windows PC, it is observed that there are
+multiple NTB's contained in one usb request giveback. Since the driver
+unwraps the obtained request data assuming only one NTB is present, we
+loose the subsequent NTB's present resulting in data loss.
+
+Fix this by checking the parsed block length with the obtained data
+length in usb request and continue parsing after the last byte of current
+NTB.
+
+Cc: stable@vger.kernel.org
+Fixes: 9f6ce4240a2b ("usb: gadget: f_ncm.c added")
+Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
+Reviewed-by: Maciej Żenczykowski <maze@google.com>
+Link: https://lore.kernel.org/r/20230927105858.12950-1-quic_kriskura@quicinc.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/gadget/function/f_ncm.c | 26 +++++++++++++++++++-------
+ 1 file changed, 19 insertions(+), 7 deletions(-)
+
+--- a/drivers/usb/gadget/function/f_ncm.c
++++ b/drivers/usb/gadget/function/f_ncm.c
+@@ -1171,7 +1171,8 @@ static int ncm_unwrap_ntb(struct gether
+ struct sk_buff_head *list)
+ {
+ struct f_ncm *ncm = func_to_ncm(&port->func);
+- __le16 *tmp = (void *) skb->data;
++ unsigned char *ntb_ptr = skb->data;
++ __le16 *tmp;
+ unsigned index, index2;
+ int ndp_index;
+ unsigned dg_len, dg_len2;
+@@ -1184,6 +1185,10 @@ static int ncm_unwrap_ntb(struct gether
+ const struct ndp_parser_opts *opts = ncm->parser_opts;
+ unsigned crc_len = ncm->is_crc ? sizeof(uint32_t) : 0;
+ int dgram_counter;
++ int to_process = skb->len;
++
++parse_ntb:
++ tmp = (__le16 *)ntb_ptr;
+
+ /* dwSignature */
+ if (get_unaligned_le32(tmp) != opts->nth_sign) {
+@@ -1230,7 +1235,7 @@ static int ncm_unwrap_ntb(struct gether
+ * walk through NDP
+ * dwSignature
+ */
+- tmp = (void *)(skb->data + ndp_index);
++ tmp = (__le16 *)(ntb_ptr + ndp_index);
+ if (get_unaligned_le32(tmp) != ncm->ndp_sign) {
+ INFO(port->func.config->cdev, "Wrong NDP SIGN\n");
+ goto err;
+@@ -1287,11 +1292,11 @@ static int ncm_unwrap_ntb(struct gether
+ if (ncm->is_crc) {
+ uint32_t crc, crc2;
+
+- crc = get_unaligned_le32(skb->data +
++ crc = get_unaligned_le32(ntb_ptr +
+ index + dg_len -
+ crc_len);
+ crc2 = ~crc32_le(~0,
+- skb->data + index,
++ ntb_ptr + index,
+ dg_len - crc_len);
+ if (crc != crc2) {
+ INFO(port->func.config->cdev,
+@@ -1318,7 +1323,7 @@ static int ncm_unwrap_ntb(struct gether
+ dg_len - crc_len);
+ if (skb2 == NULL)
+ goto err;
+- skb_put_data(skb2, skb->data + index,
++ skb_put_data(skb2, ntb_ptr + index,
+ dg_len - crc_len);
+
+ skb_queue_tail(list, skb2);
+@@ -1331,10 +1336,17 @@ static int ncm_unwrap_ntb(struct gether
+ } while (ndp_len > 2 * (opts->dgram_item_len * 2));
+ } while (ndp_index);
+
+- dev_consume_skb_any(skb);
+-
+ VDBG(port->func.config->cdev,
+ "Parsed NTB with %d frames\n", dgram_counter);
++
++ to_process -= block_len;
++ if (to_process != 0) {
++ ntb_ptr = (unsigned char *)(ntb_ptr + block_len);
++ goto parse_ntb;
++ }
++
++ dev_consume_skb_any(skb);
++
+ return 0;
+ err:
+ skb_queue_purge(list);
--- /dev/null
+From 3061b6491f491197a35e14e49f805d661b02acd4 Mon Sep 17 00:00:00 2001
+From: Piyush Mehta <piyush.mehta@amd.com>
+Date: Fri, 29 Sep 2023 17:45:14 +0530
+Subject: usb: gadget: udc-xilinx: replace memcpy with memcpy_toio
+
+From: Piyush Mehta <piyush.mehta@amd.com>
+
+commit 3061b6491f491197a35e14e49f805d661b02acd4 upstream.
+
+For ARM processor, unaligned access to device memory is not allowed.
+Method memcpy does not take care of alignment.
+
+USB detection failure with the unalingned address of memory, with
+below kernel crash. To fix the unalingned address kernel panic,
+replace memcpy with memcpy_toio method.
+
+Kernel crash:
+Unable to handle kernel paging request at virtual address ffff80000c05008a
+Mem abort info:
+ ESR = 0x96000061
+ EC = 0x25: DABT (current EL), IL = 32 bits
+ SET = 0, FnV = 0
+ EA = 0, S1PTW = 0
+ FSC = 0x21: alignment fault
+Data abort info:
+ ISV = 0, ISS = 0x00000061
+ CM = 0, WnR = 1
+swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000000143b000
+[ffff80000c05008a] pgd=100000087ffff003, p4d=100000087ffff003,
+pud=100000087fffe003, pmd=1000000800bcc003, pte=00680000a0010713
+Internal error: Oops: 96000061 [#1] SMP
+Modules linked in:
+CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.19-xilinx-v2022.1 #1
+Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
+pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
+pc : __memcpy+0x30/0x260
+lr : __xudc_ep0_queue+0xf0/0x110
+sp : ffff800008003d00
+x29: ffff800008003d00 x28: ffff800009474e80 x27: 00000000000000a0
+x26: 0000000000000100 x25: 0000000000000012 x24: ffff000800bc8080
+x23: 0000000000000001 x22: 0000000000000012 x21: ffff000800bc8080
+x20: 0000000000000012 x19: ffff000800bc8080 x18: 0000000000000000
+x17: ffff800876482000 x16: ffff800008004000 x15: 0000000000004000
+x14: 00001f09785d0400 x13: 0103020101005567 x12: 0781400000000200
+x11: 00000000c5672a10 x10: 00000000000008d0 x9 : ffff800009463cf0
+x8 : ffff8000094757b0 x7 : 0201010055670781 x6 : 4000000002000112
+x5 : ffff80000c05009a x4 : ffff000800a15012 x3 : ffff00080362ad80
+x2 : 0000000000000012 x1 : ffff000800a15000 x0 : ffff80000c050088
+Call trace:
+ __memcpy+0x30/0x260
+ xudc_ep0_queue+0x3c/0x60
+ usb_ep_queue+0x38/0x44
+ composite_ep0_queue.constprop.0+0x2c/0xc0
+ composite_setup+0x8d0/0x185c
+ configfs_composite_setup+0x74/0xb0
+ xudc_irq+0x570/0xa40
+ __handle_irq_event_percpu+0x58/0x170
+ handle_irq_event+0x60/0x120
+ handle_fasteoi_irq+0xc0/0x220
+ handle_domain_irq+0x60/0x90
+ gic_handle_irq+0x74/0xa0
+ call_on_irq_stack+0x2c/0x60
+ do_interrupt_handler+0x54/0x60
+ el1_interrupt+0x30/0x50
+ el1h_64_irq_handler+0x18/0x24
+ el1h_64_irq+0x78/0x7c
+ arch_cpu_idle+0x18/0x2c
+ do_idle+0xdc/0x15c
+ cpu_startup_entry+0x28/0x60
+ rest_init+0xc8/0xe0
+ arch_call_rest_init+0x10/0x1c
+ start_kernel+0x694/0x6d4
+ __primary_switched+0xa4/0xac
+
+Fixes: 1f7c51660034 ("usb: gadget: Add xilinx usb2 device support")
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/all/202209020044.CX2PfZzM-lkp@intel.com/
+Cc: stable@vger.kernel.org
+Signed-off-by: Piyush Mehta <piyush.mehta@amd.com>
+Link: https://lore.kernel.org/r/20230929121514.13475-1-piyush.mehta@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/gadget/udc/udc-xilinx.c | 20 ++++++++++++--------
+ 1 file changed, 12 insertions(+), 8 deletions(-)
+
+--- a/drivers/usb/gadget/udc/udc-xilinx.c
++++ b/drivers/usb/gadget/udc/udc-xilinx.c
+@@ -499,11 +499,13 @@ static int xudc_eptxrx(struct xusb_ep *e
+ /* Get the Buffer address and copy the transmit data.*/
+ eprambase = (u32 __force *)(udc->addr + ep->rambase);
+ if (ep->is_in) {
+- memcpy(eprambase, bufferptr, bytestosend);
++ memcpy_toio((void __iomem *)eprambase, bufferptr,
++ bytestosend);
+ udc->write_fn(udc->addr, ep->offset +
+ XUSB_EP_BUF0COUNT_OFFSET, bufferlen);
+ } else {
+- memcpy(bufferptr, eprambase, bytestosend);
++ memcpy_toio((void __iomem *)bufferptr, eprambase,
++ bytestosend);
+ }
+ /*
+ * Enable the buffer for transmission.
+@@ -517,11 +519,13 @@ static int xudc_eptxrx(struct xusb_ep *e
+ eprambase = (u32 __force *)(udc->addr + ep->rambase +
+ ep->ep_usb.maxpacket);
+ if (ep->is_in) {
+- memcpy(eprambase, bufferptr, bytestosend);
++ memcpy_toio((void __iomem *)eprambase, bufferptr,
++ bytestosend);
+ udc->write_fn(udc->addr, ep->offset +
+ XUSB_EP_BUF1COUNT_OFFSET, bufferlen);
+ } else {
+- memcpy(bufferptr, eprambase, bytestosend);
++ memcpy_toio((void __iomem *)bufferptr, eprambase,
++ bytestosend);
+ }
+ /*
+ * Enable the buffer for transmission.
+@@ -1023,7 +1027,7 @@ static int __xudc_ep0_queue(struct xusb_
+ udc->addr);
+ length = req->usb_req.actual = min_t(u32, length,
+ EP0_MAX_PACKET);
+- memcpy(corebuf, req->usb_req.buf, length);
++ memcpy_toio((void __iomem *)corebuf, req->usb_req.buf, length);
+ udc->write_fn(udc->addr, XUSB_EP_BUF0COUNT_OFFSET, length);
+ udc->write_fn(udc->addr, XUSB_BUFFREADY_OFFSET, 1);
+ } else {
+@@ -1752,7 +1756,7 @@ static void xudc_handle_setup(struct xus
+
+ /* Load up the chapter 9 command buffer.*/
+ ep0rambase = (u32 __force *) (udc->addr + XUSB_SETUP_PKT_ADDR_OFFSET);
+- memcpy(&setup, ep0rambase, 8);
++ memcpy_toio((void __iomem *)&setup, ep0rambase, 8);
+
+ udc->setup = setup;
+ udc->setup.wValue = cpu_to_le16(setup.wValue);
+@@ -1839,7 +1843,7 @@ static void xudc_ep0_out(struct xusb_udc
+ (ep0->rambase << 2));
+ buffer = req->usb_req.buf + req->usb_req.actual;
+ req->usb_req.actual = req->usb_req.actual + bytes_to_rx;
+- memcpy(buffer, ep0rambase, bytes_to_rx);
++ memcpy_toio((void __iomem *)buffer, ep0rambase, bytes_to_rx);
+
+ if (req->usb_req.length == req->usb_req.actual) {
+ /* Data transfer completed get ready for Status stage */
+@@ -1915,7 +1919,7 @@ static void xudc_ep0_in(struct xusb_udc
+ (ep0->rambase << 2));
+ buffer = req->usb_req.buf + req->usb_req.actual;
+ req->usb_req.actual = req->usb_req.actual + length;
+- memcpy(ep0rambase, buffer, length);
++ memcpy_toio((void __iomem *)ep0rambase, buffer, length);
+ }
+ udc->write_fn(udc->addr, XUSB_EP_BUF0COUNT_OFFSET, count);
+ udc->write_fn(udc->addr, XUSB_BUFFREADY_OFFSET, 1);
--- /dev/null
+From f74a7afc224acd5e922c7a2e52244d891bbe44ee Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ricardo=20Ca=C3=B1uelo?= <ricardo.canuelo@collabora.com>
+Date: Wed, 30 Aug 2023 12:04:18 +0200
+Subject: usb: hub: Guard against accesses to uninitialized BOS descriptors
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
+
+commit f74a7afc224acd5e922c7a2e52244d891bbe44ee upstream.
+
+Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h
+access fields inside udev->bos without checking if it was allocated and
+initialized. If usb_get_bos_descriptor() fails for whatever
+reason, udev->bos will be NULL and those accesses will result in a
+crash:
+
+BUG: kernel NULL pointer dereference, address: 0000000000000018
+PGD 0 P4D 0
+Oops: 0000 [#1] PREEMPT SMP NOPTI
+CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1>
+Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021
+Workqueue: usb_hub_wq hub_event
+RIP: 0010:hub_port_reset+0x193/0x788
+Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9
+RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246
+RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310
+RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840
+RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060
+R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
+R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000
+FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0
+Call Trace:
+hub_event+0x73f/0x156e
+? hub_activate+0x5b7/0x68f
+process_one_work+0x1a2/0x487
+worker_thread+0x11a/0x288
+kthread+0x13a/0x152
+? process_one_work+0x487/0x487
+? kthread_associate_blkcg+0x70/0x70
+ret_from_fork+0x1f/0x30
+
+Fall back to a default behavior if the BOS descriptor isn't accessible
+and skip all the functionalities that depend on it: LPM support checks,
+Super Speed capabilitiy checks, U1/U2 states setup.
+
+Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20230830100418.1952143-1-ricardo.canuelo@collabora.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/core/hub.c | 25 ++++++++++++++++++++++---
+ drivers/usb/core/hub.h | 2 +-
+ 2 files changed, 23 insertions(+), 4 deletions(-)
+
+--- a/drivers/usb/core/hub.c
++++ b/drivers/usb/core/hub.c
+@@ -151,6 +151,10 @@ int usb_device_supports_lpm(struct usb_d
+ if (udev->quirks & USB_QUIRK_NO_LPM)
+ return 0;
+
++ /* Skip if the device BOS descriptor couldn't be read */
++ if (!udev->bos)
++ return 0;
++
+ /* USB 2.1 (and greater) devices indicate LPM support through
+ * their USB 2.0 Extended Capabilities BOS descriptor.
+ */
+@@ -327,6 +331,10 @@ static void usb_set_lpm_parameters(struc
+ if (!udev->lpm_capable || udev->speed < USB_SPEED_SUPER)
+ return;
+
++ /* Skip if the device BOS descriptor couldn't be read */
++ if (!udev->bos)
++ return;
++
+ hub = usb_hub_to_struct_hub(udev->parent);
+ /* It doesn't take time to transition the roothub into U0, since it
+ * doesn't have an upstream link.
+@@ -2705,13 +2713,17 @@ out_authorized:
+ static enum usb_ssp_rate get_port_ssp_rate(struct usb_device *hdev,
+ u32 ext_portstatus)
+ {
+- struct usb_ssp_cap_descriptor *ssp_cap = hdev->bos->ssp_cap;
++ struct usb_ssp_cap_descriptor *ssp_cap;
+ u32 attr;
+ u8 speed_id;
+ u8 ssac;
+ u8 lanes;
+ int i;
+
++ if (!hdev->bos)
++ goto out;
++
++ ssp_cap = hdev->bos->ssp_cap;
+ if (!ssp_cap)
+ goto out;
+
+@@ -4187,8 +4199,15 @@ static void usb_enable_link_state(struct
+ enum usb3_link_state state)
+ {
+ int timeout;
+- __u8 u1_mel = udev->bos->ss_cap->bU1devExitLat;
+- __le16 u2_mel = udev->bos->ss_cap->bU2DevExitLat;
++ __u8 u1_mel;
++ __le16 u2_mel;
++
++ /* Skip if the device BOS descriptor couldn't be read */
++ if (!udev->bos)
++ return;
++
++ u1_mel = udev->bos->ss_cap->bU1devExitLat;
++ u2_mel = udev->bos->ss_cap->bU2DevExitLat;
+
+ /* If the device says it doesn't have *any* exit latency to come out of
+ * U1 or U2, it's probably lying. Assume it doesn't implement that link
+--- a/drivers/usb/core/hub.h
++++ b/drivers/usb/core/hub.h
+@@ -145,7 +145,7 @@ static inline int hub_is_superspeedplus(
+ {
+ return (hdev->descriptor.bDeviceProtocol == USB_HUB_PR_SS &&
+ le16_to_cpu(hdev->descriptor.bcdUSB) >= 0x0310 &&
+- hdev->bos->ssp_cap);
++ hdev->bos && hdev->bos->ssp_cap);
+ }
+
+ static inline unsigned hub_power_on_good_delay(struct usb_hub *hub)
--- /dev/null
+From 33d7e37232155aadebe4145dcc592f00dabd7a2b Mon Sep 17 00:00:00 2001
+From: Xingxing Luo <xingxing.luo@unisoc.com>
+Date: Tue, 19 Sep 2023 11:30:55 +0800
+Subject: usb: musb: Get the musb_qh poniter after musb_giveback
+
+From: Xingxing Luo <xingxing.luo@unisoc.com>
+
+commit 33d7e37232155aadebe4145dcc592f00dabd7a2b upstream.
+
+When multiple threads are performing USB transmission, musb->lock will be
+unlocked when musb_giveback is executed. At this time, qh may be released
+in the dequeue process in other threads, resulting in a wild pointer, so
+it needs to be here get qh again, and judge whether qh is NULL, and when
+dequeue, you need to set qh to NULL.
+
+Fixes: dbac5d07d13e ("usb: musb: host: don't start next rx urb if current one failed")
+Cc: stable@vger.kernel.org
+Signed-off-by: Xingxing Luo <xingxing.luo@unisoc.com>
+Link: https://lore.kernel.org/r/20230919033055.14085-1-xingxing.luo@unisoc.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/musb/musb_host.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/musb/musb_host.c
++++ b/drivers/usb/musb/musb_host.c
+@@ -321,10 +321,16 @@ static void musb_advance_schedule(struct
+ musb_giveback(musb, urb, status);
+ qh->is_ready = ready;
+
++ /*
++ * musb->lock had been unlocked in musb_giveback, so qh may
++ * be freed, need to get it again
++ */
++ qh = musb_ep_get_qh(hw_ep, is_in);
++
+ /* reclaim resources (and bandwidth) ASAP; deschedule it, and
+ * invalidate qh as soon as list_empty(&hep->urb_list)
+ */
+- if (list_empty(&qh->hep->urb_list)) {
++ if (qh && list_empty(&qh->hep->urb_list)) {
+ struct list_head *head;
+ struct dma_controller *dma = musb->dma_controller;
+
+@@ -2398,6 +2404,7 @@ static int musb_urb_dequeue(struct usb_h
+ * and its URB list has emptied, recycle this qh.
+ */
+ if (ready && list_empty(&qh->hep->urb_list)) {
++ musb_ep_set_qh(qh->hw_ep, is_in, NULL);
+ qh->hep->hcpriv = NULL;
+ list_del(&qh->ring);
+ kfree(qh);
--- /dev/null
+From 6658a62e1ddf726483cb2d8bf45ea3f9bd533074 Mon Sep 17 00:00:00 2001
+From: Xingxing Luo <xingxing.luo@unisoc.com>
+Date: Fri, 22 Sep 2023 15:59:29 +0800
+Subject: usb: musb: Modify the "HWVers" register address
+
+From: Xingxing Luo <xingxing.luo@unisoc.com>
+
+commit 6658a62e1ddf726483cb2d8bf45ea3f9bd533074 upstream.
+
+musb HWVers rgister address is not 0x69, if we operate the
+wrong address 0x69, it will cause a kernel crash, because
+there is no register corresponding to this address in the
+additional control register of musb. In fact, HWVers has
+been defined in musb_register.h, and the name is
+"MUSB_HWVERS", so We need to use this macro instead of 0x69.
+
+Fixes: c2365ce5d5a0 ("usb: musb: replace hard coded registers with defines")
+Cc: stable@vger.kernel.org
+Signed-off-by: Xingxing Luo <xingxing.luo@unisoc.com>
+Link: https://lore.kernel.org/r/20230922075929.31074-1-xingxing.luo@unisoc.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/musb/musb_debugfs.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/usb/musb/musb_debugfs.c
++++ b/drivers/usb/musb/musb_debugfs.c
+@@ -39,7 +39,7 @@ static const struct musb_register_map mu
+ { "IntrUsbE", MUSB_INTRUSBE, 8 },
+ { "DevCtl", MUSB_DEVCTL, 8 },
+ { "VControl", 0x68, 32 },
+- { "HWVers", 0x69, 16 },
++ { "HWVers", MUSB_HWVERS, 16 },
+ { "LinkInfo", MUSB_LINKINFO, 8 },
+ { "VPLen", MUSB_VPLEN, 8 },
+ { "HS_EOF1", MUSB_HS_EOF1, 8 },
--- /dev/null
+From 89434b069e460967624903b049e5cf5c9e6b99b9 Mon Sep 17 00:00:00 2001
+From: RD Babiera <rdbabiera@google.com>
+Date: Mon, 9 Oct 2023 21:00:58 +0000
+Subject: usb: typec: altmodes/displayport: Signal hpd low when exiting mode
+
+From: RD Babiera <rdbabiera@google.com>
+
+commit 89434b069e460967624903b049e5cf5c9e6b99b9 upstream.
+
+Upon receiving an ACK for a sent EXIT_MODE message, the DisplayPort
+driver currently resets the status and configuration of the port partner.
+The hpd signal is not updated despite being part of the status, so the
+Display stack can still transmit video despite typec_altmode_exit placing
+the lanes in a Safe State.
+
+Set hpd to low when a sent EXIT_MODE message is ACK'ed.
+
+Fixes: 0e3bb7d6894d ("usb: typec: Add driver for DisplayPort alternate mode")
+Cc: stable@vger.kernel.org
+Signed-off-by: RD Babiera <rdbabiera@google.com>
+Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Link: https://lore.kernel.org/r/20231009210057.3773877-2-rdbabiera@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/typec/altmodes/displayport.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/usb/typec/altmodes/displayport.c
++++ b/drivers/usb/typec/altmodes/displayport.c
+@@ -301,6 +301,11 @@ static int dp_altmode_vdm(struct typec_a
+ case CMD_EXIT_MODE:
+ dp->data.status = 0;
+ dp->data.conf = 0;
++ if (dp->hpd) {
++ drm_connector_oob_hotplug_event(dp->connector_fwnode);
++ dp->hpd = false;
++ sysfs_notify(&dp->alt->dev.kobj, "displayport", "hpd");
++ }
+ break;
+ case DP_CMD_STATUS_UPDATE:
+ dp->data.status = *vdo;
--- /dev/null
+From a00e197daec52bcd955e118f5f57d706da5bfe50 Mon Sep 17 00:00:00 2001
+From: Prashanth K <quic_prashk@quicinc.com>
+Date: Mon, 11 Sep 2023 14:34:15 +0530
+Subject: usb: typec: ucsi: Clear EVENT_PENDING bit if ucsi_send_command fails
+
+From: Prashanth K <quic_prashk@quicinc.com>
+
+commit a00e197daec52bcd955e118f5f57d706da5bfe50 upstream.
+
+Currently if ucsi_send_command() fails, then we bail out without
+clearing EVENT_PENDING flag. So when the next connector change
+event comes, ucsi_connector_change() won't queue the con->work,
+because of which none of the new events will be processed.
+
+Fix this by clearing EVENT_PENDING flag if ucsi_send_command()
+fails.
+
+Cc: stable@vger.kernel.org # 5.16
+Fixes: 512df95b9432 ("usb: typec: ucsi: Better fix for missing unplug events issue")
+Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
+Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Link: https://lore.kernel.org/r/1694423055-8440-1-git-send-email-quic_prashk@quicinc.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/typec/ucsi/ucsi.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/usb/typec/ucsi/ucsi.c
++++ b/drivers/usb/typec/ucsi/ucsi.c
+@@ -785,6 +785,7 @@ static void ucsi_handle_connector_change
+ if (ret < 0) {
+ dev_err(ucsi->dev, "%s: GET_CONNECTOR_STATUS failed (%d)\n",
+ __func__, ret);
++ clear_bit(EVENT_PENDING, &con->ucsi->flags);
+ goto out_unlock;
+ }
+
--- /dev/null
+From c9ca8de2eb15f9da24113e652980c61f95a47530 Mon Sep 17 00:00:00 2001
+From: Mario Limonciello <mario.limonciello@amd.com>
+Date: Mon, 9 Oct 2023 13:46:43 -0500
+Subject: usb: typec: ucsi: Use GET_CAPABILITY attributes data to set power supply scope
+
+From: Mario Limonciello <mario.limonciello@amd.com>
+
+commit c9ca8de2eb15f9da24113e652980c61f95a47530 upstream.
+
+On some OEM systems, adding a W7900 dGPU triggers RAS errors and hangs
+at a black screen on startup. This issue occurs only if `ucsi_acpi` has
+loaded before `amdgpu` has loaded. The reason for this failure is that
+`amdgpu` uses power_supply_is_system_supplied() to determine if running
+on AC or DC power at startup. If this value is reported incorrectly the
+dGPU will also be programmed incorrectly and trigger errors.
+
+power_supply_is_system_supplied() reports the wrong value because UCSI
+power supplies provided as part of the system don't properly report the
+scope as "DEVICE" scope (not powering the system).
+
+In order to fix this issue check the capabilities reported from the UCSI
+power supply to ensure that it supports charging a battery and that it can
+be powered by AC. Mark the scope accordingly.
+
+Cc: stable@vger.kernel.org
+Fixes: a7fbfd44c020 ("usb: typec: ucsi: Mark dGPUs as DEVICE scope")
+Link: https://www.intel.com/content/www/us/en/products/docs/io/universal-serial-bus/usb-type-c-ucsi-spec.html p28
+Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
+Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
+Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
+Link: https://lore.kernel.org/r/20231009184643.129986-1-mario.limonciello@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/typec/ucsi/psy.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/drivers/usb/typec/ucsi/psy.c
++++ b/drivers/usb/typec/ucsi/psy.c
+@@ -37,6 +37,15 @@ static int ucsi_psy_get_scope(struct ucs
+ struct device *dev = con->ucsi->dev;
+
+ device_property_read_u8(dev, "scope", &scope);
++ if (scope == POWER_SUPPLY_SCOPE_UNKNOWN) {
++ u32 mask = UCSI_CAP_ATTR_POWER_AC_SUPPLY |
++ UCSI_CAP_ATTR_BATTERY_CHARGING;
++
++ if (con->ucsi->cap.attributes & mask)
++ scope = POWER_SUPPLY_SCOPE_SYSTEM;
++ else
++ scope = POWER_SUPPLY_SCOPE_DEVICE;
++ }
+ val->intval = scope;
+ return 0;
+ }
--- /dev/null
+From 41a43013d2366db5b88b42bbcd8e8f040b6ccf21 Mon Sep 17 00:00:00 2001
+From: Wesley Cheng <quic_wcheng@quicinc.com>
+Date: Fri, 15 Sep 2023 17:31:05 +0300
+Subject: usb: xhci: xhci-ring: Use sysdev for mapping bounce buffer
+
+From: Wesley Cheng <quic_wcheng@quicinc.com>
+
+commit 41a43013d2366db5b88b42bbcd8e8f040b6ccf21 upstream.
+
+As mentioned in:
+ commit 474ed23a6257 ("xhci: align the last trb before link if it is
+easily splittable.")
+
+A bounce buffer is utilized for ensuring that transfers that span across
+ring segments are aligned to the EP's max packet size. However, the device
+that is used to map the DMA buffer to is currently using the XHCI HCD,
+which does not carry any DMA operations in certain configrations.
+Migration to using the sysdev entry was introduced for DWC3 based
+implementations where the IOMMU operations are present.
+
+Replace the reference to the controller device to sysdev instead. This
+allows the bounce buffer to be properly mapped to any implementations that
+have an IOMMU involved.
+
+cc: stable@vger.kernel.org
+Fixes: 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA configuration")
+Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Link: https://lore.kernel.org/r/20230915143108.1532163-2-mathias.nyman@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/host/xhci-ring.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/host/xhci-ring.c
++++ b/drivers/usb/host/xhci-ring.c
+@@ -764,7 +764,7 @@ static void xhci_giveback_urb_in_irq(str
+ static void xhci_unmap_td_bounce_buffer(struct xhci_hcd *xhci,
+ struct xhci_ring *ring, struct xhci_td *td)
+ {
+- struct device *dev = xhci_to_hcd(xhci)->self.controller;
++ struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
+ struct xhci_segment *seg = td->bounce_seg;
+ struct urb *urb = td->urb;
+ size_t len;
+@@ -3455,7 +3455,7 @@ static u32 xhci_td_remainder(struct xhci
+ static int xhci_align_td(struct xhci_hcd *xhci, struct urb *urb, u32 enqd_len,
+ u32 *trb_buff_len, struct xhci_segment *seg)
+ {
+- struct device *dev = xhci_to_hcd(xhci)->self.controller;
++ struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
+ unsigned int unalign;
+ unsigned int max_pkt;
+ u32 new_buff_len;
--- /dev/null
+From f454b18e07f518bcd0c05af17a2239138bff52de Mon Sep 17 00:00:00 2001
+From: "Borislav Petkov (AMD)" <bp@alien8.de>
+Date: Sat, 7 Oct 2023 12:57:02 +0200
+Subject: x86/cpu: Fix AMD erratum #1485 on Zen4-based CPUs
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Borislav Petkov (AMD) <bp@alien8.de>
+
+commit f454b18e07f518bcd0c05af17a2239138bff52de upstream.
+
+Fix erratum #1485 on Zen4 parts where running with STIBP disabled can
+cause an #UD exception. The performance impact of the fix is negligible.
+
+Reported-by: René Rebe <rene@exactcode.de>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Tested-by: René Rebe <rene@exactcode.de>
+Cc: <stable@kernel.org>
+Link: https://lore.kernel.org/r/D99589F4-BC5D-430B-87B2-72C20370CF57@exactcode.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/include/asm/msr-index.h | 9 +++++++--
+ arch/x86/kernel/cpu/amd.c | 8 ++++++++
+ 2 files changed, 15 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/include/asm/msr-index.h
++++ b/arch/x86/include/asm/msr-index.h
+@@ -635,12 +635,17 @@
+ /* AMD Last Branch Record MSRs */
+ #define MSR_AMD64_LBR_SELECT 0xc000010e
+
+-/* Fam 17h MSRs */
+-#define MSR_F17H_IRPERF 0xc00000e9
++/* Zen4 */
++#define MSR_ZEN4_BP_CFG 0xc001102e
++#define MSR_ZEN4_BP_CFG_SHARED_BTB_FIX_BIT 5
+
++/* Zen 2 */
+ #define MSR_ZEN2_SPECTRAL_CHICKEN 0xc00110e3
+ #define MSR_ZEN2_SPECTRAL_CHICKEN_BIT BIT_ULL(1)
+
++/* Fam 17h MSRs */
++#define MSR_F17H_IRPERF 0xc00000e9
++
+ /* Fam 16h MSRs */
+ #define MSR_F16H_L2I_PERF_CTL 0xc0010230
+ #define MSR_F16H_L2I_PERF_CTR 0xc0010231
+--- a/arch/x86/kernel/cpu/amd.c
++++ b/arch/x86/kernel/cpu/amd.c
+@@ -80,6 +80,10 @@ static const int amd_div0[] =
+ AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x17, 0x00, 0x0, 0x2f, 0xf),
+ AMD_MODEL_RANGE(0x17, 0x50, 0x0, 0x5f, 0xf));
+
++static const int amd_erratum_1485[] =
++ AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x19, 0x10, 0x0, 0x1f, 0xf),
++ AMD_MODEL_RANGE(0x19, 0x60, 0x0, 0xaf, 0xf));
++
+ static bool cpu_has_amd_erratum(struct cpuinfo_x86 *cpu, const int *erratum)
+ {
+ int osvw_id = *erratum++;
+@@ -1125,6 +1129,10 @@ static void init_amd(struct cpuinfo_x86
+ pr_notice_once("AMD Zen1 DIV0 bug detected. Disable SMT for full protection.\n");
+ setup_force_cpu_bug(X86_BUG_DIV0);
+ }
++
++ if (!cpu_has(c, X86_FEATURE_HYPERVISOR) &&
++ cpu_has_amd_erratum(c, amd_erratum_1485))
++ msr_set_bit(MSR_ZEN4_BP_CFG, MSR_ZEN4_BP_CFG_SHARED_BTB_FIX_BIT);
+ }
+
+ #ifdef CONFIG_X86_32
projects / thirdparty / kernel / stable-queue.git / commitdiff
