--- /dev/null
+From 496f9372eae14775e0524e83e952814691fe850a Mon Sep 17 00:00:00 2001
+From: Amir Mohammad Jahangirzad <a.jahangirzad@gmail.com>
+Date: Tue, 23 Sep 2025 05:01:13 +0330
+Subject: ACPI: debug: fix signedness issues in read/write helpers
+
+From: Amir Mohammad Jahangirzad <a.jahangirzad@gmail.com>
+
+commit 496f9372eae14775e0524e83e952814691fe850a upstream.
+
+In the ACPI debugger interface, the helper functions for read and write
+operations use "int" as the length parameter data type. When a large
+"size_t count" is passed from the file operations, this cast to "int"
+results in truncation and a negative value due to signed integer
+representation.
+
+Logically, this negative number propagates to the min() calculation,
+where it is selected over the positive buffer space value, leading to
+unexpected behavior. Subsequently, when this negative value is used in
+copy_to_user() or copy_from_user(), it is interpreted as a large positive
+value due to the unsigned nature of the size parameter in these functions,
+causing the copy operations to attempt handling sizes far beyond the
+intended buffer limits.
+
+Address the issue by:
+ - Changing the length parameters in acpi_aml_read_user() and
+ acpi_aml_write_user() from "int" to "size_t", aligning with the
+ expected unsigned size semantics.
+ - Updating return types and local variables in acpi_aml_read() and
+ acpi_aml_write() to "ssize_t" for consistency with kernel file
+ operation conventions.
+ - Using "size_t" for the "n" variable to ensure calculations remain
+ unsigned.
+ - Using min_t() for circ_count_to_end() and circ_space_to_end() to
+ ensure type-safe comparisons and prevent integer overflow.
+
+Signed-off-by: Amir Mohammad Jahangirzad <a.jahangirzad@gmail.com>
+Link: https://patch.msgid.link/20250923013113.20615-1-a.jahangirzad@gmail.com
+[ rjw: Changelog tweaks, local variable definitions ordering adjustments ]
+Fixes: 8cfb0cdf07e2 ("ACPI / debugger: Add IO interface to access debugger functionalities")
+Cc: 4.5+ <stable@vger.kernel.org> # 4.5+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/acpi_dbg.c | 26 +++++++++++++-------------
+ 1 file changed, 13 insertions(+), 13 deletions(-)
+
+--- a/drivers/acpi/acpi_dbg.c
++++ b/drivers/acpi/acpi_dbg.c
+@@ -569,11 +569,11 @@ static int acpi_aml_release(struct inode
+ return 0;
+ }
+
+-static int acpi_aml_read_user(char __user *buf, int len)
++static ssize_t acpi_aml_read_user(char __user *buf, size_t len)
+ {
+- int ret;
+ struct circ_buf *crc = &acpi_aml_io.out_crc;
+- int n;
++ ssize_t ret;
++ size_t n;
+ char *p;
+
+ ret = acpi_aml_lock_read(crc, ACPI_AML_OUT_USER);
+@@ -582,7 +582,7 @@ static int acpi_aml_read_user(char __use
+ /* sync head before removing logs */
+ smp_rmb();
+ p = &crc->buf[crc->tail];
+- n = min(len, circ_count_to_end(crc));
++ n = min_t(size_t, len, circ_count_to_end(crc));
+ if (copy_to_user(buf, p, n)) {
+ ret = -EFAULT;
+ goto out;
+@@ -599,8 +599,8 @@ out:
+ static ssize_t acpi_aml_read(struct file *file, char __user *buf,
+ size_t count, loff_t *ppos)
+ {
+- int ret = 0;
+- int size = 0;
++ ssize_t ret = 0;
++ ssize_t size = 0;
+
+ if (!count)
+ return 0;
+@@ -639,11 +639,11 @@ again:
+ return size > 0 ? size : ret;
+ }
+
+-static int acpi_aml_write_user(const char __user *buf, int len)
++static ssize_t acpi_aml_write_user(const char __user *buf, size_t len)
+ {
+- int ret;
+ struct circ_buf *crc = &acpi_aml_io.in_crc;
+- int n;
++ ssize_t ret;
++ size_t n;
+ char *p;
+
+ ret = acpi_aml_lock_write(crc, ACPI_AML_IN_USER);
+@@ -652,7 +652,7 @@ static int acpi_aml_write_user(const cha
+ /* sync tail before inserting cmds */
+ smp_mb();
+ p = &crc->buf[crc->head];
+- n = min(len, circ_space_to_end(crc));
++ n = min_t(size_t, len, circ_space_to_end(crc));
+ if (copy_from_user(p, buf, n)) {
+ ret = -EFAULT;
+ goto out;
+@@ -663,14 +663,14 @@ static int acpi_aml_write_user(const cha
+ ret = n;
+ out:
+ acpi_aml_unlock_fifo(ACPI_AML_IN_USER, ret >= 0);
+- return n;
++ return ret;
+ }
+
+ static ssize_t acpi_aml_write(struct file *file, const char __user *buf,
+ size_t count, loff_t *ppos)
+ {
+- int ret = 0;
+- int size = 0;
++ ssize_t ret = 0;
++ ssize_t size = 0;
+
+ if (!count)
+ return 0;
--- /dev/null
+From d0759b10989c5c5aae3d455458c9fc4e8cc694f7 Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Mon, 15 Sep 2025 20:21:33 +0200
+Subject: ACPI: property: Fix buffer properties extraction for subnodes
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+commit d0759b10989c5c5aae3d455458c9fc4e8cc694f7 upstream.
+
+The ACPI handle passed to acpi_extract_properties() as the first
+argument represents the ACPI namespace scope in which to look for
+objects returning buffers associated with buffer properties.
+
+For _DSD objects located immediately under ACPI devices, this handle is
+the same as the handle of the device object holding the _DSD, but for
+data-only subnodes it is not so.
+
+First of all, data-only subnodes are represented by objects that
+cannot hold other objects in their scopes (like control methods).
+Therefore a data-only subnode handle cannot be used for completing
+relative pathname segments, so the current code in
+in acpi_nondev_subnode_extract() passing a data-only subnode handle
+to acpi_extract_properties() is invalid.
+
+Moreover, a data-only subnode of device A may be represented by an
+object located in the scope of device B (which kind of makes sense,
+for instance, if A is a B's child). In that case, the scope in
+question would be the one of device B. In other words, the scope
+mentioned above is the same as the scope used for subnode object
+lookup in acpi_nondev_subnode_extract().
+
+Accordingly, rearrange that function to use the same scope for the
+extraction of properties and subnode object lookup.
+
+Fixes: 103e10c69c61 ("ACPI: property: Add support for parsing buffer property UUID")
+Cc: 6.0+ <stable@vger.kernel.org> # 6.0+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Tested-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/property.c | 30 +++++++++++-------------------
+ 1 file changed, 11 insertions(+), 19 deletions(-)
+
+--- a/drivers/acpi/property.c
++++ b/drivers/acpi/property.c
+@@ -83,6 +83,7 @@ static bool acpi_nondev_subnode_extract(
+ struct fwnode_handle *parent)
+ {
+ struct acpi_data_node *dn;
++ acpi_handle scope = NULL;
+ bool result;
+
+ if (acpi_graph_ignore_port(handle))
+@@ -98,27 +99,18 @@ static bool acpi_nondev_subnode_extract(
+ INIT_LIST_HEAD(&dn->data.properties);
+ INIT_LIST_HEAD(&dn->data.subnodes);
+
+- result = acpi_extract_properties(handle, desc, &dn->data);
++ /*
++ * The scope for the completion of relative pathname segments and
++ * subnode object lookup is the one of the namespace node (device)
++ * containing the object that has returned the package. That is, it's
++ * the scope of that object's parent device.
++ */
++ if (handle)
++ acpi_get_parent(handle, &scope);
+
+- if (handle) {
+- acpi_handle scope;
+- acpi_status status;
+-
+- /*
+- * The scope for the subnode object lookup is the one of the
+- * namespace node (device) containing the object that has
+- * returned the package. That is, it's the scope of that
+- * object's parent.
+- */
+- status = acpi_get_parent(handle, &scope);
+- if (ACPI_SUCCESS(status)
+- && acpi_enumerate_nondev_subnodes(scope, desc, &dn->data,
+- &dn->fwnode))
+- result = true;
+- } else if (acpi_enumerate_nondev_subnodes(NULL, desc, &dn->data,
+- &dn->fwnode)) {
++ result = acpi_extract_properties(scope, desc, &dn->data);
++ if (acpi_enumerate_nondev_subnodes(scope, desc, &dn->data, &dn->fwnode))
+ result = true;
+- }
+
+ if (result) {
+ dn->handle = handle;
--- /dev/null
+From 4aac453deca0d9c61df18d968f8864c3ae7d3d8d Mon Sep 17 00:00:00 2001
+From: Daniel Tang <danielzgtg.opensource@gmail.com>
+Date: Thu, 28 Aug 2025 01:38:14 -0400
+Subject: ACPI: TAD: Add missing sysfs_remove_group() for ACPI_TAD_RT
+
+From: Daniel Tang <danielzgtg.opensource@gmail.com>
+
+commit 4aac453deca0d9c61df18d968f8864c3ae7d3d8d upstream.
+
+Previously, after `rmmod acpi_tad`, `modprobe acpi_tad` would fail
+with this dmesg:
+
+sysfs: cannot create duplicate filename '/devices/platform/ACPI000E:00/time'
+Call Trace:
+ <TASK>
+ dump_stack_lvl+0x6c/0x90
+ dump_stack+0x10/0x20
+ sysfs_warn_dup+0x8b/0xa0
+ sysfs_add_file_mode_ns+0x122/0x130
+ internal_create_group+0x1dd/0x4c0
+ sysfs_create_group+0x13/0x20
+ acpi_tad_probe+0x147/0x1f0 [acpi_tad]
+ platform_probe+0x42/0xb0
+ </TASK>
+acpi-tad ACPI000E:00: probe with driver acpi-tad failed with error -17
+
+Fixes: 3230b2b3c1ab ("ACPI: TAD: Add low-level support for real time capability")
+Signed-off-by: Daniel Tang <danielzgtg.opensource@gmail.com>
+Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Link: https://patch.msgid.link/2881298.hMirdbgypa@daniel-desktop3
+Cc: 5.2+ <stable@vger.kernel.org> # 5.2+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/acpi_tad.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/acpi/acpi_tad.c
++++ b/drivers/acpi/acpi_tad.c
+@@ -565,6 +565,9 @@ static void acpi_tad_remove(struct platf
+
+ pm_runtime_get_sync(dev);
+
++ if (dd->capabilities & ACPI_TAD_RT)
++ sysfs_remove_group(&dev->kobj, &acpi_tad_time_attr_group);
++
+ if (dd->capabilities & ACPI_TAD_DC_WAKE)
+ sysfs_remove_group(&dev->kobj, &acpi_tad_dc_attr_group);
+
--- /dev/null
+From 8a6506e1ba0d2b831729808d958aae77604f12f9 Mon Sep 17 00:00:00 2001
+From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
+Date: Thu, 17 Jul 2025 17:27:03 +0200
+Subject: ARM: AM33xx: Implement TI advisory 1.0.36 (EMU0/EMU1 pins state on reset)
+
+From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
+
+commit 8a6506e1ba0d2b831729808d958aae77604f12f9 upstream.
+
+There is an issue possible where TI AM33xx SoCs do not boot properly after
+a reset if EMU0/EMU1 pins were used as GPIO and have been driving low level
+actively prior to reset [1].
+
+"Advisory 1.0.36 EMU0 and EMU1: Terminals Must be Pulled High Before
+ICEPick Samples
+
+The state of the EMU[1:0] terminals are latched during reset to determine
+ICEPick boot mode. For normal device operation, these terminals must be
+pulled up to a valid high logic level ( > VIH min) before ICEPick samples
+the state of these terminals, which occurs
+[five CLK_M_OSC clock cycles - 10 ns] after the falling edge of WARMRSTn.
+
+Many applications may not require the secondary GPIO function of the
+EMU[1:0] terminals. In this case, they would only be connected to pull-up
+resistors, which ensures they are always high when ICEPick samples.
+However, some applications may need to use these terminals as GPIO where
+they could be driven low before reset is asserted. This usage of the
+EMU[1:0] terminals may require special attention to ensure the terminals
+are allowed to return to a valid high-logic level before ICEPick samples
+the state of these terminals.
+
+When any device reset is asserted, the pin mux mode of EMU[1:0] terminals
+configured to operate as GPIO (mode 7) will change back to EMU input
+(mode 0) on the falling edge of WARMRSTn. This only provides a short period
+of time for the terminals to return high if driven low before reset is
+asserted...
+
+If the EMU[1:0] terminals are configured to operate as GPIO, the product
+should be designed such these terminals can be pulled to a valid high-logic
+level within 190 ns after the falling edge of WARMRSTn."
+
+We've noticed this problem with custom am335x hardware in combination with
+recently implemented cold reset method
+(commit 6521f6a195c70 ("ARM: AM33xx: PRM: Implement REBOOT_COLD")).
+It looks like the problem can affect other HW, for instance AM335x
+Chiliboard, because the latter has LEDs on GPIO3_7/GPIO3_8 as well.
+
+One option would be to check if the pins are in GPIO mode and either switch
+to output active high, or switch to input and poll until the external
+pull-ups have brought the pins to the desired high state. But fighting
+with GPIO driver for these pins is probably not the most straight forward
+approch in a reboot handler.
+
+Fortunately we can easily control pinmuxing here and rely on the external
+pull-ups. TI recommends 4k7 external pull up resistors [2] and even with
+quite conservative estimation for pin capacity (1 uF should never happen)
+the required delay shall not exceed 5ms.
+
+[1] Link: https://www.ti.com/lit/pdf/sprz360
+[2] Link: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/866346/am3352-emu-1-0-questions
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
+Link: https://lore.kernel.org/r/20250717152708.487891-1-alexander.sverdlin@siemens.com
+Signed-off-by: Kevin Hilman <khilman@baylibre.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/mach-omap2/am33xx-restart.c | 36 +++++++++++++++++++++++++++++++++++
+ 1 file changed, 36 insertions(+)
+
+--- a/arch/arm/mach-omap2/am33xx-restart.c
++++ b/arch/arm/mach-omap2/am33xx-restart.c
+@@ -2,12 +2,46 @@
+ /*
+ * am33xx-restart.c - Code common to all AM33xx machines.
+ */
++#include <dt-bindings/pinctrl/am33xx.h>
++#include <linux/delay.h>
+ #include <linux/kernel.h>
+ #include <linux/reboot.h>
+
+ #include "common.h"
++#include "control.h"
+ #include "prm.h"
+
++/*
++ * Advisory 1.0.36 EMU0 and EMU1: Terminals Must be Pulled High Before
++ * ICEPick Samples
++ *
++ * If EMU0/EMU1 pins have been used as GPIO outputs and actively driving low
++ * level, the device might not reboot in normal mode. We are in a bad position
++ * to override GPIO state here, so just switch the pins into EMU input mode
++ * (that's what reset will do anyway) and wait a bit, because the state will be
++ * latched 190 ns after reset.
++ */
++static void am33xx_advisory_1_0_36(void)
++{
++ u32 emu0 = omap_ctrl_readl(AM335X_PIN_EMU0);
++ u32 emu1 = omap_ctrl_readl(AM335X_PIN_EMU1);
++
++ /* If both pins are in EMU mode, nothing to do */
++ if (!(emu0 & 7) && !(emu1 & 7))
++ return;
++
++ /* Switch GPIO3_7/GPIO3_8 into EMU0/EMU1 modes respectively */
++ omap_ctrl_writel(emu0 & ~7, AM335X_PIN_EMU0);
++ omap_ctrl_writel(emu1 & ~7, AM335X_PIN_EMU1);
++
++ /*
++ * Give pull-ups time to load the pin/PCB trace capacity.
++ * 5 ms shall be enough to load 1 uF (would be huge capacity for these
++ * pins) with TI-recommended 4k7 external pull-ups.
++ */
++ mdelay(5);
++}
++
+ /**
+ * am33xx_restart - trigger a software restart of the SoC
+ * @mode: the "reboot mode", see arch/arm/kernel/{setup,process}.c
+@@ -18,6 +52,8 @@
+ */
+ void am33xx_restart(enum reboot_mode mode, const char *cmd)
+ {
++ am33xx_advisory_1_0_36();
++
+ /* TODO: Handle cmd if necessary */
+ prm_reboot_mode = mode;
+
--- /dev/null
+From 74139a64e8cedb6d971c78d5d17384efeced1725 Mon Sep 17 00:00:00 2001
+From: Miaoqian Lin <linmq006@gmail.com>
+Date: Tue, 2 Sep 2025 15:59:43 +0800
+Subject: ARM: OMAP2+: pm33xx-core: ix device node reference leaks in amx3_idle_init
+
+From: Miaoqian Lin <linmq006@gmail.com>
+
+commit 74139a64e8cedb6d971c78d5d17384efeced1725 upstream.
+
+Add missing of_node_put() calls to release
+device node references obtained via of_parse_phandle().
+
+Fixes: 06ee7a950b6a ("ARM: OMAP2+: pm33xx-core: Add cpuidle_ops for am335x/am437x")
+Cc: stable@vger.kernel.org
+Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
+Link: https://lore.kernel.org/r/20250902075943.2408832-1-linmq006@gmail.com
+Signed-off-by: Kevin Hilman <khilman@baylibre.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/mach-omap2/pm33xx-core.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/arch/arm/mach-omap2/pm33xx-core.c
++++ b/arch/arm/mach-omap2/pm33xx-core.c
+@@ -388,12 +388,15 @@ static int __init amx3_idle_init(struct
+ if (!state_node)
+ break;
+
+- if (!of_device_is_available(state_node))
++ if (!of_device_is_available(state_node)) {
++ of_node_put(state_node);
+ continue;
++ }
+
+ if (i == CPUIDLE_STATE_MAX) {
+ pr_warn("%s: cpuidle states reached max possible\n",
+ __func__);
++ of_node_put(state_node);
+ break;
+ }
+
+@@ -403,6 +406,7 @@ static int __init amx3_idle_init(struct
+ states[state_count].wfi_flags |= WFI_FLAG_WAKE_M3 |
+ WFI_FLAG_FLUSH_CACHE;
+
++ of_node_put(state_node);
+ state_count++;
+ }
+
--- /dev/null
+From 99b78773c2ae55dcc01025f94eae8ce9700ae985 Mon Sep 17 00:00:00 2001
+From: Stephan Gerhold <stephan.gerhold@linaro.org>
+Date: Mon, 15 Sep 2025 15:28:30 +0200
+Subject: arm64: dts: qcom: msm8916: Add missing MDSS reset
+
+From: Stephan Gerhold <stephan.gerhold@linaro.org>
+
+commit 99b78773c2ae55dcc01025f94eae8ce9700ae985 upstream.
+
+On most MSM8916 devices (aside from the DragonBoard 410c), the bootloader
+already initializes the display to show the boot splash screen. In this
+situation, MDSS is already configured and left running when starting Linux.
+To avoid side effects from the bootloader configuration, the MDSS reset can
+be specified in the device tree to start again with a clean hardware state.
+
+The reset for MDSS is currently missing in msm8916.dtsi, which causes
+errors when the MDSS driver tries to re-initialize the registers:
+
+ dsi_err_worker: status=6
+ dsi_err_worker: status=6
+ dsi_err_worker: status=6
+ ...
+
+It turns out that we have always indirectly worked around this by building
+the MDSS driver as a module. Before v6.17, the power domain was temporarily
+turned off until the module was loaded, long enough to clear the register
+contents. In v6.17, power domains are not turned off during boot until
+sync_state() happens, so this is no longer working. Even before v6.17 this
+resulted in broken behavior, but notably only when the MDSS driver was
+built-in instead of a module.
+
+Cc: stable@vger.kernel.org
+Fixes: 305410ffd1b2 ("arm64: dts: msm8916: Add display support")
+Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
+Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Link: https://lore.kernel.org/r/20250915-msm8916-resets-v1-1-a5c705df0c45@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
++++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
+@@ -1540,6 +1540,8 @@
+
+ interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
+
++ resets = <&gcc GCC_MDSS_BCR>;
++
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
--- /dev/null
+From f73c82c855e186e9b67125e3eee743960320e43c Mon Sep 17 00:00:00 2001
+From: Stephan Gerhold <stephan.gerhold@linaro.org>
+Date: Mon, 15 Sep 2025 15:28:31 +0200
+Subject: arm64: dts: qcom: msm8939: Add missing MDSS reset
+
+From: Stephan Gerhold <stephan.gerhold@linaro.org>
+
+commit f73c82c855e186e9b67125e3eee743960320e43c upstream.
+
+On most MSM8939 devices, the bootloader already initializes the display to
+show the boot splash screen. In this situation, MDSS is already configured
+and left running when starting Linux. To avoid side effects from the
+bootloader configuration, the MDSS reset can be specified in the device
+tree to start again with a clean hardware state.
+
+The reset for MDSS is currently missing in msm8939.dtsi, which causes
+errors when the MDSS driver tries to re-initialize the registers:
+
+ dsi_err_worker: status=6
+ dsi_err_worker: status=6
+ dsi_err_worker: status=6
+ ...
+
+It turns out that we have always indirectly worked around this by building
+the MDSS driver as a module. Before v6.17, the power domain was temporarily
+turned off until the module was loaded, long enough to clear the register
+contents. In v6.17, power domains are not turned off during boot until
+sync_state() happens, so this is no longer working. Even before v6.17 this
+resulted in broken behavior, but notably only when the MDSS driver was
+built-in instead of a module.
+
+Cc: stable@vger.kernel.org
+Fixes: 61550c6c156c ("arm64: dts: qcom: Add msm8939 SoC")
+Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
+Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Link: https://lore.kernel.org/r/20250915-msm8916-resets-v1-2-a5c705df0c45@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/msm8939.dtsi | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/arm64/boot/dts/qcom/msm8939.dtsi
++++ b/arch/arm64/boot/dts/qcom/msm8939.dtsi
+@@ -1218,6 +1218,8 @@
+
+ power-domains = <&gcc MDSS_GDSC>;
+
++ resets = <&gcc GCC_MDSS_BCR>;
++
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <1>;
--- /dev/null
+From 316294bb6695a43a9181973ecd4e6fb3e576a9f7 Mon Sep 17 00:00:00 2001
+From: Stephan Gerhold <stephan.gerhold@linaro.org>
+Date: Thu, 21 Aug 2025 10:15:09 +0200
+Subject: arm64: dts: qcom: sdm845: Fix slimbam num-channels/ees
+
+From: Stephan Gerhold <stephan.gerhold@linaro.org>
+
+commit 316294bb6695a43a9181973ecd4e6fb3e576a9f7 upstream.
+
+Reading the hardware registers of the &slimbam on RB3 reveals that the BAM
+supports only 23 pipes (channels) and supports 4 EEs instead of 2. This
+hasn't caused problems so far since nothing is using the extra channels,
+but attempting to use them would lead to crashes.
+
+The bam_dma driver might warn in the future if the num-channels in the DT
+are wrong, so correct the properties in the DT to avoid future regressions.
+
+Cc: stable@vger.kernel.org
+Fixes: 27ca1de07dc3 ("arm64: dts: qcom: sdm845: add slimbus nodes")
+Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
+Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
+Link: https://lore.kernel.org/r/20250821-sdm845-slimbam-channels-v1-1-498f7d46b9ee@linaro.org
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
++++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
+@@ -5365,11 +5365,11 @@
+ compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0";
+ qcom,controlled-remotely;
+ reg = <0 0x17184000 0 0x2a000>;
+- num-channels = <31>;
++ num-channels = <23>;
+ interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
+ #dma-cells = <1>;
+ qcom,ee = <1>;
+- qcom,num-ees = <2>;
++ qcom,num-ees = <4>;
+ iommus = <&apps_smmu 0x1806 0x0>;
+ };
+
--- /dev/null
+From b9a185198f96259311543b30d884d8c01da913f7 Mon Sep 17 00:00:00 2001
+From: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
+Date: Tue, 1 Jul 2025 20:35:53 +0200
+Subject: arm64: dts: qcom: x1e80100-pmics: Disable pm8010 by default
+
+From: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
+
+commit b9a185198f96259311543b30d884d8c01da913f7 upstream.
+
+pm8010 is a camera specific PMIC, and may not be present on some
+devices. These may instead use a dedicated vreg for this purpose (Dell
+XPS 9345, Dell Inspiron..) or use USB webcam instead of a MIPI one
+alltogether (Lenovo Thinbook 16, Lenovo Yoga..).
+
+Disable pm8010 by default, let platforms that actually have one onboard
+enable it instead.
+
+Cc: stable@vger.kernel.org
+Fixes: 2559e61e7ef4 ("arm64: dts: qcom: x1e80100-pmics: Add the missing PMICs")
+Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
+Link: https://lore.kernel.org/r/20250701183625.1968246-2-alex.vinarskis@gmail.com
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi
++++ b/arch/arm64/boot/dts/qcom/x1e80100-pmics.dtsi
+@@ -475,6 +475,8 @@
+ #address-cells = <1>;
+ #size-cells = <0>;
+
++ status = "disabled";
++
+ pm8010_temp_alarm: temp-alarm@2400 {
+ compatible = "qcom,spmi-temp-alarm";
+ reg = <0x2400>;
--- /dev/null
+From 4c4e48afb6d85c1a8f9fdbae1fdf17ceef4a6f5b Mon Sep 17 00:00:00 2001
+From: Vibhore Vardhan <vibhore@ti.com>
+Date: Wed, 3 Sep 2025 11:55:12 +0530
+Subject: arm64: dts: ti: k3-am62a-main: Fix main padcfg length
+
+From: Vibhore Vardhan <vibhore@ti.com>
+
+commit 4c4e48afb6d85c1a8f9fdbae1fdf17ceef4a6f5b upstream.
+
+The main pad configuration register region starts with the register
+MAIN_PADCFG_CTRL_MMR_CFG0_PADCONFIG0 with address 0x000f4000 and ends
+with the MAIN_PADCFG_CTRL_MMR_CFG0_PADCONFIG150 register with address
+0x000f4258, as a result of which, total size of the region is 0x25c
+instead of 0x2ac.
+
+Reference Docs
+TRM (AM62A) - https://www.ti.com/lit/ug/spruj16b/spruj16b.pdf
+TRM (AM62D) - https://www.ti.com/lit/ug/sprujd4/sprujd4.pdf
+
+Fixes: 5fc6b1b62639c ("arm64: dts: ti: Introduce AM62A7 family of SoCs")
+Cc: stable@vger.kernel.org
+Signed-off-by: Vibhore Vardhan <vibhore@ti.com>
+Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
+Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
+Link: https://patch.msgid.link/20250903062513.813925-2-p-bhagat@ti.com
+Signed-off-by: Nishanth Menon <nm@ti.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
++++ b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
+@@ -258,7 +258,7 @@
+
+ main_pmx0: pinctrl@f4000 {
+ compatible = "pinctrl-single";
+- reg = <0x00 0xf4000 0x00 0x2ac>;
++ reg = <0x00 0xf4000 0x00 0x25c>;
+ #pinctrl-cells = <1>;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0xffffffff>;
--- /dev/null
+From 195a1b7d8388c0ec2969a39324feb8bebf9bb907 Mon Sep 17 00:00:00 2001
+From: Yang Shi <yang@os.amperecomputing.com>
+Date: Thu, 18 Sep 2025 09:23:49 -0700
+Subject: arm64: kprobes: call set_memory_rox() for kprobe page
+
+From: Yang Shi <yang@os.amperecomputing.com>
+
+commit 195a1b7d8388c0ec2969a39324feb8bebf9bb907 upstream.
+
+The kprobe page is allocated by execmem allocator with ROX permission.
+It needs to call set_memory_rox() to set proper permission for the
+direct map too. It was missed.
+
+Fixes: 10d5e97c1bf8 ("arm64: use PAGE_KERNEL_ROX directly in alloc_insn_page")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Yang Shi <yang@os.amperecomputing.com>
+Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/kernel/probes/kprobes.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/arch/arm64/kernel/probes/kprobes.c
++++ b/arch/arm64/kernel/probes/kprobes.c
+@@ -10,6 +10,7 @@
+
+ #define pr_fmt(fmt) "kprobes: " fmt
+
++#include <linux/execmem.h>
+ #include <linux/extable.h>
+ #include <linux/kasan.h>
+ #include <linux/kernel.h>
+@@ -41,6 +42,17 @@ DEFINE_PER_CPU(struct kprobe_ctlblk, kpr
+ static void __kprobes
+ post_kprobe_handler(struct kprobe *, struct kprobe_ctlblk *, struct pt_regs *);
+
++void *alloc_insn_page(void)
++{
++ void *addr;
++
++ addr = execmem_alloc(EXECMEM_KPROBES, PAGE_SIZE);
++ if (!addr)
++ return NULL;
++ set_memory_rox((unsigned long)addr, 1);
++ return addr;
++}
++
+ static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
+ {
+ kprobe_opcode_t *addr = p->ainsn.api.insn;
--- /dev/null
+From b3fe1c83a56f3cb7c475747ee1c6ec5a9dd5f60e Mon Sep 17 00:00:00 2001
+From: Robin Murphy <robin.murphy@arm.com>
+Date: Thu, 18 Sep 2025 17:25:31 +0100
+Subject: perf/arm-cmn: Fix CMN S3 DTM offset
+
+From: Robin Murphy <robin.murphy@arm.com>
+
+commit b3fe1c83a56f3cb7c475747ee1c6ec5a9dd5f60e upstream.
+
+CMN S3's DTM offset is different between r0px and r1p0, and it
+turns out this was not a error in the earlier documentation, but
+does actually exist in the design. Lovely.
+
+Cc: stable@vger.kernel.org
+Fixes: 0dc2f4963f7e ("perf/arm-cmn: Support CMN S3")
+Signed-off-by: Robin Murphy <robin.murphy@arm.com>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/perf/arm-cmn.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+--- a/drivers/perf/arm-cmn.c
++++ b/drivers/perf/arm-cmn.c
+@@ -65,7 +65,7 @@
+ /* PMU registers occupy the 3rd 4KB page of each node's region */
+ #define CMN_PMU_OFFSET 0x2000
+ /* ...except when they don't :( */
+-#define CMN_S3_DTM_OFFSET 0xa000
++#define CMN_S3_R1_DTM_OFFSET 0xa000
+ #define CMN_S3_PMU_OFFSET 0xd900
+
+ /* For most nodes, this is all there is */
+@@ -233,6 +233,9 @@ enum cmn_revision {
+ REV_CMN700_R1P0,
+ REV_CMN700_R2P0,
+ REV_CMN700_R3P0,
++ REV_CMNS3_R0P0 = 0,
++ REV_CMNS3_R0P1,
++ REV_CMNS3_R1P0,
+ REV_CI700_R0P0 = 0,
+ REV_CI700_R1P0,
+ REV_CI700_R2P0,
+@@ -425,8 +428,8 @@ static enum cmn_model arm_cmn_model(cons
+ static int arm_cmn_pmu_offset(const struct arm_cmn *cmn, const struct arm_cmn_node *dn)
+ {
+ if (cmn->part == PART_CMN_S3) {
+- if (dn->type == CMN_TYPE_XP)
+- return CMN_S3_DTM_OFFSET;
++ if (cmn->rev >= REV_CMNS3_R1P0 && dn->type == CMN_TYPE_XP)
++ return CMN_S3_R1_DTM_OFFSET;
+ return CMN_S3_PMU_OFFSET;
+ }
+ return CMN_PMU_OFFSET;
bpf-avoid-rcu-context-warning-when-unpinning-htab-wi.patch
s390-vmlinux.lds.s-reorder-sections.patch
s390-vmlinux.lds.s-move-.vmlinux.info-to-end-of-allo.patch
+acpi-property-fix-buffer-properties-extraction-for-subnodes.patch
+acpi-tad-add-missing-sysfs_remove_group-for-acpi_tad_rt.patch
+acpi-debug-fix-signedness-issues-in-read-write-helpers.patch
+arm64-dts-qcom-msm8916-add-missing-mdss-reset.patch
+arm64-dts-qcom-msm8939-add-missing-mdss-reset.patch
+arm64-dts-qcom-sdm845-fix-slimbam-num-channels-ees.patch
+arm64-dts-qcom-x1e80100-pmics-disable-pm8010-by-default.patch
+arm64-dts-ti-k3-am62a-main-fix-main-padcfg-length.patch
+arm64-kprobes-call-set_memory_rox-for-kprobe-page.patch
+arm-am33xx-implement-ti-advisory-1.0.36-emu0-emu1-pins-state-on-reset.patch
+arm-omap2-pm33xx-core-ix-device-node-reference-leaks-in-amx3_idle_init.patch
+perf-arm-cmn-fix-cmn-s3-dtm-offset.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
