* Re: [PATCH 2/2] interconnect: qcom: add Hawi interconnect provider driver
From: Dmitry Baryshkov @ 2026-03-31 0:47 UTC (permalink / raw)
To: Vivek Aknurwar
Cc: Georgi Djakov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-pm, devicetree, linux-kernel, Mike Tipton
In-Reply-To: <20260330-icc-hawi-v1-2-4b54a9e7d38c@oss.qualcomm.com>
On Mon, Mar 30, 2026 at 05:40:01PM -0700, Vivek Aknurwar wrote:
> Add driver for the Qualcomm interconnect buses found in Hawi
> based platforms. The topology consists of several NoCs that are
> controlled by a remote processor that collects the aggregated
> bandwidth for each master-slave pairs.
>
> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
> ---
> drivers/interconnect/qcom/Kconfig | 9 +
> drivers/interconnect/qcom/Makefile | 2 +
> drivers/interconnect/qcom/hawi.c | 2021 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 2032 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: interconnect: document the RPMh Network-On-Chip interconnect in Hawi SoC
From: Rob Herring (Arm) @ 2026-03-31 1:27 UTC (permalink / raw)
To: Vivek Aknurwar
Cc: linux-kernel, Georgi Djakov, linux-pm, Conor Dooley,
Krzysztof Kozlowski, devicetree, Mike Tipton, linux-arm-msm
In-Reply-To: <20260330-icc-hawi-v1-1-4b54a9e7d38c@oss.qualcomm.com>
On Mon, 30 Mar 2026 17:40:00 -0700, Vivek Aknurwar wrote:
> Document the RPMh Network-On-Chip Interconnect of the Hawi platform.
>
> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
> ---
> .../bindings/interconnect/qcom,hawi-rpmh.yaml | 126 ++++++++++++++++
> include/dt-bindings/interconnect/qcom,hawi-rpmh.h | 164 +++++++++++++++++++++
> 2 files changed, 290 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/interconnect/qcom,hawi-rpmh.example.dtb: interconnect@f00000 (qcom,hawi-aggre1-noc): reg: [[0, 15728640], [0, 345088]] is too long
from schema $id: http://devicetree.org/schemas/interconnect/qcom,hawi-rpmh.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260330-icc-hawi-v1-1-4b54a9e7d38c@oss.qualcomm.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v1 00/10] devfreq: Fix NULL pointer dereference when a governor module is unloaded
From: Yaxiong Tian @ 2026-03-31 1:30 UTC (permalink / raw)
To: Jie Zhan, cw00.choi, myungjoo.ham, kyungmin.park
Cc: linux-pm, linux-arm-kernel, linuxarm, jonathan.cameron,
zhenglifeng1, zhangpengjie2, lihuisong, prime.zeng
In-Reply-To: <1774919144945331.7.seg@mailgw.kylinos.cn>
在 2026/3/30 14:29, Jie Zhan 写道:
>
> On 3/27/2026 10:06 AM, Yaxiong Tian wrote:
>> 在 2026/3/26 21:14, Jie Zhan 写道:
>>> On 3/26/2026 8:34 PM, Jie Zhan wrote:
>>>> When compiled as a kernel module, the governor module can be dynamically
>>>> inserted or removed. 'devfreq->governor' would become NULL if the governor
>>>> module is removed when it's in use, and NULL pointer dereference would be
>>>> triggered. A similar issue was also reported in [1].
>>>>
>>>> To address this issue:
>>>>
>>>> Patch 1-5 rework mutex, factor out a common governor setting function, and
>>>> clean up some unreachable code.
>>>>
>>>> Patch 6-8 prevent a governor module in use from being removed (except for
>>>> force unload) by getting/putting a refcount of the governor's module when
>>>> switching governors.
>>>>
>>>> Patch 9-10 allow 'governor' and 'available_governors' to work normally even
>>>> when a governor module in use is force unloaded.
>>>>
>>>> Note that this series is based on [1] or devfreq-next, otherwise code
>> Sorry, please ignore the "remember to CC me on the patches." in my previous email.
>>
>> In my opinion, it would be better to prioritize the FIX first before proceeding with the lock mechanism optimizations and other work. This would make it easier to backport the patches to lower-version kernels. I noticed the patch is already in the devfreq-testing branch. I hope the FIX work can be moved forward smoothly to resolve the null pointer and other bugs. Thank you!
> Hi Yaxiong,
>
> I don't think this issue is urgent because it can only possibly happen when
> governors are built as loadable modules, which is typically used for
> development rather than production.
No, loading/unloading modules is also a user operational requirement,
not just for development.
>
> For downstream kernels, feel free to go ahead with quick fixes. For the
> upstream kernel, however, I'd prefer to make the devfreq core clean and
> sensible.
I don't think code cleanup should take priority over bug fixes,
especially when you already know there's an issue with the
functionality. In fact, the version users are running is not the
upstream version, but rather individual stable releases.
Most users don't have the time or energy to research and fix kernel
issues themselves; they rely on upstream community patches most of the time.
By the way, although your patch subject says "FIX", I don't see any fix tag.
>
> Your approach is to prevent kernel panics when unloading governor modules
> before changing governors.
>
> This patchset achieves that, and additionally let userspace get a friendly
> warning when trying to remove a governor module in use, e.g.
> "rmmod: ERROR: Module governor_performance is in use".
> This requires using the module refcount stuff, and brings out a set of
> cleanups and refactoring. BTW, cpufreq implements a similar mechanism like
> this.
>
> I may carry your fourth patch that changes the return code of
> governor_show() in v2 and address some Sashiko review comments along the
> way.
>
> Please let me know if this works for you?
So I don't approve of this. Maybe you should ask for others' opinions,
such as Chanwoo Choi.
>
> Regards,
> Jie
>>
>>
>>> sorry, based on [2] or devfreq-next
>>>> would conflict.
>>>>
>>>> [1] https://lore.kernel.org/all/20260319091409.998397-1-tianyaxiong@kylinos.cn/
>>>> [2] https://lore.kernel.org/all/20251216031153.2242306-1-zhangpengjie2@huawei.com/
^ permalink raw reply
* Re: [PATCH v8 2/2] cpufreq: Add boost_freq_req QoS request
From: Zhongqiu Han @ 2026-03-31 3:14 UTC (permalink / raw)
To: Viresh Kumar
Cc: Pierre Gondois, linux-kernel, Lifeng Zheng, Huang Rui,
Gautham R. Shenoy, Mario Limonciello, Perry Yuan,
Rafael J. Wysocki, linux-pm, zhongqiu.han
In-Reply-To: <779ebbd4-d495-426e-bce1-020686c3f946@oss.qualcomm.com>
On 3/30/2026 8:55 PM, Zhongqiu Han wrote:
> On 3/30/2026 1:20 PM, Viresh Kumar wrote:
>> On 29-03-26, 17:00, Zhongqiu Han wrote:
>>> Sorry for the late follow-up on v8. While re-reading the patch, I
>>> noticed a potential UAF issue on an error path — I might be missing
>>> something, so I'd appreciate a double-check.
>>>
>>> min_freq_req, max_freq_req and boost_freq_req all point into the same
>>> contiguous kzalloc'd block:
>>>
>>> slot0 (min_freq_req + 0) -> min_freq_req
>>> slot1 (min_freq_req + 1) -> max_freq_req
>>> slot2 (min_freq_req + 2) -> boost_freq_req
>>>
>>> If boost_freq_req is successfully added to the QoS constraints list, but
>>> the subsequent freq_qos_add_request() for min_freq_req fails, the error
>>> path does:
>>>
>>> kfree(policy->min_freq_req); /* frees the entire block, including slot2
>>> */
>>> policy->min_freq_req = NULL;
>>> goto out_destroy_policy;
>>>
>>> policy->boost_freq_req is not set to NULL here, so it becomes a dangling
>>> pointer into freed memory.
>>
>> Nice catch.
>>
>> The right solution to this I guess is to do kfree and setting
>> min_freq_req to
>> NULL if boost_freq_req fails (just like what happens in min_freq_req
>> failure
>> now) and then for later failures, don't do kfree at all but just set
>> the failed
>> qos feature to NULL (like what is done for max_freq_req now).
>>
>
>
> Thanks Viresh — agreed, that approach makes sense.
> I sketched a small example along those lines for discussion only if
> needed: add boost_freq_req early when boost_supported, free the shared
> allocation if that add fails, and on later failures just unwind without
> freeing the block.
>
>
> + 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,
> + FREQ_QOS_MAX,
> + policy->cpuinfo.max_freq);
> + if (ret < 0) {
> + policy->boost_freq_req = NULL;
> + kfree(policy->min_freq_req);
> + policy->min_freq_req = NULL;
> + goto out_destroy_policy;
> + }
> + }
> +
> ret = freq_qos_add_request(&policy->constraints,
> policy->min_freq_req, FREQ_QOS_MIN,
> FREQ_QOS_MIN_DEFAULT_VALUE);
> if (ret < 0) {
> - /*
> - * So we don't call freq_qos_remove_request() for an
> - * uninitialized request.
> - */
> + if (policy->boost_freq_req) {
> + freq_qos_remove_request(policy->boost_freq_req);
> + policy->boost_freq_req = NULL;
> + }
> kfree(policy->min_freq_req);
> policy->min_freq_req = NULL;
> goto out_destroy_policy;
>
>
>
Now that the patch has been picked on queue, if the approach in the
current draft looks reasonable, I'm happy to send it out as a proper
fixup.
--
Thx and BRs,
Zhongqiu Han
^ permalink raw reply
* Re: [PATCH v8 2/2] cpufreq: Add boost_freq_req QoS request
From: Viresh Kumar @ 2026-03-31 3:58 UTC (permalink / raw)
To: Zhongqiu Han
Cc: Pierre Gondois, linux-kernel, Lifeng Zheng, Huang Rui,
Gautham R. Shenoy, Mario Limonciello, Perry Yuan,
Rafael J. Wysocki, linux-pm
In-Reply-To: <779ebbd4-d495-426e-bce1-020686c3f946@oss.qualcomm.com>
On 30-03-26, 20:55, Zhongqiu Han wrote:
> Thanks Viresh — agreed, that approach makes sense.
> I sketched a small example along those lines for discussion only if
> needed: add boost_freq_req early when boost_supported, free the shared
> allocation if that add fails, and on later failures just unwind without
> freeing the block.
I have taken a different approach to fix this. (Build tested).
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;
--
viresh
^ permalink raw reply related
* [PATCH] cpupower: replace atoi() with validated parse_int_range() helper
From: Kaushlendra Kumar @ 2026-03-31 4:28 UTC (permalink / raw)
To: shuah, jwyatt, jkacur; +Cc: linux-pm, Kaushlendra Kumar
atoi() provides no error detection for invalid input or out-of-range
values. Introduce parse_int_range(), which uses strtol() with full
errno and end-pointer checking, returning -EINVAL on parse failure
and -ERANGE when the value falls outside the caller-supplied [min,
max] bounds.
Switch --perf-bias and --turbo-boost option parsing to use this
helper. Also move error messages from printf() to fprintf(stderr)
to follow standard CLI conventions for diagnostic output.
Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com>
---
tools/power/cpupower/utils/cpupower-set.c | 29 +++++++++++++++++------
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/tools/power/cpupower/utils/cpupower-set.c b/tools/power/cpupower/utils/cpupower-set.c
index 550a942e72ce..dcbdff5c9ae5 100644
--- a/tools/power/cpupower/utils/cpupower-set.c
+++ b/tools/power/cpupower/utils/cpupower-set.c
@@ -31,6 +31,24 @@ static void print_wrong_arg_exit(void)
exit(EXIT_FAILURE);
}
+/* Safe integer parsing with range validation. Returns 0 on success,
+ * -EINVAL on parse error, -ERANGE if value is outside [min, max].
+ */
+static int parse_int_range(const char *arg, int min, int max, int *out)
+{
+ char *end = NULL;
+ long val;
+
+ errno = 0;
+ val = strtol(arg, &end, 10);
+ if (errno || end == arg || *end != '\0')
+ return -EINVAL;
+ if (val < min || val > max)
+ return -ERANGE;
+ *out = (int)val;
+ return 0;
+}
+
int cmd_set(int argc, char **argv)
{
extern char *optarg;
@@ -69,10 +87,8 @@ int cmd_set(int argc, char **argv)
case 'b':
if (params.perf_bias)
print_wrong_arg_exit();
- perf_bias = atoi(optarg);
- if (perf_bias < 0 || perf_bias > 15) {
- printf(_("--perf-bias param out "
- "of range [0-%d]\n"), 15);
+ if (parse_int_range(optarg, 0, 15, &perf_bias)) {
+ fprintf(stderr, _("--perf-bias param out of range [0-%d]\n"), 15);
print_wrong_arg_exit();
}
params.perf_bias = 1;
@@ -100,9 +116,8 @@ int cmd_set(int argc, char **argv)
case 't':
if (params.turbo_boost)
print_wrong_arg_exit();
- turbo_boost = atoi(optarg);
- if (turbo_boost < 0 || turbo_boost > 1) {
- printf("--turbo-boost param out of range [0-1]\n");
+ if (parse_int_range(optarg, 0, 1, &turbo_boost)) {
+ fprintf(stderr, "--turbo-boost param out of range [0-1]\n");
print_wrong_arg_exit();
}
params.turbo_boost = 1;
--
2.34.1
^ permalink raw reply related
* [PATCH] cpupower: remove extern declarations in cmd_set()
From: Kaushlendra Kumar @ 2026-03-31 4:59 UTC (permalink / raw)
To: shuah, jwyatt, jkacur; +Cc: linux-pm, Kaushlendra Kumar
extern char *optarg and extern int optind, opterr, optopt are
already declared by <getopt.h>, which is included at the top of
the file. Repeating extern declarations inside a function body
is misleading and unnecessary.
Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com>
---
tools/power/cpupower/utils/cpupower-set.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/tools/power/cpupower/utils/cpupower-set.c b/tools/power/cpupower/utils/cpupower-set.c
index dcbdff5c9ae5..64d2d4b070b4 100644
--- a/tools/power/cpupower/utils/cpupower-set.c
+++ b/tools/power/cpupower/utils/cpupower-set.c
@@ -51,8 +51,6 @@ static int parse_int_range(const char *arg, int min, int max, int *out)
int cmd_set(int argc, char **argv)
{
- extern char *optarg;
- extern int optind, opterr, optopt;
unsigned int cpu;
struct utsname uts;
--
2.34.1
^ permalink raw reply related
* [PATCH] cpufreq: Allocate QoS freq_req objects with policy
From: Viresh Kumar @ 2026-03-31 5:03 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, Pierre Gondois, Lifeng Zheng
Cc: linux-pm, Vincent Guittot, Sumit Semwal, Zhongqiu Han,
Rafael J. Wysocki, linux-kernel
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;
--
2.31.1.272.g89b43f80a514
^ permalink raw reply related
* Re: [PATCH v1 00/10] devfreq: Fix NULL pointer dereference when a governor module is unloaded
From: Jie Zhan @ 2026-03-31 6:43 UTC (permalink / raw)
To: Yaxiong Tian, cw00.choi, myungjoo.ham, kyungmin.park
Cc: linux-pm, linux-arm-kernel, linuxarm, jonathan.cameron,
zhenglifeng1, zhangpengjie2, lihuisong, prime.zeng
In-Reply-To: <94f5b6ff-f610-44f6-90e4-2e538b4f99c9@kylinos.cn>
On 3/31/2026 9:30 AM, Yaxiong Tian wrote:
>
> 在 2026/3/30 14:29, Jie Zhan 写道:
>>
>> On 3/27/2026 10:06 AM, Yaxiong Tian wrote:
>>> 在 2026/3/26 21:14, Jie Zhan 写道:
>>>> On 3/26/2026 8:34 PM, Jie Zhan wrote:
>>>>> When compiled as a kernel module, the governor module can be dynamically
>>>>> inserted or removed. 'devfreq->governor' would become NULL if the governor
>>>>> module is removed when it's in use, and NULL pointer dereference would be
>>>>> triggered. A similar issue was also reported in [1].
>>>>>
>>>>> To address this issue:
>>>>>
>>>>> Patch 1-5 rework mutex, factor out a common governor setting function, and
>>>>> clean up some unreachable code.
>>>>>
>>>>> Patch 6-8 prevent a governor module in use from being removed (except for
>>>>> force unload) by getting/putting a refcount of the governor's module when
>>>>> switching governors.
>>>>>
>>>>> Patch 9-10 allow 'governor' and 'available_governors' to work normally even
>>>>> when a governor module in use is force unloaded.
>>>>>
>>>>> Note that this series is based on [1] or devfreq-next, otherwise code
>>> Sorry, please ignore the "remember to CC me on the patches." in my previous email.
>>>
>>> In my opinion, it would be better to prioritize the FIX first before proceeding with the lock mechanism optimizations and other work. This would make it easier to backport the patches to lower-version kernels. I noticed the patch is already in the devfreq-testing branch. I hope the FIX work can be moved forward smoothly to resolve the null pointer and other bugs. Thank you!
>> Hi Yaxiong,
>>
>> I don't think this issue is urgent because it can only possibly happen when
>> governors are built as loadable modules, which is typically used for
>> development rather than production.
> No, loading/unloading modules is also a user operational requirement, not just for development.
>
>>
>> For downstream kernels, feel free to go ahead with quick fixes. For the
>> upstream kernel, however, I'd prefer to make the devfreq core clean and
>> sensible.
>
> I don't think code cleanup should take priority over bug fixes, especially when you already know there's an issue with the functionality. In fact, the version users are running is not the upstream version, but rather individual stable releases.
The point is to do the bugfix in a different way rather than cleanups.
>
> Most users don't have the time or energy to research and fix kernel issues themselves; they rely on upstream community patches most of the time.
>
> By the way, although your patch subject says "FIX", I don't see any fix tag.
>
>>
>> Your approach is to prevent kernel panics when unloading governor modules
>> before changing governors.
>>
>> This patchset achieves that, and additionally let userspace get a friendly
>> warning when trying to remove a governor module in use, e.g.
>> "rmmod: ERROR: Module governor_performance is in use".
>> This requires using the module refcount stuff, and brings out a set of
>> cleanups and refactoring. BTW, cpufreq implements a similar mechanism like
>> this.
>>
>> I may carry your fourth patch that changes the return code of
>> governor_show() in v2 and address some Sashiko review comments along the
>> way.
>>
>> Please let me know if this works for you?
> So I don't approve of this. Maybe you should ask for others' opinions, such as Chanwoo Choi.
>
No problem. I see your point.
I'll take a closer look at your version and see if that works.
The module owner refcount related stuff can be rebased later if needed.
Thanks,
Jie
>>
>> Regards,
>> Jie
>>>
>>>
>>>> sorry, based on [2] or devfreq-next
>>>>> would conflict.
>>>>>
>>>>> [1] https://lore.kernel.org/all/20260319091409.998397-1-tianyaxiong@kylinos.cn/
>>>>> [2] https://lore.kernel.org/all/20251216031153.2242306-1-zhangpengjie2@huawei.com/
^ permalink raw reply
* Re: [PATCH] cpufreq: Allocate QoS freq_req objects with policy
From: zhenglifeng (A) @ 2026-03-31 6:44 UTC (permalink / raw)
To: Viresh Kumar, Rafael J. Wysocki, Pierre Gondois
Cc: linux-pm, Vincent Guittot, Sumit Semwal, Zhongqiu Han,
Rafael J. Wysocki, linux-kernel
In-Reply-To: <a293f29d841b86c51f34699c6e717e01858d8ada.1774933424.git.viresh.kumar@linaro.org>
On 3/31/2026 1:03 PM, Viresh Kumar 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>
This looks much neater. Thanks!
Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com>
^ permalink raw reply
* Re: [PATCH v4 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Krzysztof Kozlowski @ 2026-03-31 7:01 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Fabien Parent, Val Packett, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Louis-Alexis Eyraud, Gary Bisson, Julien Massot,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260330083429.359819-2-l.scorcia@gmail.com>
On Mon, Mar 30, 2026 at 09:29:35AM +0100, Luca Leonardo Scorcia wrote:
> - items:
> - enum:
> - mediatek,mt6366-rtc
> @@ -99,9 +107,6 @@ properties:
> - mediatek,mt6366-regulator
> - const: mediatek,mt6358-regulator
>
> - required:
> - - compatible
Not really, this affects existing ABI and might make the child schema
being applied. Basically regulators node can be anything now.
This is definitely not a binding we want. The syntax for parent schema
when listing only compatibles is requiring this compatible. You cannot
have here whatever empty node.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 3/9] regulator: dt-bindings: Add MediaTek MT6392 PMIC
From: Krzysztof Kozlowski @ 2026-03-31 7:04 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Linus Walleij,
Liam Girdwood, Mark Brown, Julien Massot, Gary Bisson,
Louis-Alexis Eyraud, Val Packett, Fabien Parent, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <20260330083429.359819-4-l.scorcia@gmail.com>
On Mon, Mar 30, 2026 at 09:29:37AM +0100, Luca Leonardo Scorcia wrote:
> Add bindings for the regulators found in the MediaTek MT6392 PMIC,
> usually found in board designs using the MediaTek MT8516/MT8167 SoCs.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../regulator/mediatek,mt6392-regulator.yaml | 74 +++++++++++++++++++
> .../regulator/mediatek,mt6392-regulator.h | 24 ++++++
> 2 files changed, 98 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> create mode 100644 include/dt-bindings/regulator/mediatek,mt6392-regulator.h
>
> diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> new file mode 100644
> index 000000000000..24fbaef0e717
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/mediatek,mt6392-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MT6392 regulator
> +
> +description:
> + Regulator node of the PMIC. This node should under the PMIC's device node.
> + MT6392 is a power management system chip containing three buck converters and
> + 23 LDOs. All voltage regulators provided by the PMIC are described as
> + sub-nodes of this node.
> +
So that's a dead code / schema.
Try yourself if it works.
Your parent schema must reference this one for the regulators node.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] cpufreq: Allocate QoS freq_req objects with policy
From: Pierre Gondois @ 2026-03-31 7:03 UTC (permalink / raw)
To: zhenglifeng (A), Viresh Kumar, Rafael J. Wysocki
Cc: linux-pm, Vincent Guittot, Sumit Semwal, Zhongqiu Han,
Rafael J. Wysocki, linux-kernel
In-Reply-To: <fbe74184-98dd-42f8-a851-8a8b5d001f1e@huawei.com>
On 3/31/26 08:44, zhenglifeng (A) wrote:
> On 3/31/2026 1:03 PM, Viresh Kumar 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>
> This looks much neater. Thanks!
>
> Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com>
Thanks for fixing the patch, removing the allocation makes
things much cleaner.
Tested-by: Pierre Gondois <pierre.gondois@arm.com>
^ permalink raw reply
* Re: [PATCH RESEND 1/4] PM / devfreq: Fix possible null pointer issue in devfreq_add_governor()
From: Jie Zhan @ 2026-03-31 7:04 UTC (permalink / raw)
To: Yaxiong Tian, myungjoo.ham, kyungmin.park, cw00.choi, nm
Cc: linux-pm, linux-kernel
In-Reply-To: <20260319091653.1005878-1-tianyaxiong@kylinos.cn>
On 3/19/2026 5:16 PM, Yaxiong Tian wrote:
> When a user removes a governor using devfreq_remove_governor(), if
> the current device is using this governor, devfreq->governor will
> be set to NULL. When the user registers any governor
> using devfreq_add_governor(), since devfreq->governor is NULL, a
> null pointer error occurs in strncmp().
>
> For example: A user loads the userspace gov through a module, then
> a device selects userspace. When unloading the userspace module and
> then loading it again, the null pointer error occurs:
>
> Unable to handle kernel NULL pointer dereference at virtual address
> 0000000000000010
> Mem abort info:
> ESR = 0x0000000096000004
> EC = 0x25: DABT (current EL), IL = 32 bits
> *******************skip *********************
> Call trace:
> __pi_strncmp+0x20/0x1b8
> devfreq_userspace_init+0x1c/0xff8 [governor_userspace]
> do_one_initcall+0x4c/0x278
> do_init_module+0x5c/0x218
> load_module+0x1f1c/0x1fc8
> init_module_from_file+0x8c/0xd0
> __arm64_sys_finit_module+0x220/0x3d8
> invoke_syscall+0x48/0x110
> el0_svc_common.constprop.0+0xbc/0xe8
> do_el0_svc+0x20/0x30
> el0_svc+0x24/0xb8
> el0t_64_sync_handler+0xb8/0xc0
> el0t_64_sync+0x14c/0x150
>
> To fix this issue, modify the relevant logic in devfreq_add_governor():
> Only check whether the new governor matches the existing one when
> devfreq->governor exists. When devfreq->governor is NULL, directly
> select the new governor and perform the DEVFREQ_GOV_START operation.
>
> Fixes: 1b5c1be2c88e ("PM / devfreq: map devfreq drivers to governor using name")
> Signed-off-by: Yaxiong Tian <tianyaxiong@kylinos.cn>
> ---
> drivers/devfreq/devfreq.c | 24 +++++++++++-------------
> 1 file changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 54f0b18536db..63ce6e25abe2 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -1288,23 +1288,21 @@ int devfreq_add_governor(struct devfreq_governor *governor)
> int ret = 0;
> struct device *dev = devfreq->dev.parent;
>
> - if (!strncmp(devfreq->governor->name, governor->name,
> + if (devfreq->governor && !strncmp(devfreq->governor->name, governor->name,
> DEVFREQ_NAME_LEN)) {
Probaly do:
if (!devfreq->governor)
continue;
so as to keep the line short and the "else if (!devfreq->governor) {" below
can be removed.
and also:
if (!strncmp(devfreq->governor->name, governor->name,
DEVFREQ_NAME_LEN))
continue;
so we don't have to indent that much.
> /* The following should never occur */
> - if (devfreq->governor) {
> + dev_warn(dev,
> + "%s: Governor %s already present\n",
> + __func__, devfreq->governor->name);
> + ret = devfreq->governor->event_handler(devfreq,
> + DEVFREQ_GOV_STOP, NULL);
> + if (ret) {
> dev_warn(dev,
> - "%s: Governor %s already present\n",
> - __func__, devfreq->governor->name);
> - ret = devfreq->governor->event_handler(devfreq,
> - DEVFREQ_GOV_STOP, NULL);
> - if (ret) {
> - dev_warn(dev,
> - "%s: Governor %s stop = %d\n",
> - __func__,
> - devfreq->governor->name, ret);
> - }
> - /* Fall through */
> + "%s: Governor %s stop = %d\n",
> + __func__,
> + devfreq->governor->name, ret);
> }
> + } else if (!devfreq->governor) {
> devfreq->governor = governor;
> ret = devfreq->governor->event_handler(devfreq,
> DEVFREQ_GOV_START, NULL);
^ permalink raw reply
* Re: [PATCH RESEND 2/4] PM / devfreq: Fix available_governors_show() when no governor is set
From: Jie Zhan @ 2026-03-31 7:08 UTC (permalink / raw)
To: Yaxiong Tian, myungjoo.ham, kyungmin.park, cw00.choi, nm
Cc: linux-pm, linux-kernel
In-Reply-To: <20260319091701.1006345-1-tianyaxiong@kylinos.cn>
On 3/19/2026 5:17 PM, Yaxiong Tian wrote:
> Since devfreq_remove_governor() may clear the device's current governor
> in certain situations, while governors actually exist independently of
> the device, directly returning EINVAL in this case is inaccurate.
>
> To fix this issue, remove this check and use df->governor for validity
> verification in the following code.
>
> Fixes: 483d557ee9a3 ("PM / devfreq: Clean up the devfreq instance name in sysfs attr")
> Signed-off-by: Yaxiong Tian <tianyaxiong@kylinos.cn>
LGTM
Reviewed-by: Jie Zhan <zhanjie9@hisilicon.com>
> ---
> drivers/devfreq/devfreq.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 63ce6e25abe2..0bf320123e3a 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -1504,16 +1504,13 @@ static ssize_t available_governors_show(struct device *d,
> struct devfreq *df = to_devfreq(d);
> ssize_t count = 0;
>
> - if (!df->governor)
> - return -EINVAL;
> -
> mutex_lock(&devfreq_list_lock);
>
> /*
> * The devfreq with immutable governor (e.g., passive) shows
> * only own governor.
> */
> - if (IS_SUPPORTED_FLAG(df->governor->flags, IMMUTABLE)) {
> + if (df->governor && IS_SUPPORTED_FLAG(df->governor->flags, IMMUTABLE)) {
> count = scnprintf(&buf[count], DEVFREQ_NAME_LEN,
> "%s ", df->governor->name);
> /*
^ permalink raw reply
* Re: [PATCH] cpufreq: Allocate QoS freq_req objects with policy
From: Zhongqiu Han @ 2026-03-31 7:10 UTC (permalink / raw)
To: Viresh Kumar, Rafael J. Wysocki, Pierre Gondois, Lifeng Zheng
Cc: linux-pm, Vincent Guittot, Sumit Semwal, Rafael J. Wysocki,
linux-kernel, zhongqiu.han
In-Reply-To: <a293f29d841b86c51f34699c6e717e01858d8ada.1774933424.git.viresh.kumar@linaro.org>
On 3/31/2026 1:03 PM, Viresh Kumar 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>
Thanks for the elegant solution. It looks good to me.
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
> ---
> 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;
--
Thx and BRs,
Zhongqiu Han
^ permalink raw reply
* Re: [PATCH RESEND 3/4] PM / devfreq: Fix governor_store() failing when device has no current governor
From: Jie Zhan @ 2026-03-31 7:16 UTC (permalink / raw)
To: Yaxiong Tian, myungjoo.ham, kyungmin.park, cw00.choi, nm
Cc: linux-pm, linux-kernel
In-Reply-To: <20260319091710.1006814-1-tianyaxiong@kylinos.cn>
On 3/19/2026 5:17 PM, Yaxiong Tian wrote:
> Since devfreq_remove_governor() may clear the device's current governor
> in certain situations, while governors actually exist independently
> of the device, directly returning EINVAL in this case is inaccurate.
>
> To fix this issue, remove this check and add relevant logic for when
> df->governor is NULL.
>
> Fixes: 483d557ee9a3 ("PM / devfreq: Clean up the devfreq instance name in sysfs attr")
> Signed-off-by: Yaxiong Tian <tianyaxiong@kylinos.cn>
> ---
> drivers/devfreq/devfreq.c | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 0bf320123e3a..4a312f3c2421 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -1425,9 +1425,6 @@ static ssize_t governor_store(struct device *dev, struct device_attribute *attr,
> char str_governor[DEVFREQ_NAME_LEN + 1];
> const struct devfreq_governor *governor, *prev_governor;
>
> - if (!df->governor)
> - return -EINVAL;
> -
> ret = sscanf(buf, "%" __stringify(DEVFREQ_NAME_LEN) "s", str_governor);
> if (ret != 1)
> return -EINVAL;
> @@ -1438,6 +1435,18 @@ static ssize_t governor_store(struct device *dev, struct device_attribute *attr,
> ret = PTR_ERR(governor);
> goto out;
> }
> +
> + if (!df->governor) {
> + df->governor = governor;
> + ret = df->governor->event_handler(df, DEVFREQ_GOV_START, NULL);
> + if (ret) {
> + dev_warn(dev, "%s: Governor %s not started(%d)\n",
> + __func__, df->governor->name, ret);
> + df->governor = NULL;
> + }
> + goto out;
> + }
> +
The sequence that starts the governor, and stops, and then re-starts looks
quite weird.
Can you do a NULL pointer check before the IMMUTABLE flag check and
stopping governor, rather than this?
> if (df->governor == governor) {
> ret = 0;
> goto out;
^ permalink raw reply
* Re: [PATCH RESEND 4/4] PM / devfreq: Optimize error return value of governor_show()
From: Jie Zhan @ 2026-03-31 7:21 UTC (permalink / raw)
To: Yaxiong Tian, myungjoo.ham, kyungmin.park, cw00.choi, nm
Cc: linux-pm, linux-kernel
In-Reply-To: <20260319091719.1007244-1-tianyaxiong@kylinos.cn>
On 3/19/2026 5:17 PM, Yaxiong Tian wrote:
> When df->governor is NULL, governor_show() returns -EINVAL, which
> confuses users.
>
> To fix this issue, return -ENOENT to indicate that no governor is
> currently set for the device.
>
> Signed-off-by: Yaxiong Tian <tianyaxiong@kylinos.cn>
> ---
> drivers/devfreq/devfreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 4a312f3c2421..7cc60711fafd 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -1412,7 +1412,7 @@ static ssize_t governor_show(struct device *dev,
> struct devfreq *df = to_devfreq(dev);
>
> if (!df->governor)
> - return -EINVAL;
> + return -ENOENT;
What about -ENODEV?
>
> return sprintf(buf, "%s\n", df->governor->name);
> }
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: power: reset: cortina,gemini-power-controller: convert to DT schema
From: Krzysztof Kozlowski @ 2026-03-31 7:22 UTC (permalink / raw)
To: Khushal Chitturi
Cc: sre, robh, krzk+dt, conor+dt, ulli.kroll, linusw, daniel.baluta,
simona.toaca, d-gole, m-chawdhry, linux-pm, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260330110135.10316-2-khushalchitturi@gmail.com>
On Mon, Mar 30, 2026 at 04:31:34PM +0530, Khushal Chitturi wrote:
> Convert the Cortina Systems Gemini Poweroff Controller bindings to
> DT schema.
>
> Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/2] ARM: dts: gemini: Rename power controller node to poweroff
From: Krzysztof Kozlowski @ 2026-03-31 7:22 UTC (permalink / raw)
To: Khushal Chitturi
Cc: sre, robh, krzk+dt, conor+dt, ulli.kroll, linusw, daniel.baluta,
simona.toaca, d-gole, m-chawdhry, linux-pm, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260330110135.10316-3-khushalchitturi@gmail.com>
On Mon, Mar 30, 2026 at 04:31:35PM +0530, Khushal Chitturi wrote:
> Update the node name for the Cortina Gemini power controller from
> power-controller to poweroff since node "power controller" is
> reserved for power domain controller.
>
> Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] cpufreq: cleanup dead code in Kconfig
From: Julian Braha @ 2026-03-31 7:42 UTC (permalink / raw)
To: rafael, viresh.kumar; +Cc: linux-pm, linux-kernel, Julian Braha
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
--
2.51.2
^ permalink raw reply related
* [PATCH] cpuidle: cleanup dead dependencies on CPU_IDLE in Kconfig
From: Julian Braha @ 2026-03-31 7:49 UTC (permalink / raw)
To: christian.loehle, daniel.lezcano, rafael
Cc: linux-pm, linux-kernel, Julian Braha
The Kconfig in the parent directory already has the first 'if CPU_IDLE'
gating the inclusion of this Kconfig, meaning that the 'depends on CPUIDLE'
statements in these config options are effectively dead code.
I propose leaving the 'if CPU_IDLE...endif' condition, and removing these
individual 'depends on' statements in Kconfig.mips and Kconfig.powerpc
This dead code was found by kconfirm, a static analysis tool for Kconfig.
Signed-off-by: Julian Braha <julianbraha@gmail.com>
---
drivers/cpuidle/Kconfig | 2 +-
drivers/cpuidle/Kconfig.mips | 2 +-
drivers/cpuidle/Kconfig.powerpc | 2 --
3 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
index cac5997dca50..d6d8386d3f02 100644
--- a/drivers/cpuidle/Kconfig
+++ b/drivers/cpuidle/Kconfig
@@ -81,7 +81,7 @@ config HALTPOLL_CPUIDLE
before halting in the guest (more efficient than polling in the
host via halt_poll_ns for some scenarios).
-endif
+endif # CPU_IDLE
config ARCH_NEEDS_CPU_IDLE_COUPLED
def_bool n
diff --git a/drivers/cpuidle/Kconfig.mips b/drivers/cpuidle/Kconfig.mips
index c3c011af4a35..88728b2b4ea0 100644
--- a/drivers/cpuidle/Kconfig.mips
+++ b/drivers/cpuidle/Kconfig.mips
@@ -4,7 +4,7 @@
#
config MIPS_CPS_CPUIDLE
bool "CPU Idle driver for MIPS CPS platforms"
- depends on CPU_IDLE && MIPS_CPS
+ depends on MIPS_CPS
depends on SYS_SUPPORTS_MIPS_CPS
select ARCH_NEEDS_CPU_IDLE_COUPLED if MIPS_MT || CPU_MIPSR6
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
diff --git a/drivers/cpuidle/Kconfig.powerpc b/drivers/cpuidle/Kconfig.powerpc
index a797a02b7b6f..1931ac8faffb 100644
--- a/drivers/cpuidle/Kconfig.powerpc
+++ b/drivers/cpuidle/Kconfig.powerpc
@@ -4,7 +4,6 @@
#
config PSERIES_CPUIDLE
bool "Cpuidle driver for pSeries platforms"
- depends on CPU_IDLE
depends on PPC_PSERIES
default y
help
@@ -13,7 +12,6 @@ config PSERIES_CPUIDLE
config POWERNV_CPUIDLE
bool "Cpuidle driver for powernv platforms"
- depends on CPU_IDLE
depends on PPC_POWERNV
default y
help
--
2.51.2
^ permalink raw reply related
* Re: [PATCH RESEND 1/4] PM / devfreq: Fix possible null pointer issue in devfreq_add_governor()
From: Yaxiong Tian @ 2026-03-31 7:49 UTC (permalink / raw)
To: Jie Zhan, myungjoo.ham, kyungmin.park, cw00.choi, nm
Cc: linux-pm, linux-kernel
In-Reply-To: <f167d24d-73f9-4463-889e-89fb9f1e4a1a@hisilicon.com>
在 2026/3/31 15:04, Jie Zhan 写道:
>
> On 3/19/2026 5:16 PM, Yaxiong Tian wrote:
>> When a user removes a governor using devfreq_remove_governor(), if
>> the current device is using this governor, devfreq->governor will
>> be set to NULL. When the user registers any governor
>> using devfreq_add_governor(), since devfreq->governor is NULL, a
>> null pointer error occurs in strncmp().
>>
>> For example: A user loads the userspace gov through a module, then
>> a device selects userspace. When unloading the userspace module and
>> then loading it again, the null pointer error occurs:
>>
>> Unable to handle kernel NULL pointer dereference at virtual address
>> 0000000000000010
>> Mem abort info:
>> ESR = 0x0000000096000004
>> EC = 0x25: DABT (current EL), IL = 32 bits
>> *******************skip *********************
>> Call trace:
>> __pi_strncmp+0x20/0x1b8
>> devfreq_userspace_init+0x1c/0xff8 [governor_userspace]
>> do_one_initcall+0x4c/0x278
>> do_init_module+0x5c/0x218
>> load_module+0x1f1c/0x1fc8
>> init_module_from_file+0x8c/0xd0
>> __arm64_sys_finit_module+0x220/0x3d8
>> invoke_syscall+0x48/0x110
>> el0_svc_common.constprop.0+0xbc/0xe8
>> do_el0_svc+0x20/0x30
>> el0_svc+0x24/0xb8
>> el0t_64_sync_handler+0xb8/0xc0
>> el0t_64_sync+0x14c/0x150
>>
>> To fix this issue, modify the relevant logic in devfreq_add_governor():
>> Only check whether the new governor matches the existing one when
>> devfreq->governor exists. When devfreq->governor is NULL, directly
>> select the new governor and perform the DEVFREQ_GOV_START operation.
>>
>> Fixes: 1b5c1be2c88e ("PM / devfreq: map devfreq drivers to governor using name")
>> Signed-off-by: Yaxiong Tian <tianyaxiong@kylinos.cn>
>> ---
>> drivers/devfreq/devfreq.c | 24 +++++++++++-------------
>> 1 file changed, 11 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>> index 54f0b18536db..63ce6e25abe2 100644
>> --- a/drivers/devfreq/devfreq.c
>> +++ b/drivers/devfreq/devfreq.c
>> @@ -1288,23 +1288,21 @@ int devfreq_add_governor(struct devfreq_governor *governor)
>> int ret = 0;
>> struct device *dev = devfreq->dev.parent;
>>
>> - if (!strncmp(devfreq->governor->name, governor->name,
>> + if (devfreq->governor && !strncmp(devfreq->governor->name, governor->name,
>> DEVFREQ_NAME_LEN)) {
> Probaly do:
> if (!devfreq->governor)
> continue;
> so as to keep the line short and the "else if (!devfreq->governor) {" below
> can be removed.
If that's the case, a dev without a governor would not be able to add a
new governor.
>
> and also:
> if (!strncmp(devfreq->governor->name, governor->name,
> DEVFREQ_NAME_LEN))
> continue;
> so we don't have to indent that much.
Currently, governor->name can be set arbitrarily, so duplicate names are
possible.
But they could still be two different governors. Leaving it unchanged
seems fine to me.
>
>> /* The following should never occur */
>> - if (devfreq->governor) {
>> + dev_warn(dev,
>> + "%s: Governor %s already present\n",
>> + __func__, devfreq->governor->name);
>> + ret = devfreq->governor->event_handler(devfreq,
>> + DEVFREQ_GOV_STOP, NULL);
>> + if (ret) {
>> dev_warn(dev,
>> - "%s: Governor %s already present\n",
>> - __func__, devfreq->governor->name);
>> - ret = devfreq->governor->event_handler(devfreq,
>> - DEVFREQ_GOV_STOP, NULL);
>> - if (ret) {
>> - dev_warn(dev,
>> - "%s: Governor %s stop = %d\n",
>> - __func__,
>> - devfreq->governor->name, ret);
>> - }
>> - /* Fall through */
>> + "%s: Governor %s stop = %d\n",
>> + __func__,
>> + devfreq->governor->name, ret);
>> }
>> + } else if (!devfreq->governor) {
>> devfreq->governor = governor;
>> ret = devfreq->governor->event_handler(devfreq,
>> DEVFREQ_GOV_START, NULL);
^ permalink raw reply
* Re: [PATCH 2/2] interconnect: qcom: add Hawi interconnect provider driver
From: Konrad Dybcio @ 2026-03-31 7:52 UTC (permalink / raw)
To: Vivek Aknurwar, Georgi Djakov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-pm, devicetree, linux-kernel, Mike Tipton
In-Reply-To: <20260330-icc-hawi-v1-2-4b54a9e7d38c@oss.qualcomm.com>
On 3/31/26 2:40 AM, Vivek Aknurwar wrote:
> Add driver for the Qualcomm interconnect buses found in Hawi
> based platforms. The topology consists of several NoCs that are
> controlled by a remote processor that collects the aggregated
> bandwidth for each master-slave pairs.
>
> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH] cpufreq: cleanup dead code in Kconfig
From: Viresh Kumar @ 2026-03-31 7:55 UTC (permalink / raw)
To: Julian Braha; +Cc: rafael, linux-pm, linux-kernel
In-Reply-To: <20260331074242.39986-1-julianbraha@gmail.com>
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>
--
viresh
^ 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