--- /dev/null
+From 07bb097b92b987db518e72525b515d77904e966e Mon Sep 17 00:00:00 2001
+From: Tom Lendacky <thomas.lendacky@amd.com>
+Date: Fri, 17 Jan 2025 17:05:47 -0600
+Subject: crypto: ccp - Fix check for the primary ASP device
+
+From: Tom Lendacky <thomas.lendacky@amd.com>
+
+commit 07bb097b92b987db518e72525b515d77904e966e upstream.
+
+Currently, the ASP primary device check does not have support for PCI
+domains, and, as a result, when the system is configured with PCI domains
+(PCI segments) the wrong device can be selected as primary. This results
+in commands submitted to the device timing out and failing. The device
+check also relies on specific device and function assignments that may
+not hold in the future.
+
+Fix the primary ASP device check to include support for PCI domains and
+to perform proper checking of the Bus/Device/Function positions.
+
+Fixes: 2a6170dfe755 ("crypto: ccp: Add Platform Security Processor (PSP) device support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/crypto/ccp/sp-pci.c | 15 +++++++++------
+ 1 file changed, 9 insertions(+), 6 deletions(-)
+
+--- a/drivers/crypto/ccp/sp-pci.c
++++ b/drivers/crypto/ccp/sp-pci.c
+@@ -118,14 +118,17 @@ static bool sp_pci_is_master(struct sp_d
+ pdev_new = to_pci_dev(dev_new);
+ pdev_cur = to_pci_dev(dev_cur);
+
+- if (pdev_new->bus->number < pdev_cur->bus->number)
+- return true;
++ if (pci_domain_nr(pdev_new->bus) != pci_domain_nr(pdev_cur->bus))
++ return pci_domain_nr(pdev_new->bus) < pci_domain_nr(pdev_cur->bus);
+
+- if (PCI_SLOT(pdev_new->devfn) < PCI_SLOT(pdev_cur->devfn))
+- return true;
++ if (pdev_new->bus->number != pdev_cur->bus->number)
++ return pdev_new->bus->number < pdev_cur->bus->number;
+
+- if (PCI_FUNC(pdev_new->devfn) < PCI_FUNC(pdev_cur->devfn))
+- return true;
++ if (PCI_SLOT(pdev_new->devfn) != PCI_SLOT(pdev_cur->devfn))
++ return PCI_SLOT(pdev_new->devfn) < PCI_SLOT(pdev_cur->devfn);
++
++ if (PCI_FUNC(pdev_new->devfn) != PCI_FUNC(pdev_cur->devfn))
++ return PCI_FUNC(pdev_new->devfn) < PCI_FUNC(pdev_cur->devfn);
+
+ return false;
+ }
--- /dev/null
+From 00204ae3d6712ee053353920e3ce2b00c35ef75b Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Mon, 10 Feb 2025 16:14:22 +0100
+Subject: dm-integrity: set ti->error on memory allocation failure
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 00204ae3d6712ee053353920e3ce2b00c35ef75b upstream.
+
+The dm-integrity target didn't set the error string when memory
+allocation failed. This patch fixes it.
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/dm-integrity.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/md/dm-integrity.c
++++ b/drivers/md/dm-integrity.c
+@@ -4303,16 +4303,19 @@ try_smaller_buffer:
+
+ ic->recalc_bitmap = dm_integrity_alloc_page_list(n_bitmap_pages);
+ if (!ic->recalc_bitmap) {
++ ti->error = "Could not allocate memory for bitmap";
+ r = -ENOMEM;
+ goto bad;
+ }
+ ic->may_write_bitmap = dm_integrity_alloc_page_list(n_bitmap_pages);
+ if (!ic->may_write_bitmap) {
++ ti->error = "Could not allocate memory for bitmap";
+ r = -ENOMEM;
+ goto bad;
+ }
+ ic->bbs = kvmalloc_array(ic->n_bitmap_blocks, sizeof(struct bitmap_block_status), GFP_KERNEL);
+ if (!ic->bbs) {
++ ti->error = "Could not allocate memory for bitmap";
+ r = -ENOMEM;
+ goto bad;
+ }
--- /dev/null
+From 42ea22e754ba4f2b86f8760ca27f6f71da2d982c Mon Sep 17 00:00:00 2001
+From: zhoumin <teczm@foxmail.com>
+Date: Tue, 1 Apr 2025 01:00:34 +0800
+Subject: ftrace: Add cond_resched() to ftrace_graph_set_hash()
+
+From: zhoumin <teczm@foxmail.com>
+
+commit 42ea22e754ba4f2b86f8760ca27f6f71da2d982c upstream.
+
+When the kernel contains a large number of functions that can be traced,
+the loop in ftrace_graph_set_hash() may take a lot of time to execute.
+This may trigger the softlockup watchdog.
+
+Add cond_resched() within the loop to allow the kernel to remain
+responsive even when processing a large number of functions.
+
+This matches the cond_resched() that is used in other locations of the
+code that iterates over all functions that can be traced.
+
+Cc: stable@vger.kernel.org
+Fixes: b9b0c831bed26 ("ftrace: Convert graph filter to use hash tables")
+Link: https://lore.kernel.org/tencent_3E06CE338692017B5809534B9C5C03DA7705@qq.com
+Signed-off-by: zhoumin <teczm@foxmail.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/ftrace.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/kernel/trace/ftrace.c
++++ b/kernel/trace/ftrace.c
+@@ -6096,6 +6096,7 @@ ftrace_graph_set_hash(struct ftrace_hash
+ }
+ }
+ }
++ cond_resched();
+ } while_for_each_ftrace_rec();
+ out:
+ mutex_unlock(&ftrace_lock);
--- /dev/null
+From c5672e310ad971d408752fce7596ed27adc6008f Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Sun, 6 Apr 2025 22:22:45 +0200
+Subject: gpio: zynq: Fix wakeup source leaks on device unbind
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit c5672e310ad971d408752fce7596ed27adc6008f upstream.
+
+Device can be unbound, so driver must also release memory for the wakeup
+source.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20250406202245.53854-2-krzysztof.kozlowski@linaro.org
+Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpio/gpio-zynq.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/gpio/gpio-zynq.c
++++ b/drivers/gpio/gpio-zynq.c
+@@ -1016,6 +1016,7 @@ static int zynq_gpio_remove(struct platf
+ ret = pm_runtime_get_sync(&pdev->dev);
+ if (ret < 0)
+ dev_warn(&pdev->dev, "pm_runtime_get_sync() Failed\n");
++ device_init_wakeup(&pdev->dev, 0);
+ gpiochip_remove(&gpio->chip);
+ clk_disable_unprepare(gpio->clk);
+ device_set_wakeup_capable(&pdev->dev, 0);
sparc-mm-disable-preemption-in-lazy-mmu-mode.patch
mm-add-missing-release-barrier-on-pgdat_reclaim_locked-unlock.patch
sctp-detect-and-prevent-references-to-a-freed-transport-in-sendmsg.patch
+thermal-drivers-rockchip-add-missing-rk3328-mapping-entry.patch
+crypto-ccp-fix-check-for-the-primary-asp-device.patch
+dm-integrity-set-ti-error-on-memory-allocation-failure.patch
+ftrace-add-cond_resched-to-ftrace_graph_set_hash.patch
+gpio-zynq-fix-wakeup-source-leaks-on-device-unbind.patch
--- /dev/null
+From ee022e5cae052e0c67ca7c5fec0f2e7bc897c70e Mon Sep 17 00:00:00 2001
+From: Trevor Woerner <twoerner@gmail.com>
+Date: Fri, 7 Feb 2025 12:50:47 -0500
+Subject: thermal/drivers/rockchip: Add missing rk3328 mapping entry
+
+From: Trevor Woerner <twoerner@gmail.com>
+
+commit ee022e5cae052e0c67ca7c5fec0f2e7bc897c70e upstream.
+
+The mapping table for the rk3328 is missing the entry for -25C which is
+found in the TRM section 9.5.2 "Temperature-to-code mapping".
+
+NOTE: the kernel uses the tsadc_q_sel=1'b1 mode which is defined as:
+ 4096-<code in table>. Whereas the table in the TRM gives the code
+ "3774" for -25C, the kernel uses 4096-3774=322.
+
+[Dragan Simic] : "After going through the RK3308 and RK3328 TRMs, as
+ well as through the downstream kernel code, it seems we may have
+ some troubles at our hands. Let me explain, please.
+
+ To sum it up, part 1 of the RK3308 TRM v1.1 says on page 538 that
+ the equation for the output when tsadc_q_sel equals 1 is (4096 -
+ tsadc_q), while part 1 of the RK3328 TRM v1.2 says that the output
+ equation is (1024 - tsadc_q) in that case.
+
+ The downstream kernel code, however, treats the RK3308 and RK3328
+ tables and their values as being the same. It even mentions 1024 as
+ the "offset" value in a comment block for the rk_tsadcv3_control()
+ function, just like the upstream code does, which is obviously wrong
+ "offset" value when correlated with the table on page 544 of part 1
+ of the RK3308 TRM v1.1.
+
+ With all this in mind, it's obvious that more work is needed to make
+ it clear where's the actual mistake (it could be that the TRM is
+ wrong), which I'll volunteer for as part of the SoC binning project.
+ In the meantime, this patch looks fine as-is to me, by offering
+ what's a clear improvement to the current state of the upstream
+ code"
+
+Link: https://opensource.rock-chips.com/images/9/97/Rockchip_RK3328TRM_V1.1-Part1-20170321.pdf
+Cc: stable@vger.kernel.org
+Fixes: eda519d5f73e ("thermal: rockchip: Support the RK3328 SOC in thermal driver")
+Signed-off-by: Trevor Woerner <twoerner@gmail.com>
+Reviewed-by: Dragan Simic <dsimic@manjaro.org>
+Link: https://lore.kernel.org/r/20250207175048.35959-1-twoerner@gmail.com
+Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/thermal/rockchip_thermal.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/thermal/rockchip_thermal.c
++++ b/drivers/thermal/rockchip_thermal.c
+@@ -363,6 +363,7 @@ static const struct tsadc_table rk3328_c
+ {296, -40000},
+ {304, -35000},
+ {313, -30000},
++ {322, -25000},
+ {331, -20000},
+ {340, -15000},
+ {349, -10000},
projects / thirdparty / kernel / stable-queue.git / commitdiff
