* [PATCH 3/7] remoteproc: qcom_q6v5_mss: Use mss as regulator for MSM8953
From: Barnabás Czémán @ 2026-03-27 20:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Mathieu Poirier, Konrad Dybcio, Stephan Gerhold
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pm,
linux-remoteproc, Barnabás Czémán
In-Reply-To: <20260327-sdm632-rpmpd-v1-0-6098dc997d66@mainlining.org>
MSM8953 MSS is using mss-supply as regulator what is usually pm8953_s1.
Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
---
drivers/remoteproc/qcom_q6v5_mss.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
index 4e9eb5bd11fa..86edd826ede8 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -2705,6 +2705,14 @@ static const struct rproc_hexagon_res msm8953_mss = {
},
{}
},
+ .active_supply = (struct qcom_mss_reg_res[]) {
+ {
+ .supply = "mss",
+ .uV = 1050000,
+ .uA = 100000,
+ },
+ {}
+ },
.proxy_clk_names = (char*[]){
"xo",
NULL
@@ -2718,7 +2726,6 @@ static const struct rproc_hexagon_res msm8953_mss = {
.proxy_pd_names = (char*[]) {
"cx",
"mx",
- "mss",
NULL
},
.need_mem_protection = false,
--
2.53.0
^ permalink raw reply related
* [PATCH 1/7] dt-bindings: power: qcom-rpmpd: Split MSM8953 and SDM632
From: Barnabás Czémán @ 2026-03-27 20:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Mathieu Poirier, Konrad Dybcio, Stephan Gerhold
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pm,
linux-remoteproc, Barnabás Czémán
In-Reply-To: <20260327-sdm632-rpmpd-v1-0-6098dc997d66@mainlining.org>
Remove modem related bindings from MSM8953 rpmpd because MSM8953 MSS
is using mss-supply as a regulator usually it is pm8953_s1.
Split SDM632 bindings from MSM8953 because SDM632 is using mss-supply
as a pm domain.
Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
---
.../devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
include/dt-bindings/power/qcom-rpmpd.h | 20 +++++++++++++-------
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
index 8174ceeab572..659936d6a46e 100644
--- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
@@ -48,6 +48,7 @@ properties:
- qcom,sc7280-rpmhpd
- qcom,sc8180x-rpmhpd
- qcom,sc8280xp-rpmhpd
+ - qcom,sdm632-rpmpd
- qcom,sdm660-rpmpd
- qcom,sdm670-rpmhpd
- qcom,sdm845-rpmhpd
diff --git a/include/dt-bindings/power/qcom-rpmpd.h b/include/dt-bindings/power/qcom-rpmpd.h
index 4371ac941f29..2d82434b993c 100644
--- a/include/dt-bindings/power/qcom-rpmpd.h
+++ b/include/dt-bindings/power/qcom-rpmpd.h
@@ -84,13 +84,11 @@
#define QM215_VDDMX_AO MSM8917_VDDMX_AO
/* MSM8953 Power Domain Indexes */
-#define MSM8953_VDDMD 0
-#define MSM8953_VDDMD_AO 1
-#define MSM8953_VDDCX 2
-#define MSM8953_VDDCX_AO 3
-#define MSM8953_VDDCX_VFL 4
-#define MSM8953_VDDMX 5
-#define MSM8953_VDDMX_AO 6
+#define MSM8953_VDDCX RPMPD_VDDCX
+#define MSM8953_VDDCX_AO RPMPD_VDDCX_AO
+#define MSM8953_VDDCX_VFL RPMPD_VDDCX_VFL
+#define MSM8953_VDDMX RPMPD_VDDMX
+#define MSM8953_VDDMX_AO RPMPD_VDDMX_AO
/* MSM8974 Power Domain Indexes */
#define MSM8974_VDDCX 0
@@ -156,6 +154,14 @@
#define QCS404_LPIMX 5
#define QCS404_LPIMX_VFL 6
+/* SDM632 Power Domain Indexes */
+#define SDM632_VDDMD 0
+#define SDM632_VDDCX 1
+#define SDM632_VDDCX_AO 2
+#define SDM632_VDDCX_VFL 3
+#define SDM632_VDDMX 4
+#define SDM632_VDDMX_AO 5
+
/* SDM660 Power Domains */
#define SDM660_VDDCX RPMPD_VDDCX
#define SDM660_VDDCX_AO RPMPD_VDDCX_AO
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v8 0/2] cpufreq: Introduce boost frequency QoS
From: Pierre Gondois @ 2026-03-27 16:07 UTC (permalink / raw)
To: Viresh Kumar
Cc: linux-kernel, Lifeng Zheng, Huang Rui, Gautham R. Shenoy,
Mario Limonciello, Perry Yuan, Rafael J. Wysocki, linux-pm
In-Reply-To: <mv7ham5nlret74v6kvstourb2f7d4zxurbgpqm57w7c3hzdw2c@w2rx5r2t5vyg>
On 3/27/26 04:43, Viresh Kumar wrote:
> On 26-03-26, 21:43, Pierre Gondois wrote:
>> Pierre Gondois (2):
>> cpufreq: Remove max_freq_req update for pre-existing policy
>> cpufreq: Add boost_freq_req QoS request
>>
>> drivers/cpufreq/amd-pstate.c | 2 --
>> drivers/cpufreq/cppc_cpufreq.c | 10 ++-----
>> drivers/cpufreq/cpufreq.c | 50 +++++++++++++++++++++-------------
>> include/linux/cpufreq.h | 1 +
>> 4 files changed, 34 insertions(+), 29 deletions(-)
> Thanks Pierre for your patience.
Thanks for the review (to Lifeng aswell)
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>
^ permalink raw reply
* [rafael-pm:bleeding-edge] BUILD SUCCESS ccbc696f9e4ceb00bd007184c84bf8e08344da99
From: kernel test robot @ 2026-03-27 15:54 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: ccbc696f9e4ceb00bd007184c84bf8e08344da99 Merge branch 'acpi-tables' into bleeding-edge
elapsed time: 1201m
configs tested: 153
configs skipped: 4
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 gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260327 gcc-11.5.0
arc randconfig-002-20260327 gcc-8.5.0
arm allnoconfig clang-23
arm allyesconfig gcc-15.2.0
arm defconfig clang-23
arm randconfig-001-20260327 gcc-8.5.0
arm randconfig-002-20260327 clang-23
arm randconfig-003-20260327 clang-18
arm randconfig-004-20260327 gcc-11.5.0
arm tegra_defconfig gcc-15.2.0
arm64 allmodconfig clang-19
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260327 clang-23
arm64 randconfig-002-20260327 clang-18
arm64 randconfig-003-20260327 gcc-9.5.0
arm64 randconfig-004-20260327 clang-23
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260327 gcc-15.2.0
csky randconfig-002-20260327 gcc-15.2.0
hexagon allmodconfig clang-17
hexagon allnoconfig clang-23
hexagon defconfig clang-23
hexagon randconfig-001-20260327 clang-23
hexagon randconfig-002-20260327 clang-19
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260327 clang-20
i386 buildonly-randconfig-002-20260327 clang-20
i386 buildonly-randconfig-003-20260327 gcc-14
i386 buildonly-randconfig-004-20260327 clang-20
i386 buildonly-randconfig-005-20260327 clang-20
i386 buildonly-randconfig-006-20260327 gcc-14
i386 defconfig clang-20
i386 randconfig-001-20260327 clang-20
i386 randconfig-002-20260327 clang-20
i386 randconfig-003-20260327 gcc-14
i386 randconfig-004-20260327 clang-20
i386 randconfig-005-20260327 clang-20
i386 randconfig-006-20260327 clang-20
i386 randconfig-007-20260327 gcc-14
i386 randconfig-011-20260327 clang-20
i386 randconfig-012-20260327 gcc-14
i386 randconfig-013-20260327 gcc-12
i386 randconfig-014-20260327 gcc-12
i386 randconfig-015-20260327 clang-20
i386 randconfig-016-20260327 gcc-14
i386 randconfig-017-20260327 gcc-14
loongarch allmodconfig clang-19
loongarch allnoconfig clang-23
loongarch defconfig clang-19
loongarch randconfig-001-20260327 gcc-15.2.0
loongarch randconfig-002-20260327 clang-23
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig gcc-15.2.0
m68k defconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig gcc-15.2.0
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig gcc-11.5.0
nios2 defconfig gcc-11.5.0
nios2 randconfig-001-20260327 gcc-9.5.0
nios2 randconfig-002-20260327 gcc-8.5.0
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allnoconfig gcc-15.2.0
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260327 gcc-8.5.0
parisc randconfig-002-20260327 gcc-8.5.0
parisc64 defconfig gcc-15.2.0
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig gcc-15.2.0
powerpc randconfig-001-20260327 gcc-8.5.0
powerpc randconfig-002-20260327 clang-18
powerpc64 randconfig-001-20260327 clang-23
powerpc64 randconfig-002-20260327 clang-23
riscv allmodconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig clang-23
riscv randconfig-001-20260327 clang-23
riscv randconfig-002-20260327 clang-23
s390 allmodconfig clang-18
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig clang-23
s390 randconfig-001-20260327 clang-23
s390 randconfig-002-20260327 gcc-12.5.0
sh allmodconfig gcc-15.2.0
sh allnoconfig gcc-15.2.0
sh allyesconfig gcc-15.2.0
sh defconfig gcc-15.2.0
sh randconfig-001-20260327 gcc-14.3.0
sh randconfig-002-20260327 gcc-13.4.0
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260327 gcc-14.3.0
sparc randconfig-002-20260327 gcc-13.4.0
sparc64 allmodconfig clang-23
sparc64 defconfig clang-20
sparc64 randconfig-001-20260327 clang-23
sparc64 randconfig-002-20260327 clang-23
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um defconfig clang-23
um i386_defconfig gcc-14
um randconfig-001-20260327 gcc-14
um randconfig-002-20260327 clang-23
um x86_64_defconfig clang-23
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260327 clang-20
x86_64 buildonly-randconfig-002-20260327 clang-20
x86_64 buildonly-randconfig-003-20260327 gcc-14
x86_64 buildonly-randconfig-004-20260327 clang-20
x86_64 buildonly-randconfig-005-20260327 gcc-14
x86_64 buildonly-randconfig-006-20260327 gcc-14
x86_64 defconfig gcc-14
x86_64 randconfig-001-20260327 clang-20
x86_64 randconfig-002-20260327 clang-20
x86_64 randconfig-003-20260327 gcc-14
x86_64 randconfig-004-20260327 clang-20
x86_64 randconfig-005-20260327 gcc-14
x86_64 randconfig-006-20260327 gcc-14
x86_64 randconfig-071-20260327 clang-20
x86_64 randconfig-072-20260327 clang-20
x86_64 randconfig-073-20260327 clang-20
x86_64 randconfig-074-20260327 gcc-13
x86_64 randconfig-075-20260327 clang-20
x86_64 randconfig-076-20260327 clang-20
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig gcc-15.2.0
xtensa randconfig-001-20260327 gcc-14.3.0
xtensa randconfig-002-20260327 gcc-10.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 3/3] arm64/sched: Enable CPPC-based asympacking
From: Valentin Schneider @ 2026-03-27 15:44 UTC (permalink / raw)
To: Christian Loehle, arighi
Cc: peterz, vincent.guittot, dietmar.eggemann, valentin.schneider,
mingo, rostedt, segall, mgorman, catalin.marinas, will,
sudeep.holla, rafael, linux-pm, linux-kernel, juri.lelli, kobak,
fabecassis, Christian Loehle
In-Reply-To: <20260325181314.3875909-4-christian.loehle@arm.com>
On 25/03/26 18:13, Christian Loehle wrote:
> @@ -1753,7 +1760,7 @@ static inline int topology_arch_sched_asym_flags(void)
> #ifdef CONFIG_SCHED_SMT
> int cpu_smt_flags(void)
> {
> - return SD_SHARE_CPUCAPACITY | SD_SHARE_LLC;
> + return SD_SHARE_CPUCAPACITY | SD_SHARE_LLC | arch_sched_asym_flags();
> }
>
> const struct cpumask *tl_smt_mask(struct sched_domain_topology_level *tl, int cpu)
> @@ -1765,7 +1772,7 @@ const struct cpumask *tl_smt_mask(struct sched_domain_topology_level *tl, int cp
> #ifdef CONFIG_SCHED_CLUSTER
> int cpu_cluster_flags(void)
> {
> - return SD_CLUSTER | SD_SHARE_LLC;
> + return SD_CLUSTER | SD_SHARE_LLC | arch_sched_asym_flags();
> }
>
> const struct cpumask *tl_cls_mask(struct sched_domain_topology_level *tl, int cpu)
> @@ -1777,7 +1784,7 @@ const struct cpumask *tl_cls_mask(struct sched_domain_topology_level *tl, int cp
> #ifdef CONFIG_SCHED_MC
> int cpu_core_flags(void)
> {
> - return SD_SHARE_LLC;
> + return SD_SHARE_LLC | arch_sched_asym_flags();
> }
>
So while the binning problem applies to more than one architecture, I'm not
sure we want this to be generally applied to all topology levels. This is
/technically/ not a problem since even if a topology level has
SD_ASYM_PACKING, all CPUs at that level can have the same priority, but
in that case it's a bit wasteful.
I don't have any better ideas ATM to keep this arch-specific via
set_sched_topology(), like how x86 and powerpc handle asym packing.
^ permalink raw reply
* Re: [PATCH v2] thermal: core: Address thermal zone removal races with resume
From: Rafael J. Wysocki @ 2026-03-27 14:50 UTC (permalink / raw)
To: Mauricio Faria de Oliveira
Cc: Rafael J. Wysocki, Linux PM, Daniel Lezcano, Lukasz Luba, LKML,
Kernel Dev
In-Reply-To: <00a83964cc75f86bed096bac6256b890@igalia.com>
On Fri, Mar 27, 2026 at 3:47 PM Mauricio Faria de Oliveira
<mfo@igalia.com> wrote:
>
> On 2026-03-27 06:49, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > Since thermal_zone_pm_complete() and thermal_zone_device_resume()
> > re-initialize the poll_queue delayed work for the given thermal zone,
> > the cancel_delayed_work_sync() in thermal_zone_device_unregister()
> > may miss some already running work items and the thermal zone may
> > be freed prematurely [1].
> >
> > There are two failing scenarios that both start with
> > running thermal_pm_notify_complete() right before invoking
> > thermal_zone_device_unregister() for one of the thermal zones.
> >
> > In the first scenario, there is a work item already running for
> > the given thermal zone when thermal_pm_notify_complete() calls
> > thermal_zone_pm_complete() for that thermal zone and it continues to
> > run when thermal_zone_device_unregister() starts. Since the poll_queue
> > delayed work has been re-initialized by thermal_pm_notify_complete(), the
> > running work item will be missed by the cancel_delayed_work_sync() in
> > thermal_zone_device_unregister() and if it continues to run past the
> > freeing of the thermal zone object, a use-after-free will occur.
> >
> > In the second scenario, thermal_zone_device_resume() queued up by
> > thermal_pm_notify_complete() runs right after the thermal_zone_exit()
> > called by thermal_zone_device_unregister() has returned. The poll_queue
> > delayed work is re-initialized by it before cancel_delayed_work_sync() is
> > called by thermal_zone_device_unregister(), so it may continue to run
> > after the freeing of the thermal zone object, which also leads to a
> > use-after-free.
> >
> > Address the first failing scenario by ensuring that no thermal work
> > items will be running when thermal_pm_notify_complete() is called.
> > For this purpose, first move the cancel_delayed_work() call from
> > thermal_zone_pm_complete() to thermal_zone_pm_prepare() to prevent
> > new work from entering the workqueue going forward. Next, switch
> > over to using a dedicated workqueue for thermal events and update
> > the code in thermal_pm_notify() to flush that workqueue after
> > thermal_pm_notify_prepare() has returned which will take care of
> > all leftover thermal work already on the workqueue (that leftover
> > work would do nothing useful anyway because all of the thermal zones
> > have been flagged as suspended).
> >
> > The second failing scenario is addressed by adding a tz->state check
> > to thermal_zone_device_resume() to prevent it from re-initializing
> > the poll_queue delayed work if the thermal zone is going away.
> >
> > Note that the above changes will also facilitate relocating the suspend
> > and resume of thermal zones closer to the suspend and resume of devices,
> > respectively.
> >
> > Fixes: 5a5efdaffda5 ("thermal: core: Resume thermal zones asynchronously")
> > Reported-by: Mauricio Faria de Oliveira <mfo@igalia.com>
> > Closes: https://lore.kernel.org/linux-pm/20260324-thermal-core-uaf-init_delayed_work-v1-1-6611ae76a8a1@igalia.com/ [1]
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > ---
>
> I spent some hours reviewing and thinking of corner cases for this
> patch,
> and found the code to correctly handle all cases I thought of.
>
> I also tested it with the synthetic reproducers for the 2 cases reported
> in [1], and it prevented the errors.
>
> Please feel free to add:
>
> Reviewed-by: Mauricio Faria de Oliveira <mfo@igalia.com>
> Tested-by: Mauricio Faria de Oliveira <mfo@igalia.com>
>
> And please carry these from [1], if that's OK with you:
>
> Reported-by: syzbot+3b3852c6031d0f30dfaf@syzkaller.appspotmail.com
> Closes: https://syzbot.org/bug?extid=3b3852c6031d0f30dfaf
I will, thank you!
> >
> > v1 -> v2: Return -ENOMEM from thermal_init() when the workqueue allocation
> > fails (Sashiko)
> >
> > Lukasz, Daniel, I'm quite confident about this patch, but I would appreciate
> > your feedback.
> >
> > ---
> > drivers/thermal/thermal_core.c | 31 ++++++++++++++++++++++++++-----
> > 1 file changed, 26 insertions(+), 5 deletions(-)
> >
> > --- a/drivers/thermal/thermal_core.c
> > +++ b/drivers/thermal/thermal_core.c
> > @@ -42,6 +42,8 @@ static struct thermal_governor *def_gove
> >
> > static bool thermal_pm_suspended;
> >
> > +static struct workqueue_struct *thermal_wq __ro_after_init;
> > +
> > /*
> > * Governor section: set of functions to handle thermal governors
> > *
> > @@ -314,7 +316,7 @@ static void thermal_zone_device_set_poll
> > if (delay > HZ)
> > delay = round_jiffies_relative(delay);
> >
> > - mod_delayed_work(system_freezable_power_efficient_wq, &tz->poll_queue, delay);
> > + mod_delayed_work(thermal_wq, &tz->poll_queue, delay);
> > }
> >
> > static void thermal_zone_recheck(struct thermal_zone_device *tz, int error)
> > @@ -1795,6 +1797,10 @@ static void thermal_zone_device_resume(s
> >
> > guard(thermal_zone)(tz);
> >
> > + /* If the thermal zone is going away, there's nothing to do. */
> > + if (tz->state & TZ_STATE_FLAG_EXIT)
> > + return;
> > +
> > tz->state &= ~(TZ_STATE_FLAG_SUSPENDED | TZ_STATE_FLAG_RESUMING);
> >
> > thermal_debug_tz_resume(tz);
> > @@ -1825,6 +1831,9 @@ static void thermal_zone_pm_prepare(stru
> > }
> >
> > tz->state |= TZ_STATE_FLAG_SUSPENDED;
> > +
> > + /* Prevent new work from getting to the workqueue subsequently. */
> > + cancel_delayed_work(&tz->poll_queue);
> > }
> >
> > static void thermal_pm_notify_prepare(void)
> > @@ -1843,8 +1852,6 @@ static void thermal_zone_pm_complete(str
> > {
> > guard(thermal_zone)(tz);
> >
> > - cancel_delayed_work(&tz->poll_queue);
> > -
> > reinit_completion(&tz->resume);
> > tz->state |= TZ_STATE_FLAG_RESUMING;
> >
> > @@ -1854,7 +1861,7 @@ static void thermal_zone_pm_complete(str
> > */
> > INIT_DELAYED_WORK(&tz->poll_queue, thermal_zone_device_resume);
> > /* Queue up the work without a delay. */
> > - mod_delayed_work(system_freezable_power_efficient_wq, &tz->poll_queue, 0);
> > + mod_delayed_work(thermal_wq, &tz->poll_queue, 0);
> > }
> >
> > static void thermal_pm_notify_complete(void)
> > @@ -1877,6 +1884,11 @@ static int thermal_pm_notify(struct noti
> > 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:
> > @@ -1909,9 +1921,16 @@ static int __init thermal_init(void)
> > if (result)
> > goto error;
> >
> > + thermal_wq = alloc_workqueue("thermal_events",
> > + WQ_FREEZABLE | WQ_POWER_EFFICIENT | WQ_PERCPU, 0);
> > + if (!thermal_wq) {
> > + result = -ENOMEM;
> > + goto unregister_netlink;
> > + }
> > +
> > result = thermal_register_governors();
> > if (result)
> > - goto unregister_netlink;
> > + goto destroy_workqueue;
> >
> > thermal_class = kzalloc_obj(*thermal_class);
> > if (!thermal_class) {
> > @@ -1938,6 +1957,8 @@ static int __init thermal_init(void)
> >
> > unregister_governors:
> > thermal_unregister_governors();
> > +destroy_workqueue:
> > + destroy_workqueue(thermal_wq);
> > unregister_netlink:
> > thermal_netlink_exit();
> > error:
>
> --
> Mauricio
^ permalink raw reply
* Re: [PATCH v2] thermal: core: Address thermal zone removal races with resume
From: Mauricio Faria de Oliveira @ 2026-03-27 14:47 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux PM, Daniel Lezcano, Lukasz Luba, LKML, Kernel Dev
In-Reply-To: <6267615.lOV4Wx5bFT@rafael.j.wysocki>
On 2026-03-27 06:49, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> Since thermal_zone_pm_complete() and thermal_zone_device_resume()
> re-initialize the poll_queue delayed work for the given thermal zone,
> the cancel_delayed_work_sync() in thermal_zone_device_unregister()
> may miss some already running work items and the thermal zone may
> be freed prematurely [1].
>
> There are two failing scenarios that both start with
> running thermal_pm_notify_complete() right before invoking
> thermal_zone_device_unregister() for one of the thermal zones.
>
> In the first scenario, there is a work item already running for
> the given thermal zone when thermal_pm_notify_complete() calls
> thermal_zone_pm_complete() for that thermal zone and it continues to
> run when thermal_zone_device_unregister() starts. Since the poll_queue
> delayed work has been re-initialized by thermal_pm_notify_complete(), the
> running work item will be missed by the cancel_delayed_work_sync() in
> thermal_zone_device_unregister() and if it continues to run past the
> freeing of the thermal zone object, a use-after-free will occur.
>
> In the second scenario, thermal_zone_device_resume() queued up by
> thermal_pm_notify_complete() runs right after the thermal_zone_exit()
> called by thermal_zone_device_unregister() has returned. The poll_queue
> delayed work is re-initialized by it before cancel_delayed_work_sync() is
> called by thermal_zone_device_unregister(), so it may continue to run
> after the freeing of the thermal zone object, which also leads to a
> use-after-free.
>
> Address the first failing scenario by ensuring that no thermal work
> items will be running when thermal_pm_notify_complete() is called.
> For this purpose, first move the cancel_delayed_work() call from
> thermal_zone_pm_complete() to thermal_zone_pm_prepare() to prevent
> new work from entering the workqueue going forward. Next, switch
> over to using a dedicated workqueue for thermal events and update
> the code in thermal_pm_notify() to flush that workqueue after
> thermal_pm_notify_prepare() has returned which will take care of
> all leftover thermal work already on the workqueue (that leftover
> work would do nothing useful anyway because all of the thermal zones
> have been flagged as suspended).
>
> The second failing scenario is addressed by adding a tz->state check
> to thermal_zone_device_resume() to prevent it from re-initializing
> the poll_queue delayed work if the thermal zone is going away.
>
> Note that the above changes will also facilitate relocating the suspend
> and resume of thermal zones closer to the suspend and resume of devices,
> respectively.
>
> Fixes: 5a5efdaffda5 ("thermal: core: Resume thermal zones asynchronously")
> Reported-by: Mauricio Faria de Oliveira <mfo@igalia.com>
> Closes: https://lore.kernel.org/linux-pm/20260324-thermal-core-uaf-init_delayed_work-v1-1-6611ae76a8a1@igalia.com/ [1]
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
I spent some hours reviewing and thinking of corner cases for this
patch,
and found the code to correctly handle all cases I thought of.
I also tested it with the synthetic reproducers for the 2 cases reported
in [1], and it prevented the errors.
Please feel free to add:
Reviewed-by: Mauricio Faria de Oliveira <mfo@igalia.com>
Tested-by: Mauricio Faria de Oliveira <mfo@igalia.com>
And please carry these from [1], if that's OK with you:
Reported-by: syzbot+3b3852c6031d0f30dfaf@syzkaller.appspotmail.com
Closes: https://syzbot.org/bug?extid=3b3852c6031d0f30dfaf
Thanks,
Mauricio
>
> v1 -> v2: Return -ENOMEM from thermal_init() when the workqueue allocation
> fails (Sashiko)
>
> Lukasz, Daniel, I'm quite confident about this patch, but I would appreciate
> your feedback.
>
> ---
> drivers/thermal/thermal_core.c | 31 ++++++++++++++++++++++++++-----
> 1 file changed, 26 insertions(+), 5 deletions(-)
>
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -42,6 +42,8 @@ static struct thermal_governor *def_gove
>
> static bool thermal_pm_suspended;
>
> +static struct workqueue_struct *thermal_wq __ro_after_init;
> +
> /*
> * Governor section: set of functions to handle thermal governors
> *
> @@ -314,7 +316,7 @@ static void thermal_zone_device_set_poll
> if (delay > HZ)
> delay = round_jiffies_relative(delay);
>
> - mod_delayed_work(system_freezable_power_efficient_wq, &tz->poll_queue, delay);
> + mod_delayed_work(thermal_wq, &tz->poll_queue, delay);
> }
>
> static void thermal_zone_recheck(struct thermal_zone_device *tz, int error)
> @@ -1795,6 +1797,10 @@ static void thermal_zone_device_resume(s
>
> guard(thermal_zone)(tz);
>
> + /* If the thermal zone is going away, there's nothing to do. */
> + if (tz->state & TZ_STATE_FLAG_EXIT)
> + return;
> +
> tz->state &= ~(TZ_STATE_FLAG_SUSPENDED | TZ_STATE_FLAG_RESUMING);
>
> thermal_debug_tz_resume(tz);
> @@ -1825,6 +1831,9 @@ static void thermal_zone_pm_prepare(stru
> }
>
> tz->state |= TZ_STATE_FLAG_SUSPENDED;
> +
> + /* Prevent new work from getting to the workqueue subsequently. */
> + cancel_delayed_work(&tz->poll_queue);
> }
>
> static void thermal_pm_notify_prepare(void)
> @@ -1843,8 +1852,6 @@ static void thermal_zone_pm_complete(str
> {
> guard(thermal_zone)(tz);
>
> - cancel_delayed_work(&tz->poll_queue);
> -
> reinit_completion(&tz->resume);
> tz->state |= TZ_STATE_FLAG_RESUMING;
>
> @@ -1854,7 +1861,7 @@ static void thermal_zone_pm_complete(str
> */
> INIT_DELAYED_WORK(&tz->poll_queue, thermal_zone_device_resume);
> /* Queue up the work without a delay. */
> - mod_delayed_work(system_freezable_power_efficient_wq, &tz->poll_queue, 0);
> + mod_delayed_work(thermal_wq, &tz->poll_queue, 0);
> }
>
> static void thermal_pm_notify_complete(void)
> @@ -1877,6 +1884,11 @@ static int thermal_pm_notify(struct noti
> 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:
> @@ -1909,9 +1921,16 @@ static int __init thermal_init(void)
> if (result)
> goto error;
>
> + thermal_wq = alloc_workqueue("thermal_events",
> + WQ_FREEZABLE | WQ_POWER_EFFICIENT | WQ_PERCPU, 0);
> + if (!thermal_wq) {
> + result = -ENOMEM;
> + goto unregister_netlink;
> + }
> +
> result = thermal_register_governors();
> if (result)
> - goto unregister_netlink;
> + goto destroy_workqueue;
>
> thermal_class = kzalloc_obj(*thermal_class);
> if (!thermal_class) {
> @@ -1938,6 +1957,8 @@ static int __init thermal_init(void)
>
> unregister_governors:
> thermal_unregister_governors();
> +destroy_workqueue:
> + destroy_workqueue(thermal_wq);
> unregister_netlink:
> thermal_netlink_exit();
> error:
--
Mauricio
^ permalink raw reply
* Re: [char-misc v3] mei: me: reduce the scope on unexpected reset
From: Rafael J. Wysocki @ 2026-03-27 14:43 UTC (permalink / raw)
To: Alexander Usyskin
Cc: Greg Kroah-Hartman, Menachem Adin, Rafael J . Wysocki, linux-pm,
linux-kernel, Todd Brandt
In-Reply-To: <20260326145720.3937252-1-alexander.usyskin@intel.com>
On Thu, Mar 26, 2026 at 4:14 PM Alexander Usyskin
<alexander.usyskin@intel.com> wrote:
>
> After commit 2cedb296988c ("mei: me: trigger link reset if hw ready is unexpected")
> some devices started to show long resume times (5-7 seconds).
> This happens as mei falsely detects unready hardware,
> starts parallel link reset flow and triggers link reset timeouts
> in the resume callback.
>
> Address it by performing detection of unready hardware only
> when driver is in the ENABLED state instead of blacklisting
> states as done in the original patch.
>
> Reported-by: Todd Brandt <todd.e.brandt@linux.intel.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221023
> Tested-by: Todd Brandt <todd.e.brandt@linux.intel.com>
> Fixes: 2cedb296988c ("mei: me: trigger link reset if hw ready is unexpected")
> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
> ---
>
> V3: reword commit message, add Rafael and PM list
>
> V2: rebase over v7.0-rc4
>
> drivers/misc/mei/hw-me.c | 14 ++++----------
> 1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
> index d4612c659784..1e4a41ac428f 100644
> --- a/drivers/misc/mei/hw-me.c
> +++ b/drivers/misc/mei/hw-me.c
> @@ -1337,19 +1337,13 @@ irqreturn_t mei_me_irq_thread_handler(int irq, void *dev_id)
> /* check if we need to start the dev */
> if (!mei_host_is_ready(dev)) {
> if (mei_hw_is_ready(dev)) {
> - /* synchronized by dev mutex */
I think that the comment above is still valid, isn't it? If so, why remove it?
> - if (waitqueue_active(&dev->wait_hw_ready)) {
> - dev_dbg(&dev->dev, "we need to start the dev.\n");
> - dev->recvd_hw_ready = true;
> - wake_up(&dev->wait_hw_ready);
> - } else if (dev->dev_state != MEI_DEV_UNINITIALIZED &&
> - dev->dev_state != MEI_DEV_POWERING_DOWN &&
> - dev->dev_state != MEI_DEV_POWER_DOWN) {
> + if (dev->dev_state == MEI_DEV_ENABLED) {
> dev_dbg(&dev->dev, "Force link reset.\n");
> schedule_work(&dev->reset_work);
> } else {
Isn't the waitqueue_active() check needed any more?
> - dev_dbg(&dev->dev, "Ignore this interrupt in state = %d\n",
> - dev->dev_state);
> + dev_dbg(&dev->dev, "we need to start the dev.\n");
> + dev->recvd_hw_ready = true;
> + wake_up(&dev->wait_hw_ready);
> }
> } else {
> dev_dbg(&dev->dev, "Spurious Interrupt\n");
> --
^ permalink raw reply
* Re: [PATCH v5 6/6] ARM: tegra: Add SOCTHERM support on Tegra114
From: Thierry Reding @ 2026-03-27 14:38 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Thierry Reding, Mikko Perttunen, Jonathan Hunter, linux-pm,
devicetree, linux-tegra, linux-kernel
In-Reply-To: <20250828055104.8073-7-clamor95@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 417 bytes --]
On Thu, Aug 28, 2025 at 08:51:04AM +0300, Svyatoslav Ryhel wrote:
> Add SOCTHERM and thermal zones nodes into common Tegra 4 device tree.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
> ---
> arch/arm/boot/dts/nvidia/tegra114.dtsi | 197 +++++++++++++++++++++++++
> 1 file changed, 197 insertions(+)
Applied, finally.
Thanks,
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Lorenzo Pieralisi @ 2026-03-27 14:14 UTC (permalink / raw)
To: Shivendra Pratap
Cc: 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,
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
In-Reply-To: <20260304-arm-psci-system_reset2-vendor-reboots-v20-6-cf7d346b8372@oss.qualcomm.com>
On Wed, Mar 04, 2026 at 11:33:06PM +0530, Shivendra Pratap wrote:
> PSCI supports different types of resets like COLD reset, ARCH WARM
> reset, vendor-specific resets. Currently there is no common driver that
> handles all supported psci resets at one place. Additionally, there is
> no common mechanism to issue the supported psci resets from userspace.
>
> Add a PSCI reboot mode driver and define two types of PSCI resets in the
> driver as reboot-modes: predefined resets controlled by Linux
> reboot_mode and customizable resets defined by SoC vendors in their
> device tree under the psci:reboot-mode node.
>
> Register the driver with the reboot-mode framework to interface these
> resets to userspace. When userspace initiates a supported command, pass
> the reset arguments to the PSCI driver to enable command-based reset.
>
> This change allows userspace to issue supported PSCI reset commands
> using the standard reboot system calls while enabling SoC vendors to
> define their specific resets for PSCI.
>
> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
> ---
> drivers/power/reset/Kconfig | 10 +++
> drivers/power/reset/Makefile | 1 +
> drivers/power/reset/psci-reboot-mode.c | 119 +++++++++++++++++++++++++++++++++
Add an entry into MAINTAINERS.POWER STATE COORDINATION INTERFACE for this
specific file because I'd like to keep an eye on it, if you don't mind.
Creating a MAINTAINER entry just for this seems overkill to me, it
does not look like it is done for other reboot mode drivers.
Thanks,
Lorenzo
> 3 files changed, 130 insertions(+)
>
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index f6c1bcbb57deff3568d6b1b326454add3b3bbf06..529d6c7d3555601f7b7e6199acd29838030fcef2 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -348,6 +348,16 @@ config NVMEM_REBOOT_MODE
> then the bootloader can read it and take different
> action according to the mode.
>
> +config PSCI_REBOOT_MODE
> + bool "PSCI reboot mode driver"
> + depends on OF && ARM_PSCI_FW
> + select REBOOT_MODE
> + help
> + Say y here will enable PSCI reboot mode driver. This gets
> + the PSCI reboot mode arguments and passes them to psci
> + driver. psci driver uses these arguments for issuing
> + device reset into different boot states.
> +
> config POWER_MLXBF
> tristate "Mellanox BlueField power handling driver"
> depends on (GPIO_MLXBF2 || GPIO_MLXBF3) && ACPI
> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> index 0e4ae6f6b5c55729cf60846d47e6fe0fec24f3cc..49774b42cdf61fd57a5b70f286c65c9d66bbc0cb 100644
> --- a/drivers/power/reset/Makefile
> +++ b/drivers/power/reset/Makefile
> @@ -40,4 +40,5 @@ obj-$(CONFIG_REBOOT_MODE) += reboot-mode.o
> obj-$(CONFIG_SYSCON_REBOOT_MODE) += syscon-reboot-mode.o
> obj-$(CONFIG_POWER_RESET_SC27XX) += sc27xx-poweroff.o
> obj-$(CONFIG_NVMEM_REBOOT_MODE) += nvmem-reboot-mode.o
> +obj-$(CONFIG_PSCI_REBOOT_MODE) += psci-reboot-mode.o
> obj-$(CONFIG_POWER_MLXBF) += pwr-mlxbf.o
> diff --git a/drivers/power/reset/psci-reboot-mode.c b/drivers/power/reset/psci-reboot-mode.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..86bef195228b0924704c2936b99f6801c14ff1b1
> --- /dev/null
> +++ b/drivers/power/reset/psci-reboot-mode.c
> @@ -0,0 +1,119 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/device/faux.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/of.h>
> +#include <linux/psci.h>
> +#include <linux/reboot.h>
> +#include <linux/reboot-mode.h>
> +#include <linux/types.h>
> +
> +/*
> + * Predefined reboot-modes are defined as per the values
> + * of enum reboot_mode defined in the kernel: reboot.c.
> + */
> +static struct mode_info psci_resets[] = {
> + { .mode = "warm", .magic = REBOOT_WARM},
> + { .mode = "soft", .magic = REBOOT_SOFT},
> + { .mode = "cold", .magic = REBOOT_COLD},
> +};
> +
> +static void psci_reboot_mode_set_predefined_modes(struct reboot_mode_driver *reboot)
> +{
> + INIT_LIST_HEAD(&reboot->predefined_modes);
> + for (u32 i = 0; i < ARRAY_SIZE(psci_resets); i++) {
> + /* Prepare the magic with arg1 as 0 and arg2 as per pre-defined mode */
> + psci_resets[i].magic = REBOOT_MODE_MAGIC(0, psci_resets[i].magic);
> + INIT_LIST_HEAD(&psci_resets[i].list);
> + list_add_tail(&psci_resets[i].list, &reboot->predefined_modes);
> + }
> +}
> +
> +/*
> + * arg1 is reset_type(Low 32 bit of magic).
> + * arg2 is cookie(High 32 bit of magic).
> + * If reset_type is 0, cookie will be used to decide the reset command.
> + */
> +static int psci_reboot_mode_write(struct reboot_mode_driver *reboot, u64 magic)
> +{
> + u32 reset_type = REBOOT_MODE_ARG1(magic);
> + u32 cookie = REBOOT_MODE_ARG2(magic);
> +
> + if (reset_type == 0) {
> + if (cookie == REBOOT_WARM || cookie == REBOOT_SOFT)
> + psci_set_reset_cmd(true, 0, 0);
> + else
> + psci_set_reset_cmd(false, 0, 0);
> + } else {
> + psci_set_reset_cmd(true, reset_type, cookie);
> + }
> +
> + return NOTIFY_DONE;
> +}
> +
> +static int psci_reboot_mode_register_device(struct faux_device *fdev)
> +{
> + struct reboot_mode_driver *reboot;
> + int ret;
> +
> + reboot = devm_kzalloc(&fdev->dev, sizeof(*reboot), GFP_KERNEL);
> + if (!reboot)
> + return -ENOMEM;
> +
> + psci_reboot_mode_set_predefined_modes(reboot);
> + reboot->write = psci_reboot_mode_write;
> + reboot->dev = &fdev->dev;
> +
> + ret = devm_reboot_mode_register(&fdev->dev, reboot);
> + if (ret) {
> + dev_err_probe(&fdev->dev, ret, "devm_reboot_mode_register failed %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int __init psci_reboot_mode_init(void)
> +{
> + struct device_node *psci_np;
> + struct faux_device *fdev;
> + struct device_node *np;
> + int ret;
> +
> + psci_np = of_find_compatible_node(NULL, NULL, "arm,psci-1.0");
> + if (!psci_np)
> + return -ENODEV;
> + /*
> + * Look for reboot-mode in the psci node. Even if the reboot-mode
> + * node is not defined in psci, continue to register with the
> + * reboot-mode driver and let the dev.ofnode be set as NULL.
> + */
> + np = of_find_node_by_name(psci_np, "reboot-mode");
> +
> + fdev = faux_device_create("psci-reboot-mode", NULL, NULL);
> + if (!fdev) {
> + ret = -ENODEV;
> + goto error;
> + }
> +
> + device_set_node(&fdev->dev, of_fwnode_handle(np));
> + ret = psci_reboot_mode_register_device(fdev);
> + if (ret)
> + goto error;
> +
> + return 0;
> +
> +error:
> + of_node_put(np);
> + if (fdev) {
> + device_set_node(&fdev->dev, NULL);
> + faux_device_destroy(fdev);
> + }
> +
> + return ret;
> +}
> +device_initcall(psci_reboot_mode_init);
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Bartosz Golaszewski @ 2026-03-27 14:09 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Shivendra Pratap, 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, 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, Sudeep Holla
In-Reply-To: <acaPSW6VeYceoMnO@lpieralisi>
On Fri, Mar 27, 2026 at 3:08 PM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
>
> On Fri, Mar 06, 2026 at 02:32:46PM +0100, Bartosz Golaszewski wrote:
> > On Thu, Mar 5, 2026 at 6:07 PM Shivendra Pratap
> > <shivendra.pratap@oss.qualcomm.com> wrote:
> > >
> > > >
> > > > You should pass the address of this function in faux_device_ops instead of
> > > > calling it directly.
> > >
> > > In last patch, we were using a probe function. As faux_device_create,
> > > calls the probe from its internal operations, "of_node" can only be
> > > assigned from inside of faux device probe.
> > >
> > > As our primary requirement is to assign reboot-mode of_node to the faux
> > > device, thought to make it this way. (As we did not want to assign it
> > > inside the faux device probe).
> > >
> >
> > TBH This sounds like a limitation of the faux device API. I'll Cc you
> > on a patch proposing to extend it with the ability of using a firmware
> > node to describe the device. If it works for you, you can integrate it
> > into your series and use it.
>
> What's the status on this matter ?
>
I looked around and didn't find any good reason for adding this after
all so I dropped it.
Bart
^ permalink raw reply
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Lorenzo Pieralisi @ 2026-03-27 14:08 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Shivendra Pratap, 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, 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, Sudeep Holla
In-Reply-To: <CAMRc=McUdboG0ziWmUf+h9mUiuGesaFk2v27z_Opbw-AF33C0g@mail.gmail.com>
On Fri, Mar 06, 2026 at 02:32:46PM +0100, Bartosz Golaszewski wrote:
> On Thu, Mar 5, 2026 at 6:07 PM Shivendra Pratap
> <shivendra.pratap@oss.qualcomm.com> wrote:
> >
> > >
> > > You should pass the address of this function in faux_device_ops instead of
> > > calling it directly.
> >
> > In last patch, we were using a probe function. As faux_device_create,
> > calls the probe from its internal operations, "of_node" can only be
> > assigned from inside of faux device probe.
> >
> > As our primary requirement is to assign reboot-mode of_node to the faux
> > device, thought to make it this way. (As we did not want to assign it
> > inside the faux device probe).
> >
>
> TBH This sounds like a limitation of the faux device API. I'll Cc you
> on a patch proposing to extend it with the ability of using a firmware
> node to describe the device. If it works for you, you can integrate it
> into your series and use it.
What's the status on this matter ?
Thanks,
Lorenzo
^ permalink raw reply
* Re: [PATCH v20 04/10] firmware: psci: Introduce command-based reset in psci_sys_reset
From: Lorenzo Pieralisi @ 2026-03-27 14:07 UTC (permalink / raw)
To: Shivendra Pratap
Cc: 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,
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
In-Reply-To: <20260304-arm-psci-system_reset2-vendor-reboots-v20-4-cf7d346b8372@oss.qualcomm.com>
On Wed, Mar 04, 2026 at 11:33:04PM +0530, Shivendra Pratap wrote:
> PSCI currently supports only COLD reset and ARCH WARM reset based on the
> Linux reboot_mode variable. The PSCI specification now includes
> SYSTEM_RESET2 for vendor-specific resets, but there's no mechanism to
> issue these through psci_sys_reset.
>
> Add a command-based reset mechanism that allows external drivers to set
> the psci reset command via a new psci_set_reset_cmd() function.
>
> The psci command-based reset is disabled by default and the
> psci_sys_reset follows its original flow until a psci_reset command is
> set. In kernel panic path, psci_reset command is ignored.
If it is function calls you should add parenthesis (eg psci_sys_reset ->
psci_sys_reset()).
You must explain why the kernel panic path requires separate handling
here AND in the code - think about looking at this years down the line
and figure out why kernel panics are special here.
> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
> ---
> drivers/firmware/psci/psci.c | 45 ++++++++++++++++++++++++++++++++++++++++++--
> include/linux/psci.h | 2 ++
> 2 files changed, 45 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index 38ca190d4a22d6e7e0f06420e8478a2b0ec2fe6f..ae6f7a0aead913d740070080d4b2a3da15b29485 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -51,6 +51,15 @@ static int resident_cpu = -1;
> struct psci_operations psci_ops;
> static enum arm_smccc_conduit psci_conduit = SMCCC_CONDUIT_NONE;
>
> +struct psci_sys_reset_params {
> + u32 system_reset;
> + u32 reset_type;
> + u32 cookie;
> + bool cmd;
> +};
> +
> +static struct psci_sys_reset_params psci_reset;
> +
> bool psci_tos_resident_on(int cpu)
> {
> return cpu == resident_cpu;
> @@ -80,6 +89,28 @@ static u32 psci_cpu_suspend_feature;
> static bool psci_system_reset2_supported;
> static bool psci_system_off2_hibernate_supported;
>
> +/**
> + * psci_set_reset_cmd - Sets the psci_reset_cmd for command-based
> + * reset which will be used in psci_sys_reset call.
> + *
> + * @cmd_sys_rst2: Set to true for SYSTEM_RESET2 based resets.
> + * @cmd_reset_type: Set the reset_type argument for psci_sys_reset.
> + * @cmd_cookie: Set the cookie argument for psci_sys_reset.
> + */
> +void psci_set_reset_cmd(bool cmd_sys_rst2, u32 cmd_reset_type, u32 cmd_cookie)
> +{
I don't think cmd_sys_rst2 is needed, as a replied in a different thread.
> + if (cmd_sys_rst2 && psci_system_reset2_supported) {
> + psci_reset.system_reset = PSCI_FN_NATIVE(1_1, SYSTEM_RESET2);
> + psci_reset.reset_type = cmd_reset_type;
> + psci_reset.cookie = cmd_cookie;
> + } else {
> + psci_reset.system_reset = PSCI_0_2_FN_SYSTEM_RESET;
> + psci_reset.reset_type = 0;
> + psci_reset.cookie = 0;
> + }
> + psci_reset.cmd = true;
> +}
> +
> static inline bool psci_has_ext_power_state(void)
> {
> return psci_cpu_suspend_feature &
> @@ -309,14 +340,24 @@ static int get_set_conduit_method(const struct device_node *np)
> static int psci_sys_reset(struct notifier_block *nb, unsigned long action,
> void *data)
> {
> - if ((reboot_mode == REBOOT_WARM || reboot_mode == REBOOT_SOFT) &&
> - psci_system_reset2_supported) {
> + if (((reboot_mode == REBOOT_WARM || reboot_mode == REBOOT_SOFT) &&
> + psci_system_reset2_supported) && (panic_in_progress() || !psci_reset.cmd)) {
> /*
> * reset_type[31] = 0 (architectural)
> * reset_type[30:0] = 0 (SYSTEM_WARM_RESET)
> * cookie = 0 (ignored by the implementation)
> */
> invoke_psci_fn(PSCI_FN_NATIVE(1_1, SYSTEM_RESET2), 0, 0, 0);
> + } else if (!panic_in_progress() && psci_reset.cmd) {
> + /*
> + * Commands are being set in psci_set_reset_cmd
> + * This issues, SYSTEM_RESET2 arch warm reset or
> + * SYSTEM_RESET2 vendor-specific reset or
> + * a SYSTEM_RESET cold reset in accordance with
> + * the reboot-mode command.
> + */
> + invoke_psci_fn(psci_reset.system_reset, psci_reset.reset_type,
> + psci_reset.cookie, 0);
> } else {
> invoke_psci_fn(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0);
This is very hard to parse. IMO, what you should do is:
- Split this into two different paths: reboot_mode vs psci_reset.cmd == true.
- Document very clearly why a panic needs separate handling.
Something like:
if (psci_reset.cmd)
handle_reset_cmd();
else
handle_reboot_mode();
I don't think we are far from converging but I want to be able to maintain
this code going forward.
Thanks,
Lorenzo
> }
> diff --git a/include/linux/psci.h b/include/linux/psci.h
> index 4ca0060a3fc42ba1ca751c7862fb4ad8dda35a4c..d13ceca88eab8932894051e7c86e806c2ad8a73a 100644
> --- a/include/linux/psci.h
> +++ b/include/linux/psci.h
> @@ -45,8 +45,10 @@ struct psci_0_1_function_ids get_psci_0_1_function_ids(void);
>
> #if defined(CONFIG_ARM_PSCI_FW)
> int __init psci_dt_init(void);
> +void psci_set_reset_cmd(bool cmd_sys_rst2, u32 cmd_reset_type, u32 cmd_cookie);
> #else
> static inline int psci_dt_init(void) { return 0; }
> +static inline void psci_set_reset_cmd(bool cmd_sys_rst2, u32 cmd_reset_type, u32 cmd_cookie) { }
> #endif
>
> #if defined(CONFIG_ARM_PSCI_FW) && defined(CONFIG_ACPI)
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Bartosz Golaszewski @ 2026-03-27 13:59 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Shivendra Pratap, 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,
Sudeep Holla, 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
In-Reply-To: <acaMPgRALnoUIHMC@lpieralisi>
On Fri, Mar 27, 2026 at 2:55 PM Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
>
> > +
> > +static int __init psci_reboot_mode_init(void)
> > +{
> > + struct device_node *psci_np;
> > + struct faux_device *fdev;
> > + struct device_node *np;
> > + int ret;
> > +
> > + psci_np = of_find_compatible_node(NULL, NULL, "arm,psci-1.0");
> > + if (!psci_np)
> > + return -ENODEV;
> > + /*
> > + * Look for reboot-mode in the psci node. Even if the reboot-mode
> > + * node is not defined in psci, continue to register with the
> > + * reboot-mode driver and let the dev.ofnode be set as NULL.
> > + */
> > + np = of_find_node_by_name(psci_np, "reboot-mode");
> > +
> > + fdev = faux_device_create("psci-reboot-mode", NULL, NULL);
>
> Same comment as Bartosz (have you picked up his work and working towards
> a solution) ?
>
Hi Lorenzo!
Yes, I suggested creating an MFD driver binding to the "arm,psci-1.0"
compatible node which will have two cells: one for the existing
cpuidle-domain functionality and a second for the new reboot-mode
driver. This way we'll simply add a platform device as Greg suggested.
Bart
^ permalink raw reply
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Lorenzo Pieralisi @ 2026-03-27 13:55 UTC (permalink / raw)
To: Shivendra Pratap
Cc: 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,
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
In-Reply-To: <20260304-arm-psci-system_reset2-vendor-reboots-v20-6-cf7d346b8372@oss.qualcomm.com>
On Wed, Mar 04, 2026 at 11:33:06PM +0530, Shivendra Pratap wrote:
> PSCI supports different types of resets like COLD reset, ARCH WARM
> reset, vendor-specific resets. Currently there is no common driver that
> handles all supported psci resets at one place. Additionally, there is
> no common mechanism to issue the supported psci resets from userspace.
>
> Add a PSCI reboot mode driver and define two types of PSCI resets in the
> driver as reboot-modes: predefined resets controlled by Linux
> reboot_mode and customizable resets defined by SoC vendors in their
> device tree under the psci:reboot-mode node.
>
> Register the driver with the reboot-mode framework to interface these
> resets to userspace. When userspace initiates a supported command, pass
> the reset arguments to the PSCI driver to enable command-based reset.
>
> This change allows userspace to issue supported PSCI reset commands
> using the standard reboot system calls while enabling SoC vendors to
> define their specific resets for PSCI.
>
> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
> ---
> drivers/power/reset/Kconfig | 10 +++
> drivers/power/reset/Makefile | 1 +
> drivers/power/reset/psci-reboot-mode.c | 119 +++++++++++++++++++++++++++++++++
> 3 files changed, 130 insertions(+)
>
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index f6c1bcbb57deff3568d6b1b326454add3b3bbf06..529d6c7d3555601f7b7e6199acd29838030fcef2 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -348,6 +348,16 @@ config NVMEM_REBOOT_MODE
> then the bootloader can read it and take different
> action according to the mode.
>
> +config PSCI_REBOOT_MODE
> + bool "PSCI reboot mode driver"
> + depends on OF && ARM_PSCI_FW
> + select REBOOT_MODE
> + help
> + Say y here will enable PSCI reboot mode driver. This gets
> + the PSCI reboot mode arguments and passes them to psci
> + driver. psci driver uses these arguments for issuing
> + device reset into different boot states.
> +
> config POWER_MLXBF
> tristate "Mellanox BlueField power handling driver"
> depends on (GPIO_MLXBF2 || GPIO_MLXBF3) && ACPI
> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> index 0e4ae6f6b5c55729cf60846d47e6fe0fec24f3cc..49774b42cdf61fd57a5b70f286c65c9d66bbc0cb 100644
> --- a/drivers/power/reset/Makefile
> +++ b/drivers/power/reset/Makefile
> @@ -40,4 +40,5 @@ obj-$(CONFIG_REBOOT_MODE) += reboot-mode.o
> obj-$(CONFIG_SYSCON_REBOOT_MODE) += syscon-reboot-mode.o
> obj-$(CONFIG_POWER_RESET_SC27XX) += sc27xx-poweroff.o
> obj-$(CONFIG_NVMEM_REBOOT_MODE) += nvmem-reboot-mode.o
> +obj-$(CONFIG_PSCI_REBOOT_MODE) += psci-reboot-mode.o
> obj-$(CONFIG_POWER_MLXBF) += pwr-mlxbf.o
> diff --git a/drivers/power/reset/psci-reboot-mode.c b/drivers/power/reset/psci-reboot-mode.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..86bef195228b0924704c2936b99f6801c14ff1b1
> --- /dev/null
> +++ b/drivers/power/reset/psci-reboot-mode.c
> @@ -0,0 +1,119 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/device/faux.h>
> +#include <linux/device.h>
Nit: swap the two.
> +#include <linux/err.h>
> +#include <linux/of.h>
> +#include <linux/psci.h>
> +#include <linux/reboot.h>
> +#include <linux/reboot-mode.h>
> +#include <linux/types.h>
> +
> +/*
> + * Predefined reboot-modes are defined as per the values
> + * of enum reboot_mode defined in the kernel: reboot.c.
> + */
> +static struct mode_info psci_resets[] = {
> + { .mode = "warm", .magic = REBOOT_WARM},
> + { .mode = "soft", .magic = REBOOT_SOFT},
> + { .mode = "cold", .magic = REBOOT_COLD},
> +};
> +
> +static void psci_reboot_mode_set_predefined_modes(struct reboot_mode_driver *reboot)
> +{
> + INIT_LIST_HEAD(&reboot->predefined_modes);
> + for (u32 i = 0; i < ARRAY_SIZE(psci_resets); i++) {
> + /* Prepare the magic with arg1 as 0 and arg2 as per pre-defined mode */
> + psci_resets[i].magic = REBOOT_MODE_MAGIC(0, psci_resets[i].magic);
This looks weird to me, why can't we just initialize the array with the values
directly ?
> + INIT_LIST_HEAD(&psci_resets[i].list);
> + list_add_tail(&psci_resets[i].list, &reboot->predefined_modes);
> + }
> +}
> +
> +/*
> + * arg1 is reset_type(Low 32 bit of magic).
> + * arg2 is cookie(High 32 bit of magic).
> + * If reset_type is 0, cookie will be used to decide the reset command.
> + */
> +static int psci_reboot_mode_write(struct reboot_mode_driver *reboot, u64 magic)
> +{
> + u32 reset_type = REBOOT_MODE_ARG1(magic);
> + u32 cookie = REBOOT_MODE_ARG2(magic);
> +
> + if (reset_type == 0) {
> + if (cookie == REBOOT_WARM || cookie == REBOOT_SOFT)
> + psci_set_reset_cmd(true, 0, 0);
> + else
> + psci_set_reset_cmd(false, 0, 0);
> + } else {
> + psci_set_reset_cmd(true, reset_type, cookie);
> + }
I don't think that psci_set_reset_cmd() has the right interface (and this
nested if is too complicated for my taste). All we need to pass is reset-type
and cookie (and if the reset is one of the predefined ones, reset-type is 0
and cookie is the REBOOT_* cookie).
Then the PSCI firmware driver will take the action according to what
resets are available.
How does it sound ?
> +
> + return NOTIFY_DONE;
> +}
> +
> +static int psci_reboot_mode_register_device(struct faux_device *fdev)
> +{
> + struct reboot_mode_driver *reboot;
> + int ret;
> +
> + reboot = devm_kzalloc(&fdev->dev, sizeof(*reboot), GFP_KERNEL);
> + if (!reboot)
> + return -ENOMEM;
> +
> + psci_reboot_mode_set_predefined_modes(reboot);
> + reboot->write = psci_reboot_mode_write;
> + reboot->dev = &fdev->dev;
> +
> + ret = devm_reboot_mode_register(&fdev->dev, reboot);
> + if (ret) {
> + dev_err_probe(&fdev->dev, ret, "devm_reboot_mode_register failed %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int __init psci_reboot_mode_init(void)
> +{
> + struct device_node *psci_np;
> + struct faux_device *fdev;
> + struct device_node *np;
> + int ret;
> +
> + psci_np = of_find_compatible_node(NULL, NULL, "arm,psci-1.0");
> + if (!psci_np)
> + return -ENODEV;
> + /*
> + * Look for reboot-mode in the psci node. Even if the reboot-mode
> + * node is not defined in psci, continue to register with the
> + * reboot-mode driver and let the dev.ofnode be set as NULL.
> + */
> + np = of_find_node_by_name(psci_np, "reboot-mode");
> +
> + fdev = faux_device_create("psci-reboot-mode", NULL, NULL);
Same comment as Bartosz (have you picked up his work and working towards
a solution) ?
Thanks,
Lorenzo
> + if (!fdev) {
> + ret = -ENODEV;
> + goto error;
> + }
> +
> + device_set_node(&fdev->dev, of_fwnode_handle(np));
> + ret = psci_reboot_mode_register_device(fdev);
> + if (ret)
> + goto error;
> +
> + return 0;
> +
> +error:
> + of_node_put(np);
> + if (fdev) {
> + device_set_node(&fdev->dev, NULL);
> + faux_device_destroy(fdev);
> + }
> +
> + return ret;
> +}
> +device_initcall(psci_reboot_mode_init);
>
> --
> 2.34.1
>
^ permalink raw reply
* [amd-pstate:bleeding-edge] BUILD SUCCESS 9e6a50933c63fc15b2b86eba101eed2e0864b6c5
From: kernel test robot @ 2026-03-27 12:05 UTC (permalink / raw)
To: Mario Limonciello (AMD); +Cc: linux-pm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/superm1/linux.git bleeding-edge
branch HEAD: 9e6a50933c63fc15b2b86eba101eed2e0864b6c5 Documentation/amd-pstate: Add documentation for amd_pstate_floor_{freq,count}
elapsed time: 966m
configs tested: 178
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 allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260327 gcc-8.5.0
arc randconfig-002-20260327 gcc-8.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm randconfig-001-20260327 gcc-8.5.0
arm randconfig-002-20260327 gcc-8.5.0
arm randconfig-003-20260327 gcc-8.5.0
arm randconfig-004-20260327 gcc-8.5.0
arm tegra_defconfig gcc-15.2.0
arm64 allmodconfig clang-19
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260327 clang-23
arm64 randconfig-002-20260327 clang-23
arm64 randconfig-003-20260327 clang-23
arm64 randconfig-004-20260327 clang-23
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260327 clang-23
csky randconfig-002-20260327 clang-23
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260327 gcc-8.5.0
hexagon randconfig-002-20260327 gcc-8.5.0
i386 allmodconfig clang-20
i386 allmodconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260327 clang-20
i386 buildonly-randconfig-002-20260327 clang-20
i386 buildonly-randconfig-003-20260327 clang-20
i386 buildonly-randconfig-004-20260327 clang-20
i386 buildonly-randconfig-005-20260327 clang-20
i386 buildonly-randconfig-006-20260327 clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260327 clang-20
i386 randconfig-002-20260327 clang-20
i386 randconfig-003-20260327 clang-20
i386 randconfig-004-20260327 clang-20
i386 randconfig-005-20260327 clang-20
i386 randconfig-006-20260327 clang-20
i386 randconfig-007-20260327 clang-20
i386 randconfig-011-20260327 gcc-14
i386 randconfig-012-20260327 gcc-14
i386 randconfig-013-20260327 gcc-14
i386 randconfig-014-20260327 gcc-14
i386 randconfig-015-20260327 gcc-14
i386 randconfig-016-20260327 gcc-14
i386 randconfig-017-20260327 gcc-14
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260327 gcc-8.5.0
loongarch randconfig-002-20260327 gcc-8.5.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
mips pic32mzda_defconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260327 gcc-8.5.0
nios2 randconfig-002-20260327 gcc-8.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 allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260327 clang-18
parisc randconfig-002-20260327 clang-18
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc randconfig-001-20260327 clang-18
powerpc randconfig-002-20260327 clang-18
powerpc64 randconfig-001-20260327 clang-18
powerpc64 randconfig-002-20260327 clang-18
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260327 gcc-12.5.0
riscv randconfig-002-20260327 gcc-12.5.0
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260327 gcc-12.5.0
s390 randconfig-002-20260327 gcc-12.5.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh randconfig-001-20260327 gcc-12.5.0
sh randconfig-002-20260327 gcc-12.5.0
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260327 gcc-14
sparc randconfig-002-20260327 gcc-14
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260327 gcc-14
sparc64 randconfig-002-20260327 gcc-14
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-20260327 gcc-14
um randconfig-002-20260327 gcc-14
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-20260327 clang-20
x86_64 buildonly-randconfig-002-20260327 clang-20
x86_64 buildonly-randconfig-003-20260327 clang-20
x86_64 buildonly-randconfig-004-20260327 clang-20
x86_64 buildonly-randconfig-005-20260327 clang-20
x86_64 buildonly-randconfig-006-20260327 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260327 gcc-14
x86_64 randconfig-002-20260327 gcc-14
x86_64 randconfig-003-20260327 gcc-14
x86_64 randconfig-004-20260327 gcc-14
x86_64 randconfig-005-20260327 gcc-14
x86_64 randconfig-006-20260327 gcc-14
x86_64 randconfig-011-20260327 gcc-14
x86_64 randconfig-012-20260327 gcc-14
x86_64 randconfig-013-20260327 gcc-14
x86_64 randconfig-014-20260327 gcc-14
x86_64 randconfig-015-20260327 gcc-14
x86_64 randconfig-016-20260327 gcc-14
x86_64 randconfig-071-20260327 gcc-13
x86_64 randconfig-072-20260327 gcc-13
x86_64 randconfig-073-20260327 gcc-13
x86_64 randconfig-074-20260327 gcc-13
x86_64 randconfig-075-20260327 gcc-13
x86_64 randconfig-076-20260327 gcc-13
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 nommu_kc705_defconfig gcc-15.2.0
xtensa randconfig-001-20260327 gcc-14
xtensa randconfig-002-20260327 gcc-14
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: power: reset: qcom-pon: Add new compatible PMM8654AU
From: Krzysztof Kozlowski @ 2026-03-27 10:32 UTC (permalink / raw)
To: Rakesh Kota, Rob Herring
Cc: Sebastian Reichel, Krzysztof Kozlowski, Conor Dooley, Vinod Koul,
Bjorn Andersson, Konrad Dybcio, linux-pm, devicetree,
linux-kernel, linux-arm-msm, Dmitry Baryshkov
In-Reply-To: <20260327095341.5radsv6dsbwptnfs@hu-kotarake-hyd.qualcomm.com>
On 27/03/2026 10:53, Rakesh Kota wrote:
> On Mon, Mar 23, 2026 at 01:18:20PM -0500, Rob Herring wrote:
>> On Mon, Mar 23, 2026 at 04:15:15PM +0530, Rakesh Kota wrote:
>>> PMM8654AU is a different PMIC from PMM8650AU, even though both share
>>> the same PMIC subtype. Add PON compatible string for PMM8654AU PMIC
>>> variant.
>>>
>>> The PMM8654AU PON block is compatible with the PMK8350 PON
>>> implementation, but PMM8654AU also implements additional PON registers
>>> beyond the baseline. Use the PMM8654AU naming to match the compatible
>>> string already present in the upstream pinctrl-spmi-gpio driver, keeping
>>> device tree and kernel driver naming consistent.
>>>
>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>> Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
>>> ---
>>> Changes in v4:
>>> - Remove the contain for PMK8350 and new if:then for PMM8654AU as
>>> suggested by Krzysztof Kozlowski
>>>
>>> Changes in v3:
>>> - Update the commit message.
>>>
>>> Changes in v2:
>>> - Introduces PMM8654AU compatible strings as suggested by Konrad Dybcio.
>>> ---
>>> .../devicetree/bindings/power/reset/qcom,pon.yaml | 32 +++++++++++++++++-----
>>> 1 file changed, 25 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
>>> index 979a377cb4ffd577bfa51b9a3cd089acc202de0c..2a5d9182b8d5c1a286716ab175c7bb5e39b334e0 100644
>>> --- a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
>>> +++ b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
>>> @@ -17,12 +17,16 @@ description: |
>>>
>>> properties:
>>> compatible:
>>> - enum:
>>> - - qcom,pm8916-pon
>>> - - qcom,pm8941-pon
>>> - - qcom,pms405-pon
>>> - - qcom,pm8998-pon
>>> - - qcom,pmk8350-pon
>>> + oneOf:
>>> + - enum:
>>> + - qcom,pm8916-pon
>>> + - qcom,pm8941-pon
>>> + - qcom,pms405-pon
>>> + - qcom,pm8998-pon
>>> + - qcom,pmk8350-pon
>>> + - items:
>>> + - const: qcom,pmm8654au-pon
>>> + - const: qcom,pmk8350-pon
>>>
>>> reg:
>>> description: |
>>> @@ -100,7 +104,6 @@ allOf:
>>> - if:
>>> properties:
>>> compatible:
>>> - contains:
>>> const: qcom,pmk8350-pon
>>> then:
>>> properties:
>>> @@ -113,6 +116,21 @@ allOf:
>>> - const: hlos
>>> - const: pbs
>>>
>>> + - if:
>>> + properties:
>>> + compatible:
>>> + const: qcom,pmm8654au-pon
>>> + then:
>>> + properties:
>>> + reg:
>>> + minItems: 1
>>> + maxItems: 2
>>> + reg-names:
>>> + minItems: 1
>>> + items:
>>> + - const: hlos
>>> + - const: pbs
>>
>> I don't understand this. The existing if/then schema did the exact same
>> thing until you removed 'contains'. Now we just have the same schema
>> duplicated.
>>
>> What does need changing now that I've looked at it is dropping 'reg'
>> in this schema as it just repeats what the top-level schema has.
>>
>
> we have got suggestion to add a new if:then block for the new compatible from Krzysztof Kozlowski.
>
But I did not suggest to add the contents in new if:then: block. I
certainly did not suggest to not check this patch before submitting, either.
We had long discussion where I asked you how many address spaces you
have there?
Answer above.
And then answer why the patch says the device has one address space or
two address spaces. You engaged me, Konrad and now Rob in reviewing this
triviality. This is on the verge of wasting of our time.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] thermal: fix error condition for reading st,thermal-flags
From: Daniel Lezcano @ 2026-03-27 10:27 UTC (permalink / raw)
To: Gopi Krishna Menon, rafael, daniel.lezcano, rui.zhang,
lukasz.luba
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, linux-pm,
linux-kernel
In-Reply-To: <20260327090526.59330-1-krishnagopi487@gmail.com>
On 3/27/26 10:05, Gopi Krishna Menon wrote:
> of_property_read_u32 returns 0 on success. The current check returns
> -EINVAL if the property is read successfully.
>
> Fix the check by removing ! from of_property_read_u32
>
> Fixes: b9c7aff481f1 ("drivers/thermal/spear_thermal.c: add Device Tree probing capability")
> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
> Suggested-by: Daniel Baluta <daniel.baluta@nxp.com>
> Signed-off-by: Gopi Krishna Menon <krishnagopi487@gmail.com>
> ---
> Changes since v1:
> - Add Fixes and Reviewed-by tags
Applied, thanks
^ permalink raw reply
* Re: [PATCH RESEND] dt-bindings: thermal: qcom-tsens: Add Eliza SoC TSENS
From: Daniel Lezcano @ 2026-03-27 10:25 UTC (permalink / raw)
To: Krzysztof Kozlowski, Amit Kucheria, Thara Gopinath,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm,
linux-pm, devicetree, linux-kernel
Cc: Konrad Dybcio
In-Reply-To: <20260327100733.365573-2-krzysztof.kozlowski@oss.qualcomm.com>
On 3/27/26 11:07, Krzysztof Kozlowski wrote:
> Document the compatible for Qualcomm Eliza SoC TSENS module, fully
> compatible with TSENS v2 generation (e.g. SM8650).
>
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
Applied, thanks
^ permalink raw reply
* [PATCH RESEND] dt-bindings: thermal: qcom-tsens: Add Eliza SoC TSENS
From: Krzysztof Kozlowski @ 2026-03-27 10:07 UTC (permalink / raw)
To: Amit Kucheria, Thara Gopinath, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-pm, devicetree, linux-kernel
Cc: Krzysztof Kozlowski, Konrad Dybcio
Document the compatible for Qualcomm Eliza SoC TSENS module, fully
compatible with TSENS v2 generation (e.g. SM8650).
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
index 928243cd2883..7d34ba00e684 100644
--- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
+++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
@@ -54,6 +54,7 @@ properties:
- description: v2 of TSENS
items:
- enum:
+ - qcom,eliza-tsens
- qcom,glymur-tsens
- qcom,kaanapali-tsens
- qcom,milos-tsens
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v4 1/2] dt-bindings: power: reset: qcom-pon: Add new compatible PMM8654AU
From: Rakesh Kota @ 2026-03-27 9:53 UTC (permalink / raw)
To: Rob Herring
Cc: Sebastian Reichel, Krzysztof Kozlowski, Conor Dooley, Vinod Koul,
Bjorn Andersson, Konrad Dybcio, linux-pm, devicetree,
linux-kernel, linux-arm-msm, Dmitry Baryshkov, Rakesh Kota
In-Reply-To: <20260323181820.GA888901-robh@kernel.org>
On Mon, Mar 23, 2026 at 01:18:20PM -0500, Rob Herring wrote:
> On Mon, Mar 23, 2026 at 04:15:15PM +0530, Rakesh Kota wrote:
> > PMM8654AU is a different PMIC from PMM8650AU, even though both share
> > the same PMIC subtype. Add PON compatible string for PMM8654AU PMIC
> > variant.
> >
> > The PMM8654AU PON block is compatible with the PMK8350 PON
> > implementation, but PMM8654AU also implements additional PON registers
> > beyond the baseline. Use the PMM8654AU naming to match the compatible
> > string already present in the upstream pinctrl-spmi-gpio driver, keeping
> > device tree and kernel driver naming consistent.
> >
> > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
> > ---
> > Changes in v4:
> > - Remove the contain for PMK8350 and new if:then for PMM8654AU as
> > suggested by Krzysztof Kozlowski
> >
> > Changes in v3:
> > - Update the commit message.
> >
> > Changes in v2:
> > - Introduces PMM8654AU compatible strings as suggested by Konrad Dybcio.
> > ---
> > .../devicetree/bindings/power/reset/qcom,pon.yaml | 32 +++++++++++++++++-----
> > 1 file changed, 25 insertions(+), 7 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
> > index 979a377cb4ffd577bfa51b9a3cd089acc202de0c..2a5d9182b8d5c1a286716ab175c7bb5e39b334e0 100644
> > --- a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
> > +++ b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
> > @@ -17,12 +17,16 @@ description: |
> >
> > properties:
> > compatible:
> > - enum:
> > - - qcom,pm8916-pon
> > - - qcom,pm8941-pon
> > - - qcom,pms405-pon
> > - - qcom,pm8998-pon
> > - - qcom,pmk8350-pon
> > + oneOf:
> > + - enum:
> > + - qcom,pm8916-pon
> > + - qcom,pm8941-pon
> > + - qcom,pms405-pon
> > + - qcom,pm8998-pon
> > + - qcom,pmk8350-pon
> > + - items:
> > + - const: qcom,pmm8654au-pon
> > + - const: qcom,pmk8350-pon
> >
> > reg:
> > description: |
> > @@ -100,7 +104,6 @@ allOf:
> > - if:
> > properties:
> > compatible:
> > - contains:
> > const: qcom,pmk8350-pon
> > then:
> > properties:
> > @@ -113,6 +116,21 @@ allOf:
> > - const: hlos
> > - const: pbs
> >
> > + - if:
> > + properties:
> > + compatible:
> > + const: qcom,pmm8654au-pon
> > + then:
> > + properties:
> > + reg:
> > + minItems: 1
> > + maxItems: 2
> > + reg-names:
> > + minItems: 1
> > + items:
> > + - const: hlos
> > + - const: pbs
>
> I don't understand this. The existing if/then schema did the exact same
> thing until you removed 'contains'. Now we just have the same schema
> duplicated.
>
> What does need changing now that I've looked at it is dropping 'reg'
> in this schema as it just repeats what the top-level schema has.
>
we have got suggestion to add a new if:then block for the new compatible from Krzysztof Kozlowski.
Best regards,
Rakesh kota
> Rob
^ permalink raw reply
* Re: [RFC][RFT][PATCH 0/3] arm64: Enable asympacking for minor CPPC asymmetry
From: Andrea Righi @ 2026-03-27 9:53 UTC (permalink / raw)
To: Christian Loehle
Cc: Vincent Guittot, peterz, dietmar.eggemann, valentin.schneider,
mingo, rostedt, segall, mgorman, catalin.marinas, will,
sudeep.holla, rafael, linux-pm, linux-kernel, juri.lelli, kobak,
fabecassis
In-Reply-To: <3a1ecb19-779a-418a-bc87-033d16905b46@arm.com>
Hi Christian,
On Thu, Mar 26, 2026 at 03:55:54PM +0000, Christian Loehle wrote:
...
> > Right, the issue I'm trying to solve is SD_ASYM_CPUCAPACITY + SMT. Removing
> > SD_ASYM_CPUCAPACITY from the equation fixes my issue, because we fall back
> > into the regular idle CPU selection policy, which avoids allocating both
> > SMT siblings when possible.
> >
> > Thanks,
> > -Andrea
>
> Could you also report how Grace baseline vs ASYM_PACKING works for your
> benchmark? (or Vera nosmt)
>
I've done some tests with Vera nosmt. I don't see much difference with
ASYM_PACKING vs ASYM_CPUCAPACITY (baseline), pretty much in error range (I
see around 1-2% difference across runs, but there's not a clear bias
between the two solutions).
I'll try to find a Grace system and repeat the tests there as well.
Thanks,
-Andrea
^ permalink raw reply
* [PATCH v1] driver core: auxiliary bus: Drop auxiliary_dev_pm_ops
From: Rafael J. Wysocki @ 2026-03-27 9:51 UTC (permalink / raw)
To: Greg Kroah-Hartman, Danilo Krummrich
Cc: LKML, Linux PM, Linux Driver Core Development
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Since the PM core automatically falls back to using the driver PM
callbacks directly if no bus type callbacks are present, it is not
necessary to define a struct dev_pm_ops for a bus type that will only
invoke driver PM callbacks from its PM callbacks.
Accordingly, auxiliary_dev_pm_ops is redundant, so drop it.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/base/auxiliary.c | 6 ------
1 file changed, 6 deletions(-)
--- a/drivers/base/auxiliary.c
+++ b/drivers/base/auxiliary.c
@@ -207,11 +207,6 @@ static int auxiliary_uevent(const struct
(int)(p - name), name);
}
-static const struct dev_pm_ops auxiliary_dev_pm_ops = {
- SET_RUNTIME_PM_OPS(pm_generic_runtime_suspend, pm_generic_runtime_resume, NULL)
- SET_SYSTEM_SLEEP_PM_OPS(pm_generic_suspend, pm_generic_resume)
-};
-
static int auxiliary_bus_probe(struct device *dev)
{
const struct auxiliary_driver *auxdrv = to_auxiliary_drv(dev->driver);
@@ -258,7 +253,6 @@ static const struct bus_type auxiliary_b
.shutdown = auxiliary_bus_shutdown,
.match = auxiliary_match,
.uevent = auxiliary_uevent,
- .pm = &auxiliary_dev_pm_ops,
};
/**
^ permalink raw reply
* [PATCH v2] thermal: core: Address thermal zone removal races with resume
From: Rafael J. Wysocki @ 2026-03-27 9:49 UTC (permalink / raw)
To: Linux PM, Daniel Lezcano, Lukasz Luba; +Cc: Mauricio Faria de Oliveira, LKML
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Since thermal_zone_pm_complete() and thermal_zone_device_resume()
re-initialize the poll_queue delayed work for the given thermal zone,
the cancel_delayed_work_sync() in thermal_zone_device_unregister()
may miss some already running work items and the thermal zone may
be freed prematurely [1].
There are two failing scenarios that both start with
running thermal_pm_notify_complete() right before invoking
thermal_zone_device_unregister() for one of the thermal zones.
In the first scenario, there is a work item already running for
the given thermal zone when thermal_pm_notify_complete() calls
thermal_zone_pm_complete() for that thermal zone and it continues to
run when thermal_zone_device_unregister() starts. Since the poll_queue
delayed work has been re-initialized by thermal_pm_notify_complete(), the
running work item will be missed by the cancel_delayed_work_sync() in
thermal_zone_device_unregister() and if it continues to run past the
freeing of the thermal zone object, a use-after-free will occur.
In the second scenario, thermal_zone_device_resume() queued up by
thermal_pm_notify_complete() runs right after the thermal_zone_exit()
called by thermal_zone_device_unregister() has returned. The poll_queue
delayed work is re-initialized by it before cancel_delayed_work_sync() is
called by thermal_zone_device_unregister(), so it may continue to run
after the freeing of the thermal zone object, which also leads to a
use-after-free.
Address the first failing scenario by ensuring that no thermal work
items will be running when thermal_pm_notify_complete() is called.
For this purpose, first move the cancel_delayed_work() call from
thermal_zone_pm_complete() to thermal_zone_pm_prepare() to prevent
new work from entering the workqueue going forward. Next, switch
over to using a dedicated workqueue for thermal events and update
the code in thermal_pm_notify() to flush that workqueue after
thermal_pm_notify_prepare() has returned which will take care of
all leftover thermal work already on the workqueue (that leftover
work would do nothing useful anyway because all of the thermal zones
have been flagged as suspended).
The second failing scenario is addressed by adding a tz->state check
to thermal_zone_device_resume() to prevent it from re-initializing
the poll_queue delayed work if the thermal zone is going away.
Note that the above changes will also facilitate relocating the suspend
and resume of thermal zones closer to the suspend and resume of devices,
respectively.
Fixes: 5a5efdaffda5 ("thermal: core: Resume thermal zones asynchronously")
Reported-by: Mauricio Faria de Oliveira <mfo@igalia.com>
Closes: https://lore.kernel.org/linux-pm/20260324-thermal-core-uaf-init_delayed_work-v1-1-6611ae76a8a1@igalia.com/ [1]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
v1 -> v2: Return -ENOMEM from thermal_init() when the workqueue allocation
fails (Sashiko)
Lukasz, Daniel, I'm quite confident about this patch, but I would appreciate
your feedback.
---
drivers/thermal/thermal_core.c | 31 ++++++++++++++++++++++++++-----
1 file changed, 26 insertions(+), 5 deletions(-)
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -42,6 +42,8 @@ static struct thermal_governor *def_gove
static bool thermal_pm_suspended;
+static struct workqueue_struct *thermal_wq __ro_after_init;
+
/*
* Governor section: set of functions to handle thermal governors
*
@@ -314,7 +316,7 @@ static void thermal_zone_device_set_poll
if (delay > HZ)
delay = round_jiffies_relative(delay);
- mod_delayed_work(system_freezable_power_efficient_wq, &tz->poll_queue, delay);
+ mod_delayed_work(thermal_wq, &tz->poll_queue, delay);
}
static void thermal_zone_recheck(struct thermal_zone_device *tz, int error)
@@ -1795,6 +1797,10 @@ static void thermal_zone_device_resume(s
guard(thermal_zone)(tz);
+ /* If the thermal zone is going away, there's nothing to do. */
+ if (tz->state & TZ_STATE_FLAG_EXIT)
+ return;
+
tz->state &= ~(TZ_STATE_FLAG_SUSPENDED | TZ_STATE_FLAG_RESUMING);
thermal_debug_tz_resume(tz);
@@ -1825,6 +1831,9 @@ static void thermal_zone_pm_prepare(stru
}
tz->state |= TZ_STATE_FLAG_SUSPENDED;
+
+ /* Prevent new work from getting to the workqueue subsequently. */
+ cancel_delayed_work(&tz->poll_queue);
}
static void thermal_pm_notify_prepare(void)
@@ -1843,8 +1852,6 @@ static void thermal_zone_pm_complete(str
{
guard(thermal_zone)(tz);
- cancel_delayed_work(&tz->poll_queue);
-
reinit_completion(&tz->resume);
tz->state |= TZ_STATE_FLAG_RESUMING;
@@ -1854,7 +1861,7 @@ static void thermal_zone_pm_complete(str
*/
INIT_DELAYED_WORK(&tz->poll_queue, thermal_zone_device_resume);
/* Queue up the work without a delay. */
- mod_delayed_work(system_freezable_power_efficient_wq, &tz->poll_queue, 0);
+ mod_delayed_work(thermal_wq, &tz->poll_queue, 0);
}
static void thermal_pm_notify_complete(void)
@@ -1877,6 +1884,11 @@ static int thermal_pm_notify(struct noti
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:
@@ -1909,9 +1921,16 @@ static int __init thermal_init(void)
if (result)
goto error;
+ thermal_wq = alloc_workqueue("thermal_events",
+ WQ_FREEZABLE | WQ_POWER_EFFICIENT | WQ_PERCPU, 0);
+ if (!thermal_wq) {
+ result = -ENOMEM;
+ goto unregister_netlink;
+ }
+
result = thermal_register_governors();
if (result)
- goto unregister_netlink;
+ goto destroy_workqueue;
thermal_class = kzalloc_obj(*thermal_class);
if (!thermal_class) {
@@ -1938,6 +1957,8 @@ static int __init thermal_init(void)
unregister_governors:
thermal_unregister_governors();
+destroy_workqueue:
+ destroy_workqueue(thermal_wq);
unregister_netlink:
thermal_netlink_exit();
error:
^ permalink raw reply
* Re: [PATCH v2 06/19] cpufreq: Use trace_call__##name() at guarded tracepoint call sites
From: Gautham R. Shenoy @ 2026-03-27 9:10 UTC (permalink / raw)
To: Vineeth Pillai (Google)
Cc: Steven Rostedt, Peter Zijlstra, Huang Rui, Mario Limonciello,
Perry Yuan, Rafael J. Wysocki, Viresh Kumar, Srinivas Pandruvada,
Len Brown, linux-pm, linux-kernel, linux-trace-kernel
In-Reply-To: <20260323160052.17528-7-vineeth@bitbyteword.org>
Hello Vineeth,
On Mon, Mar 23, 2026 at 12:00:25PM -0400, Vineeth Pillai (Google) wrote:
> Replace trace_foo() with the new trace_call__foo() at sites already
> guarded by trace_foo_enabled(), avoiding a redundant
> static_branch_unlikely() re-evaluation inside the tracepoint.
> trace_call__foo() calls the tracepoint callbacks directly without
> utilizing the static branch again.
>
> Suggested-by: Steven Rostedt <rostedt@goodmis.org>
> Suggested-by: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org>
> Assisted-by: Claude:claude-sonnet-4-6
For drivers/cpufreq/amd-pstate.c and drivers/cpufreq/cpufreq.c
Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
--
Thanks and Regards
gautham.
> ---
> drivers/cpufreq/amd-pstate.c | 10 +++++-----
> drivers/cpufreq/cpufreq.c | 2 +-
> drivers/cpufreq/intel_pstate.c | 2 +-
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> index 5aa9fcd80cf51..4c47324aa2f73 100644
> --- a/drivers/cpufreq/amd-pstate.c
> +++ b/drivers/cpufreq/amd-pstate.c
> @@ -247,7 +247,7 @@ static int msr_update_perf(struct cpufreq_policy *policy, u8 min_perf,
> if (trace_amd_pstate_epp_perf_enabled()) {
> union perf_cached perf = READ_ONCE(cpudata->perf);
>
> - trace_amd_pstate_epp_perf(cpudata->cpu,
> + trace_call__amd_pstate_epp_perf(cpudata->cpu,
> perf.highest_perf,
> epp,
> min_perf,
> @@ -298,7 +298,7 @@ static int msr_set_epp(struct cpufreq_policy *policy, u8 epp)
> if (trace_amd_pstate_epp_perf_enabled()) {
> union perf_cached perf = cpudata->perf;
>
> - trace_amd_pstate_epp_perf(cpudata->cpu, perf.highest_perf,
> + trace_call__amd_pstate_epp_perf(cpudata->cpu, perf.highest_perf,
> epp,
> FIELD_GET(AMD_CPPC_MIN_PERF_MASK,
> cpudata->cppc_req_cached),
> @@ -343,7 +343,7 @@ static int shmem_set_epp(struct cpufreq_policy *policy, u8 epp)
> if (trace_amd_pstate_epp_perf_enabled()) {
> union perf_cached perf = cpudata->perf;
>
> - trace_amd_pstate_epp_perf(cpudata->cpu, perf.highest_perf,
> + trace_call__amd_pstate_epp_perf(cpudata->cpu, perf.highest_perf,
> epp,
> FIELD_GET(AMD_CPPC_MIN_PERF_MASK,
> cpudata->cppc_req_cached),
> @@ -507,7 +507,7 @@ static int shmem_update_perf(struct cpufreq_policy *policy, u8 min_perf,
> if (trace_amd_pstate_epp_perf_enabled()) {
> union perf_cached perf = READ_ONCE(cpudata->perf);
>
> - trace_amd_pstate_epp_perf(cpudata->cpu,
> + trace_call__amd_pstate_epp_perf(cpudata->cpu,
> perf.highest_perf,
> epp,
> min_perf,
> @@ -588,7 +588,7 @@ static void amd_pstate_update(struct amd_cpudata *cpudata, u8 min_perf,
> }
>
> if (trace_amd_pstate_perf_enabled() && amd_pstate_sample(cpudata)) {
> - trace_amd_pstate_perf(min_perf, des_perf, max_perf, cpudata->freq,
> + trace_call__amd_pstate_perf(min_perf, des_perf, max_perf, cpudata->freq,
> cpudata->cur.mperf, cpudata->cur.aperf, cpudata->cur.tsc,
> cpudata->cpu, fast_switch);
> }
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 277884d91913c..58901047eae5a 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2222,7 +2222,7 @@ unsigned int cpufreq_driver_fast_switch(struct cpufreq_policy *policy,
>
> if (trace_cpu_frequency_enabled()) {
> for_each_cpu(cpu, policy->cpus)
> - trace_cpu_frequency(freq, cpu);
> + trace_call__cpu_frequency(freq, cpu);
> }
>
> return freq;
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index 11c58af419006..70be952209144 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -3132,7 +3132,7 @@ static void intel_cpufreq_trace(struct cpudata *cpu, unsigned int trace_type, in
> return;
>
> sample = &cpu->sample;
> - trace_pstate_sample(trace_type,
> + trace_call__pstate_sample(trace_type,
> 0,
> old_pstate,
> cpu->pstate.current_pstate,
> --
> 2.53.0
>
^ 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