--- /dev/null
+From 399dbcadc01ebf0035f325eaa8c264f8b5cd0a14 Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Sun, 28 Sep 2025 12:18:29 +0200
+Subject: ACPI: battery: Add synchronization between interface updates
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+commit 399dbcadc01ebf0035f325eaa8c264f8b5cd0a14 upstream.
+
+There is no synchronization between different code paths in the ACPI
+battery driver that update its sysfs interface or its power supply
+class device interface. In some cases this results to functional
+failures due to race conditions.
+
+One example of this is when two ACPI notifications:
+
+ - ACPI_BATTERY_NOTIFY_STATUS (0x80)
+ - ACPI_BATTERY_NOTIFY_INFO (0x81)
+
+are triggered (by the platform firmware) in a row with a little delay
+in between after removing and reinserting a laptop battery. Both
+notifications cause acpi_battery_update() to be called and if the delay
+between them is sufficiently small, sysfs_add_battery() can be re-entered
+before battery->bat is set which leads to a duplicate sysfs entry error:
+
+ sysfs: cannot create duplicate filename '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT1'
+ CPU: 1 UID: 0 PID: 185 Comm: kworker/1:4 Kdump: loaded Not tainted 6.12.38+deb13-amd64 #1 Debian 6.12.38-1
+ Hardware name: Gateway NV44 /SJV40-MV , BIOS V1.3121 04/08/2009
+ Workqueue: kacpi_notify acpi_os_execute_deferred
+ Call Trace:
+ <TASK>
+ dump_stack_lvl+0x5d/0x80
+ sysfs_warn_dup.cold+0x17/0x23
+ sysfs_create_dir_ns+0xce/0xe0
+ kobject_add_internal+0xba/0x250
+ kobject_add+0x96/0xc0
+ ? get_device_parent+0xde/0x1e0
+ device_add+0xe2/0x870
+ __power_supply_register.part.0+0x20f/0x3f0
+ ? wake_up_q+0x4e/0x90
+ sysfs_add_battery+0xa4/0x1d0 [battery]
+ acpi_battery_update+0x19e/0x290 [battery]
+ acpi_battery_notify+0x50/0x120 [battery]
+ acpi_ev_notify_dispatch+0x49/0x70
+ acpi_os_execute_deferred+0x1a/0x30
+ process_one_work+0x177/0x330
+ worker_thread+0x251/0x390
+ ? __pfx_worker_thread+0x10/0x10
+ kthread+0xd2/0x100
+ ? __pfx_kthread+0x10/0x10
+ ret_from_fork+0x34/0x50
+ ? __pfx_kthread+0x10/0x10
+ ret_from_fork_asm+0x1a/0x30
+ </TASK>
+ kobject: kobject_add_internal failed for BAT1 with -EEXIST, don't try to register things with the same name in the same directory.
+
+There are also other scenarios in which analogous issues may occur.
+
+Address this by using a common lock in all of the code paths leading
+to updates of driver interfaces: ACPI Notify () handler, system resume
+callback and post-resume notification, device addition and removal.
+
+This new lock replaces sysfs_lock that has been used only in
+sysfs_remove_battery() which now is going to be always called under
+the new lock, so it doesn't need any internal locking any more.
+
+Fixes: 10666251554c ("ACPI: battery: Install Notify() handler directly")
+Closes: https://lore.kernel.org/linux-acpi/20250910142653.313360-1-luogf2025@163.com/
+Reported-by: GuangFei Luo <luogf2025@163.com>
+Tested-by: GuangFei Luo <luogf2025@163.com>
+Cc: 6.6+ <stable@vger.kernel.org> # 6.6+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/battery.c | 43 +++++++++++++++++++++++++++++--------------
+ 1 file changed, 29 insertions(+), 14 deletions(-)
+
+--- a/drivers/acpi/battery.c
++++ b/drivers/acpi/battery.c
+@@ -92,7 +92,7 @@ enum {
+
+ struct acpi_battery {
+ struct mutex lock;
+- struct mutex sysfs_lock;
++ struct mutex update_lock;
+ struct power_supply *bat;
+ struct power_supply_desc bat_desc;
+ struct acpi_device *device;
+@@ -904,15 +904,12 @@ static int sysfs_add_battery(struct acpi
+
+ static void sysfs_remove_battery(struct acpi_battery *battery)
+ {
+- mutex_lock(&battery->sysfs_lock);
+- if (!battery->bat) {
+- mutex_unlock(&battery->sysfs_lock);
++ if (!battery->bat)
+ return;
+- }
++
+ battery_hook_remove_battery(battery);
+ power_supply_unregister(battery->bat);
+ battery->bat = NULL;
+- mutex_unlock(&battery->sysfs_lock);
+ }
+
+ static void find_battery(const struct dmi_header *dm, void *private)
+@@ -1072,6 +1069,9 @@ static void acpi_battery_notify(acpi_han
+
+ if (!battery)
+ return;
++
++ guard(mutex)(&battery->update_lock);
++
+ old = battery->bat;
+ /*
+ * On Acer Aspire V5-573G notifications are sometimes triggered too
+@@ -1094,21 +1094,22 @@ static void acpi_battery_notify(acpi_han
+ }
+
+ static int battery_notify(struct notifier_block *nb,
+- unsigned long mode, void *_unused)
++ unsigned long mode, void *_unused)
+ {
+ struct acpi_battery *battery = container_of(nb, struct acpi_battery,
+ pm_nb);
+- int result;
+
+- switch (mode) {
+- case PM_POST_HIBERNATION:
+- case PM_POST_SUSPEND:
++ if (mode == PM_POST_SUSPEND || mode == PM_POST_HIBERNATION) {
++ guard(mutex)(&battery->update_lock);
++
+ if (!acpi_battery_present(battery))
+ return 0;
+
+ if (battery->bat) {
+ acpi_battery_refresh(battery);
+ } else {
++ int result;
++
+ result = acpi_battery_get_info(battery);
+ if (result)
+ return result;
+@@ -1120,7 +1121,6 @@ static int battery_notify(struct notifie
+
+ acpi_battery_init_alarm(battery);
+ acpi_battery_get_state(battery);
+- break;
+ }
+
+ return 0;
+@@ -1198,6 +1198,8 @@ static int acpi_battery_update_retry(str
+ {
+ int retry, ret;
+
++ guard(mutex)(&battery->update_lock);
++
+ for (retry = 5; retry; retry--) {
+ ret = acpi_battery_update(battery, false);
+ if (!ret)
+@@ -1208,6 +1210,13 @@ static int acpi_battery_update_retry(str
+ return ret;
+ }
+
++static void sysfs_battery_cleanup(struct acpi_battery *battery)
++{
++ guard(mutex)(&battery->update_lock);
++
++ sysfs_remove_battery(battery);
++}
++
+ static int acpi_battery_add(struct acpi_device *device)
+ {
+ int result = 0;
+@@ -1230,7 +1239,7 @@ static int acpi_battery_add(struct acpi_
+ if (result)
+ return result;
+
+- result = devm_mutex_init(&device->dev, &battery->sysfs_lock);
++ result = devm_mutex_init(&device->dev, &battery->update_lock);
+ if (result)
+ return result;
+
+@@ -1262,7 +1271,7 @@ fail_pm:
+ device_init_wakeup(&device->dev, 0);
+ unregister_pm_notifier(&battery->pm_nb);
+ fail:
+- sysfs_remove_battery(battery);
++ sysfs_battery_cleanup(battery);
+
+ return result;
+ }
+@@ -1281,6 +1290,9 @@ static void acpi_battery_remove(struct a
+
+ device_init_wakeup(&device->dev, 0);
+ unregister_pm_notifier(&battery->pm_nb);
++
++ guard(mutex)(&battery->update_lock);
++
+ sysfs_remove_battery(battery);
+ }
+
+@@ -1297,6 +1309,9 @@ static int acpi_battery_resume(struct de
+ return -EINVAL;
+
+ battery->update_time = 0;
++
++ guard(mutex)(&battery->update_lock);
++
+ acpi_battery_update(battery, true);
+ return 0;
+ }
--- /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 16ae95800b1cc46c0d69d8d90c9c7be488421a40 Mon Sep 17 00:00:00 2001
+From: Ahmed Salem <x0rw3ll@gmail.com>
+Date: Fri, 12 Sep 2025 21:58:25 +0200
+Subject: ACPICA: acpidump: drop ACPI_NONSTRING attribute from file_name
+
+From: Ahmed Salem <x0rw3ll@gmail.com>
+
+commit 16ae95800b1cc46c0d69d8d90c9c7be488421a40 upstream.
+
+Partially revert commit 70662db73d54 ("ACPICA: Apply ACPI_NONSTRING in
+more places") as I've yet again incorrectly applied the ACPI_NONSTRING
+attribute where it is not needed.
+
+A warning was initially reported by Collin Funk [1], and further review
+by Jiri Slaby [2] highlighted another issue related to the same commit.
+
+Drop the ACPI_NONSTRING attribute to fix the issue.
+
+Fixes: 70662db73d54 ("ACPICA: Apply ACPI_NONSTRING in more places")
+Link: https://lore.kernel.org/all/87ecvpcypw.fsf@gmail.com [1]
+Link: https://lore.kernel.org/all/5c210121-c9b8-4458-b1ad-0da24732ac72@kernel.org [2]
+Link: https://github.com/acpica/acpica/commit/a6ee09ca
+Reported-by: Collin Funk <collin.funk1@gmail.com>
+Signed-off-by: Ahmed Salem <x0rw3ll@gmail.com>
+Cc: 6.16+ <stable@vger.kernel.org> # 6.16+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/power/acpi/tools/acpidump/apfiles.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/tools/power/acpi/tools/acpidump/apfiles.c
++++ b/tools/power/acpi/tools/acpidump/apfiles.c
+@@ -103,7 +103,7 @@ int ap_open_output_file(char *pathname)
+
+ int ap_write_to_binary_file(struct acpi_table_header *table, u32 instance)
+ {
+- char filename[ACPI_NAMESEG_SIZE + 16] ACPI_NONSTRING;
++ char filename[ACPI_NAMESEG_SIZE + 16];
+ char instance_str[16];
+ ACPI_FILE file;
+ acpi_size actual;
--- /dev/null
+From 22c65572eff14a6e9546a9dbaa333619eb5505ab Mon Sep 17 00:00:00 2001
+From: Ahmed Salem <x0rw3ll@gmail.com>
+Date: Fri, 12 Sep 2025 21:59:17 +0200
+Subject: ACPICA: Debugger: drop ACPI_NONSTRING attribute from name_seg
+
+From: Ahmed Salem <x0rw3ll@gmail.com>
+
+commit 22c65572eff14a6e9546a9dbaa333619eb5505ab upstream.
+
+ACPICA commit 4623b3369f3aa1ec5229d461e91c514510a96912
+
+Partially revert commit 70662db73d54 ("ACPICA: Apply ACPI_NONSTRING in
+more places") as I've yet again incorrectly applied the ACPI_NONSTRING
+attribute where it is not needed.
+
+A warning was initially reported by Collin Funk [1], and further review
+by Jiri Slaby [2] highlighted another issue related to the same commit.
+
+Drop the ACPI_NONSTRING attribute to fix the issue.
+
+Fixes: 70662db73d54 ("ACPICA: Apply ACPI_NONSTRING in more places")
+Link: https://lore.kernel.org/all/87ecvpcypw.fsf@gmail.com [1]
+Link: https://lore.kernel.org/all/5c210121-c9b8-4458-b1ad-0da24732ac72@kernel.org [2]
+Link: https://github.com/acpica/acpica/commit/4623b336
+Reported-by: Jiri Slaby <jirislaby@kernel.org>
+Signed-off-by: Ahmed Salem <x0rw3ll@gmail.com>
+Cc: 6.16+ <stable@vger.kernel.org> # 6.16+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/acpica/acdebug.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/acpi/acpica/acdebug.h
++++ b/drivers/acpi/acpica/acdebug.h
+@@ -37,7 +37,7 @@ struct acpi_db_argument_info {
+ struct acpi_db_execute_walk {
+ u32 count;
+ u32 max_count;
+- char name_seg[ACPI_NAMESEG_SIZE + 1] ACPI_NONSTRING;
++ char name_seg[ACPI_NAMESEG_SIZE + 1];
+ };
+
+ #define PARAM_LIST(pl) pl
--- /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
+@@ -1562,6 +1562,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
+@@ -1249,6 +1249,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
+@@ -5404,11 +5404,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
+@@ -267,7 +267,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 f434ec2200667d5362bd19f93a498d9b3f121588 Mon Sep 17 00:00:00 2001
+From: Judith Mendez <jm@ti.com>
+Date: Mon, 18 Aug 2025 14:26:32 -0500
+Subject: arm64: dts: ti: k3-am62p: Fix supported hardware for 1GHz OPP
+
+From: Judith Mendez <jm@ti.com>
+
+commit f434ec2200667d5362bd19f93a498d9b3f121588 upstream.
+
+The 1GHz OPP is supported on speed grade "O" as well according to the
+device datasheet [0], so fix the opp-supported-hw property to support
+this speed grade for 1GHz OPP.
+
+[0] https://www.ti.com/lit/gpn/am62p
+Fixes: 76d855f05801 ("arm64: dts: ti: k3-am62p: add opp frequencies")
+Cc: stable@vger.kernel.org
+Signed-off-by: Judith Mendez <jm@ti.com>
+Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/ti/k3-am62p5.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/ti/k3-am62p5.dtsi
++++ b/arch/arm64/boot/dts/ti/k3-am62p5.dtsi
+@@ -135,7 +135,7 @@
+
+ opp-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+- opp-supported-hw = <0x01 0x0006>;
++ opp-supported-hw = <0x01 0x0007>;
+ clock-latency-ns = <6000000>;
+ };
+
--- /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.xol_insn;
--- /dev/null
+From f620d66af3165838bfa845dcf9f5f9b4089bf508 Mon Sep 17 00:00:00 2001
+From: Catalin Marinas <catalin.marinas@arm.com>
+Date: Wed, 24 Sep 2025 13:31:22 +0100
+Subject: arm64: mte: Do not flag the zero page as PG_mte_tagged
+
+From: Catalin Marinas <catalin.marinas@arm.com>
+
+commit f620d66af3165838bfa845dcf9f5f9b4089bf508 upstream.
+
+Commit 68d54ceeec0e ("arm64: mte: Allow PTRACE_PEEKMTETAGS access to the
+zero page") attempted to fix ptrace() reading of tags from the zero page
+by marking it as PG_mte_tagged during cpu_enable_mte(). The same commit
+also changed the ptrace() tag access permission check to the VM_MTE vma
+flag while turning the page flag test into a WARN_ON_ONCE().
+
+Attempting to set the PG_mte_tagged flag early with
+CONFIG_DEFERRED_STRUCT_PAGE_INIT enabled may either hang (after commit
+d77e59a8fccd "arm64: mte: Lock a page for MTE tag initialisation") or
+have the flags cleared later during page_alloc_init_late(). In addition,
+pages_identical() -> memcmp_pages() will reject any comparison with the
+zero page as it is marked as tagged.
+
+Partially revert the above commit to avoid setting PG_mte_tagged on the
+zero page. Update the __access_remote_tags() warning on untagged pages
+to ignore the zero page since it is known to have the tags initialised.
+
+Note that all user mapping of the zero page are marked as pte_special().
+The arm64 set_pte_at() will not call mte_sync_tags() on such pages, so
+PG_mte_tagged will remain cleared.
+
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Fixes: 68d54ceeec0e ("arm64: mte: Allow PTRACE_PEEKMTETAGS access to the zero page")
+Reported-by: Gergely Kovacs <Gergely.Kovacs2@arm.com>
+Cc: stable@vger.kernel.org # 5.10.x
+Cc: Will Deacon <will@kernel.org>
+Cc: David Hildenbrand <david@redhat.com>
+Cc: Lance Yang <lance.yang@linux.dev>
+Acked-by: Lance Yang <lance.yang@linux.dev>
+Reviewed-by: David Hildenbrand <david@redhat.com>
+Tested-by: Lance Yang <lance.yang@linux.dev>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/kernel/cpufeature.c | 10 +++++++---
+ arch/arm64/kernel/mte.c | 2 +-
+ 2 files changed, 8 insertions(+), 4 deletions(-)
+
+--- a/arch/arm64/kernel/cpufeature.c
++++ b/arch/arm64/kernel/cpufeature.c
+@@ -2408,17 +2408,21 @@ static void bti_enable(const struct arm6
+ #ifdef CONFIG_ARM64_MTE
+ static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap)
+ {
++ static bool cleared_zero_page = false;
++
+ sysreg_clear_set(sctlr_el1, 0, SCTLR_ELx_ATA | SCTLR_EL1_ATA0);
+
+ mte_cpu_setup();
+
+ /*
+ * Clear the tags in the zero page. This needs to be done via the
+- * linear map which has the Tagged attribute.
++ * linear map which has the Tagged attribute. Since this page is
++ * always mapped as pte_special(), set_pte_at() will not attempt to
++ * clear the tags or set PG_mte_tagged.
+ */
+- if (try_page_mte_tagging(ZERO_PAGE(0))) {
++ if (!cleared_zero_page) {
++ cleared_zero_page = true;
+ mte_clear_page_tags(lm_alias(empty_zero_page));
+- set_page_mte_tagged(ZERO_PAGE(0));
+ }
+
+ kasan_init_hw_tags_cpu();
+--- a/arch/arm64/kernel/mte.c
++++ b/arch/arm64/kernel/mte.c
+@@ -460,7 +460,7 @@ static int __access_remote_tags(struct m
+ if (folio_test_hugetlb(folio))
+ WARN_ON_ONCE(!folio_test_hugetlb_mte_tagged(folio));
+ else
+- WARN_ON_ONCE(!page_mte_tagged(page));
++ WARN_ON_ONCE(!page_mte_tagged(page) && !is_zero_page(page));
+
+ /* limit access to the end of the page */
+ offset = offset_in_page(addr);
--- /dev/null
+From 572ce546390d1b7c99b16c38cae1b680c716216c Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Fri, 29 Aug 2025 15:21:52 +0200
+Subject: firmware: arm_scmi: quirk: Prevent writes to string constants
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 572ce546390d1b7c99b16c38cae1b680c716216c upstream.
+
+The quirk version range is typically a string constant and must not be
+modified (e.g. as it may be stored in read-only memory). Attempting
+to do so can trigger faults such as:
+
+ | Unable to handle kernel write to read-only memory at virtual
+ | address ffffc036d998a947
+
+Update the range parsing so that it operates on a copy of the version
+range string, and mark all the quirk strings as const to reduce the
+risk of introducing similar future issues.
+
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220437
+Fixes: 487c407d57d6 ("firmware: arm_scmi: Add common framework to handle firmware quirks")
+Cc: stable@vger.kernel.org # 6.16
+Cc: Cristian Marussi <cristian.marussi@arm.com>
+Reported-by: Jan Palus <jpalus@fastmail.com>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Message-Id: <20250829132152.28218-1-johan@kernel.org>
+[sudeep.holla: minor commit message rewording; switch to cleanup helpers]
+Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/firmware/arm_scmi/quirks.c | 15 ++++++++++-----
+ 1 file changed, 10 insertions(+), 5 deletions(-)
+
+--- a/drivers/firmware/arm_scmi/quirks.c
++++ b/drivers/firmware/arm_scmi/quirks.c
+@@ -71,6 +71,7 @@
+ */
+
+ #include <linux/ctype.h>
++#include <linux/cleanup.h>
+ #include <linux/device.h>
+ #include <linux/export.h>
+ #include <linux/hashtable.h>
+@@ -89,9 +90,9 @@
+ struct scmi_quirk {
+ bool enabled;
+ const char *name;
+- char *vendor;
+- char *sub_vendor_id;
+- char *impl_ver_range;
++ const char *vendor;
++ const char *sub_vendor_id;
++ const char *impl_ver_range;
+ u32 start_range;
+ u32 end_range;
+ struct static_key_false *key;
+@@ -217,7 +218,7 @@ static unsigned int scmi_quirk_signature
+
+ static int scmi_quirk_range_parse(struct scmi_quirk *quirk)
+ {
+- const char *last, *first = quirk->impl_ver_range;
++ const char *last, *first __free(kfree) = NULL;
+ size_t len;
+ char *sep;
+ int ret;
+@@ -228,8 +229,12 @@ static int scmi_quirk_range_parse(struct
+ if (!len)
+ return 0;
+
++ first = kmemdup(quirk->impl_ver_range, len + 1, GFP_KERNEL);
++ if (!first)
++ return -ENOMEM;
++
+ last = first + len - 1;
+- sep = strchr(quirk->impl_ver_range, '-');
++ sep = strchr(first, '-');
+ if (sep)
+ *sep = '\0';
+
--- /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;
kbuild-add-.rel.-strip-pattern-for-vmlinux.patch
s390-vmlinux.lds.s-reorder-sections.patch
s390-vmlinux.lds.s-move-.vmlinux.info-to-end-of-allo.patch
+acpica-acpidump-drop-acpi_nonstring-attribute-from-file_name.patch
+acpi-property-fix-buffer-properties-extraction-for-subnodes.patch
+acpi-tad-add-missing-sysfs_remove_group-for-acpi_tad_rt.patch
+acpica-debugger-drop-acpi_nonstring-attribute-from-name_seg.patch
+acpi-debug-fix-signedness-issues-in-read-write-helpers.patch
+acpi-battery-add-synchronization-between-interface-updates.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-dts-ti-k3-am62p-fix-supported-hardware-for-1ghz-opp.patch
+arm64-kprobes-call-set_memory_rox-for-kprobe-page.patch
+arm64-mte-do-not-flag-the-zero-page-as-pg_mte_tagged.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
+firmware-arm_scmi-quirk-prevent-writes-to-string-constants.patch
+perf-arm-cmn-fix-cmn-s3-dtm-offset.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
