* Re: [chanwoo:devfreq-next 5/5] drivers/devfreq/devfreq.c:1946:37: error: redefinition of 'devfreq_group'
From: Jori Koolstra @ 2026-04-01 16:54 UTC (permalink / raw)
To: Chanwoo Choi, kernel test robot, gregkh@linuxfoundation.org
Cc: llvm, oe-kbuild-all, linux-pm, Chanwoo Choi
In-Reply-To: <CAGTfZH0bZMGpdKjvgw7S54NF+KeXPtvhsanKmSs1vHDhx7F7Lg@mail.gmail.com>
> Op 21-03-2026 16:11 CET schreef Chanwoo Choi <chanwoo@kernel.org>:
>
>
> HI Jori,
>
> There are build errors in your patches.
> DId you test it? I hope to fix and test the patch before posting.
>
Yes, I have no built issues. Can it be the test bot did not apply the patch
correctly?
Looking at the build error it seems that ATTRIBUTE_GROUPS(devfreq) is duplicated,
not moved.
>
>
> --
> Best Regards,
> Chanwoo Choi
> Samsung Electronics
Thanks,
Jori.
^ permalink raw reply
* Re: [PATCH] PM / wakeup: Allocate class wakeup_class statically
From: Heiner Kallweit @ 2026-04-01 15:45 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Pavel Machek, Len Brown, Greg Kroah-Hartman, Danilo Krummrich,
Linux PM, driver-core
In-Reply-To: <CAJZ5v0iMfiqjkkvOMU6jWEZ+nBvcRtWNwjvBW0pEva1G_owFcg@mail.gmail.com>
On 01.04.2026 16:19, Rafael J. Wysocki wrote:
> On Sun, Mar 29, 2026 at 6:14 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>>
>> Allocating wakeup_class statically avoids a little runtime overhead.
>> Define groups and device release function as part of the class, so that
>> we don't have to repeat this for each class device.
>> Whilst at it, constify wakeup_source_attrs[].
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>
> Can you please have a look at this and let me know what you think:
>
> https://sashiko.dev/#/patchset/0fe1b679-ab28-4505-b0db-14e7ac3ba749%40gmail.com
>
Interesting finding! I think the diagnosis is right.
But: I would say the current behavior isn't a nice solution as well:
wakeup_source_device_create() does: dev->class = wakeup_class;
I think no reader will expect that wakeup_class may be NULL here due to
initcall ordering. In addition this behavior results in such early
wakeup sources not being shown in sysfs.
But I'm not sure whether registering class "wakeup" (and registering
classes in general) would be possible early enough (core_initcall,
or even pure_initcall).
>> ---
>> drivers/base/power/wakeup_stats.c | 18 +++++++++---------
>> 1 file changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/base/power/wakeup_stats.c b/drivers/base/power/wakeup_stats.c
>> index 308f8bde9..72beb8fce 100644
>> --- a/drivers/base/power/wakeup_stats.c
>> +++ b/drivers/base/power/wakeup_stats.c
>> @@ -18,8 +18,6 @@
>>
>> #include "power.h"
>>
>> -static struct class *wakeup_class;
>> -
>> #define wakeup_attr(_name) \
>> static ssize_t _name##_show(struct device *dev, \
>> struct device_attribute *attr, char *buf) \
>> @@ -114,7 +112,7 @@ static ssize_t prevent_suspend_time_ms_show(struct device *dev,
>> }
>> static DEVICE_ATTR_RO(prevent_suspend_time_ms);
>>
>> -static struct attribute *wakeup_source_attrs[] = {
>> +static const struct attribute *const wakeup_source_attrs[] = {
>> &dev_attr_name.attr,
>> &dev_attr_active_count.attr,
>> &dev_attr_event_count.attr,
>> @@ -135,6 +133,12 @@ static void device_create_release(struct device *dev)
>> kfree(dev);
>> }
>>
>> +static const struct class wakeup_class = {
>> + .name = "wakeup",
>> + .dev_release = device_create_release,
>> + .dev_groups = wakeup_source_groups,
>> +};
>> +
>> static struct device *wakeup_source_device_create(struct device *parent,
>> struct wakeup_source *ws)
>> {
>> @@ -149,10 +153,8 @@ static struct device *wakeup_source_device_create(struct device *parent,
>>
>> device_initialize(dev);
>> dev->devt = MKDEV(0, 0);
>> - dev->class = wakeup_class;
>> + dev->class = &wakeup_class;
>> dev->parent = parent;
>> - dev->groups = wakeup_source_groups;
>> - dev->release = device_create_release;
>> dev_set_drvdata(dev, ws);
>> device_set_pm_not_required(dev);
>>
>> @@ -212,8 +214,6 @@ void wakeup_source_sysfs_remove(struct wakeup_source *ws)
>>
>> static int __init wakeup_sources_sysfs_init(void)
>> {
>> - wakeup_class = class_create("wakeup");
>> -
>> - return PTR_ERR_OR_ZERO(wakeup_class);
>> + return class_register(&wakeup_class);
>> }
>> postcore_initcall(wakeup_sources_sysfs_init);
>> --
>> 2.53.0
>>
^ permalink raw reply
* Re: [PATCH v20 01/10] power: reset: reboot-mode: Remove devres based allocations
From: Krzysztof Kozlowski @ 2026-04-01 15:19 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, 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-1-cf7d346b8372@oss.qualcomm.com>
On 04/03/2026 19:03, Shivendra Pratap wrote:
> Devres APIs are intended for use in drivers, where the managed lifetime
> of resources is tied directly to the driver attach/detach cycle. In
> shared subsystem code, there is no guarantee that the subsystem
> functions will only be called after a driver has been attached, nor that
> they will not be referenced after the managed resources have been
> released during driver detach.
>
> To ensure correct lifetime handling, avoid using devres-based
> allocations in the reboot-mode and explicitly handle allocation and
> cleanup of resources.
>
> Fixes: 4fcd504edbf7 ("power: reset: add reboot mode driver")
I don't think this is correct tag.
That commit added code which was a driver, not subsystem level things.
Using devres, as you pointed out, in platform_driver is correct.
Otherwise please specify what bug from that commit is being fixed.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v20 06/10] power: reset: Add psci-reboot-mode driver
From: Arnd Bergmann @ 2026-04-01 14:56 UTC (permalink / raw)
To: Lorenzo Pieralisi, Shivendra Pratap
Cc: 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, André Draszik, Kathiravan Thirumoorthy,
linux-pm, linux-kernel, linux-arm-kernel, linux-arm-msm,
devicetree, Srinivas Kandagatla
In-Reply-To: <ac0trUGsRBLPS+ux@lpieralisi>
On Wed, Apr 1, 2026, at 16:37, Lorenzo Pieralisi wrote:
> On Tue, Mar 31, 2026 at 11:30:09PM +0530, Shivendra Pratap wrote:
>>
>> > > +#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},
>
> These strings match the command userspace issue right ? I think that we
> should make them match the corresponding PSCI reset types, the list above
> maps command to reboot_mode values and those can belong to any reboot
> mode driver to be honest they don't make much sense in a PSCI reboot
> mode driver only.
>
> It is a question for everyone here: would it make sense to make these
> predefined resets a set of strings, eg:
>
> psci-system-reset
> psci-system-reset2-arch-warm-reset
>
> and then vendor resets:
>
> psci-system-reset2-vendor-reset
>
> at least we know what a string maps to ?
>
> We can export a function from the PSCI driver to detect whether PSCI
> SYSTEM_RESET2 is supported, an equivalent of psci_has_osi_support() for
> instance that we can call from this driver to detect its presence.
Sorry I've been out of the loop for this series for a while, but
can someone refresh me on why we got back to mixing in
the 'enum reboot_mode' from legacy i386 and arm32 into the new
interface?
I don't mind having whichever strings are defined for PSCI present
in the user interface, but this seems like a mistake to me.
If at all possible, lets define your own magic constants that
are not tied to "enum reboot_mode" or the legacy reboot= command
line argument.
Arnd
^ permalink raw reply
* [PATCH v2 0/4] thermal: core: Simplifications and suspend/resume relocation
From: Rafael J. Wysocki @ 2026-04-01 14:36 UTC (permalink / raw)
To: Linux PM; +Cc: Daniel Lezcano, LKML, Lukasz Luba, Armin Wolf
Hi All,
This is an update of
https://lore.kernel.org/linux-pm/4745677.LvFx2qVVIh@rafael.j.wysocki/
that reorders the last two patches and modifies them to address Sashiko
review feedback.
This series is intended for 7.1 (it applies on top of linux-next).
It removes a redundant check (patch [1/4]), changes the thermal workqueue
to an unbound and non-freezable one (patch [2/4]), relocates the suspend
and resume of thermal zones closer to the suspend and resume of devices,
respectively (patch [3/4]), and changes the allocation of thermal_class to
static (patch [4/4]).
Thanks!
^ permalink raw reply
* [PATCH v2 1/4] thermal: core: Drop redundant check from thermal_zone_device_update()
From: Rafael J. Wysocki @ 2026-04-01 14:37 UTC (permalink / raw)
To: Linux PM; +Cc: Daniel Lezcano, LKML, Lukasz Luba, Armin Wolf
In-Reply-To: <6277980.lOV4Wx5bFT@rafael.j.wysocki>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Since __thermal_zone_device_update() checks if tz->state is
TZ_STATE_READY and bails out immediately otherwise, it is not
necessary to check the thermal_zone_is_present() return value in
thermal_zone_device_update(). Namely, tz->state is equal to
TZ_STATE_FLAG_INIT initially and that flag is only cleared in
thermal_zone_init_complete() after adding tz to the list of thermal
zones, and thermal_zone_exit() sets TZ_STATE_FLAG_EXIT in tz->state
while removing tz from that list. Thus tz->state is not TZ_STATE_READY
when tz is not in the list and the check mentioned above is redundant.
Accordingly, drop the redundant thermal_zone_is_present() check from
thermal_zone_device_update() and drop the former altogether because it
has no more users.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
v1 -> v2: No changes
---
drivers/thermal/thermal_core.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -702,18 +702,12 @@ int thermal_zone_device_disable(struct t
}
EXPORT_SYMBOL_GPL(thermal_zone_device_disable);
-static bool thermal_zone_is_present(struct thermal_zone_device *tz)
-{
- return !list_empty(&tz->node);
-}
-
void thermal_zone_device_update(struct thermal_zone_device *tz,
enum thermal_notify_event event)
{
guard(thermal_zone)(tz);
- if (thermal_zone_is_present(tz))
- __thermal_zone_device_update(tz, event);
+ __thermal_zone_device_update(tz, event);
}
EXPORT_SYMBOL_GPL(thermal_zone_device_update);
^ permalink raw reply
* [PATCH v2 2/4] thermal: core: Change thermal_wq to be unbound and not freezable
From: Rafael J. Wysocki @ 2026-04-01 14:38 UTC (permalink / raw)
To: Linux PM; +Cc: Daniel Lezcano, LKML, Lukasz Luba, Armin Wolf
In-Reply-To: <6277980.lOV4Wx5bFT@rafael.j.wysocki>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The thermal workqueue doesn't need to be freezable or per-CPU, so drop
WQ_FREEZABLE and WQ_PERCPU from the flags when allocating it.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
v1 -> v2: No changes
---
drivers/thermal/thermal_core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1915,8 +1915,7 @@ static int __init thermal_init(void)
if (result)
goto error;
- thermal_wq = alloc_workqueue("thermal_events",
- WQ_FREEZABLE | WQ_POWER_EFFICIENT | WQ_PERCPU, 0);
+ thermal_wq = alloc_workqueue("thermal_events", WQ_POWER_EFFICIENT, 0);
if (!thermal_wq) {
result = -ENOMEM;
goto unregister_netlink;
^ permalink raw reply
* [PATCH v2 3/4] thermal: core: Allocate thermal_class statically
From: Rafael J. Wysocki @ 2026-04-01 14:45 UTC (permalink / raw)
To: Linux PM; +Cc: Daniel Lezcano, LKML, Lukasz Luba, Armin Wolf
In-Reply-To: <6277980.lOV4Wx5bFT@rafael.j.wysocki>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Define thermal_class as a static structure to simplify thermal_init()
and the thermal class availability checks that will need to be carried
out during the suspend and resume of thermal zones after subsequent
changes.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
v1 -> v2:
* Reorder with respect to the next patch to allow the latter to be simpler
* Add thermal_class_unavailable() (the next patch uses it too)
---
drivers/thermal/thermal_core.c | 34 +++++++++++++++-------------------
1 file changed, 15 insertions(+), 19 deletions(-)
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -977,7 +977,15 @@ static void thermal_release(struct devic
}
}
-static struct class *thermal_class;
+static const struct class thermal_class = {
+ .name = "thermal",
+ .dev_release = thermal_release,
+};
+
+static bool thermal_class_unavailable(void)
+{
+ return !class_is_registered(&thermal_class);
+}
static inline
void print_bind_err_msg(struct thermal_zone_device *tz,
@@ -1070,7 +1078,7 @@ __thermal_cooling_device_register(struct
!ops->set_cur_state)
return ERR_PTR(-EINVAL);
- if (!thermal_class)
+ if (thermal_class_unavailable())
return ERR_PTR(-ENODEV);
cdev = kzalloc_obj(*cdev);
@@ -1094,7 +1102,7 @@ __thermal_cooling_device_register(struct
cdev->np = np;
cdev->ops = ops;
cdev->updated = false;
- cdev->device.class = thermal_class;
+ cdev->device.class = &thermal_class;
cdev->devdata = devdata;
ret = cdev->ops->get_max_state(cdev, &cdev->max_state);
@@ -1542,7 +1550,7 @@ thermal_zone_device_register_with_trips(
if (polling_delay && passive_delay > polling_delay)
return ERR_PTR(-EINVAL);
- if (!thermal_class)
+ if (thermal_class_unavailable())
return ERR_PTR(-ENODEV);
tz = kzalloc_flex(*tz, trips, num_trips);
@@ -1578,7 +1586,7 @@ thermal_zone_device_register_with_trips(
if (!tz->ops.critical)
tz->ops.critical = thermal_zone_device_critical;
- tz->device.class = thermal_class;
+ tz->device.class = &thermal_class;
tz->devdata = devdata;
tz->num_trips = num_trips;
for_each_trip_desc(tz, td) {
@@ -1925,21 +1933,9 @@ static int __init thermal_init(void)
if (result)
goto destroy_workqueue;
- thermal_class = kzalloc_obj(*thermal_class);
- if (!thermal_class) {
- result = -ENOMEM;
- goto unregister_governors;
- }
-
- thermal_class->name = "thermal";
- thermal_class->dev_release = thermal_release;
-
- result = class_register(thermal_class);
- if (result) {
- kfree(thermal_class);
- thermal_class = NULL;
+ result = class_register(&thermal_class);
+ if (result)
goto unregister_governors;
- }
result = register_pm_notifier(&thermal_pm_nb);
if (result)
^ permalink raw reply
* [PATCH v2 4/4] thermal: core: Suspend thermal zones later and resume them earlier
From: Rafael J. Wysocki @ 2026-04-01 14:51 UTC (permalink / raw)
To: Linux PM; +Cc: Daniel Lezcano, LKML, Lukasz Luba, Armin Wolf
In-Reply-To: <6277980.lOV4Wx5bFT@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>
---
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;
@@ -1937,11 +1918,6 @@ static int __init thermal_init(void)
if (result)
goto unregister_governors;
- 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 v20 06/10] power: reset: Add psci-reboot-mode driver
From: Lorenzo Pieralisi @ 2026-04-01 14:37 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: <93a78bc2-4fd1-41bd-bf4a-b433b06fc218@oss.qualcomm.com>
On Tue, Mar 31, 2026 at 11:30:09PM +0530, Shivendra Pratap wrote:
>
>
> On 27-03-2026 19:25, Lorenzo Pieralisi wrote:
> > 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.
>
> Ack. thanks.
>
>
> > > +#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},
These strings match the command userspace issue right ? I think that we
should make them match the corresponding PSCI reset types, the list above
maps command to reboot_mode values and those can belong to any reboot
mode driver to be honest they don't make much sense in a PSCI reboot
mode driver only.
It is a question for everyone here: would it make sense to make these
predefined resets a set of strings, eg:
psci-system-reset
psci-system-reset2-arch-warm-reset
and then vendor resets:
psci-system-reset2-vendor-reset
at least we know what a string maps to ?
We can export a function from the PSCI driver to detect whether PSCI
SYSTEM_RESET2 is supported, an equivalent of psci_has_osi_support() for
instance that we can call from this driver to detect its presence.
> > > +};
> > > +
> > > +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 ?
>
> Ack. The idea was to avoid Typecasting. Will check on this.
>
> > > + 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 ?
>
> So we mean these checks will move to the psci driver? Sorry for re-iterating
> the question.
Given what I say above, I believe that something we can do is mapping the magic
to an enum like:
PSCI_SYSTEM_RESET
PSCI_SYSTEM_RESET2_ARCH_SYSTEM_WARM_RESET
PSCI_SYSTEM_RESET2_VENDOR_RESET
and can add a probe function into PSCI driver similar to psci_has_osi_support() but
to probe for SYSTEM_RESET2 and initialize the predefined strings accordingly,
depending on its presence.
It is getting a bit hairy, agreed, but I am not sure there is cleaner ways
of pulling this off.
Lorenzo
>
> > > +
> > > + 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) ?
> Working on this via MFD. Some issue as again MFD framework does not allows a
> fwnode based driver registration. Will update.
>
> thanks,
> Shivendra
^ permalink raw reply
* [PATCH v1] thermal: core: Fix thermal zone device registration error path
From: Rafael J. Wysocki @ 2026-04-01 14:33 UTC (permalink / raw)
To: Linux PM; +Cc: Daniel Lezcano, LKML, Lukasz Luba
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
If thermal_zone_device_register_with_trips() fails after registering
a thermal zone device, it needs to wait for the tz->removal completion
like thermal_zone_device_unregister(), in case user space has managed
to take a reference to the thermal zone device's kobject, in which case
thermal_release() may not be called by the error path itself and tz may
be freed prematurely.
Add the missing wait_for_completion() call to the thermal zone device
registration error path.
Fixes: 04e6ccfc93c5 ("thermal: core: Fix NULL pointer dereference in zone registration error path")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: All applicable <stable@vger.kernel.org>
---
drivers/thermal/thermal_core.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1651,6 +1651,7 @@ unregister:
device_del(&tz->device);
release_device:
put_device(&tz->device);
+ wait_for_completion(&tz->removal);
remove_id:
ida_free(&thermal_tz_ida, id);
free_tzp:
^ permalink raw reply
* Re: [PATCH v3 1/2] PM: wakeup: Add kfuncs to traverse over wakeup_sources
From: Kumar Kartikeya Dwivedi @ 2026-04-01 14:22 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Samuel Wu, Rafael J. Wysocki, Len Brown, Pavel Machek,
Danilo Krummrich, Andrii Nakryiko, Eduard Zingerman,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, Jiri Olsa, Shuah Khan, kernel-team, linux-kernel,
linux-pm, driver-core, bpf, linux-kselftest
In-Reply-To: <2026040153-overpass-shanty-71a0@gregkh>
On Wed, 1 Apr 2026 at 11:11, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Tue, Mar 31, 2026 at 08:34:10AM -0700, Samuel Wu wrote:
> > Iterating through wakeup sources via sysfs or debugfs can be inefficient
> > or restricted. Introduce BPF kfuncs to allow high-performance and safe
> > in-kernel traversal of the wakeup_sources list.
>
> What exactly is "inefficient"? I think you might have some numbers in
> your 0/2 patch, but putting it in here would be best.
>
> And who is going to be calling these functions, just ebpf scripts?
>
> > The new kfuncs include:
> > - bpf_wakeup_sources_get_head() to obtain the list head.
> > - bpf_wakeup_sources_read_lock/unlock() to manage the SRCU lock.
>
> Does this mean we can stop exporting wakeup_sources_read_lock() now?
>
> > For verifier safety, the underlying SRCU index is wrapped in an opaque
> > 'struct bpf_ws_lock' pointer. This enables the use of KF_ACQUIRE and
> > KF_RELEASE flags, allowing the BPF verifier to strictly enforce paired
> > lock/unlock cycles and prevent resource leaks.
>
> But it's an index, not a lock. Is this just a verifier thing?
It's a verifier thing. The index must be passed to SRCU unlock wrapped
by the unlock kfunc for correctness. The verifier understands such
acquire/release tracking for pointers (e.g., taking refcount and
putting it), but not for scalar values, so we need to launder it
through a pointer to an empty struct, which isn't really usable except
for passing it eventually to unlock. If the program doesn't do the
unlock, the verifier will reject it.
>
> >
> > Signed-off-by: Samuel Wu <wusamuel@google.com>
> > ---
> > drivers/base/power/power.h | 7 ++++
> > drivers/base/power/wakeup.c | 72 +++++++++++++++++++++++++++++++++++--
> > 2 files changed, 77 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/base/power/power.h b/drivers/base/power/power.h
> > index 922ed457db19..8823aceeac8b 100644
> > --- a/drivers/base/power/power.h
> > +++ b/drivers/base/power/power.h
> > @@ -168,3 +168,10 @@ static inline void device_pm_init(struct device *dev)
> > device_pm_sleep_init(dev);
> > pm_runtime_init(dev);
> > }
> > +
> > +#ifdef CONFIG_BPF_SYSCALL
> > +struct bpf_ws_lock { };
>
> An empty structure? This is just an int, so you are casting an int to a
> pointer? Can we make wakeup_sources_read_lock() actually use a
> structure instead to make this simpler?
See above.
>
> > +struct bpf_ws_lock *bpf_wakeup_sources_read_lock(void);
> > +void bpf_wakeup_sources_read_unlock(struct bpf_ws_lock *lock);
> > +void *bpf_wakeup_sources_get_head(void);
> > +#endif
> > diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
> > index b8e48a023bf0..8eda7d35d9cc 100644
> > --- a/drivers/base/power/wakeup.c
> > +++ b/drivers/base/power/wakeup.c
> > @@ -1168,11 +1168,79 @@ static const struct file_operations wakeup_sources_stats_fops = {
> > .release = seq_release_private,
> > };
> >
> > -static int __init wakeup_sources_debugfs_init(void)
> > +#ifdef CONFIG_BPF_SYSCALL
> > +#include <linux/btf.h>
> > +
> > +__bpf_kfunc_start_defs();
> > +
> > +/**
> > + * bpf_wakeup_sources_read_lock - Acquire the SRCU lock for wakeup sources
> > + *
> > + * The underlying SRCU lock returns an integer index. However, the BPF verifier
> > + * requires a pointer (PTR_TO_BTF_ID) to strictly track the state of acquired
> > + * resources using KF_ACQUIRE and KF_RELEASE semantics. We use an opaque
> > + * structure pointer (struct bpf_ws_lock *) to satisfy the verifier while
> > + * safely encoding the integer index within the pointer address itself.
> > + *
> > + * Return: An opaque pointer encoding the SRCU lock index + 1 (to avoid NULL).
> > + */
> > +__bpf_kfunc struct bpf_ws_lock *bpf_wakeup_sources_read_lock(void)
> > +{
> > + return (struct bpf_ws_lock *)(long)(wakeup_sources_read_lock() + 1);
>
> Why are you incrementing this by 1?
I think SRCU indices can be 0, so it would appear as a NULL pointer to
the program.
>
> > +}
> > +
> > +/**
> > + * bpf_wakeup_sources_read_unlock - Release the SRCU lock for wakeup sources
> > + * @lock: The opaque pointer returned by bpf_wakeup_sources_read_lock()
> > + *
> > + * The BPF verifier guarantees that @lock is a valid, unreleased pointer from
> > + * the acquire function. We decode the pointer back into the integer SRCU index
> > + * by subtracting 1 and release the lock.
> > + */
> > +__bpf_kfunc void bpf_wakeup_sources_read_unlock(struct bpf_ws_lock *lock)
> > +{
> > + wakeup_sources_read_unlock((int)(long)lock - 1);
>
> Why decrementing by one?
>
> So it's really an int, but you are casting it to a pointer, incrementing
> it by one to make it a "fake" pointer value (i.e. unaligned mess), and
> then when unlocking casting the pointer back to an int, and then
> decrementing the value?
>
> This feels "odd" :(
It isn't readable, though, because it's an empty struct, so I don't
think it would cause any issues in practice.
>
> [...]
^ permalink raw reply
* Re: [PATCH] PM / wakeup: Allocate class wakeup_class statically
From: Rafael J. Wysocki @ 2026-04-01 14:19 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Rafael J. Wysocki, Pavel Machek, Len Brown, Greg Kroah-Hartman,
Danilo Krummrich, Linux PM, driver-core
In-Reply-To: <0fe1b679-ab28-4505-b0db-14e7ac3ba749@gmail.com>
On Sun, Mar 29, 2026 at 6:14 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>
> Allocating wakeup_class statically avoids a little runtime overhead.
> Define groups and device release function as part of the class, so that
> we don't have to repeat this for each class device.
> Whilst at it, constify wakeup_source_attrs[].
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Can you please have a look at this and let me know what you think:
https://sashiko.dev/#/patchset/0fe1b679-ab28-4505-b0db-14e7ac3ba749%40gmail.com
> ---
> drivers/base/power/wakeup_stats.c | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/base/power/wakeup_stats.c b/drivers/base/power/wakeup_stats.c
> index 308f8bde9..72beb8fce 100644
> --- a/drivers/base/power/wakeup_stats.c
> +++ b/drivers/base/power/wakeup_stats.c
> @@ -18,8 +18,6 @@
>
> #include "power.h"
>
> -static struct class *wakeup_class;
> -
> #define wakeup_attr(_name) \
> static ssize_t _name##_show(struct device *dev, \
> struct device_attribute *attr, char *buf) \
> @@ -114,7 +112,7 @@ static ssize_t prevent_suspend_time_ms_show(struct device *dev,
> }
> static DEVICE_ATTR_RO(prevent_suspend_time_ms);
>
> -static struct attribute *wakeup_source_attrs[] = {
> +static const struct attribute *const wakeup_source_attrs[] = {
> &dev_attr_name.attr,
> &dev_attr_active_count.attr,
> &dev_attr_event_count.attr,
> @@ -135,6 +133,12 @@ static void device_create_release(struct device *dev)
> kfree(dev);
> }
>
> +static const struct class wakeup_class = {
> + .name = "wakeup",
> + .dev_release = device_create_release,
> + .dev_groups = wakeup_source_groups,
> +};
> +
> static struct device *wakeup_source_device_create(struct device *parent,
> struct wakeup_source *ws)
> {
> @@ -149,10 +153,8 @@ static struct device *wakeup_source_device_create(struct device *parent,
>
> device_initialize(dev);
> dev->devt = MKDEV(0, 0);
> - dev->class = wakeup_class;
> + dev->class = &wakeup_class;
> dev->parent = parent;
> - dev->groups = wakeup_source_groups;
> - dev->release = device_create_release;
> dev_set_drvdata(dev, ws);
> device_set_pm_not_required(dev);
>
> @@ -212,8 +214,6 @@ void wakeup_source_sysfs_remove(struct wakeup_source *ws)
>
> static int __init wakeup_sources_sysfs_init(void)
> {
> - wakeup_class = class_create("wakeup");
> -
> - return PTR_ERR_OR_ZERO(wakeup_class);
> + return class_register(&wakeup_class);
> }
> postcore_initcall(wakeup_sources_sysfs_init);
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH] cpufreq: governor: fix double free in cpufreq_dbs_governor_init() error path
From: Rafael J. Wysocki @ 2026-04-01 14:13 UTC (permalink / raw)
To: Viresh Kumar, Guangshuo Li
Cc: Tobin C. Harding, linux-pm, linux-kernel, stable
In-Reply-To: <aziv3yszmqef3amj3wgnutif7eop5slnmf5eqrg6rl7sk5ghf3@7et2qcnti2y2>
On Wed, Apr 1, 2026 at 8:23 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 01-04-26, 10:45, Guangshuo Li wrote:
> > When kobject_init_and_add() fails, cpufreq_dbs_governor_init() calls
> > kobject_put(&dbs_data->attr_set.kobj).
> >
> > The kobject release callback cpufreq_dbs_data_release() calls
> > gov->exit(dbs_data) and kfree(dbs_data), but the current error path
> > then calls gov->exit(dbs_data) and kfree(dbs_data) again, causing a
> > double free.
> >
> > Keep the direct kfree(dbs_data) for the gov->init() failure path, but
> > after kobject_init_and_add() has been called, let kobject_put() handle
> > the cleanup through cpufreq_dbs_data_release().
> >
> > Fixes: 4ebe36c94aed ("cpufreq: Fix kobject memleak")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> > ---
> > drivers/cpufreq/cpufreq_governor.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Applied as 7.0-rc material, thanks!
^ permalink raw reply
* Re: [PATCH v1 0/7] RAPL fixes (for linux-next)
From: Rafael J. Wysocki @ 2026-04-01 14:05 UTC (permalink / raw)
To: Kuppuswamy Sathyanarayanan
Cc: Rafael J . Wysocki, Srinivas Pandruvada, Zhang Rui, linux-pm,
linux-kernel
In-Reply-To: <20260331211950.3329932-1-sathyanarayanan.kuppuswamy@linux.intel.com>
On Tue, Mar 31, 2026 at 11:20 PM Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com> wrote:
>
> Hi Rafael,
>
> This series consolidates and rebases patches from three previously
> submitted cleanup series that were dropped from your linux-next due
> to a circular locking dependency issue:
>
> https://lore.kernel.org/linux-pm/202603300921.b5dc709c-lkp@intel.com/
>
> The three series are:
>
> Move RAPL defaults to interface drivers:
> https://lore.kernel.org/linux-pm/20260212233044.329790-1-sathyanarayanan.kuppuswamy@linux.intel.com/
>
> Move RAPL primitives to interface drivers:
> https://lore.kernel.org/linux-pm/20260313185333.2370733-1-sathyanarayanan.kuppuswamy@linux.intel.com/
>
> Consolidate CPU list in RAPL MSR drivers:
> https://lore.kernel.org/linux-pm/20260313190052.2370963-1-sathyanarayanan.kuppuswamy@linux.intel.com/
>
> The circular locking dependency was introduced by a patch in the first
> series that registered and unregistered the PM notifier dynamically
> from rapl_add_package_cpuslocked() and rapl_remove_package_cpuslocked(),
> which are called from CPU hotplug callbacks leading to circular
> dependency between PM notifier lock and hotplug locks.
>
> That patch has been dropped in this series. The PM notifier
> registration is kept in rapl_init()/rapl_exit() as it was originally,
> and the remaining dependent patches are rebased on top of this.
>
> This series is based on top of:
> https://github.com/rafaeljw/linux-pm/tree/pm-powercap
>
> Kuppuswamy Sathyanarayanan (7):
> powercap: intel_rapl: Move MSR default settings into MSR interface
> driver
> powercap: intel_rapl: Remove unused macro definitions
> powercap: intel_rapl: Move primitive info to header for interface
> drivers
> powercap: intel_rapl: Move TPMI primitives to TPMI driver
> thermal: intel: int340x: processor: Move MMIO primitives to MMIO
> driver
> powercap: intel_rapl: Move MSR primitives to MSR driver
> powercap: intel_rapl: Consolidate PL4 and PMU support flags into
> rapl_defaults
>
> drivers/powercap/intel_rapl_common.c | 421 +-----------------
> drivers/powercap/intel_rapl_msr.c | 392 ++++++++++++++--
> drivers/powercap/intel_rapl_tpmi.c | 53 +++
> .../int340x_thermal/processor_thermal_rapl.c | 72 +++
> include/linux/intel_rapl.h | 34 +-
> 5 files changed, 522 insertions(+), 450 deletions(-)
>
> --
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] cpufreq: cleanup dead code in Kconfig
From: Rafael J. Wysocki @ 2026-04-01 13:59 UTC (permalink / raw)
To: Viresh Kumar, Julian Braha; +Cc: linux-pm, linux-kernel
In-Reply-To: <4qxfqgj7jbjywmkzblf762oamxvb2s6m5b2w3ftq2i72abhmcl@cgtgslih7ric>
On Tue, Mar 31, 2026 at 9:55 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 31-03-26, 08:42, Julian Braha wrote:
> > There is already an 'if CPU_FREQ' condition wrapping these config
> > options, making the 'depends on' statement for each a duplicate
> > dependency (dead code).
> >
> > I propose leaving the outer 'if CPU_FREQ...endif' and
> > removing the individual 'depends on' statement from each option.
> >
> > This dead code was found by kconfirm, a static analysis tool for Kconfig.
> >
> > Signed-off-by: Julian Braha <julianbraha@gmail.com>
> > ---
> > drivers/cpufreq/Kconfig | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
> > index 78702a08364f..db83f3365698 100644
> > --- a/drivers/cpufreq/Kconfig
> > +++ b/drivers/cpufreq/Kconfig
> > @@ -163,7 +163,6 @@ config CPU_FREQ_GOV_ONDEMAND
> >
> > config CPU_FREQ_GOV_CONSERVATIVE
> > tristate "'conservative' cpufreq governor"
> > - depends on CPU_FREQ
> > select CPU_FREQ_GOV_COMMON
> > help
> > 'conservative' - this driver is rather similar to the 'ondemand'
> > @@ -188,7 +187,7 @@ config CPU_FREQ_GOV_CONSERVATIVE
> >
> > config CPU_FREQ_GOV_SCHEDUTIL
> > bool "'schedutil' cpufreq policy governor"
> > - depends on CPU_FREQ && SMP
> > + depends on SMP
> > select CPU_FREQ_GOV_ATTR_SET
> > select IRQ_WORK
> > help
> > @@ -365,6 +364,6 @@ config ACPI_CPPC_CPUFREQ_FIE
> >
> > If in doubt, say N.
> >
> > -endif
> > +endif # CPU_FREQ
> >
> > endmenu
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Applied as 7.1 material, thanks!
^ permalink raw reply
* Re: [PATCH] cpufreq: Allocate QoS freq_req objects with policy
From: Rafael J. Wysocki @ 2026-04-01 13:55 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael J. Wysocki, Pierre Gondois, Lifeng Zheng, linux-pm,
Vincent Guittot, Sumit Semwal, Zhongqiu Han, Rafael J. Wysocki,
linux-kernel
In-Reply-To: <a293f29d841b86c51f34699c6e717e01858d8ada.1774933424.git.viresh.kumar@linaro.org>
On Tue, Mar 31, 2026 at 7:04 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> A recent change exposed a bug in the error path: if
> freq_qos_add_request(boost_freq_req) fails, min_freq_req may remain a
> valid pointer even though it was never successfully added. During policy
> teardown, this leads to an unconditional call to
> freq_qos_remove_request(), triggering a WARN.
>
> The current design allocates all three freq_req objects together, making
> the lifetime rules unclear and error handling fragile.
>
> Simplify this by allocating the QoS freq_req objects at policy
> allocation time. The policy itself is dynamically allocated, and two of
> the three requests are always needed anyway. This ensures consistent
> lifetime management and eliminates the inconsistent state in failure
> paths.
>
> Reported-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
> Fixes: 6e39ba4e5a82 ("cpufreq: Add boost_freq_req QoS request")
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> drivers/cpufreq/cpufreq.c | 53 +++++++++++----------------------------
> include/linux/cpufreq.h | 6 ++---
> 2 files changed, 17 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index c0aa970c7a67..f4a949f1e48f 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -614,7 +614,7 @@ static int policy_set_boost(struct cpufreq_policy *policy, bool enable)
> return ret;
> }
>
> - ret = freq_qos_update_request(policy->boost_freq_req, policy->cpuinfo.max_freq);
> + ret = freq_qos_update_request(&policy->boost_freq_req, policy->cpuinfo.max_freq);
> if (ret < 0) {
> policy->boost_enabled = !policy->boost_enabled;
> cpufreq_driver->set_boost(policy, policy->boost_enabled);
> @@ -769,7 +769,7 @@ static ssize_t store_##file_name \
> if (ret) \
> return ret; \
> \
> - ret = freq_qos_update_request(policy->object##_freq_req, val);\
> + ret = freq_qos_update_request(&policy->object##_freq_req, val); \
> return ret >= 0 ? count : ret; \
> }
>
> @@ -1374,7 +1374,7 @@ static void cpufreq_policy_free(struct cpufreq_policy *policy)
> /* Cancel any pending policy->update work before freeing the policy. */
> cancel_work_sync(&policy->update);
>
> - if (policy->max_freq_req) {
> + if (freq_qos_request_active(&policy->max_freq_req)) {
> /*
> * Remove max_freq_req after sending CPUFREQ_REMOVE_POLICY
> * notification, since CPUFREQ_CREATE_POLICY notification was
> @@ -1382,12 +1382,13 @@ static void cpufreq_policy_free(struct cpufreq_policy *policy)
> */
> blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
> CPUFREQ_REMOVE_POLICY, policy);
> - freq_qos_remove_request(policy->max_freq_req);
> + freq_qos_remove_request(&policy->max_freq_req);
> }
>
> - freq_qos_remove_request(policy->min_freq_req);
> - freq_qos_remove_request(policy->boost_freq_req);
> - kfree(policy->min_freq_req);
> + if (freq_qos_request_active(&policy->min_freq_req))
> + freq_qos_remove_request(&policy->min_freq_req);
> + if (freq_qos_request_active(&policy->boost_freq_req))
> + freq_qos_remove_request(&policy->boost_freq_req);
>
> cpufreq_policy_put_kobj(policy);
> free_cpumask_var(policy->real_cpus);
> @@ -1452,57 +1453,31 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
> cpumask_and(policy->cpus, policy->cpus, cpu_online_mask);
>
> if (new_policy) {
> - unsigned int count;
> -
> for_each_cpu(j, policy->related_cpus) {
> per_cpu(cpufreq_cpu_data, j) = policy;
> add_cpu_dev_symlink(policy, j, get_cpu_device(j));
> }
>
> - count = policy->boost_supported ? 3 : 2;
> - policy->min_freq_req = kzalloc(count * sizeof(*policy->min_freq_req),
> - GFP_KERNEL);
> - if (!policy->min_freq_req) {
> - ret = -ENOMEM;
> - goto out_destroy_policy;
> - }
> -
> if (policy->boost_supported) {
> - policy->boost_freq_req = policy->min_freq_req + 2;
> -
> ret = freq_qos_add_request(&policy->constraints,
> - policy->boost_freq_req,
> + &policy->boost_freq_req,
> FREQ_QOS_MAX,
> policy->cpuinfo.max_freq);
> - if (ret < 0) {
> - policy->boost_freq_req = NULL;
> + if (ret < 0)
> goto out_destroy_policy;
> - }
> }
>
> ret = freq_qos_add_request(&policy->constraints,
> - policy->min_freq_req, FREQ_QOS_MIN,
> + &policy->min_freq_req, FREQ_QOS_MIN,
> FREQ_QOS_MIN_DEFAULT_VALUE);
> - if (ret < 0) {
> - kfree(policy->min_freq_req);
> - policy->min_freq_req = NULL;
> + if (ret < 0)
> goto out_destroy_policy;
> - }
> -
> - /*
> - * This must be initialized right here to avoid calling
> - * freq_qos_remove_request() on uninitialized request in case
> - * of errors.
> - */
> - policy->max_freq_req = policy->min_freq_req + 1;
>
> ret = freq_qos_add_request(&policy->constraints,
> - policy->max_freq_req, FREQ_QOS_MAX,
> + &policy->max_freq_req, FREQ_QOS_MAX,
> FREQ_QOS_MAX_DEFAULT_VALUE);
> - if (ret < 0) {
> - policy->max_freq_req = NULL;
> + if (ret < 0)
> goto out_destroy_policy;
> - }
>
> blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
> CPUFREQ_CREATE_POLICY, policy);
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index b6f6c7d06912..9b10eb486ece 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -79,9 +79,9 @@ struct cpufreq_policy {
> * called, but you're in IRQ context */
>
> struct freq_constraints constraints;
> - struct freq_qos_request *min_freq_req;
> - struct freq_qos_request *max_freq_req;
> - struct freq_qos_request *boost_freq_req;
> + struct freq_qos_request min_freq_req;
> + struct freq_qos_request max_freq_req;
> + struct freq_qos_request boost_freq_req;
>
> struct cpufreq_frequency_table *freq_table;
> enum cpufreq_table_sorting freq_table_sorted;
> --
Applied as 7.1 material, thanks!
^ permalink raw reply
* Re: [PATCH v5 2/5] media: iris: scale MMCX power domain on SM8250
From: Bryan O'Donoghue @ 2026-04-01 11:43 UTC (permalink / raw)
To: Ulf Hansson, Bryan O'Donoghue
Cc: Dmitry Baryshkov, Dikshita Agarwal, Bjorn Andersson,
Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Taniya Das, Jonathan Marek, Rafael J. Wysocki,
Vikash Garodia, Mauro Carvalho Chehab, Stanimir Varbanov,
Abhinav Kumar, Hans Verkuil, Stefan Schmidt, Konrad Dybcio,
Dikshita Agarwal, linux-arm-msm, linux-clk, devicetree,
linux-kernel, linux-pm, linux-media, Mauro Carvalho Chehab
In-Reply-To: <CAPDyKFrkVbvZcnbhxbLqFySn4V+USCKAjooT3yXN56jq+D9XGw@mail.gmail.com>
On 01/04/2026 12:41, Ulf Hansson wrote:
> On Wed, 1 Apr 2026 at 12:58, Bryan O'Donoghue <bod@kernel.org> wrote:
>>
>> On 01/04/2026 11:46, Ulf Hansson wrote:
>>>>> The intent was for this patch to be part of v7.0-rc1, but I failed
>>>>> with my pull-request to Linus.
>>>>>
>>>>> Instead this will be part of v7.1-rc1, assuming everything goes as expected.
>>>>>
>>>>> Is it possible to drop/defer these changes until v7.2?
>>>> It would be very sad.
>>> Right.
>>>
>>> Since it's my mistake, let me reconsider. If I rebase my branch and
>>> share the necessary commit through an immutable branch that you can
>>> pull in. Would that work for you?
>>>
>>> Kind regards
>>> Uffe
>>
>> Yes. Please go ahead.
>
> The patch is available for you to pull from the immutable branch:
>
> git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm.git pmdomain
>
> Kind regards
> Uffe
Awesome, thank you.
---
bod
^ permalink raw reply
* Re: [PATCH v5 2/5] media: iris: scale MMCX power domain on SM8250
From: Ulf Hansson @ 2026-04-01 11:41 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Dmitry Baryshkov, Dikshita Agarwal, Bjorn Andersson,
Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Taniya Das, Jonathan Marek, Rafael J. Wysocki,
Vikash Garodia, Mauro Carvalho Chehab, Stanimir Varbanov,
Abhinav Kumar, Hans Verkuil, Stefan Schmidt, Konrad Dybcio,
Bryan O'Donoghue, Dikshita Agarwal, linux-arm-msm, linux-clk,
devicetree, linux-kernel, linux-pm, linux-media,
Mauro Carvalho Chehab
In-Reply-To: <39b31606-b4e1-48bb-b9cc-911c1ac350fc@kernel.org>
On Wed, 1 Apr 2026 at 12:58, Bryan O'Donoghue <bod@kernel.org> wrote:
>
> On 01/04/2026 11:46, Ulf Hansson wrote:
> >>> The intent was for this patch to be part of v7.0-rc1, but I failed
> >>> with my pull-request to Linus.
> >>>
> >>> Instead this will be part of v7.1-rc1, assuming everything goes as expected.
> >>>
> >>> Is it possible to drop/defer these changes until v7.2?
> >> It would be very sad.
> > Right.
> >
> > Since it's my mistake, let me reconsider. If I rebase my branch and
> > share the necessary commit through an immutable branch that you can
> > pull in. Would that work for you?
> >
> > Kind regards
> > Uffe
>
> Yes. Please go ahead.
The patch is available for you to pull from the immutable branch:
git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm.git pmdomain
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH 3/3] pmdomain: qcom: rpmhpd: Add power domains for Hawi SoC
From: Dmitry Baryshkov @ 2026-04-01 11:31 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
In-Reply-To: <20260401-haw-rpmhpd-v1-3-c830c79ed8f9@oss.qualcomm.com>
On Wed, Apr 01, 2026 at 02:15:31AM -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
>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> drivers/pmdomain/qcom/rpmhpd.c | 38 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
>
> + [RPMHPD_LCX] = &lcx,
> + [RPMHPD_LMX] = &lmx,
> + [RPMHPD_MMCX] = &mmcx,
> + [RPMHPD_MMCX_AO] = &mmcx_ao,
So, should it be just mmcx or mmcx_w_cx_parent ?
> + [RPMHPD_MX] = &mx,
> + [RPMHPD_MX_AO] = &mx_ao,
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v5 2/5] media: iris: scale MMCX power domain on SM8250
From: Dikshita Agarwal @ 2026-04-01 11:21 UTC (permalink / raw)
To: Dmitry Baryshkov, Ulf Hansson
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Jonathan Marek,
Rafael J. Wysocki, Bryan O'Donoghue, Vikash Garodia,
Mauro Carvalho Chehab, Stanimir Varbanov, Abhinav Kumar,
Hans Verkuil, Stefan Schmidt, Konrad Dybcio, Bryan O'Donoghue,
Dikshita Agarwal, linux-arm-msm, linux-clk, devicetree,
linux-kernel, linux-pm, linux-media, Mauro Carvalho Chehab
In-Reply-To: <4fiyjcqt5smotudsfzyqrevxxnx3sf5grbgfluzkndbp2od6pq@vlyikcvl3xkb>
On 4/1/2026 4:31 PM, Dmitry Baryshkov wrote:
> On Wed, Apr 01, 2026 at 12:46:01PM +0200, Ulf Hansson wrote:
>> On Tue, 31 Mar 2026 at 20:46, Dmitry Baryshkov
>> <dmitry.baryshkov@oss.qualcomm.com> wrote:
>>>
>>> On Tue, Mar 31, 2026 at 01:33:35PM +0200, Ulf Hansson wrote:
>>>> On Mon, 30 Mar 2026 at 15:06, Dikshita Agarwal
>>>> <dikshita.agarwal@oss.qualcomm.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 3/30/2026 4:45 PM, Dmitry Baryshkov wrote:
>>>>>> On Mon, Mar 30, 2026 at 10:55:02AM +0530, Dikshita Agarwal wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 2/9/2026 7:02 AM, Dmitry Baryshkov wrote:
>>>>>>>> On SM8250 most of the video clocks are powered by the MMCX domain, while
>>>>>>>> the PLL is powered on by the MX domain. Extend the driver to support
>>>>>>>> scaling both power domains, while keeping compatibility with the
>>>>>>>> existing DTs, which define only the MX domain.
>>>>>>>>
>>>>>>>> Fixes: 79865252acb6 ("media: iris: enable video driver probe of SM8250 SoC")
>>>>>>>> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
>>>>>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>>>>>>> ---
>>>>>>>> drivers/media/platform/qcom/iris/iris_platform_gen1.c | 2 +-
>>>>>>>> drivers/media/platform/qcom/iris/iris_probe.c | 7 +++++++
>>>>>>>> 2 files changed, 8 insertions(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_gen1.c b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
>>>>>>>> index df8e6bf9430e..aa71f7f53ee3 100644
>>>>>>>> --- a/drivers/media/platform/qcom/iris/iris_platform_gen1.c
>>>>>>>> +++ b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
>>>>>>>> @@ -281,7 +281,7 @@ static const struct bw_info sm8250_bw_table_dec[] = {
>>>>>>>>
>>>>>>>> static const char * const sm8250_pmdomain_table[] = { "venus", "vcodec0" };
>>>>>>>>
>>>>>>>> -static const char * const sm8250_opp_pd_table[] = { "mx" };
>>>>>>>> +static const char * const sm8250_opp_pd_table[] = { "mx", "mmcx" };
>>>>>>>>
>>>>>>>> static const struct platform_clk_data sm8250_clk_table[] = {
>>>>>>>> {IRIS_AXI_CLK, "iface" },
>>>>>>>> diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
>>>>>>>> index 7b612ad37e4f..74ec81e3d622 100644
>>>>>>>> --- a/drivers/media/platform/qcom/iris/iris_probe.c
>>>>>>>> +++ b/drivers/media/platform/qcom/iris/iris_probe.c
>>>>>>>> @@ -64,6 +64,13 @@ static int iris_init_power_domains(struct iris_core *core)
>>>>>>>> return ret;
>>>>>>>>
>>>>>>>> ret = devm_pm_domain_attach_list(core->dev, &iris_opp_pd_data, &core->opp_pmdomain_tbl);
>>>>>>>> + /* backwards compatibility for incomplete ABI SM8250 */
>>>>>>>> + if (ret == -ENODEV &&
>>>>>>>> + of_device_is_compatible(core->dev->of_node, "qcom,sm8250-venus")) {
>>>>>>>> + iris_opp_pd_data.num_pd_names--;
>>>>>>>> + ret = devm_pm_domain_attach_list(core->dev, &iris_opp_pd_data,
>>>>>>>> + &core->opp_pmdomain_tbl);
>>>>>>>> + }
>>>>>>>> if (ret < 0)
>>>>>>>> return ret;
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Hitting below compilation error on latest kernel
>>>>>>>
>>>>>>> drivers/media/platform/qcom/iris/iris_probe.c: In function
>>>>>>> ‘iris_init_power_domains’:
>>>>>>> drivers/media/platform/qcom/iris/iris_probe.c:71:46: error: decrement of
>>>>>>> read-only member ‘num_pd_names’
>>>>>>> 71 | iris_opp_pd_data.num_pd_names--;
>>>>>>
>>>>>> See commit 7ad7f43e568b ("pmdomain: de-constify fields struct
>>>>>> dev_pm_domain_attach_data")
>>>>
>>>> The intent was for this patch to be part of v7.0-rc1, but I failed
>>>> with my pull-request to Linus.
>>>>
>>>> Instead this will be part of v7.1-rc1, assuming everything goes as expected.
>>>>
>>>> Is it possible to drop/defer these changes until v7.2?
>>>
>>> It would be very sad.
>>
>> Right.
>>
>> Since it's my mistake, let me reconsider. If I rebase my branch and
>> share the necessary commit through an immutable branch that you can
>> pull in. Would that work for you?
>
> I think that question goes to Vikash, Dikshita, Bryan and linux-media
> maintainers. Bryan, what is the plan for this patchset? Should Ulf
> rebase the branch? Or is this patchset delayed for some other reasons?
Its good to go, Bryan can comment as he will be raising the PR.
Thanks,
Dikshita
>
^ permalink raw reply
* Re: (subset) [PATCH v5 0/2] driver: reset: spacemit-p1: add driver for poweroff/reboot
From: Lee Jones @ 2026-04-01 11:19 UTC (permalink / raw)
To: Troy Mitchell, Sebastian Reichel, linux-kernel, Sebastian Reichel,
Yixun Lan, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, linux-riscv, spacemit, linux-pm
In-Reply-To: <acxInP3_rU9H8Q5V@aurel32.net>
On Wed, 01 Apr 2026, Aurelien Jarno wrote:
> Hi Lee,
>
> On 2025-11-05 10:11, Lee Jones wrote:
> > On Wed, 05 Nov 2025, Lee Jones wrote:
> >
> > > On Wed, 05 Nov 2025, Troy Mitchell wrote:
> > >
> > > > On Wed, Nov 05, 2025 at 09:34:21AM +0000, Lee Jones wrote:
> > > > > On Tue, 04 Nov 2025, Troy Mitchell wrote:
> > > > >
> > > > > > On Mon, Nov 03, 2025 at 01:48:33AM +0100, Sebastian Reichel wrote:
> > > > > > >
> > > > > > > On Mon, 03 Nov 2025 00:01:58 +0100, Aurelien Jarno wrote:
> > > > > > > > This adds poweroff/reboot support for the SpacemiT P1 PMIC chip, which is
> > > > > > > > commonly paired with the SpacemiT K1 SoC.
> > > > > > > >
> > > > > > > > Note: For reliable operation, this driver depends on a this patch that adds
> > > > > > > > atomic transfer support to the SpacemiT I2C controller driver:
> > > > > > > > https://lore.kernel.org/spacemit/20251009-k1-i2c-atomic-v4-1-a89367870286@linux.spacemit.com/
> > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > dependency is here.
> > > > > > > >
> > > > > > > > [...]
> > > > > > >
> > > > > > > Applied, thanks!
> > > > > > >
> > > > > > > [1/2] driver: reset: spacemit-p1: add driver for poweroff/reboot
> > > > > > > commit: 28124cc0fb8c7dc01a6834d227351e25d9a92c58
> > > > > > Should we apply it now? The dependency patch hasn’t been merged yet...
> > > > >
> > > > > What is the dependency?
> > > > I point it out above.
> > > > Without this patch, reboot and shutdown would end up calling the non-atomic i2c_transfer.
> > >
> > > Okay, thanks. I was mostly checking that you weren't referring to the
> > > MFD patch, which doesn't represent a true dependency.
> >
> > To save Sebastian some trouble, let's keep the reboot patch applied.
> >
> > I'll hold off on the MFD one, which will ensure that reboot isn't probed.
> >
> > Let me know when the dep is merged and I'll hoover up the rest of the set.
>
> The dependency is still not yet merged, although it has been ready for
> weeks, and I am just crossing fingers that it will get picked-up for
> for 7.1.
>
> That said it's not a hard dependency, in most cases reboot will work,
> which is an improvement over no reboot driver. The missing I2C PIO
> patches are just there to make it reliable.
>
> Therefore given the 7.1 merge window approaching, I believe it's better
> to merge this simple MFD patch and to not wait more.
It's too late for v7.1 now.
I think this set has been well and truly forgotten.
Please rebase and submit a [RESEND] with the info in the cover letter.
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v5 2/5] media: iris: scale MMCX power domain on SM8250
From: Bryan O'Donoghue @ 2026-04-01 11:05 UTC (permalink / raw)
To: Dmitry Baryshkov, Ulf Hansson
Cc: Dikshita Agarwal, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Taniya Das, Jonathan Marek, Rafael J. Wysocki,
Bryan O'Donoghue, Vikash Garodia, Mauro Carvalho Chehab,
Stanimir Varbanov, Abhinav Kumar, Hans Verkuil, Stefan Schmidt,
Konrad Dybcio, Dikshita Agarwal, linux-arm-msm, linux-clk,
devicetree, linux-kernel, linux-pm, linux-media,
Mauro Carvalho Chehab
In-Reply-To: <4fiyjcqt5smotudsfzyqrevxxnx3sf5grbgfluzkndbp2od6pq@vlyikcvl3xkb>
On 01/04/2026 12:01, Dmitry Baryshkov wrote:
>> Right.
>>
>> Since it's my mistake, let me reconsider. If I rebase my branch and
>> share the necessary commit through an immutable branch that you can
>> pull in. Would that work for you?
> I think that question goes to Vikash, Dikshita, Bryan and linux-media
> maintainers. Bryan, what is the plan for this patchset? Should Ulf
> rebase the branch? Or is this patchset delayed for some other reasons?
Yeah no it's grand, immutable tag works fine.
---
bod
^ permalink raw reply
* Re: [PATCH v5 2/5] media: iris: scale MMCX power domain on SM8250
From: Dmitry Baryshkov @ 2026-04-01 11:01 UTC (permalink / raw)
To: Ulf Hansson
Cc: Dikshita Agarwal, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Taniya Das, Jonathan Marek, Rafael J. Wysocki,
Bryan O'Donoghue, Vikash Garodia, Mauro Carvalho Chehab,
Stanimir Varbanov, Abhinav Kumar, Hans Verkuil, Stefan Schmidt,
Konrad Dybcio, Bryan O'Donoghue, Dikshita Agarwal,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-pm,
linux-media, Mauro Carvalho Chehab
In-Reply-To: <CAPDyKFpm7ujNw51dVpPaHCwssjgYe1JVBEyrQ_1CsPbDJuW0Ww@mail.gmail.com>
On Wed, Apr 01, 2026 at 12:46:01PM +0200, Ulf Hansson wrote:
> On Tue, 31 Mar 2026 at 20:46, Dmitry Baryshkov
> <dmitry.baryshkov@oss.qualcomm.com> wrote:
> >
> > On Tue, Mar 31, 2026 at 01:33:35PM +0200, Ulf Hansson wrote:
> > > On Mon, 30 Mar 2026 at 15:06, Dikshita Agarwal
> > > <dikshita.agarwal@oss.qualcomm.com> wrote:
> > > >
> > > >
> > > >
> > > > On 3/30/2026 4:45 PM, Dmitry Baryshkov wrote:
> > > > > On Mon, Mar 30, 2026 at 10:55:02AM +0530, Dikshita Agarwal wrote:
> > > > >>
> > > > >>
> > > > >> On 2/9/2026 7:02 AM, Dmitry Baryshkov wrote:
> > > > >>> On SM8250 most of the video clocks are powered by the MMCX domain, while
> > > > >>> the PLL is powered on by the MX domain. Extend the driver to support
> > > > >>> scaling both power domains, while keeping compatibility with the
> > > > >>> existing DTs, which define only the MX domain.
> > > > >>>
> > > > >>> Fixes: 79865252acb6 ("media: iris: enable video driver probe of SM8250 SoC")
> > > > >>> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> > > > >>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > > > >>> ---
> > > > >>> drivers/media/platform/qcom/iris/iris_platform_gen1.c | 2 +-
> > > > >>> drivers/media/platform/qcom/iris/iris_probe.c | 7 +++++++
> > > > >>> 2 files changed, 8 insertions(+), 1 deletion(-)
> > > > >>>
> > > > >>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_gen1.c b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
> > > > >>> index df8e6bf9430e..aa71f7f53ee3 100644
> > > > >>> --- a/drivers/media/platform/qcom/iris/iris_platform_gen1.c
> > > > >>> +++ b/drivers/media/platform/qcom/iris/iris_platform_gen1.c
> > > > >>> @@ -281,7 +281,7 @@ static const struct bw_info sm8250_bw_table_dec[] = {
> > > > >>>
> > > > >>> static const char * const sm8250_pmdomain_table[] = { "venus", "vcodec0" };
> > > > >>>
> > > > >>> -static const char * const sm8250_opp_pd_table[] = { "mx" };
> > > > >>> +static const char * const sm8250_opp_pd_table[] = { "mx", "mmcx" };
> > > > >>>
> > > > >>> static const struct platform_clk_data sm8250_clk_table[] = {
> > > > >>> {IRIS_AXI_CLK, "iface" },
> > > > >>> diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
> > > > >>> index 7b612ad37e4f..74ec81e3d622 100644
> > > > >>> --- a/drivers/media/platform/qcom/iris/iris_probe.c
> > > > >>> +++ b/drivers/media/platform/qcom/iris/iris_probe.c
> > > > >>> @@ -64,6 +64,13 @@ static int iris_init_power_domains(struct iris_core *core)
> > > > >>> return ret;
> > > > >>>
> > > > >>> ret = devm_pm_domain_attach_list(core->dev, &iris_opp_pd_data, &core->opp_pmdomain_tbl);
> > > > >>> + /* backwards compatibility for incomplete ABI SM8250 */
> > > > >>> + if (ret == -ENODEV &&
> > > > >>> + of_device_is_compatible(core->dev->of_node, "qcom,sm8250-venus")) {
> > > > >>> + iris_opp_pd_data.num_pd_names--;
> > > > >>> + ret = devm_pm_domain_attach_list(core->dev, &iris_opp_pd_data,
> > > > >>> + &core->opp_pmdomain_tbl);
> > > > >>> + }
> > > > >>> if (ret < 0)
> > > > >>> return ret;
> > > > >>>
> > > > >>>
> > > > >>
> > > > >> Hitting below compilation error on latest kernel
> > > > >>
> > > > >> drivers/media/platform/qcom/iris/iris_probe.c: In function
> > > > >> ‘iris_init_power_domains’:
> > > > >> drivers/media/platform/qcom/iris/iris_probe.c:71:46: error: decrement of
> > > > >> read-only member ‘num_pd_names’
> > > > >> 71 | iris_opp_pd_data.num_pd_names--;
> > > > >
> > > > > See commit 7ad7f43e568b ("pmdomain: de-constify fields struct
> > > > > dev_pm_domain_attach_data")
> > >
> > > The intent was for this patch to be part of v7.0-rc1, but I failed
> > > with my pull-request to Linus.
> > >
> > > Instead this will be part of v7.1-rc1, assuming everything goes as expected.
> > >
> > > Is it possible to drop/defer these changes until v7.2?
> >
> > It would be very sad.
>
> Right.
>
> Since it's my mistake, let me reconsider. If I rebase my branch and
> share the necessary commit through an immutable branch that you can
> pull in. Would that work for you?
I think that question goes to Vikash, Dikshita, Bryan and linux-media
maintainers. Bryan, what is the plan for this patchset? Should Ulf
rebase the branch? Or is this patchset delayed for some other reasons?
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 5/5] cpufreq: ti: Add device link to k3-socinfo
From: Akashdeep Kaur @ 2026-04-01 10:59 UTC (permalink / raw)
To: Krzysztof Kozlowski, praneeth, nm, vigneshr, kristo, robh,
krzk+dt, conor+dt, rafael, viresh.kumar, linux-arm-kernel,
devicetree, linux-kernel, linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis
In-Reply-To: <da225ab1-d659-455d-b3c9-e7ff4864119e@kernel.org>
Hi Krzysztof,
On 30/03/26 18:52, Krzysztof Kozlowski wrote:
> On 30/03/2026 14:01, Akashdeep Kaur wrote:
>> opp_data->cpu_dev = get_cpu_device(0);
>> if (!opp_data->cpu_dev) {
>> @@ -560,6 +563,42 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
>> if (ret)
>> goto fail_put_node;
>>
>> + /* Create device link to k3-socinfo if specified in DT */
>> + if (opp_data->soc_data == &am625_soc_data ||
>> + opp_data->soc_data == &am62a7_soc_data ||
>> + opp_data->soc_data == &am62l3_soc_data ||
>> + opp_data->soc_data == &am62p5_soc_data) {
>> + struct device_node *socinfo_np;
>> +
>> + socinfo_np = of_parse_phandle(opp_data->opp_node, "ti,soc-info", 0);
>
> Undocumented ABI.
Added missing patch in next version, thanks for pointing this out.
Regards,
Akashdeep Kaur
>
> Best regards,
> Krzysztof
^ 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