Implemented CPUFREQ_CHANGE_POLICY notification in cpufreq subsystem.
This enhancement allows kernel modules to be notified when a CPU frequency
policy is modified, facilitating more integrated system management.
The notification is dispatched after a successful governor switch during
policy updates.

Signed-off-by: Tony W Wang-oc <TonyWWang-oc@zhaoxin.com>
---
 drivers/cpufreq/cpufreq.c | 2 ++
 include/linux/cpufreq.h   | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index a7a69f4d7675..b35fed93bca4 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -2707,6 +2707,8 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy,
 		ret = cpufreq_start_governor(policy);
 		if (!ret) {
 			pr_debug("governor change\n");
+			blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
+						     CPUFREQ_CHANGE_POLICY, policy);
 			return 0;
 		}
 		cpufreq_exit_governor(policy);
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index cc894fc38971..b1cc9138e801 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -528,6 +528,7 @@ static inline void cpufreq_resume(void) {}
 /* Policy Notifiers  */
 #define CPUFREQ_CREATE_POLICY		(0)
 #define CPUFREQ_REMOVE_POLICY		(1)
+#define CPUFREQ_CHANGE_POLICY		(2)
 
 #ifdef CONFIG_CPU_FREQ
 int cpufreq_register_notifier(struct notifier_block *nb, unsigned int list);
-- 
2.25.1

On 20-01-26, 17:24, Tony W Wang-oc wrote:
> Implemented CPUFREQ_CHANGE_POLICY notification in cpufreq subsystem.
> This enhancement allows kernel modules to be notified when a CPU frequency
> policy is modified, facilitating more integrated system management.
> The notification is dispatched after a successful governor switch during
> policy updates.
> 
> Signed-off-by: Tony W Wang-oc <TonyWWang-oc@zhaoxin.com>
> ---
>  drivers/cpufreq/cpufreq.c | 2 ++
>  include/linux/cpufreq.h   | 1 +
>  2 files changed, 3 insertions(+)

Who is using this stuff ? Please explain why you need this and how you
are going to use it. I don't think it is a great idea, but I still
want to see what you are doing in the first place.

-- 
viresh

On 2026/1/21 13:51, Viresh Kumar wrote:
> 
> 
> 
> On 20-01-26, 17:24, Tony W Wang-oc wrote:
>> Implemented CPUFREQ_CHANGE_POLICY notification in cpufreq subsystem.
>> This enhancement allows kernel modules to be notified when a CPU frequency
>> policy is modified, facilitating more integrated system management.
>> The notification is dispatched after a successful governor switch during
>> policy updates.
>>
>> Signed-off-by: Tony W Wang-oc <TonyWWang-oc@zhaoxin.com>
>> ---
>>   drivers/cpufreq/cpufreq.c | 2 ++
>>   include/linux/cpufreq.h   | 1 +
>>   2 files changed, 3 insertions(+)
> 
> Who is using this stuff ? Please explain why you need this and how you
> are going to use it. I don't think it is a great idea, but I still
> want to see what you are doing in the first place.
> 

The expectation is to register a notifier of type 
CPUFREQ_POLICY_NOTIFIER via cpufreq_register_notifier in one of our 
drivers. The notifier callback will configure Zhaoxin registers to 
different values based on the different cpufreq governors when the event 
is CPUFREQ_GOVERNOR_CHANGE, thereby allowing the Zhaoxin hardware to 
adopt different power management strategies.

Sincerely!
TonyWWang-oc

On 21-01-26, 16:37, Tony W Wang-oc wrote:
> The expectation is to register a notifier of type CPUFREQ_POLICY_NOTIFIER
> via cpufreq_register_notifier in one of our drivers. The notifier callback
> will configure Zhaoxin registers to different values based on the different
> cpufreq governors when the event is CPUFREQ_GOVERNOR_CHANGE, thereby
> allowing the Zhaoxin hardware to adopt different power management
> strategies.

Firstly, for this change to be acceptable, we would need your upstream
platform specific changes as well.

And then I am still not sure if this it the right way to solve this
problem.

-- 
viresh

On 2026/1/21 18:02, Viresh Kumar wrote:
> 
> 
> On 21-01-26, 16:37, Tony W Wang-oc wrote:
>> The expectation is to register a notifier of type CPUFREQ_POLICY_NOTIFIER
>> via cpufreq_register_notifier in one of our drivers. The notifier callback
>> will configure Zhaoxin registers to different values based on the different
>> cpufreq governors when the event is CPUFREQ_GOVERNOR_CHANGE, thereby
>> allowing the Zhaoxin hardware to adopt different power management
>> strategies.
> 
> Firstly, for this change to be acceptable, we would need your upstream
> platform specific changes as well.
> 
> And then I am still not sure if this it the right way to solve this
> problem.
> 
The driver for Zhaoxin using this patch still needs further verification 
on actual platforms; it cannot yet be submitted to the mainline. 
However, we have already verified that this patch itself has no issues 
with Zhaoxin's driver.

 From the perspective of this patch itself, we think it provides the 
capability to perceive changes in cpufreq policy for all modules 
concerned, and it can serve not just this Zhaoxin driver.

Sincerely
TonyWWang-oc

On 22-01-26, 10:13, Tony W Wang-oc wrote:
> The driver for Zhaoxin using this patch still needs further verification on
> actual platforms; it cannot yet be submitted to the mainline. However, we
> have already verified that this patch itself has no issues with Zhaoxin's
> driver.

Upstream features are only allowed if we have an upstream user of the
same. Can't take this without a user.

-- 
viresh

On 2026/1/22 13:26, Viresh Kumar wrote:
> 
> 
> 
> On 22-01-26, 10:13, Tony W Wang-oc wrote:
>> The driver for Zhaoxin using this patch still needs further verification on
>> actual platforms; it cannot yet be submitted to the mainline. However, we
>> have already verified that this patch itself has no issues with Zhaoxin's
>> driver.
> 
> Upstream features are only allowed if we have an upstream user of the
> same. Can't take this without a user.
> 

Okay, thank you for your explanation.

Sincerely
TonyWWang-oc