* [PATCH v3 6/6] thermal: core: Suspend thermal zones later and resume them earlier
From: Rafael J. Wysocki @ 2026-04-06 16:16 UTC (permalink / raw)
To: Linux PM; +Cc: Daniel Lezcano, LKML, Lukasz Luba, Armin Wolf
In-Reply-To: <5119690.31r3eYUQgx@rafael.j.wysocki>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
To avoid some undesirable interactions between thermal zone suspend
and resume with user space that is running when those operations are
carried out, move them closer to the suspend and resume of devices,
respectively, by updating dpm_prepare() to carry out thermal zone
suspend and dpm_complete() to start thermal zone resume (that will
continue asynchronously).
This also makes the code easier to follow by removing one, arguably
redundant, level of indirection represented by the thermal PM notifier.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
v2 -> v3:
* Rebase on top of the v3 of the previous patch
v1 -> v2:
* Reorder with respect to the previous patch
* Use thermal_class_unavailable() to avoid running code that should
not run without the thermal class
* Suspend thermal zones after disabling device probing and resume
them before enabling device probing for better synchronization
---
drivers/base/power/main.c | 5 +++
drivers/thermal/thermal_core.c | 60 ++++++++++++-----------------------------
include/linux/thermal.h | 6 ++++
3 files changed, 29 insertions(+), 42 deletions(-)
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -33,6 +33,7 @@
#include <trace/events/power.h>
#include <linux/cpufreq.h>
#include <linux/devfreq.h>
+#include <linux/thermal.h>
#include <linux/timer.h>
#include <linux/nmi.h>
@@ -1282,6 +1283,8 @@ void dpm_complete(pm_message_t state)
list_splice(&list, &dpm_list);
mutex_unlock(&dpm_list_mtx);
+ /* Start resuming thermal control */
+ thermal_pm_complete();
/* Allow device probing and trigger re-probing of deferred devices */
device_unblock_probing();
trace_suspend_resume(TPS("dpm_complete"), state.event, false);
@@ -2225,6 +2228,8 @@ int dpm_prepare(pm_message_t state)
* instead. The normal behavior will be restored in dpm_complete().
*/
device_block_probing();
+ /* Suspend thermal control. */
+ thermal_pm_prepare();
mutex_lock(&dpm_list_mtx);
while (!list_empty(&dpm_list) && !error) {
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1838,7 +1838,7 @@ static void thermal_zone_pm_prepare(stru
cancel_delayed_work(&tz->poll_queue);
}
-static void thermal_pm_notify_prepare(void)
+static void __thermal_pm_prepare(void)
{
struct thermal_zone_device *tz;
@@ -1850,6 +1850,19 @@ static void thermal_pm_notify_prepare(vo
thermal_zone_pm_prepare(tz);
}
+void thermal_pm_prepare(void)
+{
+ if (thermal_class_unavailable)
+ return;
+
+ __thermal_pm_prepare();
+ /*
+ * Allow any leftover thermal work items already on the worqueue to
+ * complete so they don't get in the way later.
+ */
+ flush_workqueue(thermal_wq);
+}
+
static void thermal_zone_pm_complete(struct thermal_zone_device *tz)
{
guard(thermal_zone)(tz);
@@ -1866,10 +1879,13 @@ static void thermal_zone_pm_complete(str
mod_delayed_work(thermal_wq, &tz->poll_queue, 0);
}
-static void thermal_pm_notify_complete(void)
+void thermal_pm_complete(void)
{
struct thermal_zone_device *tz;
+ if (thermal_class_unavailable)
+ return;
+
guard(mutex)(&thermal_list_lock);
thermal_pm_suspended = false;
@@ -1878,41 +1894,6 @@ static void thermal_pm_notify_complete(v
thermal_zone_pm_complete(tz);
}
-static int thermal_pm_notify(struct notifier_block *nb,
- unsigned long mode, void *_unused)
-{
- switch (mode) {
- case PM_HIBERNATION_PREPARE:
- case PM_RESTORE_PREPARE:
- case PM_SUSPEND_PREPARE:
- thermal_pm_notify_prepare();
- /*
- * Allow any leftover thermal work items already on the
- * worqueue to complete so they don't get in the way later.
- */
- flush_workqueue(thermal_wq);
- break;
- case PM_POST_HIBERNATION:
- case PM_POST_RESTORE:
- case PM_POST_SUSPEND:
- thermal_pm_notify_complete();
- break;
- default:
- break;
- }
- return 0;
-}
-
-static struct notifier_block thermal_pm_nb = {
- .notifier_call = thermal_pm_notify,
- /*
- * Run at the lowest priority to avoid interference between the thermal
- * zone resume work items spawned by thermal_pm_notify() and the other
- * PM notifiers.
- */
- .priority = INT_MIN,
-};
-
static int __init thermal_init(void)
{
int result;
@@ -1939,11 +1920,6 @@ static int __init thermal_init(void)
thermal_class_unavailable = false;
- result = register_pm_notifier(&thermal_pm_nb);
- if (result)
- pr_warn("Thermal: Can not register suspend notifier, return %d\n",
- result);
-
return 0;
unregister_governors:
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -273,6 +273,9 @@ bool thermal_trip_is_bound_to_cdev(struc
int thermal_zone_device_enable(struct thermal_zone_device *tz);
int thermal_zone_device_disable(struct thermal_zone_device *tz);
void thermal_zone_device_critical(struct thermal_zone_device *tz);
+
+void thermal_pm_prepare(void);
+void thermal_pm_complete(void);
#else
static inline struct thermal_zone_device *thermal_zone_device_register_with_trips(
const char *type,
@@ -350,6 +353,9 @@ static inline int thermal_zone_device_en
static inline int thermal_zone_device_disable(struct thermal_zone_device *tz)
{ return -ENODEV; }
+
+static inline void thermal_pm_prepare(void) {}
+static inline void thermal_pm_complete(void) {}
#endif /* CONFIG_THERMAL */
#endif /* __THERMAL_H__ */
^ permalink raw reply
* Re: [PATCH] cpufreq: governor: Fix race between sysfs store and dbs work handler
From: Rafael J. Wysocki @ 2026-04-06 15:21 UTC (permalink / raw)
To: Zhongqiu Han
Cc: rafael, viresh.kumar, venkatesh.pallipadi, davej, trenn, linux-pm,
linux-kernel
In-Reply-To: <20260406110113.3475920-1-zhongqiu.han@oss.qualcomm.com>
On Mon, Apr 6, 2026 at 1:01 PM Zhongqiu Han
<zhongqiu.han@oss.qualcomm.com> wrote:
>
> gov_update_cpu_data() resets per-CPU prev_cpu_idle and prev_cpu_nice
> for every CPU in the governed domain. It is called from sysfs store
> callbacks (e.g. ignore_nice_load_store) which run under
> attr_set->update_lock, held by the surrounding governor_store().
>
> Concurrently, dbs_work_handler() calls gov->gov_dbs_update() (which
> calls dbs_update()) under policy_dbs->update_mutex. dbs_update() both
> reads and writes the same prev_cpu_idle / prev_cpu_nice fields. The
> potential race path is:
>
> Path A (sysfs write, holds attr_set->update_lock only):
>
> governor_store()
> mutex_lock(&attr_set->update_lock)
> ignore_nice_load_store()
> dbs_data->ignore_nice_load = input
> gov_update_cpu_data(dbs_data)
> list_for_each_entry(policy_dbs, ...)
> for_each_cpu(j, ...)
> j_cdbs->prev_cpu_idle = get_cpu_idle_time(...) /* write */
> j_cdbs->prev_cpu_nice = kcpustat_field(...) /* write */
> mutex_unlock(&attr_set->update_lock)
>
> Path B (work queue, holds policy_dbs->update_mutex only):
>
> dbs_work_handler()
> mutex_lock(&policy_dbs->update_mutex)
> gov->gov_dbs_update(policy)
> dbs_update()
> for_each_cpu(j, policy->cpus)
> idle_time = cur - j_cdbs->prev_cpu_idle /* read */
> j_cdbs->prev_cpu_idle = cur_idle_time /* write */
> idle_time += cur_nice - j_cdbs->prev_cpu_nice /* read */
> j_cdbs->prev_cpu_nice = cur_nice /* write */
> mutex_unlock(&policy_dbs->update_mutex)
>
> Because attr_set->update_lock and policy_dbs->update_mutex are two
> completely independent locks, the two paths are not mutually exclusive.
> This results in a data race on cpu_dbs_info.prev_cpu_idle and
> cpu_dbs_info.prev_cpu_nice.
>
> Fix this by also acquiring policy_dbs->update_mutex in
> gov_update_cpu_data() for each policy, so that path A participates in
> the mutual exclusion already established by dbs_work_handler(). Also
> update the function comment to accurately reflect the two-level locking
> contract.
>
> The root of this race dates back to the original ondemand/conservative
> governors. Before commit ee88415caf73 ("[CPUFREQ] Cleanup locking in
> conservative governor") and commit 5a75c82828e7 ("[CPUFREQ] Cleanup
> locking in ondemand governor"), all accesses to prev_cpu_idle and
> prev_cpu_nice in cpufreq_governor_dbs() (path X), store_ignore_nice_load()
> (path Y), and do_dbs_timer() (path Z) were serialised by the same
> dbs_mutex, so no race existed. Those two commits switched do_dbs_timer()
> from dbs_mutex to a per-policy/per-cpu timer_mutex to reduce lock
> contention, but left store_ignore_nice_load() still holding dbs_mutex.
> As a result, path Y (store) and path Z (do_dbs_timer) no longer shared a
> common lock, introducing a potential race on prev_cpu_idle/prev_cpu_nice
> between store_ignore_nice_load() and dbs_check_cpu().
>
> Commit 326c86deaed54a ("[CPUFREQ] Remove unneeded locks") then removed
> dbs_mutex from store_ignore_nice_load() entirely, introducing an
> additional potential race between store_ignore_nice_load() (path Y, now
> lockless) and cpufreq_governor_dbs() (path X, still holding dbs_mutex),
> while the race between path Y and path Z remained.
>
> Fixes: ee88415caf736b ("[CPUFREQ] Cleanup locking in conservative governor")
> Fixes: 5a75c82828e7c0 ("[CPUFREQ] Cleanup locking in ondemand governor")
> Fixes: 326c86deaed54a ("[CPUFREQ] Remove unneeded locks")
> Signed-off-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
> ---
> drivers/cpufreq/cpufreq_governor.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
> index 86f35e451914..56ef793362db 100644
> --- a/drivers/cpufreq/cpufreq_governor.c
> +++ b/drivers/cpufreq/cpufreq_governor.c
> @@ -90,7 +90,8 @@ EXPORT_SYMBOL_GPL(sampling_rate_store);
> * (that may be a single policy or a bunch of them if governor tunables are
> * system-wide).
> *
> - * Call under the @dbs_data mutex.
> + * Call under the @dbs_data->attr_set.update_lock. The per-policy
> + * update_mutex is acquired and released internally for each policy.
> */
> void gov_update_cpu_data(struct dbs_data *dbs_data)
> {
> @@ -99,6 +100,7 @@ void gov_update_cpu_data(struct dbs_data *dbs_data)
> list_for_each_entry(policy_dbs, &dbs_data->attr_set.policy_list, list) {
> unsigned int j;
>
> + mutex_lock(&policy_dbs->update_mutex);
> for_each_cpu(j, policy_dbs->policy->cpus) {
> struct cpu_dbs_info *j_cdbs = &per_cpu(cpu_dbs, j);
>
> @@ -107,6 +109,7 @@ void gov_update_cpu_data(struct dbs_data *dbs_data)
> if (dbs_data->ignore_nice_load)
> j_cdbs->prev_cpu_nice = kcpustat_field(&kcpustat_cpu(j), CPUTIME_NICE, j);
> }
> + mutex_unlock(&policy_dbs->update_mutex);
> }
> }
> EXPORT_SYMBOL_GPL(gov_update_cpu_data);
> --
Please have a look at
https://sashiko.dev/#/patchset/20260406110113.3475920-1-zhongqiu.han%40oss.qualcomm.com
and let me know what you think.
Thanks!
^ permalink raw reply
* Re: [PATCH] PM / wakeup: Register class wakeup in pure_initcall phase
From: Rafael J. Wysocki @ 2026-04-06 15:17 UTC (permalink / raw)
To: Greg Kroah-Hartman, Heiner Kallweit
Cc: Pavel Machek, Danilo Krummrich, Linux PM, driver-core
In-Reply-To: <2026040354-kitchen-unwoven-c0ce@gregkh>
On Fri, Apr 3, 2026 at 7:24 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Fri, Apr 03, 2026 at 06:09:59PM +0200, Heiner Kallweit wrote:
> > Wakeup sources (e.g. autosleep) can be created as early as core_initcall.
> > Class wakeup is registered in postcore_initcall only, what results in
> > autosleep wakeup source not being shown in sysfs. To fix this,
> > register class wakeup in pure_initcall phase already.
> >
> > The current behavior doesn't cause any known issue, therefore treat
> > the change as an improvement.
> >
> > Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> > ---
> > drivers/base/power/wakeup_stats.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/base/power/wakeup_stats.c b/drivers/base/power/wakeup_stats.c
> > index 308f8bde9..30f0d3d61 100644
> > --- a/drivers/base/power/wakeup_stats.c
> > +++ b/drivers/base/power/wakeup_stats.c
> > @@ -216,4 +216,4 @@ static int __init wakeup_sources_sysfs_init(void)
> >
> > return PTR_ERR_OR_ZERO(wakeup_class);
> > }
> > -postcore_initcall(wakeup_sources_sysfs_init);
> > +pure_initcall(wakeup_sources_sysfs_init);
> > --
> > 2.53.0
> >
>
> Wait, if this doesn't need to be change, we shouldn't change it. Unless
> you have a bug that is being fixed here, don't touch init call levels.
> They are tricky and will come to bite you if you don't watch out.
Well, if this is objectionable, a quite straightforward alternative is
to call wakeup_sources_sysfs_init() directly from pm_init() before
invoking pm_autosleep_init().
That would also indicate an ordering dependency between the two calls.
^ permalink raw reply
* Re: [PATCH v3] PM: hibernate: call preallocate_image after freeze prepare
From: Rafael J. Wysocki @ 2026-04-06 15:11 UTC (permalink / raw)
To: Matthew Leach
Cc: Rafael J. Wysocki, Pavel Machek, Len Brown, Mario Limonciello,
linux-pm, linux-kernel, YoungJun Park, kernel
In-Reply-To: <20260403-hibernation-fixes-v3-1-31bc9fa3ba2d@collabora.com>
On Fri, Apr 3, 2026 at 9:36 AM Matthew Leach
<matthew.leach@collabora.com> wrote:
>
> Certain drivers release resources (pinned pages, etc.) into system
> memory during the prepare freeze PM op, making them swappable.
> Currently, hibernate_preallocate_memory is called before prepare freeze,
> so those drivers have no opportunity to release resources first. If a
> driver is holding a large amount of unswappable system RAM, this can
> cause hibernate_preallocate_memory to fail.
>
> Move the call to hibernate_preallocate_memory after prepare freeze.
> According to the documentation for the prepare callback, devices should
> be left in a usable state, so storage drivers should still be able to
> service I/O requests. This allows drivers to release unswappable
> resources prior to preallocation, so they can be swapped out through
> hibernate_preallocate_memory's reclaim path. Also remove
> shrink_shmem_memory since hibernate_preallocate_memory will have
> reclaimed enough memory for the hibernation image.
>
> Signed-off-by: Matthew Leach <matthew.leach@collabora.com>
> ---
> Changes in v3:
> - Changed error label names to 'Thaw' and 'Complete'.
> - Link to v2: https://patch.msgid.link/20260326-hibernation-fixes-v2-1-f6707d82b7b9@collabora.com
>
> Changes in v2:
> - Removed shrink_shmem_memory.
> - Fixed missing call to dpm_prepare in error path.
> - Link to v1: https://lore.kernel.org/r/20260321-hibernation-fixes-v1-1-5fe9637b6ff9@collabora.com
> ---
> kernel/power/hibernate.c | 46 +++++++++-------------------------------------
> 1 file changed, 9 insertions(+), 37 deletions(-)
>
> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> index af8d07bafe02..d2479c69d71a 100644
> --- a/kernel/power/hibernate.c
> +++ b/kernel/power/hibernate.c
> @@ -392,23 +392,6 @@ static int create_image(int platform_mode)
> return error;
> }
>
> -static void shrink_shmem_memory(void)
> -{
> - struct sysinfo info;
> - unsigned long nr_shmem_pages, nr_freed_pages;
> -
> - si_meminfo(&info);
> - nr_shmem_pages = info.sharedram; /* current page count used for shmem */
> - /*
> - * The intent is to reclaim all shmem pages. Though shrink_all_memory() can
> - * only reclaim about half of them, it's enough for creating the hibernation
> - * image.
> - */
> - nr_freed_pages = shrink_all_memory(nr_shmem_pages);
> - pr_debug("requested to reclaim %lu shmem pages, actually freed %lu pages\n",
> - nr_shmem_pages, nr_freed_pages);
> -}
> -
> /**
> * hibernation_snapshot - Quiesce devices and create a hibernation image.
> * @platform_mode: If set, use platform driver to prepare for the transition.
> @@ -425,14 +408,9 @@ int hibernation_snapshot(int platform_mode)
> if (error)
> goto Close;
>
> - /* Preallocate image memory before shutting down devices. */
> - error = hibernate_preallocate_memory();
> - if (error)
> - goto Close;
> -
> error = freeze_kernel_threads();
> if (error)
> - goto Cleanup;
> + goto Close;
>
> if (hibernation_test(TEST_FREEZER)) {
>
> @@ -445,19 +423,13 @@ int hibernation_snapshot(int platform_mode)
> }
>
> error = dpm_prepare(PMSG_FREEZE);
> - if (error) {
> - dpm_complete(PMSG_RECOVER);
> - goto Thaw;
> - }
> + if (error)
> + goto Complete;
>
> - /*
> - * Device drivers may move lots of data to shmem in dpm_prepare(). The shmem
> - * pages will use lots of system memory, causing hibernation image creation
> - * fail due to insufficient free memory.
> - * This call is to force flush the shmem pages to swap disk and reclaim
> - * the system memory so that image creation can succeed.
> - */
> - shrink_shmem_memory();
> + /* Preallocate image memory before shutting down devices. */
> + error = hibernate_preallocate_memory();
> + if (error)
> + goto Complete;
>
> console_suspend_all();
> pm_restrict_gfp_mask();
> @@ -492,10 +464,10 @@ int hibernation_snapshot(int platform_mode)
> platform_end(platform_mode);
> return error;
>
> + Complete:
> + dpm_complete(PMSG_RECOVER);
> Thaw:
> thaw_kernel_threads();
> - Cleanup:
> - swsusp_free();
> goto Close;
> }
>
>
> ---
Can you please have a look at
https://sashiko.dev/#/patchset/20260403-hibernation-fixes-v3-1-31bc9fa3ba2d%40collabora.com
and let me know what you think?
^ permalink raw reply
* Re: [PATCH v2] cpuidle: Deny idle entry when CPU already have IPI interrupt pending
From: Rafael J. Wysocki @ 2026-04-06 15:07 UTC (permalink / raw)
To: Maulik Shah
Cc: Rafael J. Wysocki, Daniel Lezcano, Christian Loehle, Ulf Hansson,
linux-pm, linux-kernel, linux-arm-msm
In-Reply-To: <20260403-cpuidle_ipi-v2-1-b3e44b032e2c@oss.qualcomm.com>
On Fri, Apr 3, 2026 at 6:08 AM Maulik Shah <maulik.shah@oss.qualcomm.com> wrote:
>
> CPU can get IPI interrupt from another CPU while it is executing
> cpuidle_select() or about to execute same. The selection do not account
> for pending interrupts and may continue to enter selected idle state only
> to exit immediately.
>
> Example trace collected when there is cross CPU IPI.
>
> [000] 154.892148: sched_waking: comm=sugov:4 pid=491 prio=-1 target_cpu=007
> [000] 154.892148: ipi_raise: target_mask=00000000,00000080 (Function call interrupts)
> [007] 154.892162: cpu_idle: state=2 cpu_id=7
> [007] 154.892208: cpu_idle: state=4294967295 cpu_id=7
> [007] 154.892211: irq_handler_entry: irq=2 name=IPI
> [007] 154.892211: ipi_entry: (Function call interrupts)
> [007] 154.892213: sched_wakeup: comm=sugov:4 pid=491 prio=-1 target_cpu=007
> [007] 154.892214: ipi_exit: (Function call interrupts)
>
> This impacts performance and the above count increments.
>
> commit ccde6525183c ("smp: Introduce a helper function to check for pending
> IPIs") already introduced a helper function to check the pending IPIs and
> it is used in pmdomain governor to deny the cluster level idle state when
> there is a pending IPI on any of cluster CPUs.
>
> This however does not stop CPU to enter CPU level idle state. Make use of
> same at CPUidle to deny the idle entry when there is already IPI pending.
>
> With change observing glmark2 [1] off screen scores improving in the range
> of 25% to 30% on Qualcomm lemans-evk board which is arm64 based having two
> clusters each with 4 CPUs.
>
> [1] https://github.com/glmark2/glmark2
>
> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
> ---
> Changes in v2:
> - Fix cpumask argument of cpus_peek_for_pending_ipi() to take single cpu
> - Link to v1: https://lore.kernel.org/r/20260316-cpuidle_ipi-v1-1-d0ff6350f4e2@oss.qualcomm.com
> ---
> drivers/cpuidle/cpuidle.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index c7876e9e024f9076663063ad21cfc69343fdbbe7..c01e57df64ca5af8c28da3d971500b3f38306cdf 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -224,6 +224,9 @@ noinstr int cpuidle_enter_state(struct cpuidle_device *dev,
> bool broadcast = !!(target_state->flags & CPUIDLE_FLAG_TIMER_STOP);
> ktime_t time_start, time_end;
>
> + if (cpus_peek_for_pending_ipi(cpumask_of(dev->cpu)))
> + return -EBUSY;
> +
Why do you want to check it here and not in cpuidle_idle_call(), for example?
In principle, this check may be useful in the default idle path too.
> instrumentation_begin();
>
> /*
>
> ---
^ permalink raw reply
* [PATCH] dt-bindings: thermal: idle: Correct node name in the example
From: Krzysztof Kozlowski @ 2026-04-06 14:51 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-pm,
devicetree, linux-kernel
Cc: Krzysztof Kozlowski
Thermal bindings expect the node name with all the zones to be named
'thermal-zones' (hyphen instead of underscore) and also DTS coding style
is not to use underscores for node names, so adjust the example code.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/devicetree/bindings/thermal/thermal-idle.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/thermal/thermal-idle.yaml b/Documentation/devicetree/bindings/thermal/thermal-idle.yaml
index 1b77d542a7b8..357699b50c68 100644
--- a/Documentation/devicetree/bindings/thermal/thermal-idle.yaml
+++ b/Documentation/devicetree/bindings/thermal/thermal-idle.yaml
@@ -101,7 +101,7 @@ examples:
/* ... */
- thermal_zones {
+ thermal-zones {
cpu_thermal: cpu {
polling-delay-passive = <100>;
polling-delay = <1000>;
--
2.51.0
^ permalink raw reply related
* Re: [GIT PULL] cpufreq/arm updates for 7.1
From: Rafael J. Wysocki @ 2026-04-06 14:35 UTC (permalink / raw)
To: Viresh Kumar; +Cc: Rafael J. Wysocki, Linux PM
In-Reply-To: <a4lvsuklad2ab3tynq34oiuu36rn53fkf6ert7al2tuvgyjziw@wkiqji6svbdj>
On Mon, Apr 6, 2026 at 1:01 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git tags/cpufreq-arm-updates-7.1-rc1
>
> for you to fetch changes up to 8655a4e35cda5534f93303af393eac4e71704701:
>
> cpufreq: tegra194: remove COMPILE_TEST (2026-03-20 11:03:33 +0530)
>
> ----------------------------------------------------------------
> CPUFreq arm updates for 7.1
>
> - Update qcom-hw DT bindings to include Eliza hardware (Abel Vesa).
>
> - Update cpufreq-dt-platdev blocklist (Faruque Ansari).
>
> - Minor updates to driver and dt-bindings for Tegra (Thierry Reding and Rosen Penev).
>
> - Add MAINTAINERS entry for CPPC driver (Viresh Kumar).
>
> ----------------------------------------------------------------
> Abel Vesa (1):
> dt-bindings: cpufreq: qcom-hw: document Eliza cpufreq hardware
>
> Faruque Ansari (1):
> cpufreq: Add QCS8300 to cpufreq-dt-platdev blocklist
>
> Rosen Penev (1):
> cpufreq: tegra194: remove COMPILE_TEST
>
> Thierry Reding (2):
> dt-bindings: arm: nvidia: Document the Tegra238 CCPLEX cluster
> cpufreq: tegra194: Rename Tegra239 to Tegra238
>
> Viresh Kumar (1):
> cpufreq: Add MAINTAINERS entry for CPPC driver
>
> Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml | 1 +
> Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml | 1 +
> MAINTAINERS | 23 +++++++++++++++++------
> drivers/cpufreq/Kconfig.arm | 2 +-
> drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
> drivers/cpufreq/tegra194-cpufreq.c | 4 ++--
> 6 files changed, 23 insertions(+), 9 deletions(-)
>
> --
Pulled and added to linux-pm.git/linux-next, thanks!
^ permalink raw reply
* Re: [GIT PULL] OPP updates 7.1
From: Rafael J. Wysocki @ 2026-04-06 14:34 UTC (permalink / raw)
To: Viresh Kumar; +Cc: Rafael J. Wysocki, Linux PM
In-Reply-To: <qgpnmh6sh5abdgrgxv2so6xo3ktn43vhvykv3sn6z3224iioks@qukoxvvz6cis>
On Mon, Apr 6, 2026 at 1:00 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git tags/opp-updates-7.1-rc1
>
> for you to fetch changes up to 3d2398f44a2d48fb1c575a6e0bc6b38f3e689e22:
>
> OPP: Move break out of scoped_guard in dev_pm_opp_xlate_required_opp() (2026-02-23 11:05:59 +0530)
>
> ----------------------------------------------------------------
> OPP updates for 7.1
>
> - Use performance level if available to distinguish between rates in
> debugfs (Manivannan Sadhasivam).
>
> - Fix scoped_guard in dev_pm_opp_xlate_required_opp() (Viresh Kumar).
>
> ----------------------------------------------------------------
> Manivannan Sadhasivam (1):
> OPP: debugfs: Use performance level if available to distinguish between rates
>
> Viresh Kumar (1):
> OPP: Move break out of scoped_guard in dev_pm_opp_xlate_required_opp()
>
> drivers/opp/core.c | 2 +-
> drivers/opp/debugfs.c | 20 +++++++++++---------
> 2 files changed, 12 insertions(+), 10 deletions(-)
>
> --
Pulled and added to linux-pm.git/linux-next, thanks!
^ permalink raw reply
* [GIT PULL] interconnect changes for 7.1
From: Georgi Djakov @ 2026-04-06 12:06 UTC (permalink / raw)
To: gregkh; +Cc: linux-pm, linux-kernel, djakov
Hello Greg,
This is the pull request with interconnect changes for the v7.1-rc1 merge
window. As always, the summary is in the signed tag.
All patches have been tested in the last few linux-next releases. There
are currently no reported issues. Please pull into char-misc-next when
possible.
Thanks,
Georgi
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/djakov/icc.git tags/icc-7.1-rc1
for you to fetch changes up to 0436cd305d0be28cde59efb137d15d1bc6af4b12:
MAINTAINERS: Add interconnect kunit test entry (2026-04-02 10:39:01 +0300)
----------------------------------------------------------------
This pull request contains the interconnect changes for the 7.1-rc1
merge window. They are listed below:
- New driver for Mahua SoC
- New driver for Eliza SoC
- Enable QoS support for QCS8300 and QCS615 SoCs
- Add L3 cache scaling compatibles for SM8550 and Eliza SoCs
- Fix multiple issues in the msm8974 driver
- Fix kfree mismatch
- Misc cleanups
- Add maintainer entry for the interconnect KUnit tests
Signed-off-by: Georgi Djakov <djakov@kernel.org>
----------------------------------------------------------------
Aaron Kling (1):
dt-bindings: interconnect: OSM L3: Document sm8550 OSM L3 compatible
Abel Vesa (1):
dt-bindings: interconnect: OSM L3: Add Eliza EPSS L3 compatible
Dmitry Baryshkov (8):
dt-bindings: interconnect: qcom,msm8974: drop bus clocks
dt-bindings: interconnect: qcom,msm8974: use qcom,rpm-common
interconnect: qcom: drop unused is_on flag
interconnect: qcom: icc-rpm: allow overwriting get_bw callback
interconnect: qcom: define OCMEM bus resource
interconnect: qcom: let platforms declare their bugginess
interconnect: qcom: msm8974: switch to the main icc-rpm driver
interconnect: qcom: msm8974: expand DEFINE_QNODE macros
Georgi Djakov (5):
Merge branch 'icc-eliza' into icc-next
Merge branch 'icc-mahua' into icc-next
Merge branch 'icc-qcs8300' into icc-next
Merge branch 'icc-qcs615' into icc-next
Merge branch 'icc-msm8974' into icc-next
Gui-Dong Han (1):
interconnect: debugfs: fix devm_kstrdup and kfree mismatch
Krzysztof Kozlowski (2):
dt-bindings: interconnect: qcom,glymur-rpmh: De-acronymize SoC name
interconnect: qcom: De-acronymize SoC names
Kuan-Wei Chiu (1):
MAINTAINERS: Add interconnect kunit test entry
Odelu Kukatla (6):
dt-bindings: interconnect: qcom,qcs8300-rpmh: add clocks property to enable QoS
interconnect: qcom: qcs8300: enable QoS configuration
dt-bindings: interconnect: document the RPMh Network-On-Chip interconnect in Eliza SoC
interconnect: qcom: Add Eliza interconnect provider driver
dt-bindings: interconnect: qcom,qcs615-rpmh: add clocks property to enable QoS
interconnect: qcom: qcs615: enable QoS configuration
Raviteja Laggyshetty (2):
dt-bindings: interconnect: document the RPMh Network-On-Chip interconnect in Mahua SoC
interconnect: qcom: glymur: Add Mahua SoC support
.../devicetree/bindings/interconnect/qcom,eliza-rpmh.yaml | 142 +
.../devicetree/bindings/interconnect/qcom,glymur-rpmh.yaml | 136 +-
.../devicetree/bindings/interconnect/qcom,msm8974.yaml | 28 +-
.../devicetree/bindings/interconnect/qcom,osm-l3.yaml | 2 +
.../devicetree/bindings/interconnect/qcom,qcs615-rpmh.yaml | 23 +
.../devicetree/bindings/interconnect/qcom,qcs8300-rpmh.yaml | 63 +
MAINTAINERS | 6 +
drivers/interconnect/debugfs-client.c | 9 +-
drivers/interconnect/qcom/Kconfig | 13 +-
drivers/interconnect/qcom/Makefile | 2 +
drivers/interconnect/qcom/eliza.c | 1585 +++++++
drivers/interconnect/qcom/glymur.c | 40 +-
drivers/interconnect/qcom/icc-rpm-clocks.c | 6 +
drivers/interconnect/qcom/icc-rpm.c | 18 +-
drivers/interconnect/qcom/icc-rpm.h | 7 +-
drivers/interconnect/qcom/msm8974.c | 1637 ++++++--
drivers/interconnect/qcom/qcs615.c | 247 ++
drivers/interconnect/qcom/qcs8300.c | 375 ++
include/dt-bindings/interconnect/qcom,eliza-rpmh.h | 136 +
19 files changed, 4014 insertions(+), 461 deletions(-)
create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,eliza-rpmh.yaml
create mode 100644 drivers/interconnect/qcom/eliza.c
create mode 100644 include/dt-bindings/interconnect/qcom,eliza-rpmh.h
^ permalink raw reply
* [GIT PULL] cpufreq/arm updates for 7.1
From: Viresh Kumar @ 2026-04-06 11:01 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux PM
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git tags/cpufreq-arm-updates-7.1-rc1
for you to fetch changes up to 8655a4e35cda5534f93303af393eac4e71704701:
cpufreq: tegra194: remove COMPILE_TEST (2026-03-20 11:03:33 +0530)
----------------------------------------------------------------
CPUFreq arm updates for 7.1
- Update qcom-hw DT bindings to include Eliza hardware (Abel Vesa).
- Update cpufreq-dt-platdev blocklist (Faruque Ansari).
- Minor updates to driver and dt-bindings for Tegra (Thierry Reding and Rosen Penev).
- Add MAINTAINERS entry for CPPC driver (Viresh Kumar).
----------------------------------------------------------------
Abel Vesa (1):
dt-bindings: cpufreq: qcom-hw: document Eliza cpufreq hardware
Faruque Ansari (1):
cpufreq: Add QCS8300 to cpufreq-dt-platdev blocklist
Rosen Penev (1):
cpufreq: tegra194: remove COMPILE_TEST
Thierry Reding (2):
dt-bindings: arm: nvidia: Document the Tegra238 CCPLEX cluster
cpufreq: tegra194: Rename Tegra239 to Tegra238
Viresh Kumar (1):
cpufreq: Add MAINTAINERS entry for CPPC driver
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml | 1 +
Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml | 1 +
MAINTAINERS | 23 +++++++++++++++++------
drivers/cpufreq/Kconfig.arm | 2 +-
drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
drivers/cpufreq/tegra194-cpufreq.c | 4 ++--
6 files changed, 23 insertions(+), 9 deletions(-)
--
viresh
^ permalink raw reply
* [PATCH] cpufreq: governor: Fix race between sysfs store and dbs work handler
From: Zhongqiu Han @ 2026-04-06 11:01 UTC (permalink / raw)
To: rafael, viresh.kumar
Cc: venkatesh.pallipadi, davej, trenn, linux-pm, linux-kernel,
zhongqiu.han
gov_update_cpu_data() resets per-CPU prev_cpu_idle and prev_cpu_nice
for every CPU in the governed domain. It is called from sysfs store
callbacks (e.g. ignore_nice_load_store) which run under
attr_set->update_lock, held by the surrounding governor_store().
Concurrently, dbs_work_handler() calls gov->gov_dbs_update() (which
calls dbs_update()) under policy_dbs->update_mutex. dbs_update() both
reads and writes the same prev_cpu_idle / prev_cpu_nice fields. The
potential race path is:
Path A (sysfs write, holds attr_set->update_lock only):
governor_store()
mutex_lock(&attr_set->update_lock)
ignore_nice_load_store()
dbs_data->ignore_nice_load = input
gov_update_cpu_data(dbs_data)
list_for_each_entry(policy_dbs, ...)
for_each_cpu(j, ...)
j_cdbs->prev_cpu_idle = get_cpu_idle_time(...) /* write */
j_cdbs->prev_cpu_nice = kcpustat_field(...) /* write */
mutex_unlock(&attr_set->update_lock)
Path B (work queue, holds policy_dbs->update_mutex only):
dbs_work_handler()
mutex_lock(&policy_dbs->update_mutex)
gov->gov_dbs_update(policy)
dbs_update()
for_each_cpu(j, policy->cpus)
idle_time = cur - j_cdbs->prev_cpu_idle /* read */
j_cdbs->prev_cpu_idle = cur_idle_time /* write */
idle_time += cur_nice - j_cdbs->prev_cpu_nice /* read */
j_cdbs->prev_cpu_nice = cur_nice /* write */
mutex_unlock(&policy_dbs->update_mutex)
Because attr_set->update_lock and policy_dbs->update_mutex are two
completely independent locks, the two paths are not mutually exclusive.
This results in a data race on cpu_dbs_info.prev_cpu_idle and
cpu_dbs_info.prev_cpu_nice.
Fix this by also acquiring policy_dbs->update_mutex in
gov_update_cpu_data() for each policy, so that path A participates in
the mutual exclusion already established by dbs_work_handler(). Also
update the function comment to accurately reflect the two-level locking
contract.
The root of this race dates back to the original ondemand/conservative
governors. Before commit ee88415caf73 ("[CPUFREQ] Cleanup locking in
conservative governor") and commit 5a75c82828e7 ("[CPUFREQ] Cleanup
locking in ondemand governor"), all accesses to prev_cpu_idle and
prev_cpu_nice in cpufreq_governor_dbs() (path X), store_ignore_nice_load()
(path Y), and do_dbs_timer() (path Z) were serialised by the same
dbs_mutex, so no race existed. Those two commits switched do_dbs_timer()
from dbs_mutex to a per-policy/per-cpu timer_mutex to reduce lock
contention, but left store_ignore_nice_load() still holding dbs_mutex.
As a result, path Y (store) and path Z (do_dbs_timer) no longer shared a
common lock, introducing a potential race on prev_cpu_idle/prev_cpu_nice
between store_ignore_nice_load() and dbs_check_cpu().
Commit 326c86deaed54a ("[CPUFREQ] Remove unneeded locks") then removed
dbs_mutex from store_ignore_nice_load() entirely, introducing an
additional potential race between store_ignore_nice_load() (path Y, now
lockless) and cpufreq_governor_dbs() (path X, still holding dbs_mutex),
while the race between path Y and path Z remained.
Fixes: ee88415caf736b ("[CPUFREQ] Cleanup locking in conservative governor")
Fixes: 5a75c82828e7c0 ("[CPUFREQ] Cleanup locking in ondemand governor")
Fixes: 326c86deaed54a ("[CPUFREQ] Remove unneeded locks")
Signed-off-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
---
drivers/cpufreq/cpufreq_governor.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
index 86f35e451914..56ef793362db 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -90,7 +90,8 @@ EXPORT_SYMBOL_GPL(sampling_rate_store);
* (that may be a single policy or a bunch of them if governor tunables are
* system-wide).
*
- * Call under the @dbs_data mutex.
+ * Call under the @dbs_data->attr_set.update_lock. The per-policy
+ * update_mutex is acquired and released internally for each policy.
*/
void gov_update_cpu_data(struct dbs_data *dbs_data)
{
@@ -99,6 +100,7 @@ void gov_update_cpu_data(struct dbs_data *dbs_data)
list_for_each_entry(policy_dbs, &dbs_data->attr_set.policy_list, list) {
unsigned int j;
+ mutex_lock(&policy_dbs->update_mutex);
for_each_cpu(j, policy_dbs->policy->cpus) {
struct cpu_dbs_info *j_cdbs = &per_cpu(cpu_dbs, j);
@@ -107,6 +109,7 @@ void gov_update_cpu_data(struct dbs_data *dbs_data)
if (dbs_data->ignore_nice_load)
j_cdbs->prev_cpu_nice = kcpustat_field(&kcpustat_cpu(j), CPUTIME_NICE, j);
}
+ mutex_unlock(&policy_dbs->update_mutex);
}
}
EXPORT_SYMBOL_GPL(gov_update_cpu_data);
--
2.43.0
^ permalink raw reply related
* [GIT PULL] OPP updates 7.1
From: Viresh Kumar @ 2026-04-06 11:00 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux PM
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git tags/opp-updates-7.1-rc1
for you to fetch changes up to 3d2398f44a2d48fb1c575a6e0bc6b38f3e689e22:
OPP: Move break out of scoped_guard in dev_pm_opp_xlate_required_opp() (2026-02-23 11:05:59 +0530)
----------------------------------------------------------------
OPP updates for 7.1
- Use performance level if available to distinguish between rates in
debugfs (Manivannan Sadhasivam).
- Fix scoped_guard in dev_pm_opp_xlate_required_opp() (Viresh Kumar).
----------------------------------------------------------------
Manivannan Sadhasivam (1):
OPP: debugfs: Use performance level if available to distinguish between rates
Viresh Kumar (1):
OPP: Move break out of scoped_guard in dev_pm_opp_xlate_required_opp()
drivers/opp/core.c | 2 +-
drivers/opp/debugfs.c | 20 +++++++++++---------
2 files changed, 12 insertions(+), 10 deletions(-)
--
viresh
^ permalink raw reply
* Re: [PATCH v20 00/10] Implement PSCI reboot mode driver for PSCI resets
From: Pankaj Patil @ 2026-04-06 7:36 UTC (permalink / raw)
To: Shivendra Pratap, Lorenzo Pieralisi, Arnd Bergmann,
Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Bartosz Golaszewski, Sudeep Holla
Cc: Florian Fainelli, Krzysztof Kozlowski, Dmitry Baryshkov,
Mukesh Ojha, Andre Draszik, Kathiravan Thirumoorthy, linux-pm,
linux-kernel, linux-arm-kernel, linux-arm-msm, devicetree,
Srinivas Kandagatla, Song Xue
In-Reply-To: <20260304-arm-psci-system_reset2-vendor-reboots-v20-0-cf7d346b8372@oss.qualcomm.com>
On 3/4/2026 11:33 PM, Shivendra Pratap wrote:
> Userspace should be able to initiate device reboots using the various
> PSCI SYSTEM_RESET and SYSTEM_RESET2 types defined by PSCI spec. This
> patch series introduces psci-reboot-mode driver that registers with
> reboot-mode framework to provide this functionality.
>
> The PSCI system reset calls takes two arguments: reset_type and cookie.
> It defines predefined reset types, such as warm and cold reset, and
> vendor-specific reset types which are SoC vendor specific. To support
> these requirements, the reboot-mode framework is enhanced in two key
> ways:
> 1. 64-bit magic support: Extend reboot-mode to handle two 32-bit
> arguments (reset_type and cookie) by encoding them into a single 64-bit
> magic value.
> 2. Predefined modes: Add support for predefined reboot modes in the
> framework.
>
> With these enhancements, the patch series enables:
> - Warm reset and cold reset as predefined reboot modes.
> - Vendor-specific resets exposed as tunables, configurable via the
> SoC-specific device tree.
>
> Together, these changes allow userspace to trigger all above PSCI resets
> from userspace.
>
> Currently three drivers register with reboot-mode framework -
> syscon-reboot-mode, nvmem-reboot-mode and qcom-pon. Consolidated
> list of commands currently added across various vendor DTs:
> mode-loader
> mode-normal
> mode-bootloader
> mode-charge
> mode-fastboot
> mode-reboot-ab-update
> mode-recovery
> mode-rescue
> mode-shutdown-thermal
> mode-shutdown-thermal-battery
>
> On gs101 we also pass kernel-generated modes from kernel_restart()
> or panic(), specifically DM verity's 'dm-verity device corrupted':
> mode-dm-verity-device-corrupted = <0x50>;
>
> - thanks Andre' for providing this.
>
> Detailed list of commands being used by syscon-reboot-mode:
> arm64/boot/dts/exynos/exynosautov9.dtsi:
> mode-bootloader = <EXYNOSAUTOV9_BOOT_BOOTLOADER>;
> mode-fastboot = <EXYNOSAUTOV9_BOOT_FASTBOOT>;
> mode-recovery = <EXYNOSAUTOV9_BOOT_RECOVERY>;
>
> arm64/boot/dts/exynos/google/gs101.dtsi:
> mode-bootloader = <0xfc>;
> mode-charge = <0x0a>;
> mode-fastboot = <0xfa>;
> mode-reboot-ab-update = <0x52>;
> mode-recovery = <0xff>;
> mode-rescue = <0xf9>;
> mode-shutdown-thermal = <0x51>;
> mode-shutdown-thermal-battery = <0x51>;
>
> arm64/boot/dts/hisilicon/hi3660-hikey960.dts:
> mode-normal = <0x77665501>;
> mode-bootloader = <0x77665500>;
> mode-recovery = <0x77665502>;
>
> arm64/boot/dts/hisilicon/hi6220-hikey.dts:
> mode-normal = <0x77665501>;
> mode-bootloader = <0x77665500>;
> mode-recovery = <0x77665502>;
>
> arm64/boot/dts/rockchip/px30.dtsi:
> mode-bootloader = <BOOT_BL_DOWNLOAD>;
> mode-fastboot = <BOOT_FASTBOOT>;
> mode-loader = <BOOT_BL_DOWNLOAD>;
> mode-normal = <BOOT_NORMAL>;
> mode-recovery = <BOOT_RECOVERY>;
>
> arm64/boot/dts/rockchip/rk3308.dtsi:
> mode-bootloader = <BOOT_BL_DOWNLOAD>;
> mode-loader = <BOOT_BL_DOWNLOAD>;
> mode-normal = <BOOT_NORMAL>;
> mode-recovery = <BOOT_RECOVERY>;
> mode-fastboot = <BOOT_FASTBOOT>;
>
> arm64/boot/dts/rockchip/rk3566-lckfb-tspi.dts:
> mode-normal = <BOOT_NORMAL>;
> mode-loader = <BOOT_BL_DOWNLOAD>;
> mode-recovery = <BOOT_RECOVERY>;
> mode-bootloader = <BOOT_FASTBOOT>;
>
> Detailed list of commands being used by nvmem-reboot-mode:
> arm64/boot/dts/qcom/pmXXXX.dtsi:(multiple qcom DTs)
> mode-recovery = <0x01>;
> mode-bootloader = <0x02>;
>
> The patch is tested on rb3Gen2, lemans-ride, lemans-evk, monaco-ride,
> qcs615-ride.
>
> @Florian/@Kathiravan, Please note that reset_type in DT needs to be
> full in itself with 31st bit set. (eg: 0x80000000).
>
> PS: As advised from Lorenzo, "PSCI maintainers should be added as
> maintainers for psci-reboot-mode".
>
> Previous discussions around SYSTEM_RESET2:
> - https://lore.kernel.org/lkml/20230724223057.1208122-2-quic_eberman@quicinc.com/T/
> - https://lore.kernel.org/all/4a679542-b48d-7e11-f33a-63535a5c68cb@quicinc.com/
>
> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
>
Tested-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] dt-bindings: opp-v2: Fix example 3 CPU reg value
From: Viresh Kumar @ 2026-04-06 4:32 UTC (permalink / raw)
To: Vivian Wang
Cc: Viresh Kumar, Nishanth Menon, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-pm, devicetree,
linux-kernel
In-Reply-To: <20260403-dt-bindings-opp-v2-hex-cpu-reg-v1-1-38a4968ab515@iscas.ac.cn>
On 03-04-26, 18:34, Vivian Wang wrote:
> Example 3 is a dual-cluster example, meaning that the CPU nodes should
> have reg values 0x0, 0x1, 0x100, 0x101. The example incorrectly uses
> decimal 0, 1, 100, 101 instead, which seems unintended. Use the correct
> hexadecimal values.
>
> Even though the value doesn't change for the first two CPUs, 0 and 1 in
> example 3 are changed to 0x0 and 0x1 respectively for consistency. Other
> examples all have reg less than 10, so they have not been changed.
>
> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
> ---
> Found while trying to figure out if cpu@* unit addresses are supposed to
> be decimal or hexadecimal. This is AFAICT the only place in-tree where
> an arm/arm64 DTS uses multi-digit decimal. See also:
>
> - https://lore.kernel.org/devicetree-spec/00ddad5a-02f5-474e-af9c-11ce7716ddfc@iscas.ac.cn/
> - https://github.com/devicetree-org/devicetree-specification/issues/86
> ---
> Documentation/devicetree/bindings/opp/opp-v2.yaml | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/opp/opp-v2.yaml b/Documentation/devicetree/bindings/opp/opp-v2.yaml
> index 6972d76233aa..10000a758572 100644
> --- a/Documentation/devicetree/bindings/opp/opp-v2.yaml
> +++ b/Documentation/devicetree/bindings/opp/opp-v2.yaml
> @@ -172,7 +172,7 @@ examples:
> cpu@0 {
> compatible = "arm,cortex-a7";
> device_type = "cpu";
> - reg = <0>;
> + reg = <0x0>;
> next-level-cache = <&L2>;
> clocks = <&clk_controller 0>;
> clock-names = "cpu";
> @@ -183,7 +183,7 @@ examples:
> cpu@1 {
> compatible = "arm,cortex-a7";
> device_type = "cpu";
> - reg = <1>;
> + reg = <0x1>;
> next-level-cache = <&L2>;
> clocks = <&clk_controller 0>;
> clock-names = "cpu";
> @@ -194,7 +194,7 @@ examples:
> cpu@100 {
> compatible = "arm,cortex-a15";
> device_type = "cpu";
> - reg = <100>;
> + reg = <0x100>;
> next-level-cache = <&L2>;
> clocks = <&clk_controller 1>;
> clock-names = "cpu";
> @@ -205,7 +205,7 @@ examples:
> cpu@101 {
> compatible = "arm,cortex-a15";
> device_type = "cpu";
> - reg = <101>;
> + reg = <0x101>;
> next-level-cache = <&L2>;
> clocks = <&clk_controller 1>;
> clock-names = "cpu";
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* Re: [PATCH 1/2] pmdomain/rockchip: skip QoS operations for idle-only domains
From: Jonas Karlman @ 2026-04-05 23:29 UTC (permalink / raw)
To: Shawn Lin, Daniel Bozeman, finley.xiao@rock-chips.com
Cc: ulf.hansson@linaro.org, heiko@sntech.de, linux-pm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
In-Reply-To: <f1b9a97a-f1f9-0757-5dc7-33960318be61@rock-chips.com>
Hi,
On 4/4/2026 1:40 PM, Shawn Lin wrote:
> + Jonas
>
> 在 2026/04/04 星期六 5:27, Daniel Bozeman 写道:
>> I ran both tests you requested:
>>
>> Test 1: Added pr_err to rockchip_pd_power_on/off to identify
>> the crashing domain. With patch 2 only (skip EPROBE_DEFER),
>> the crash occurs on PD_VO:
>
> Thanks for fing the PD_VO, and I'm still requesting more docs internally
> to check what's going on. I see there are several qos nodes under PD_VO,
> but I'm not sure if they all belong to PD_VO and even not sure if their
> registers are define correctly.
>
> Perhaps, could you help dig more by removing the qos one by one from
> PD_VO to narrow down the broken qos?
>
> I also loop in Jonas who submited the code, to have a look.(I'm also
> surprised to see there aren't any Qos nodes under PD_VO in vendor
> kernel for reference, but upstream code has...)
Upstream included all QoS that seemed to be related to each power domains
based on e.g. vendor DTs, clock driver and other hints.
Vendor kernel mostly seemed to take the easy way out and flagged all
rk3528 power domains as always on or similar, if I recall correctly.
For upstream we have instead tried to describe all power domains without
any always on flag and instead ensure all devices belong to a power
domain.
I do not have access to any rk3528 TRM or similar, so I would not be
surprised if there could be some wrong details. However, runtime
testing at time of patches was sent upstream did not show any issues.
I was however able to reproduce a crash using next-20260403 + rk3528 usb
series [1][2]. Such crash was not happening at the original submission
of the pmdomain or usb series.
Looking at pmdomain core and rk pmdomain driver changes since rk3528
merge I see that there are some changes that may have changed behavior
of the driver since initial rk3528 merge. I.e. GENPD_FLAG_NO_STAY_ON.
Following quick diff seem to remove any changed behavior introduced in
commit 2bc12a8199a0 ("pmdomain: rockchip: Fix regulator dependency with
GENPD_FLAG_NO_STAY_ON"), and fixes the crash for me.
diff --git a/drivers/pmdomain/rockchip/pm-domains.c b/drivers/pmdomain/rockchip/pm-domains.c
index 490bbb1d1d8e..4d69b9f68886 100644
--- a/drivers/pmdomain/rockchip/pm-domains.c
+++ b/drivers/pmdomain/rockchip/pm-domains.c
@@ -892,7 +892,9 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu,
pd->genpd.power_on = rockchip_pd_power_on;
pd->genpd.attach_dev = rockchip_pd_attach_dev;
pd->genpd.detach_dev = rockchip_pd_detach_dev;
- pd->genpd.flags = GENPD_FLAG_PM_CLK | GENPD_FLAG_NO_STAY_ON;
+ pd->genpd.flags = GENPD_FLAG_PM_CLK;
+ if (pd->info->pwr_mask || pd->info->status_mask)
+ pd->genpd.flags |= GENPD_FLAG_NO_STAY_ON;
if (pd_info->active_wakeup)
pd->genpd.flags |= GENPD_FLAG_ACTIVE_WAKEUP;
pm_genpd_init(&pd->genpd, NULL,
Could also be that GENPD_FLAG_NO_STAY_ON only need to be applied to
need_regulator domains?
[1] https://lore.kernel.org/r/20250723122323.2344916-1-jonas@kwiboo.se/
[2] https://github.com/Kwiboo/linux-rockchip/commits/next-20260403-rk3528/
Regards,
Jonas
>
>>
>> rockchip_pd_power_off: vo pwr_mask=0x0
>> Internal error: synchronous external abort: 0000000096000010
>> Workqueue: pm genpd_power_off_work_fn
>> Call trace:
>> regmap_mmio_read32le+0x8/0x20
>> _regmap_bus_reg_read+0x6c/0xac
>> _regmap_read+0x60/0xd8
>> regmap_read+0x4c/0x7c
>> rockchip_pmu_set_idle_request.isra.0+0x98/0x16c
>> rockchip_pd_power+0x130/0x48c
>> rockchip_pd_power_off+0x38/0x48
>> genpd_power_off.isra.0+0x1f0/0x2f0
>> genpd_power_off_work_fn+0x34/0x54
>>
>> Test 2: Same debug build, booted with clk_ignore_unused
>> added to kernel cmdline via U-Boot. Same crash, same domain:
>>
>> rockchip_pd_power_off: vo pwr_mask=0x0
>> Internal error: synchronous external abort: 0000000096000010
>> (identical call trace)
>>
>> The crash occurs even with clk_ignore_unused. The QoS
>> registers for PD_VO are inaccessible when genpd attempts
>> to power off this idle-only domain.
>>
^ permalink raw reply related
* Re: (subset) [PATCH v3 0/3] Enable QoS configuration on QCS615
From: Bjorn Andersson @ 2026-04-05 19:40 UTC (permalink / raw)
To: Georgi Djakov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Odelu Kukatla
Cc: Raviteja Laggyshetty, Dmitry Baryshkov, linux-arm-msm, linux-pm,
devicetree, linux-kernel, Mike Tipton
In-Reply-To: <20260311103548.1823044-1-odelu.kukatla@oss.qualcomm.com>
On Wed, 11 Mar 2026 16:05:45 +0530, Odelu Kukatla wrote:
> This series enables QoS configuration for QNOC type device which
> can be found on QCS615 platform. It enables QoS configuration
> for master ports with predefined priority and urgency forwarding.
> This helps in prioritizing the traffic originating from different
> interconnect masters at NOC (Network On Chip).
>
> The system may function normally without this feature. However,
> enabling QoS helps optimize latency and bandwidth across subsystems
> like CPU, GPU, and multimedia engines, which becomes important in
> high-throughput scenarios. This is a feature aimed at performance
> enhancement to improve system performance under concurrent workloads.
>
> [...]
Applied, thanks!
[3/3] arm64: dts: qcom: talos: Add clocks for QoS configuration
commit: 9b7d6b6c5cef6c578e976a1a605985c255779327
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* [rafael-pm:bleeding-edge] BUILD SUCCESS 6a1d42932a978b706bf626a4824cf92088347874
From: kernel test robot @ 2026-04-05 7:57 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-acpi, linux-pm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: 6a1d42932a978b706bf626a4824cf92088347874 Merge branch 'pm-devfreq' into bleeding-edge
elapsed time: 737m
configs tested: 165
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260405 clang-23
arc randconfig-002-20260405 clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm randconfig-001-20260405 clang-23
arm randconfig-002-20260405 clang-23
arm randconfig-003-20260405 clang-23
arm randconfig-004-20260405 clang-23
arm socfpga_defconfig gcc-15.2.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260405 gcc-9.5.0
arm64 randconfig-002-20260405 gcc-9.5.0
arm64 randconfig-003-20260405 gcc-9.5.0
arm64 randconfig-004-20260405 gcc-9.5.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260405 gcc-9.5.0
csky randconfig-002-20260405 gcc-9.5.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260405 clang-16
hexagon randconfig-001-20260405 clang-23
hexagon randconfig-002-20260405 clang-23
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260405 gcc-14
i386 buildonly-randconfig-002-20260405 gcc-14
i386 buildonly-randconfig-003-20260405 gcc-14
i386 buildonly-randconfig-004-20260405 gcc-14
i386 buildonly-randconfig-005-20260405 gcc-14
i386 buildonly-randconfig-006-20260405 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-011-20260405 gcc-14
i386 randconfig-012-20260405 gcc-14
i386 randconfig-013-20260405 gcc-14
i386 randconfig-014-20260405 gcc-14
i386 randconfig-015-20260405 gcc-14
i386 randconfig-016-20260405 gcc-14
i386 randconfig-017-20260405 gcc-14
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260405 clang-23
loongarch randconfig-002-20260405 clang-23
loongarch randconfig-002-20260405 gcc-13.4.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260405 clang-23
nios2 randconfig-001-20260405 gcc-8.5.0
nios2 randconfig-002-20260405 clang-23
nios2 randconfig-002-20260405 gcc-9.5.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260405 gcc-10.5.0
parisc randconfig-002-20260405 gcc-10.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc randconfig-001-20260405 gcc-10.5.0
powerpc randconfig-002-20260405 gcc-10.5.0
powerpc64 randconfig-001-20260405 gcc-10.5.0
powerpc64 randconfig-002-20260405 gcc-10.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260405 clang-23
riscv randconfig-002-20260405 clang-23
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260405 clang-23
s390 randconfig-002-20260405 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001-20260405 clang-23
sh randconfig-002-20260405 clang-23
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260405 clang-23
sparc randconfig-002-20260405 clang-23
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260405 clang-23
sparc64 randconfig-002-20260405 clang-23
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260405 clang-23
um randconfig-002-20260405 clang-23
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260405 gcc-14
x86_64 buildonly-randconfig-002-20260405 gcc-14
x86_64 buildonly-randconfig-003-20260405 gcc-14
x86_64 buildonly-randconfig-004-20260405 gcc-14
x86_64 buildonly-randconfig-005-20260405 gcc-14
x86_64 buildonly-randconfig-006-20260405 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260405 clang-20
x86_64 randconfig-002-20260405 clang-20
x86_64 randconfig-003-20260405 clang-20
x86_64 randconfig-004-20260405 clang-20
x86_64 randconfig-005-20260405 clang-20
x86_64 randconfig-006-20260405 clang-20
x86_64 randconfig-011-20260405 gcc-14
x86_64 randconfig-012-20260405 gcc-14
x86_64 randconfig-013-20260405 gcc-14
x86_64 randconfig-014-20260405 gcc-14
x86_64 randconfig-015-20260405 gcc-14
x86_64 randconfig-016-20260405 gcc-14
x86_64 randconfig-071-20260405 gcc-14
x86_64 randconfig-072-20260405 gcc-14
x86_64 randconfig-073-20260405 gcc-14
x86_64 randconfig-074-20260405 gcc-14
x86_64 randconfig-075-20260405 gcc-14
x86_64 randconfig-076-20260405 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260405 clang-23
xtensa randconfig-002-20260405 clang-23
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] dt-bindings: opp-v2: Fix example 3 CPU reg value
From: Krzysztof Kozlowski @ 2026-04-05 7:27 UTC (permalink / raw)
To: Vivian Wang
Cc: Viresh Kumar, Nishanth Menon, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Viresh Kumar, linux-pm,
devicetree, linux-kernel
In-Reply-To: <20260403-dt-bindings-opp-v2-hex-cpu-reg-v1-1-38a4968ab515@iscas.ac.cn>
On Fri, Apr 03, 2026 at 06:34:29PM +0800, Vivian Wang wrote:
> Example 3 is a dual-cluster example, meaning that the CPU nodes should
> have reg values 0x0, 0x1, 0x100, 0x101. The example incorrectly uses
> decimal 0, 1, 100, 101 instead, which seems unintended. Use the correct
> hexadecimal values.
>
> Even though the value doesn't change for the first two CPUs, 0 and 1 in
> example 3 are changed to 0x0 and 0x1 respectively for consistency. Other
> examples all have reg less than 10, so they have not been changed.
>
> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH RESEND v1] thermal: core: fix blocking in unregistering zone
From: Guenter Roeck @ 2026-04-05 3:34 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Jiajia Liu, Daniel Lezcano, Zhang Rui, Lukasz Luba, linux-pm,
linux-kernel, Armin Wolf, linux-hwmon
In-Reply-To: <CAJZ5v0g83UQKRcZ+u5EM13gwzktMXAxLqqcCoT8+CQLzOnChiw@mail.gmail.com>
On 4/4/26 10:38, Rafael J. Wysocki wrote:
> On Sat, Apr 4, 2026 at 4:02 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> On 4/4/26 05:58, Rafael J. Wysocki wrote:
>>> On Fri, Apr 3, 2026 at 4:20 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>>>
>>>> On 4/3/26 05:52, Rafael J. Wysocki wrote:
>>>> .[ ... ]
>>>>> It appears to work for me, but I'm not sure if having multiple hwmon class
>>>>> devices with the same value in the name attribute is fine.
>>>>
>>>> Like this ?
>>>>
>>>> $ cd /sys/class/hwmon
>>>> $ grep . */name
>>>> hwmon0/name:r8169_0_c00:00
>>>> hwmon1/name:nvme
>>>> hwmon2/name:nvme
>>>> hwmon3/name:nct6687
>>>> hwmon4/name:k10temp
>>>> hwmon5/name:spd5118
>>>> hwmon6/name:spd5118
>>>> hwmon7/name:spd5118
>>>> hwmon8/name:spd5118
>>>> hwmon9/name:mt7921_phy0
>>>
>>> Yes.
>>>
>>>> Names such as "r8169_0_c00:00" and "mt7921_phy0" are actually overkill
>>>> since the "sensors" command makes it
>>>>
>>>> r8169_0_c00:00-mdio-0
>>>> Adapter: MDIO adapter
>>>> temp1: +36.0°C (high = +120.0°C)
>>>>
>>>> mt7921_phy0-pci-0d00
>>>> Adapter: PCI adapter
>>>> temp1: +30.0°C
>>>>
>>>> essentially duplicating the device index.
>>>
>>> Well, with the patch posted by me, the output of sensors from a test
>>> system looks like this:
>>>
>>> acpitz-acpi-0
>>> Adapter: ACPI interface
>>> temp1: +16.8°C
>>>
>>> pch_cannonlake-virtual-0
>>> Adapter: Virtual device
>>> temp1: +33.0°C
>>>
>>> acpitz-acpi-0
>>> Adapter: ACPI interface
>>> temp1: +27.8°C
>>>
>>> (some further data excluded), which is kind of confusing (note the
>>> duplicate acpitz-acpi-0 entries with different values of temp1).
>>>
>>
>> Yes, agreed, that is confusing. I would have expected the second one
>> to be identified as "acpitz-acpi-1". Do they both have the same parent ?
>
> No, they don't.
>
> The parent of each of them is a thermal zone device and both parents
> have the same "type" value.
>
>>> That could be disambiguated by concatenating the thermal zone ID
>>> (possibly after a '_') to the name. Or the "temp*" things for thermal
>>> zones of the same type could carry different numbers.
>>>
>>> A less attractive alternative would be to register a special virtual
>>> device serving as a parent for all hwmon interfaces registered
>>> automatically for thermal zones.
>>
>> If they all have the same parent, technically it should be a single
>> hwmon device with multiple sensors, as in:
>>
>> acpitz-acpi-0
>> Adapter: ACPI interface
>> temp1: +16.8°C
>> temp2: +27.8°C
>
> So somebody tried to make it look like that by registering hwmon
> interfaces for all of the thermal zones of the same type under one of
> them, but that (quite obviously) doesn't work.
Not sure I understand why that doesn't work or why that is obvious,
but I'll take you by your word (I would agree that the current
_implementation_ looks problematic).
I looked into the source code of the "sensors" command. It indeed does
not index ACPI devices (nor virtual devices, for that matter) but
assumes that such devices are unique. My apologies for not realizing
this earlier.
So your only option is indeed to index the chip name if you want/need
more than one hwmon device with the same base name (here: acpitz)
instantiated from the thermal subsystem.
One comment to one of your earlier e-mails:
"However, it is more of a design issue IMV because putting temperature
attributes for all of the (possibly unrelated) thermal zones of the
same type under one hwmon interface is not particularly useful"
A single hardware monitoring device, by design, serves multiple
thermal zones. Anything else would not make sense for multi-channel
hardware monitoring chips. The hardware monitoring subsystem groups
sensors by chip, not by thermal zones.
Having said this: This discussion is not new. Certain subsystems
advocate for having one hardware monitoring device per sensor,
not per chip. One submitter went as far as telling me that I am
clueless. We don't need to repeat the exercise. I have my opinion,
you have yours, and all we can do is to agree to disagree.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH 1/2] pmdomain/rockchip: skip QoS operations for idle-only domains
From: Daniel Bozeman @ 2026-04-04 22:42 UTC (permalink / raw)
To: shawn.lin, finley.xiao, jonas, ulf.hansson, heiko, linux-pm,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <f1b9a97a-f1f9-0757-5dc7-33960318be61@rock-chips.com>
Further testing with NO kernel patches and fw_devlink=strict
reveals both crashes happening simultaneously on different
CPUs:
CPU1 (genpd_power_off_work_fn):
pc : regmap_mmio_read32le+0x8/0x20
Workqueue: pm genpd_power_off_work_fn
CPU2 (deferred_probe_work_func):
pc : clk_gate_endisable+0xa8/0x130
Workqueue: events_unbound deferred_probe_work_func
Kernel panic - not syncing: Asynchronous SError Interrupt
This shows there are perhaps two independent issues:
1. genpd tries to power off idle-only domains and crashes
in rockchip_pmu_set_idle_request (the regmap read at
PMU offset 0x1120 faults)
2. GPIO4 probes while PD_RKVENC is not registered (power
domain controller tore down due to PD_GPU EPROBE_DEFER)
and crashes in clk_gate_endisable
Both crashes occur in the unpatched kernel. Previously we
only observed crash #2 because it appeared first in serial
output, but maybe they're racing on different CPUs?
I also tested removing all pm_qos from all idle-only
domains (PD_VO, PD_RKVENC, PD_VPU). Crash #1 still
occurs. Because it is in rockchip_pmu_set_idle_request,
not in QoS save/restore?
fw_devlink=strict does not prevent either crash.
^ permalink raw reply
* Re: [PATCH v2 2/2] pmdomain: qcom: rpmhpd: Add power domains for Hawi SoC
From: Dmitry Baryshkov @ 2026-04-04 21:48 UTC (permalink / raw)
To: Fenglin Wu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Konrad Dybcio, Subbaraman Narayanamurthy,
linux-arm-msm, devicetree, linux-kernel, linux-pm, kernel,
Taniya Das
In-Reply-To: <20260402-haw-rpmhpd-v2-2-2bce0767f2ca@oss.qualcomm.com>
On Thu, Apr 02, 2026 at 05:35:22PM -0700, Fenglin Wu wrote:
> Add the RPMh power domains required for the Hawi SoC. This includes
> new definitions for domains supplying specific hardware components:
> - DCX: supplies VDD_DISP
> - GBX: supplies VDD_GFX_BX
>
> Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> drivers/pmdomain/qcom/rpmhpd.c | 38 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [GIT PULL] devfreq next for 7.1
From: Rafael J. Wysocki @ 2026-04-04 19:00 UTC (permalink / raw)
To: Choi Chanwoo
Cc: rafael, linux-kernel, linux-pm, myungjoo.ham, kyungmin.park,
cw00.choi, chanwoo
In-Reply-To: <346b33f9-5ca5-4735-a89b-f7cf813419ef@gmail.com>
Hi Chanwoo,
On Fri, Apr 3, 2026 at 8:31 PM Choi Chanwoo <cwchoi00@gmail.com> wrote:
>
> Dear Rafael,
>
> This is devfreq-next pull request. I add detailed description of
> this pull request on the following tag. Please pull devfreq with
> following updates.
>
> Best Regards,
> Chanwoo Choi
>
>
> The following changes since commit 7aaa8047eafd0bd628065b15757d9b48c5f9c07d:
>
> Linux 7.0-rc6 (2026-03-29 15:40:00 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git tags/devfreq-next-for-7.1
>
> for you to fetch changes up to cd905830ea6184d6678386ce2d652bec324034d1:
>
> PM / devfreq: tegra30-devfreq: add support for Tegra114 (2026-04-04 03:15:39 +0900)
>
> ----------------------------------------------------------------
> Update devfreq next for v7.1
>
> Detailed description for this pull request:
> - Remove unneeded casting for HZ_PER_KHZ on devfreq.c
>
> - Use _visible attribute to replace create/remove_sysfs_files() to fix sysfs
> attribute race conditions on devfreq.c
>
> - Add support for Tegra114 activity monitor device on tegra30-devfreq.c
>
> ----------------------------------------------------------------
>
> Andy Shevchenko (1):
> PM / devfreq: Remove unneeded casting for HZ_PER_KHZ
>
> Pengjie Zhang (1):
> PM / devfreq: use _visible attribute to replace create/remove_sysfs_files()
>
> Svyatoslav Ryhel (1):
> PM / devfreq: tegra30-devfreq: add support for Tegra114
>
> drivers/devfreq/devfreq.c | 108 ++++++++++++++++++++++----------------
> drivers/devfreq/tegra30-devfreq.c | 17 ++++--
> 2 files changed, 74 insertions(+), 51 deletions(-)
Pulled, thanks!
^ permalink raw reply
* Re: [GIT PULL] amd-pstate new content for 7.1 (2026-04-02)
From: Rafael J. Wysocki @ 2026-04-04 18:57 UTC (permalink / raw)
To: Mario Limonciello; +Cc: Rafael J. Wysocki, Linux PM
In-Reply-To: <8f7a08eb-26ae-47a5-bcb5-b0db7c8f771b@kernel.org>
On Thu, Apr 2, 2026 at 10:33 PM Mario Limonciello <superm1@kernel.org> wrote:
>
> The following changes since commit c369299895a591d96745d6492d4888259b004a9e:
>
> Linux 7.0-rc5 (2026-03-22 14:42:17 -0700)
>
> are available in the Git repository at:
>
>
> ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux.git
> tags/amd-pstate-v7.1-2026-04-02
>
> for you to fetch changes up to 9487e2a00e7b3c6f258c5c99953f470eba6fb61d:
>
> MAINTAINERS: amd-pstate: Step down as maintainer, add Prateek as
> reviewer (2026-04-02 11:30:24 -0500)
>
> ----------------------------------------------------------------
> amd-pstate new content for 7.1 (2026-04-02)
>
> Add support for new features:
> * CPPC performance priority
> * Dynamic EPP
> * Raw EPP
> * New unit tests for new features
> Fixes for:
> * PREEMPT_RT
> * sysfs files being present when HW missing
> * Broken/outdated documentation
>
> ----------------------------------------------------------------
> Gautham R. Shenoy (13):
> amd-pstate: Fix memory leak in amd_pstate_epp_cpu_init()
> amd-pstate: Update cppc_req_cached in fast_switch case
> amd-pstate: Make certain freq_attrs conditionally visible
> x86/cpufeatures: Add AMD CPPC Performance Priority feature.
> amd-pstate: Add support for CPPC_REQ2 and FLOOR_PERF
> amd-pstate: Add sysfs support for floor_freq and floor_count
> amd-pstate: Introduce a tracepoint trace_amd_pstate_cppc_req2()
> amd-pstate-ut: Add module parameter to select testcases
> amd-pstate-ut: Add a testcase to validate the visibility of
> driver attributes
> Documentation/amd-pstate: List amd_pstate_hw_prefcore sysfs file
> Documentation/amd-pstate: List amd_pstate_prefcore_ranking sysfs file
> Documentation/amd-pstate: Add documentation for
> amd_pstate_floor_{freq,count}
> MAINTAINERS: amd-pstate: Step down as maintainer, add Prateek as
> reviewer
>
> K Prateek Nayak (2):
> cpufreq/amd-pstate: Pass the policy to amd_pstate_update()
> cpufreq: Pass the policy to cpufreq_driver->adjust_perf()
>
> Mario Limonciello (AMD) (6):
> cpufreq/amd-pstate: Cache the max frequency in cpudata
> cpufreq/amd-pstate: Add dynamic energy performance preference
> cpufreq/amd-pstate: add kernel command line to override dynamic epp
> cpufreq/amd-pstate: Add support for platform profile class
> cpufreq/amd-pstate: Add support for raw EPP writes
> cpufreq/amd-pstate-ut: Add a unit test for raw EPP
>
> Ninad Naik (1):
> Documentation: amd-pstate: fix dead links in the reference section
>
> Documentation/admin-guide/kernel-parameters.txt | 7 ++
> Documentation/admin-guide/pm/amd-pstate.rst | 87 ++++++++++++--
> MAINTAINERS | 2 +-
> arch/x86/include/asm/cpufeatures.h | 2 +-
> arch/x86/include/asm/msr-index.h | 5 +
> arch/x86/kernel/cpu/scattered.c | 1 +
> drivers/cpufreq/Kconfig.x86 | 13 +++
> drivers/cpufreq/amd-pstate-trace.h | 35 ++++++
> drivers/cpufreq/amd-pstate-ut.c | 279
> +++++++++++++++++++++++++++++++++++++++++++-
> drivers/cpufreq/amd-pstate.c | 625
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------
> drivers/cpufreq/amd-pstate.h | 37 +++++-
> drivers/cpufreq/cpufreq.c | 6 +-
> drivers/cpufreq/intel_pstate.c | 4 +-
> include/linux/cpufreq.h | 4 +-
> kernel/sched/cpufreq_schedutil.c | 5 +-
> rust/kernel/cpufreq.rs | 13 +--
> tools/arch/x86/include/asm/cpufeatures.h | 2 +-
> 17 files changed, 1009 insertions(+), 118 deletions(-)
Pulled, thanks!
^ permalink raw reply
* Re: [PATCH RESEND v1] thermal: core: fix blocking in unregistering zone
From: Rafael J. Wysocki @ 2026-04-04 17:38 UTC (permalink / raw)
To: Guenter Roeck
Cc: Rafael J. Wysocki, Jiajia Liu, Daniel Lezcano, Zhang Rui,
Lukasz Luba, linux-pm, linux-kernel, Armin Wolf, linux-hwmon
In-Reply-To: <ec16fc75-c5fa-4ff9-bc6b-91464e9c26cc@roeck-us.net>
On Sat, Apr 4, 2026 at 4:02 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 4/4/26 05:58, Rafael J. Wysocki wrote:
> > On Fri, Apr 3, 2026 at 4:20 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >>
> >> On 4/3/26 05:52, Rafael J. Wysocki wrote:
> >> .[ ... ]
> >>> It appears to work for me, but I'm not sure if having multiple hwmon class
> >>> devices with the same value in the name attribute is fine.
> >>
> >> Like this ?
> >>
> >> $ cd /sys/class/hwmon
> >> $ grep . */name
> >> hwmon0/name:r8169_0_c00:00
> >> hwmon1/name:nvme
> >> hwmon2/name:nvme
> >> hwmon3/name:nct6687
> >> hwmon4/name:k10temp
> >> hwmon5/name:spd5118
> >> hwmon6/name:spd5118
> >> hwmon7/name:spd5118
> >> hwmon8/name:spd5118
> >> hwmon9/name:mt7921_phy0
> >
> > Yes.
> >
> >> Names such as "r8169_0_c00:00" and "mt7921_phy0" are actually overkill
> >> since the "sensors" command makes it
> >>
> >> r8169_0_c00:00-mdio-0
> >> Adapter: MDIO adapter
> >> temp1: +36.0°C (high = +120.0°C)
> >>
> >> mt7921_phy0-pci-0d00
> >> Adapter: PCI adapter
> >> temp1: +30.0°C
> >>
> >> essentially duplicating the device index.
> >
> > Well, with the patch posted by me, the output of sensors from a test
> > system looks like this:
> >
> > acpitz-acpi-0
> > Adapter: ACPI interface
> > temp1: +16.8°C
> >
> > pch_cannonlake-virtual-0
> > Adapter: Virtual device
> > temp1: +33.0°C
> >
> > acpitz-acpi-0
> > Adapter: ACPI interface
> > temp1: +27.8°C
> >
> > (some further data excluded), which is kind of confusing (note the
> > duplicate acpitz-acpi-0 entries with different values of temp1).
> >
>
> Yes, agreed, that is confusing. I would have expected the second one
> to be identified as "acpitz-acpi-1". Do they both have the same parent ?
No, they don't.
The parent of each of them is a thermal zone device and both parents
have the same "type" value.
> > That could be disambiguated by concatenating the thermal zone ID
> > (possibly after a '_') to the name. Or the "temp*" things for thermal
> > zones of the same type could carry different numbers.
> >
> > A less attractive alternative would be to register a special virtual
> > device serving as a parent for all hwmon interfaces registered
> > automatically for thermal zones.
>
> If they all have the same parent, technically it should be a single
> hwmon device with multiple sensors, as in:
>
> acpitz-acpi-0
> Adapter: ACPI interface
> temp1: +16.8°C
> temp2: +27.8°C
So somebody tried to make it look like that by registering hwmon
interfaces for all of the thermal zones of the same type under one of
them, but that (quite obviously) doesn't work.
^ permalink raw reply
* Re: [PATCH RESEND v1] thermal: core: fix blocking in unregistering zone
From: Guenter Roeck @ 2026-04-04 14:02 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Jiajia Liu, Daniel Lezcano, Zhang Rui, Lukasz Luba, linux-pm,
linux-kernel, Armin Wolf, linux-hwmon
In-Reply-To: <CAJZ5v0jZPXC5g3KY+trwmV=nXJu74y=0LaQTHaQ_MnqcfPVAGQ@mail.gmail.com>
On 4/4/26 05:58, Rafael J. Wysocki wrote:
> On Fri, Apr 3, 2026 at 4:20 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> On 4/3/26 05:52, Rafael J. Wysocki wrote:
>> .[ ... ]
>>> It appears to work for me, but I'm not sure if having multiple hwmon class
>>> devices with the same value in the name attribute is fine.
>>
>> Like this ?
>>
>> $ cd /sys/class/hwmon
>> $ grep . */name
>> hwmon0/name:r8169_0_c00:00
>> hwmon1/name:nvme
>> hwmon2/name:nvme
>> hwmon3/name:nct6687
>> hwmon4/name:k10temp
>> hwmon5/name:spd5118
>> hwmon6/name:spd5118
>> hwmon7/name:spd5118
>> hwmon8/name:spd5118
>> hwmon9/name:mt7921_phy0
>
> Yes.
>
>> Names such as "r8169_0_c00:00" and "mt7921_phy0" are actually overkill
>> since the "sensors" command makes it
>>
>> r8169_0_c00:00-mdio-0
>> Adapter: MDIO adapter
>> temp1: +36.0°C (high = +120.0°C)
>>
>> mt7921_phy0-pci-0d00
>> Adapter: PCI adapter
>> temp1: +30.0°C
>>
>> essentially duplicating the device index.
>
> Well, with the patch posted by me, the output of sensors from a test
> system looks like this:
>
> acpitz-acpi-0
> Adapter: ACPI interface
> temp1: +16.8°C
>
> pch_cannonlake-virtual-0
> Adapter: Virtual device
> temp1: +33.0°C
>
> acpitz-acpi-0
> Adapter: ACPI interface
> temp1: +27.8°C
>
> (some further data excluded), which is kind of confusing (note the
> duplicate acpitz-acpi-0 entries with different values of temp1).
>
Yes, agreed, that is confusing. I would have expected the second one
to be identified as "acpitz-acpi-1". Do they both have the same parent ?
> That could be disambiguated by concatenating the thermal zone ID
> (possibly after a '_') to the name. Or the "temp*" things for thermal
> zones of the same type could carry different numbers.
>
> A less attractive alternative would be to register a special virtual
> device serving as a parent for all hwmon interfaces registered
> automatically for thermal zones.
If they all have the same parent, technically it should be a single
hwmon device with multiple sensors, as in:
acpitz-acpi-0
Adapter: ACPI interface
temp1: +16.8°C
temp2: +27.8°C
Guenter
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox