--- /dev/null
+From bf0a800415a7397617765fe5f5278a645195c75a Mon Sep 17 00:00:00 2001
+From: Qiang Yu <quic_qianyu@quicinc.com>
+Date: Fri, 11 Oct 2024 03:41:39 -0700
+Subject: clk: qcom: gcc-x1e80100: Fix halt_check for pipediv2 clocks
+
+From: Qiang Yu <quic_qianyu@quicinc.com>
+
+commit bf0a800415a7397617765fe5f5278a645195c75a upstream.
+
+The pipediv2_clk's source from the same mux as pipe clock. So they have
+same limitation, which is that the PHY sequence requires to enable these
+local CBCs before the PHY is actually outputting a clock to them. This
+means the clock won't actually turn on when we vote them. Hence, let's
+skip the halt bit check of the pipediv2_clk, otherwise pipediv2_clk may
+stuck at off state during bootup.
+
+Cc: stable@vger.kernel.org
+Fixes: 161b7c401f4b ("clk: qcom: Add Global Clock controller (GCC) driver for X1E80100")
+Suggested-by: Mike Tipton <quic_mdtipton@quicinc.com>
+Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
+Reviewed-by: Konrad Dybcio <konradybcio@kernel.org>
+Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
+Link: https://lore.kernel.org/r/20241011104142.1181773-6-quic_qianyu@quicinc.com
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/clk/qcom/gcc-x1e80100.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/drivers/clk/qcom/gcc-x1e80100.c b/drivers/clk/qcom/gcc-x1e80100.c
+index 0f578771071f..81ba5ceab342 100644
+--- a/drivers/clk/qcom/gcc-x1e80100.c
++++ b/drivers/clk/qcom/gcc-x1e80100.c
+@@ -3123,7 +3123,7 @@ static struct clk_branch gcc_pcie_3_pipe_clk = {
+
+ static struct clk_branch gcc_pcie_3_pipediv2_clk = {
+ .halt_reg = 0x58060,
+- .halt_check = BRANCH_HALT_VOTED,
++ .halt_check = BRANCH_HALT_SKIP,
+ .clkr = {
+ .enable_reg = 0x52020,
+ .enable_mask = BIT(5),
+@@ -3248,7 +3248,7 @@ static struct clk_branch gcc_pcie_4_pipe_clk = {
+
+ static struct clk_branch gcc_pcie_4_pipediv2_clk = {
+ .halt_reg = 0x6b054,
+- .halt_check = BRANCH_HALT_VOTED,
++ .halt_check = BRANCH_HALT_SKIP,
+ .clkr = {
+ .enable_reg = 0x52010,
+ .enable_mask = BIT(27),
+@@ -3373,7 +3373,7 @@ static struct clk_branch gcc_pcie_5_pipe_clk = {
+
+ static struct clk_branch gcc_pcie_5_pipediv2_clk = {
+ .halt_reg = 0x2f054,
+- .halt_check = BRANCH_HALT_VOTED,
++ .halt_check = BRANCH_HALT_SKIP,
+ .clkr = {
+ .enable_reg = 0x52018,
+ .enable_mask = BIT(19),
+@@ -3511,7 +3511,7 @@ static struct clk_branch gcc_pcie_6a_pipe_clk = {
+
+ static struct clk_branch gcc_pcie_6a_pipediv2_clk = {
+ .halt_reg = 0x31060,
+- .halt_check = BRANCH_HALT_VOTED,
++ .halt_check = BRANCH_HALT_SKIP,
+ .clkr = {
+ .enable_reg = 0x52018,
+ .enable_mask = BIT(28),
+@@ -3649,7 +3649,7 @@ static struct clk_branch gcc_pcie_6b_pipe_clk = {
+
+ static struct clk_branch gcc_pcie_6b_pipediv2_clk = {
+ .halt_reg = 0x8d060,
+- .halt_check = BRANCH_HALT_VOTED,
++ .halt_check = BRANCH_HALT_SKIP,
+ .clkr = {
+ .enable_reg = 0x52010,
+ .enable_mask = BIT(28),
+--
+2.47.0
+
--- /dev/null
+From f903663a8dcd6e1656e52856afbf706cc14cbe6d Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan+linaro@kernel.org>
+Date: Sun, 1 Sep 2024 11:30:24 +0200
+Subject: clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs
+
+From: Johan Hovold <johan+linaro@kernel.org>
+
+commit f903663a8dcd6e1656e52856afbf706cc14cbe6d upstream.
+
+A recent change in the venus driver results in a stuck clock on the
+Lenovo ThinkPad X13s, for example, when streaming video in firefox:
+
+ video_cc_mvs0_clk status stuck at 'off'
+ WARNING: CPU: 6 PID: 2885 at drivers/clk/qcom/clk-branch.c:87 clk_branch_wait+0x144/0x15c
+ ...
+ Call trace:
+ clk_branch_wait+0x144/0x15c
+ clk_branch2_enable+0x30/0x40
+ clk_core_enable+0xd8/0x29c
+ clk_enable+0x2c/0x4c
+ vcodec_clks_enable.isra.0+0x94/0xd8 [venus_core]
+ coreid_power_v4+0x464/0x628 [venus_core]
+ vdec_start_streaming+0xc4/0x510 [venus_dec]
+ vb2_start_streaming+0x6c/0x180 [videobuf2_common]
+ vb2_core_streamon+0x120/0x1dc [videobuf2_common]
+ vb2_streamon+0x1c/0x6c [videobuf2_v4l2]
+ v4l2_m2m_ioctl_streamon+0x30/0x80 [v4l2_mem2mem]
+ v4l_streamon+0x24/0x30 [videodev]
+
+using the out-of-tree sm8350/sc8280xp venus support. [1]
+
+Update also the sm8350/sc8280xp GDSC definitions so that the hw control
+mode can be changed at runtime as the venus driver now requires.
+
+Fixes: ec9a652e5149 ("venus: pm_helpers: Use dev_pm_genpd_set_hwmode to switch GDSC mode on V6")
+Link: https://lore.kernel.org/lkml/20230731-topic-8280_venus-v1-0-8c8bbe1983a5@linaro.org/ # [1]
+Cc: Jagadeesh Kona <quic_jkona@quicinc.com>
+Cc: Taniya Das <quic_tdas@quicinc.com>
+Cc: Abel Vesa <abel.vesa@linaro.org>
+Cc: Konrad Dybcio <konradybcio@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
+Tested-by: Steev Klimaszewski <steev@kali.org>
+Link: https://lore.kernel.org/r/20240901093024.18841-1-johan+linaro@kernel.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/clk/qcom/videocc-sm8350.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/clk/qcom/videocc-sm8350.c b/drivers/clk/qcom/videocc-sm8350.c
+index 5bd6fe3e1298..874d4da95ff8 100644
+--- a/drivers/clk/qcom/videocc-sm8350.c
++++ b/drivers/clk/qcom/videocc-sm8350.c
+@@ -452,7 +452,7 @@ static struct gdsc mvs0_gdsc = {
+ .pd = {
+ .name = "mvs0_gdsc",
+ },
+- .flags = HW_CTRL | RETAIN_FF_ENABLE,
++ .flags = HW_CTRL_TRIGGER | RETAIN_FF_ENABLE,
+ .pwrsts = PWRSTS_OFF_ON,
+ };
+
+@@ -461,7 +461,7 @@ static struct gdsc mvs1_gdsc = {
+ .pd = {
+ .name = "mvs1_gdsc",
+ },
+- .flags = HW_CTRL | RETAIN_FF_ENABLE,
++ .flags = HW_CTRL_TRIGGER | RETAIN_FF_ENABLE,
+ .pwrsts = PWRSTS_OFF_ON,
+ };
+
+--
+2.47.0
+
--- /dev/null
+From 464cb98f1c07298c4c10e714ae0c36338d18d316 Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <maz@kernel.org>
+Date: Wed, 6 Nov 2024 08:44:18 +0000
+Subject: irqchip/gic-v3: Force propagation of the active state with a read-back
+
+From: Marc Zyngier <maz@kernel.org>
+
+commit 464cb98f1c07298c4c10e714ae0c36338d18d316 upstream.
+
+Christoffer reports that on some implementations, writing to
+GICR_ISACTIVER0 (and similar GICD registers) can race badly with a guest
+issuing a deactivation of that interrupt via the system register interface.
+
+There are multiple reasons to this:
+
+ - this uses an early write-acknoledgement memory type (nGnRE), meaning
+ that the write may only have made it as far as some interconnect
+ by the time the store is considered "done"
+
+ - the GIC itself is allowed to buffer the write until it decides to
+ take it into account (as long as it is in finite time)
+
+The effects are that the activation may not have taken effect by the time
+the kernel enters the guest, forcing an immediate exit, or that a guest
+deactivation occurs before the interrupt is active, doing nothing.
+
+In order to guarantee that the write to the ISACTIVER register has taken
+effect, read back from it, forcing the interconnect to propagate the write,
+and the GIC to process the write before returning the read.
+
+Reported-by: Christoffer Dall <christoffer.dall@arm.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Acked-by: Christoffer Dall <christoffer.dall@arm.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/all/20241106084418.3794612-1-maz@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/irqchip/irq-gic-v3.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/irqchip/irq-gic-v3.c
++++ b/drivers/irqchip/irq-gic-v3.c
+@@ -524,6 +524,13 @@ static int gic_irq_set_irqchip_state(str
+ }
+
+ gic_poke_irq(d, reg);
++
++ /*
++ * Force read-back to guarantee that the active state has taken
++ * effect, and won't race with a guest-driven deactivation.
++ */
++ if (reg == GICD_ISACTIVER)
++ gic_peek_irq(d, reg);
+ return 0;
+ }
+
--- /dev/null
+From 0b63c0e01fba40e3992bc627272ec7b618ccaef7 Mon Sep 17 00:00:00 2001
+From: Andrew Kanner <andrew.kanner@gmail.com>
+Date: Sun, 3 Nov 2024 20:38:45 +0100
+Subject: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove()
+
+From: Andrew Kanner <andrew.kanner@gmail.com>
+
+commit 0b63c0e01fba40e3992bc627272ec7b618ccaef7 upstream.
+
+Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove():
+
+[ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12
+[ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry
+[ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004
+[...]
+[ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0
+[...]
+[ 57.331328] Call Trace:
+[ 57.331477] <TASK>
+[...]
+[ 57.333511] ? do_user_addr_fault+0x3e5/0x740
+[ 57.333778] ? exc_page_fault+0x70/0x170
+[ 57.334016] ? asm_exc_page_fault+0x2b/0x30
+[ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10
+[ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0
+[ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0
+[ 57.335164] ocfs2_xa_set+0x704/0xcf0
+[ 57.335381] ? _raw_spin_unlock+0x1a/0x40
+[ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20
+[ 57.335915] ? trace_preempt_on+0x1e/0x70
+[ 57.336153] ? start_this_handle+0x16c/0x500
+[ 57.336410] ? preempt_count_sub+0x50/0x80
+[ 57.336656] ? _raw_read_unlock+0x20/0x40
+[ 57.336906] ? start_this_handle+0x16c/0x500
+[ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0
+[ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0
+[ 57.337706] ? ocfs2_start_trans+0x13d/0x290
+[ 57.337971] ocfs2_xattr_set+0xb13/0xfb0
+[ 57.338207] ? dput+0x46/0x1c0
+[ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30
+[ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30
+[ 57.338948] __vfs_removexattr+0x92/0xc0
+[ 57.339182] __vfs_removexattr_locked+0xd5/0x190
+[ 57.339456] ? preempt_count_sub+0x50/0x80
+[ 57.339705] vfs_removexattr+0x5f/0x100
+[...]
+
+Reproducer uses faultinject facility to fail ocfs2_xa_remove() ->
+ocfs2_xa_value_truncate() with -ENOMEM.
+
+In this case the comment mentions that we can return 0 if
+ocfs2_xa_cleanup_value_truncate() is going to wipe the entry
+anyway. But the following 'rc' check is wrong and execution flow do
+'ocfs2_xa_remove_entry(loc);' twice:
+* 1st: in ocfs2_xa_cleanup_value_truncate();
+* 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'.
+
+Fix this by skipping the 2nd removal of the same entry and making
+syzkaller repro happy.
+
+Link: https://lkml.kernel.org/r/20241103193845.2940988-1-andrew.kanner@gmail.com
+Fixes: 399ff3a748cf ("ocfs2: Handle errors while setting external xattr values.")
+Signed-off-by: Andrew Kanner <andrew.kanner@gmail.com>
+Reported-by: syzbot+386ce9e60fa1b18aac5b@syzkaller.appspotmail.com
+Closes: https://lore.kernel.org/all/671e13ab.050a0220.2b8c0f.01d0.GAE@google.com/T/
+Tested-by: syzbot+386ce9e60fa1b18aac5b@syzkaller.appspotmail.com
+Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
+Cc: Mark Fasheh <mark@fasheh.com>
+Cc: Joel Becker <jlbec@evilplan.org>
+Cc: Junxiao Bi <junxiao.bi@oracle.com>
+Cc: Changwei Ge <gechangwei@live.cn>
+Cc: Jun Piao <piaojun@huawei.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ocfs2/xattr.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/fs/ocfs2/xattr.c
++++ b/fs/ocfs2/xattr.c
+@@ -2036,8 +2036,7 @@ static int ocfs2_xa_remove(struct ocfs2_
+ rc = 0;
+ ocfs2_xa_cleanup_value_truncate(loc, "removing",
+ orig_clusters);
+- if (rc)
+- goto out;
++ goto out;
+ }
+ }
+
--- /dev/null
+From 0268d4579901821ff17259213c2d8c9679995d48 Mon Sep 17 00:00:00 2001
+From: Muhammad Usama Anjum <usama.anjum@collabora.com>
+Date: Fri, 1 Nov 2024 19:15:57 +0500
+Subject: selftests: hugetlb_dio: check for initial conditions to skip in the start
+
+From: Muhammad Usama Anjum <usama.anjum@collabora.com>
+
+commit 0268d4579901821ff17259213c2d8c9679995d48 upstream.
+
+The test should be skipped if initial conditions aren't fulfilled in the
+start instead of failing and outputting non-compliant TAP logs. This kind
+of failure pollutes the results. The initial conditions are:
+
+- The test should only execute if /tmp file can be allocated.
+- The test should only execute if huge pages are free.
+
+Before:
+TAP version 13
+1..4
+Bail out! Error opening file
+: Read-only file system (30)
+ # Planned tests != run tests (4 != 0)
+ # Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0
+
+After:
+TAP version 13
+1..0 # SKIP Unable to allocate file: Read-only file system
+
+Link: https://lkml.kernel.org/r/20241101141557.3159432-1-usama.anjum@collabora.com
+Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
+Fixes: 3a103b5315b7 ("selftest: mm: Test if hugepage does not get leaked during __bio_release_pages()")
+Cc: Muhammad Usama Anjum <usama.anjum@collabora.com>
+Cc: Shuah Khan <shuah@kernel.org>
+Cc: Donet Tom <donettom@linux.ibm.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/selftests/mm/hugetlb_dio.c | 19 ++++++++++++-------
+ 1 file changed, 12 insertions(+), 7 deletions(-)
+
+diff --git a/tools/testing/selftests/mm/hugetlb_dio.c b/tools/testing/selftests/mm/hugetlb_dio.c
+index f9ac20c657ec..60001c142ce9 100644
+--- a/tools/testing/selftests/mm/hugetlb_dio.c
++++ b/tools/testing/selftests/mm/hugetlb_dio.c
+@@ -44,13 +44,6 @@ void run_dio_using_hugetlb(unsigned int start_off, unsigned int end_off)
+ if (fd < 0)
+ ksft_exit_fail_perror("Error opening file\n");
+
+- /* Get the free huge pages before allocation */
+- free_hpage_b = get_free_hugepages();
+- if (free_hpage_b == 0) {
+- close(fd);
+- ksft_exit_skip("No free hugepage, exiting!\n");
+- }
+-
+ /* Allocate a hugetlb page */
+ orig_buffer = mmap(NULL, h_pagesize, mmap_prot, mmap_flags, -1, 0);
+ if (orig_buffer == MAP_FAILED) {
+@@ -94,8 +87,20 @@ void run_dio_using_hugetlb(unsigned int start_off, unsigned int end_off)
+ int main(void)
+ {
+ size_t pagesize = 0;
++ int fd;
+
+ ksft_print_header();
++
++ /* Open the file to DIO */
++ fd = open("/tmp", O_TMPFILE | O_RDWR | O_DIRECT, 0664);
++ if (fd < 0)
++ ksft_exit_skip("Unable to allocate file: %s\n", strerror(errno));
++ close(fd);
++
++ /* Check if huge pages are free */
++ if (!get_free_hugepages())
++ ksft_exit_skip("No free hugepage, exiting\n");
++
+ ksft_set_plan(4);
+
+ /* Get base page size */
+--
+2.47.0
+
usb-serial-qcserial-add-support-for-sierra-wireless-em86xx.patch
usb-serial-option-add-fibocom-fg132-0x0112-composition.patch
usb-serial-option-add-quectel-rg650v.patch
+clk-qcom-videocc-sm8350-use-hw_ctrl_trigger-for-vcodec-gdscs.patch
+clk-qcom-gcc-x1e80100-fix-halt_check-for-pipediv2-clocks.patch
+thunderbolt-fix-connection-issue-with-pluggable-ud-4vpd-dock.patch
+staging-vchiq_arm-use-devm_kzalloc-for-drv_mgmt-allocation.patch
+staging-vchiq_arm-use-devm_kzalloc-for-vchiq_arm_state-allocation.patch
+irqchip-gic-v3-force-propagation-of-the-active-state-with-a-read-back.patch
+ocfs2-remove-entry-once-instead-of-null-ptr-dereference-in-ocfs2_xa_remove.patch
+ucounts-fix-counter-leak-in-inc_rlimit_get_ucounts.patch
+selftests-hugetlb_dio-check-for-initial-conditions-to-skip-in-the-start.patch
--- /dev/null
+From 807babf69027b4f1c55e72b06879658e83830880 Mon Sep 17 00:00:00 2001
+From: Umang Jain <umang.jain@ideasonboard.com>
+Date: Wed, 16 Oct 2024 18:32:25 +0530
+Subject: staging: vchiq_arm: Use devm_kzalloc() for drv_mgmt allocation
+
+From: Umang Jain <umang.jain@ideasonboard.com>
+
+commit 807babf69027b4f1c55e72b06879658e83830880 upstream.
+
+The struct drv_mgmt 'mgmt' is currently allocated dynamically using
+kzalloc(). Unfortunately, it is subjected to memory leaks in the error
+handling paths of the probe() function.
+
+To address this issue, use device resource management
+helper devm_kzalloc(), to ensure cleanup after the allocation.
+
+Cc: stable@vger.kernel.org
+Fixes: 1c9e16b73166 ("staging: vc04_services: vchiq_arm: Split driver static and runtime data")
+Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
+Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
+Link: https://lore.kernel.org/r/20241016130225.61024-3-umang.jain@ideasonboard.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+index 0d8d5555e8af..6c488b1e2624 100644
+--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
++++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+@@ -1731,7 +1731,7 @@ static int vchiq_probe(struct platform_device *pdev)
+ return -ENOENT;
+ }
+
+- mgmt = kzalloc(sizeof(*mgmt), GFP_KERNEL);
++ mgmt = devm_kzalloc(&pdev->dev, sizeof(*mgmt), GFP_KERNEL);
+ if (!mgmt)
+ return -ENOMEM;
+
+@@ -1789,8 +1789,6 @@ static void vchiq_remove(struct platform_device *pdev)
+
+ arm_state = vchiq_platform_get_arm_state(&mgmt->state);
+ kthread_stop(arm_state->ka_thread);
+-
+- kfree(mgmt);
+ }
+
+ static struct platform_driver vchiq_driver = {
+--
+2.47.0
+
--- /dev/null
+From 404b739e895522838f1abdc340c554654d671dde Mon Sep 17 00:00:00 2001
+From: Umang Jain <umang.jain@ideasonboard.com>
+Date: Wed, 16 Oct 2024 18:32:24 +0530
+Subject: staging: vchiq_arm: Use devm_kzalloc() for vchiq_arm_state allocation
+
+From: Umang Jain <umang.jain@ideasonboard.com>
+
+commit 404b739e895522838f1abdc340c554654d671dde upstream.
+
+The struct vchiq_arm_state 'platform_state' is currently allocated
+dynamically using kzalloc(). Unfortunately, it is never freed and is
+subjected to memory leaks in the error handling paths of the probe()
+function.
+
+To address the issue, use device resource management helper
+devm_kzalloc(), to ensure cleanup after its allocation.
+
+Fixes: 71bad7f08641 ("staging: add bcm2708 vchiq driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
+Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
+Link: https://lore.kernel.org/r/20241016130225.61024-2-umang.jain@ideasonboard.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
++++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+@@ -593,7 +593,7 @@ vchiq_platform_init_state(struct vchiq_s
+ {
+ struct vchiq_arm_state *platform_state;
+
+- platform_state = kzalloc(sizeof(*platform_state), GFP_KERNEL);
++ platform_state = devm_kzalloc(state->dev, sizeof(*platform_state), GFP_KERNEL);
+ if (!platform_state)
+ return -ENOMEM;
+
--- /dev/null
+From bd646c768a934d28e574ee940d6759c7954a024d Mon Sep 17 00:00:00 2001
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+Date: Tue, 5 Nov 2024 09:19:02 +0200
+Subject: thunderbolt: Fix connection issue with Pluggable UD-4VPD dock
+
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+
+commit bd646c768a934d28e574ee940d6759c7954a024d upstream.
+
+Rick reported that his Pluggable USB4 dock does not work anymore after
+upgrading to v6.10 kernel.
+
+It looks like commit c6ca1ac9f472 ("thunderbolt: Increase sideband
+access polling delay") makes the device router enumeration happen later
+than what might be expected by the dock (although there is no such limit
+in the USB4 spec) which probably makes it assume there is something
+wrong with the high-speed link and reset it. After the link is reset the
+same issue happens again and again.
+
+For this reason lower the sideband access delay from 5ms to 1ms. This
+seems to work fine according to Rick's testing.
+
+Reported-by: Rick Lahaye <rick@581238.xyz>
+Closes: https://lore.kernel.org/linux-usb/000f01db247b$d10e1520$732a3f60$@581238.xyz/
+Tested-by: Rick Lahaye <rick@581238.xyz>
+Fixes: c6ca1ac9f472 ("thunderbolt: Increase sideband access polling delay")
+Cc: stable@vger.kernel.org
+Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/thunderbolt/usb4.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/thunderbolt/usb4.c b/drivers/thunderbolt/usb4.c
+index 0a9b4aeb3fa1..402fdf8b1cde 100644
+--- a/drivers/thunderbolt/usb4.c
++++ b/drivers/thunderbolt/usb4.c
+@@ -48,7 +48,7 @@ enum usb4_ba_index {
+
+ /* Delays in us used with usb4_port_wait_for_bit() */
+ #define USB4_PORT_DELAY 50
+-#define USB4_PORT_SB_DELAY 5000
++#define USB4_PORT_SB_DELAY 1000
+
+ static int usb4_native_switch_op(struct tb_switch *sw, u16 opcode,
+ u32 *metadata, u8 *status,
+--
+2.47.0
+
--- /dev/null
+From 432dc0654c612457285a5dcf9bb13968ac6f0804 Mon Sep 17 00:00:00 2001
+From: Andrei Vagin <avagin@google.com>
+Date: Fri, 1 Nov 2024 19:19:40 +0000
+Subject: ucounts: fix counter leak in inc_rlimit_get_ucounts()
+
+From: Andrei Vagin <avagin@google.com>
+
+commit 432dc0654c612457285a5dcf9bb13968ac6f0804 upstream.
+
+The inc_rlimit_get_ucounts() increments the specified rlimit counter and
+then checks its limit. If the value exceeds the limit, the function
+returns an error without decrementing the counter.
+
+Link: https://lkml.kernel.org/r/20241101191940.3211128-1-roman.gushchin@linux.dev
+Fixes: 15bc01effefe ("ucounts: Fix signal ucount refcounting")
+Signed-off-by: Andrei Vagin <avagin@google.com>
+Co-developed-by: Roman Gushchin <roman.gushchin@linux.dev>
+Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev>
+Tested-by: Roman Gushchin <roman.gushchin@linux.dev>
+Acked-by: Alexey Gladkov <legion@kernel.org>
+Cc: Kees Cook <kees@kernel.org>
+Cc: Andrei Vagin <avagin@google.com>
+Cc: "Eric W. Biederman" <ebiederm@xmission.com>
+Cc: Alexey Gladkov <legion@kernel.org>
+Cc: Oleg Nesterov <oleg@redhat.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/ucount.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/kernel/ucount.c
++++ b/kernel/ucount.c
+@@ -318,7 +318,7 @@ long inc_rlimit_get_ucounts(struct ucoun
+ for (iter = ucounts; iter; iter = iter->ns->ucounts) {
+ long new = atomic_long_add_return(1, &iter->rlimit[type]);
+ if (new < 0 || new > max)
+- goto unwind;
++ goto dec_unwind;
+ if (iter == ucounts)
+ ret = new;
+ if (!override_rlimit)
+@@ -336,7 +336,6 @@ long inc_rlimit_get_ucounts(struct ucoun
+ dec_unwind:
+ dec = atomic_long_sub_return(1, &iter->rlimit[type]);
+ WARN_ON_ONCE(dec < 0);
+-unwind:
+ do_dec_rlimit_put_ucounts(ucounts, iter, type);
+ return 0;
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
