drivers/cpufreq/scmi-cpufreq.c | 25 ++++++++++++++++++------- drivers/firmware/arm_scmi/perf.c | 37 +++++++++++++++++++------------------ include/linux/scmi_protocol.h | 5 ++++- 3 files changed, 41 insertions(+), 26 deletions(-)
PERFORMANCE_NOTIFY_LIMITS and PERFORMANCE_NOTIFY_LEVEL are optional
commands. If use these commands on platforms that not support the two,
there is error log:
SCMI Notifications - Failed to ENABLE events for key:13000008 !
scmi-cpufreq scmi_dev.4: failed to register for limits change notifier for domain 8
If platforms not support perf notification, saving some cpu cycles
by introducing notify_supported ops.
While at here, patch 1 is a typo fix when doing the patchset.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Peng Fan (3):
firmware: arm_scmi: Fix typo for scmi_perf_proto_ops
firmware: arm_scmi: perf: Add notify_supported for scmi_perf_proto_ops
cpufreq: scmi-cpufreq: Enable perf limits notification only supported
drivers/cpufreq/scmi-cpufreq.c | 25 ++++++++++++++++++-------
drivers/firmware/arm_scmi/perf.c | 37 +++++++++++++++++++------------------
include/linux/scmi_protocol.h | 5 ++++-
3 files changed, 41 insertions(+), 26 deletions(-)
---
base-commit: 19a60293b9925080d97f22f122aca3fc46dadaf9
change-id: 20250611-scmi-perf-a0ded8a5a303
Best regards,
--
Peng Fan <peng.fan@nxp.com>
On Wed, Jun 11, 2025 at 03:52:42PM +0800, Peng Fan (OSS) wrote: > PERFORMANCE_NOTIFY_LIMITS and PERFORMANCE_NOTIFY_LEVEL are optional > commands. If use these commands on platforms that not support the two, > there is error log: > SCMI Notifications - Failed to ENABLE events for key:13000008 ! > scmi-cpufreq scmi_dev.4: failed to register for limits change notifier for domain 8 > I wonder if it makes sense to quiesce the warnings from the core if the platform doesn't support notifications. I prefer to not add if notification supported in all the protocols. If the interface can return -EOPNOTSUPP(equivalent to SCMI_ERR_SUPPORT), the caller must handle it appropriately(i.e. continue if it can handle absence of notification or propagate error). Cristian, Thoughts/opinions ? > If platforms not support perf notification, saving some cpu cycles > by introducing notify_supported ops. > Sure, makes sense to improve where ever possible. > While at here, patch 1 is a typo fix when doing the patchset. > This one looks OK. -- Regards, Sudeep
On Wed, Jun 11, 2025 at 01:17:11PM +0100, Sudeep Holla wrote:
> On Wed, Jun 11, 2025 at 03:52:42PM +0800, Peng Fan (OSS) wrote:
> > PERFORMANCE_NOTIFY_LIMITS and PERFORMANCE_NOTIFY_LEVEL are optional
> > commands. If use these commands on platforms that not support the two,
> > there is error log:
> > SCMI Notifications - Failed to ENABLE events for key:13000008 !
> > scmi-cpufreq scmi_dev.4: failed to register for limits change notifier for domain 8
> >
>
Hi,
I had a quick look/refresh to this stuff from years ago...
...wont be so short to explain :P
In general when you register a notifier_block for some SCMI events,
the assumption was that a driver using proto_X_ops could want to register
NOT only for proto_X events BUT also for other protos...in such a case you
are NOT guaranteed that such other proto_Y was initialized when your
driver probes and tries to register the notifier...indeed it could be
that such proto_Y could be a module that has still to be loaded !
...in this scenario you can end-up quickly in a hell of probe-dependency
if you write a driver asking for SCMI events that can or cannot be still
readily available when the driver probes...
....so the decision was to simply place such notifier registration requests
on hold on a pending list...whenever the needed missing protocol is
loaded/inialized the notifier registration is completed...if the proto_Y
never arrives nothing happens...and your driver caller can probe
successfully anyway...
This means in such a corner-case the notifier registration is sort of
asynchonous and eventual errors detected later, when the protocol is
finally initialized and notifiers finalized, cannot be easily reported
(BUT I think we could improve on this ... thinking about this...)
...BUT....
....this is NOT our case NOR the most common case...the usual scenario,
like cpufreq, is that a driver using proto_X_ops tries to register for
that same proto_X events and in such a case we can detect that such
domain is unsupported and fail while avoiding to send any message indeed....
....so....:P...while I was going through this rabbit-hole....this issues
started to feel familiar...O_o....
... indeed I realized that the function that you (Peng) now invoke to
set the per-domain perf_limit_notify flag was introduced just for these
reasons to check and avoid such situation for all protocols in the core:
commit 8733e86a80f5a7abb7b4b6ca3f417b32c3eb68e3
Author: Cristian Marussi <cristian.marussi@arm.com>
Date: Mon Feb 12 12:32:23 2024 +0000
firmware: arm_scmi: Check for notification support
When registering protocol events, use the optional .is_notify_supported
callback provided by the protocol to check if that specific notification
type is available for that particular resource on the running system,
marking it as unsupported otherwise.
Then, when a notification enable request is received, return an error if
it was previously marked as unsuppported, so avoiding to send a needless
notification enable command and check the returned value for failure.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20240212123233.1230090-2-cristian.marussi@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
...so my suspect is that we are ALREADY avoiding to send unneeded
messages when a domain does NOT support notifications for ALL
protocols...it is just that we are a bit too noisy...
@Peng do you observe the message being sent instead ? (so maybe the
above has a bug...) or it is just the message ?
> I wonder if it makes sense to quiesce the warnings from the core if the
> platform doesn't support notifications. I prefer to not add if notification
> supported in all the protocols.
>
yes
> If the interface can return -EOPNOTSUPP(equivalent to SCMI_ERR_SUPPORT),
> the caller must handle it appropriately(i.e. continue if it can handle
> absence of notification or propagate error).
>
This is what we do indeed....
> Cristian, Thoughts/opinions ?
>
too many :D ....
> > If platforms not support perf notification, saving some cpu cycles
> > by introducing notify_supported ops.
> >
>
> Sure, makes sense to improve where ever possible.
>
Should be solved as above...
Thanks,
Cristian
On Wed, Jun 11, 2025 at 02:33:37PM +0100, Cristian Marussi wrote: >On Wed, Jun 11, 2025 at 01:17:11PM +0100, Sudeep Holla wrote: >> On Wed, Jun 11, 2025 at 03:52:42PM +0800, Peng Fan (OSS) wrote: >> > PERFORMANCE_NOTIFY_LIMITS and PERFORMANCE_NOTIFY_LEVEL are optional >> > commands. If use these commands on platforms that not support the two, >> > there is error log: >> > SCMI Notifications - Failed to ENABLE events for key:13000008 ! >> > scmi-cpufreq scmi_dev.4: failed to register for limits change notifier for domain 8 >> > >> > >Hi, > >I had a quick look/refresh to this stuff from years ago... > >...wont be so short to explain :P > >In general when you register a notifier_block for some SCMI events, >the assumption was that a driver using proto_X_ops could want to register >NOT only for proto_X events BUT also for other protos...in such a case you >are NOT guaranteed that such other proto_Y was initialized when your >driver probes and tries to register the notifier...indeed it could be >that such proto_Y could be a module that has still to be loaded ! > >...in this scenario you can end-up quickly in a hell of probe-dependency >if you write a driver asking for SCMI events that can or cannot be still >readily available when the driver probes... > >....so the decision was to simply place such notifier registration requests >on hold on a pending list...whenever the needed missing protocol is >loaded/inialized the notifier registration is completed...if the proto_Y >never arrives nothing happens...and your driver caller can probe >successfully anyway... > >This means in such a corner-case the notifier registration is sort of >asynchonous and eventual errors detected later, when the protocol is >finally initialized and notifiers finalized, cannot be easily reported >(BUT I think we could improve on this ... thinking about this...) > >...BUT.... > >....this is NOT our case NOR the most common case...the usual scenario, >like cpufreq, is that a driver using proto_X_ops tries to register for >that same proto_X events and in such a case we can detect that such >domain is unsupported and fail while avoiding to send any message indeed.... > >....so....:P...while I was going through this rabbit-hole....this issues >started to feel familiar...O_o.... > >... indeed I realized that the function that you (Peng) now invoke to >set the per-domain perf_limit_notify flag was introduced just for these >reasons to check and avoid such situation for all protocols in the core: > > >commit 8733e86a80f5a7abb7b4b6ca3f417b32c3eb68e3 >Author: Cristian Marussi <cristian.marussi@arm.com> >Date: Mon Feb 12 12:32:23 2024 +0000 > > firmware: arm_scmi: Check for notification support > > When registering protocol events, use the optional .is_notify_supported > callback provided by the protocol to check if that specific notification > type is available for that particular resource on the running system, > marking it as unsupported otherwise. > > Then, when a notification enable request is received, return an error if > it was previously marked as unsuppported, so avoiding to send a needless > notification enable command and check the returned value for failure. > > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> > Link: https://lore.kernel.org/r/20240212123233.1230090-2-cristian.marussi@arm.com > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > >...so my suspect is that we are ALREADY avoiding to send unneeded >messages when a domain does NOT support notifications for ALL >protocols...it is just that we are a bit too noisy... > >@Peng do you observe the message being sent instead ? (so maybe the >above has a bug...) or it is just the message ? Just the message. arm-scmi arm-scmi.0.auto: SCMI Notifications - Notification NOT supported - proto_id:19 evt_id:0 src_id:8 SCMI Notifications - Failed to ENABLE events for key:13000008 ! scmi-cpufreq scmi_dev.4: failed to register for limits change notifier for domain 8 It just make user has a feeling that there must be something wrong, especially those not know the internals. And from the error message, "Failed to ENABLE events for key..", we not know which protocol, and whether notification supported. I was thinking to propogate the error value, but __scmi_enable_evt always use -EINVAL if not success. > >> I wonder if it makes sense to quiesce the warnings from the core if the >> platform doesn't support notifications. If not quiesce, we might need to make it clear from the error message, saying whether X events are supported for Y protocols or not, not just a "Failed to ENABLE events for key.." Thanks, Peng
On Thu, Jun 12, 2025 at 11:43:52AM +0800, Peng Fan wrote: > On Wed, Jun 11, 2025 at 02:33:37PM +0100, Cristian Marussi wrote: > >On Wed, Jun 11, 2025 at 01:17:11PM +0100, Sudeep Holla wrote: > >> On Wed, Jun 11, 2025 at 03:52:42PM +0800, Peng Fan (OSS) wrote: > >> > PERFORMANCE_NOTIFY_LIMITS and PERFORMANCE_NOTIFY_LEVEL are optional > >> > commands. If use these commands on platforms that not support the two, > >> > there is error log: > >> > SCMI Notifications - Failed to ENABLE events for key:13000008 ! > >> > scmi-cpufreq scmi_dev.4: failed to register for limits change notifier for domain 8 > >> > > >> > > > >Hi, > > > >I had a quick look/refresh to this stuff from years ago... > > > >...wont be so short to explain :P > > > >In general when you register a notifier_block for some SCMI events, > >the assumption was that a driver using proto_X_ops could want to register > >NOT only for proto_X events BUT also for other protos...in such a case you > >are NOT guaranteed that such other proto_Y was initialized when your > >driver probes and tries to register the notifier...indeed it could be > >that such proto_Y could be a module that has still to be loaded ! > > > >...in this scenario you can end-up quickly in a hell of probe-dependency > >if you write a driver asking for SCMI events that can or cannot be still > >readily available when the driver probes... > > > >....so the decision was to simply place such notifier registration requests > >on hold on a pending list...whenever the needed missing protocol is > >loaded/inialized the notifier registration is completed...if the proto_Y > >never arrives nothing happens...and your driver caller can probe > >successfully anyway... > > > >This means in such a corner-case the notifier registration is sort of > >asynchonous and eventual errors detected later, when the protocol is > >finally initialized and notifiers finalized, cannot be easily reported > >(BUT I think we could improve on this ... thinking about this...) > > > >...BUT.... > > > >....this is NOT our case NOR the most common case...the usual scenario, > >like cpufreq, is that a driver using proto_X_ops tries to register for > >that same proto_X events and in such a case we can detect that such > >domain is unsupported and fail while avoiding to send any message indeed.... > > > >....so....:P...while I was going through this rabbit-hole....this issues > >started to feel familiar...O_o.... > > > >... indeed I realized that the function that you (Peng) now invoke to > >set the per-domain perf_limit_notify flag was introduced just for these > >reasons to check and avoid such situation for all protocols in the core: > > > > > >commit 8733e86a80f5a7abb7b4b6ca3f417b32c3eb68e3 > >Author: Cristian Marussi <cristian.marussi@arm.com> > >Date: Mon Feb 12 12:32:23 2024 +0000 > > > > firmware: arm_scmi: Check for notification support > > > > When registering protocol events, use the optional .is_notify_supported > > callback provided by the protocol to check if that specific notification > > type is available for that particular resource on the running system, > > marking it as unsupported otherwise. > > > > Then, when a notification enable request is received, return an error if > > it was previously marked as unsuppported, so avoiding to send a needless > > notification enable command and check the returned value for failure. > > > > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> > > Link: https://lore.kernel.org/r/20240212123233.1230090-2-cristian.marussi@arm.com > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > > > > >...so my suspect is that we are ALREADY avoiding to send unneeded > >messages when a domain does NOT support notifications for ALL > >protocols...it is just that we are a bit too noisy... > > > >@Peng do you observe the message being sent instead ? (so maybe the > >above has a bug...) or it is just the message ? > > Just the message. > > arm-scmi arm-scmi.0.auto: SCMI Notifications - Notification NOT supported - proto_id:19 evt_id:0 src_id:8 > SCMI Notifications - Failed to ENABLE events for key:13000008 ! > scmi-cpufreq scmi_dev.4: failed to register for limits change notifier for domain 8 > > It just make user has a feeling that there must be something wrong, especially > those not know the internals. Yes indeed it is too much noisy... > > And from the error message, "Failed to ENABLE events for key..", we not > know which protocol, and whether notification supported. > > I was thinking to propogate the error value, but __scmi_enable_evt > always use -EINVAL if not success. > I suppose, if you want also to save cycles that you could mark internally a protocol, at init time, as NOT suporting notifs (if you can detect that no domain is supported OR the related notfs commands are NOT available) and then bailing out early with -ENOTOPSUPP when trying to register a new notifier (amd muting all the errs to dbgs....) so that the caller can warn if wanted or not... > > > >> I wonder if it makes sense to quiesce the warnings from the core if the > >> platform doesn't support notifications. > > If not quiesce, we might need to make it clear from the error message, > saying whether X events are supported for Y protocols or not, not just > a "Failed to ENABLE events for key.." > Yes that was a very early and primitve errors message of mine...my bad :D Thanks, Cristian
Hi Cristian,
On Thu, Jun 12, 2025 at 11:31:01AM +0100, Cristian Marussi wrote:
>On Thu, Jun 12, 2025 at 11:43:52AM +0800, Peng Fan wrote:
>> On Wed, Jun 11, 2025 at 02:33:37PM +0100, Cristian Marussi wrote:
>> >On Wed, Jun 11, 2025 at 01:17:11PM +0100, Sudeep Holla wrote:
>> >> On Wed, Jun 11, 2025 at 03:52:42PM +0800, Peng Fan (OSS) wrote:
>> >> > PERFORMANCE_NOTIFY_LIMITS and PERFORMANCE_NOTIFY_LEVEL are optional
>> >> > commands. If use these commands on platforms that not support the two,
>> >> > there is error log:
>> >> > SCMI Notifications - Failed to ENABLE events for key:13000008 !
>> >> > scmi-cpufreq scmi_dev.4: failed to register for limits change notifier for domain 8
>> >> >
>> >>
>> >
>> >Hi,
>> >
>> >I had a quick look/refresh to this stuff from years ago...
>> >
>> >...wont be so short to explain :P
>> >
>> >In general when you register a notifier_block for some SCMI events,
>> >the assumption was that a driver using proto_X_ops could want to register
>> >NOT only for proto_X events BUT also for other protos...in such a case you
>> >are NOT guaranteed that such other proto_Y was initialized when your
>> >driver probes and tries to register the notifier...indeed it could be
>> >that such proto_Y could be a module that has still to be loaded !
>> >
>> >...in this scenario you can end-up quickly in a hell of probe-dependency
>> >if you write a driver asking for SCMI events that can or cannot be still
>> >readily available when the driver probes...
>> >
>> >....so the decision was to simply place such notifier registration requests
>> >on hold on a pending list...whenever the needed missing protocol is
>> >loaded/inialized the notifier registration is completed...if the proto_Y
>> >never arrives nothing happens...and your driver caller can probe
>> >successfully anyway...
>> >
>> >This means in such a corner-case the notifier registration is sort of
>> >asynchonous and eventual errors detected later, when the protocol is
>> >finally initialized and notifiers finalized, cannot be easily reported
>> >(BUT I think we could improve on this ... thinking about this...)
>> >
>> >...BUT....
>> >
>> >....this is NOT our case NOR the most common case...the usual scenario,
>> >like cpufreq, is that a driver using proto_X_ops tries to register for
>> >that same proto_X events and in such a case we can detect that such
>> >domain is unsupported and fail while avoiding to send any message indeed....
>> >
>> >....so....:P...while I was going through this rabbit-hole....this issues
>> >started to feel familiar...O_o....
>> >
>> >... indeed I realized that the function that you (Peng) now invoke to
>> >set the per-domain perf_limit_notify flag was introduced just for these
>> >reasons to check and avoid such situation for all protocols in the core:
>> >
>> >
>> >commit 8733e86a80f5a7abb7b4b6ca3f417b32c3eb68e3
>> >Author: Cristian Marussi <cristian.marussi@arm.com>
>> >Date: Mon Feb 12 12:32:23 2024 +0000
>> >
>> > firmware: arm_scmi: Check for notification support
>> >
>> > When registering protocol events, use the optional .is_notify_supported
>> > callback provided by the protocol to check if that specific notification
>> > type is available for that particular resource on the running system,
>> > marking it as unsupported otherwise.
>> >
>> > Then, when a notification enable request is received, return an error if
>> > it was previously marked as unsuppported, so avoiding to send a needless
>> > notification enable command and check the returned value for failure.
>> >
>> > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
>> > Link: https://lore.kernel.org/r/20240212123233.1230090-2-cristian.marussi@arm.com
>> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> >
>> >
>> >...so my suspect is that we are ALREADY avoiding to send unneeded
>> >messages when a domain does NOT support notifications for ALL
>> >protocols...it is just that we are a bit too noisy...
>> >
>> >@Peng do you observe the message being sent instead ? (so maybe the
>> >above has a bug...) or it is just the message ?
>>
>> Just the message.
>>
>> arm-scmi arm-scmi.0.auto: SCMI Notifications - Notification NOT supported - proto_id:19 evt_id:0 src_id:8
>> SCMI Notifications - Failed to ENABLE events for key:13000008 !
>> scmi-cpufreq scmi_dev.4: failed to register for limits change notifier for domain 8
>>
>> It just make user has a feeling that there must be something wrong, especially
>> those not know the internals.
>
>Yes indeed it is too much noisy...
>
>>
>> And from the error message, "Failed to ENABLE events for key..", we not
>> know which protocol, and whether notification supported.
>>
>> I was thinking to propogate the error value, but __scmi_enable_evt
>> always use -EINVAL if not success.
>>
>
>I suppose, if you want also to save cycles that you could mark internally a
>protocol, at init time, as NOT suporting notifs (if you can detect that no domain
>is supported OR the related notfs commands are NOT available) and then
>bailing out early with -ENOTOPSUPP when trying to register a new
>notifier (amd muting all the errs to dbgs....) so that the caller can
>warn if wanted or not...
Since you have more expertise in this area, do you have plan to improve here?
If no, I will give a look and see what I could do, but surely needs your
suggestion.
>
>> >
>> >> I wonder if it makes sense to quiesce the warnings from the core if the
>> >> platform doesn't support notifications.
>>
>> If not quiesce, we might need to make it clear from the error message,
>> saying whether X events are supported for Y protocols or not, not just
>> a "Failed to ENABLE events for key.."
>>
>
>Yes that was a very early and primitve errors message of mine...my bad :D
How about this?
-------------------------------
diff --git a/drivers/firmware/arm_scmi/notify.c b/drivers/firmware/arm_scmi/notify.c
index e160ecb22948..1e5a34dc36ab 100644
--- a/drivers/firmware/arm_scmi/notify.c
+++ b/drivers/firmware/arm_scmi/notify.c
@@ -1184,6 +1184,11 @@ static inline int __scmi_enable_evt(struct scmi_registered_event *r_evt,
src_id);
if (!ret)
refcount_set(sid, 1);
+ else
+ dev_err(r_evt->proto->ph->dev,
+ "Enable Notification failed - proto_id:%d evt_id:%d src_id:%d, %pe",
+ r_evt->proto->id, r_evt->evt->id,
+ src_id, ret);
} else {
refcount_inc(sid);
}
@@ -1313,12 +1318,7 @@ static void scmi_put_active_handler(struct scmi_notify_instance *ni,
*/
static int scmi_event_handler_enable_events(struct scmi_event_handler *hndl)
{
- if (scmi_enable_events(hndl)) {
- pr_err("Failed to ENABLE events for key:%X !\n", hndl->key);
- return -EINVAL;
- }
-
- return 0;
+ return scmi_enable_events(hndl)
}
/**
-------------------------------
>
>Thanks,
>Cristian
On Fri, Jun 13, 2025 at 05:50:59PM +0800, Peng Fan wrote:
> Hi Cristian,
>
> On Thu, Jun 12, 2025 at 11:31:01AM +0100, Cristian Marussi wrote:
> >On Thu, Jun 12, 2025 at 11:43:52AM +0800, Peng Fan wrote:
> >> On Wed, Jun 11, 2025 at 02:33:37PM +0100, Cristian Marussi wrote:
> >> >On Wed, Jun 11, 2025 at 01:17:11PM +0100, Sudeep Holla wrote:
> >> >> On Wed, Jun 11, 2025 at 03:52:42PM +0800, Peng Fan (OSS) wrote:
> >> >> > PERFORMANCE_NOTIFY_LIMITS and PERFORMANCE_NOTIFY_LEVEL are optional
> >> >> > commands. If use these commands on platforms that not support the two,
> >> >> > there is error log:
> >> >> > SCMI Notifications - Failed to ENABLE events for key:13000008 !
> >> >> > scmi-cpufreq scmi_dev.4: failed to register for limits change notifier for domain 8
> >> >> >
> >> >>
> >> >
> >> >Hi,
> >> >
Hi,
> >> >I had a quick look/refresh to this stuff from years ago...
> >> >
> >> >...wont be so short to explain :P
> >> >
> >> >In general when you register a notifier_block for some SCMI events,
> >> >the assumption was that a driver using proto_X_ops could want to register
> >> >NOT only for proto_X events BUT also for other protos...in such a case you
> >> >are NOT guaranteed that such other proto_Y was initialized when your
> >> >driver probes and tries to register the notifier...indeed it could be
> >> >that such proto_Y could be a module that has still to be loaded !
> >> >
> >> >...in this scenario you can end-up quickly in a hell of probe-dependency
> >> >if you write a driver asking for SCMI events that can or cannot be still
> >> >readily available when the driver probes...
> >> >
> >> >....so the decision was to simply place such notifier registration requests
> >> >on hold on a pending list...whenever the needed missing protocol is
> >> >loaded/inialized the notifier registration is completed...if the proto_Y
> >> >never arrives nothing happens...and your driver caller can probe
> >> >successfully anyway...
> >> >
> >> >This means in such a corner-case the notifier registration is sort of
> >> >asynchonous and eventual errors detected later, when the protocol is
> >> >finally initialized and notifiers finalized, cannot be easily reported
> >> >(BUT I think we could improve on this ... thinking about this...)
> >> >
> >> >...BUT....
> >> >
> >> >....this is NOT our case NOR the most common case...the usual scenario,
> >> >like cpufreq, is that a driver using proto_X_ops tries to register for
> >> >that same proto_X events and in such a case we can detect that such
> >> >domain is unsupported and fail while avoiding to send any message indeed....
> >> >
> >> >....so....:P...while I was going through this rabbit-hole....this issues
> >> >started to feel familiar...O_o....
> >> >
> >> >... indeed I realized that the function that you (Peng) now invoke to
> >> >set the per-domain perf_limit_notify flag was introduced just for these
> >> >reasons to check and avoid such situation for all protocols in the core:
> >> >
> >> >
> >> >commit 8733e86a80f5a7abb7b4b6ca3f417b32c3eb68e3
> >> >Author: Cristian Marussi <cristian.marussi@arm.com>
> >> >Date: Mon Feb 12 12:32:23 2024 +0000
> >> >
> >> > firmware: arm_scmi: Check for notification support
> >> >
> >> > When registering protocol events, use the optional .is_notify_supported
> >> > callback provided by the protocol to check if that specific notification
> >> > type is available for that particular resource on the running system,
> >> > marking it as unsupported otherwise.
> >> >
> >> > Then, when a notification enable request is received, return an error if
> >> > it was previously marked as unsuppported, so avoiding to send a needless
> >> > notification enable command and check the returned value for failure.
> >> >
> >> > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> >> > Link: https://lore.kernel.org/r/20240212123233.1230090-2-cristian.marussi@arm.com
> >> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> >> >
> >> >
> >> >...so my suspect is that we are ALREADY avoiding to send unneeded
> >> >messages when a domain does NOT support notifications for ALL
> >> >protocols...it is just that we are a bit too noisy...
> >> >
> >> >@Peng do you observe the message being sent instead ? (so maybe the
> >> >above has a bug...) or it is just the message ?
> >>
> >> Just the message.
> >>
> >> arm-scmi arm-scmi.0.auto: SCMI Notifications - Notification NOT supported - proto_id:19 evt_id:0 src_id:8
> >> SCMI Notifications - Failed to ENABLE events for key:13000008 !
> >> scmi-cpufreq scmi_dev.4: failed to register for limits change notifier for domain 8
> >>
> >> It just make user has a feeling that there must be something wrong, especially
> >> those not know the internals.
> >
> >Yes indeed it is too much noisy...
> >
> >>
> >> And from the error message, "Failed to ENABLE events for key..", we not
> >> know which protocol, and whether notification supported.
> >>
> >> I was thinking to propogate the error value, but __scmi_enable_evt
> >> always use -EINVAL if not success.
> >>
> >
> >I suppose, if you want also to save cycles that you could mark internally a
> >protocol, at init time, as NOT suporting notifs (if you can detect that no domain
> >is supported OR the related notfs commands are NOT available) and then
> >bailing out early with -ENOTOPSUPP when trying to register a new
> >notifier (amd muting all the errs to dbgs....) so that the caller can
> >warn if wanted or not...
>
> Since you have more expertise in this area, do you have plan to improve here?
>
> If no, I will give a look and see what I could do, but surely needs your
> suggestion.
... (would be) Happy to help but I dont have so much bandwidth as of now...I will
send you in reply to this an half-baked/UNTESTED patch to express what I
meant....
>
> >
> >> >
> >> >> I wonder if it makes sense to quiesce the warnings from the core if the
> >> >> platform doesn't support notifications.
> >>
> >> If not quiesce, we might need to make it clear from the error message,
> >> saying whether X events are supported for Y protocols or not, not just
> >> a "Failed to ENABLE events for key.."
> >>
> >
> >Yes that was a very early and primitve errors message of mine...my bad :D
>
> How about this?
> -------------------------------
> diff --git a/drivers/firmware/arm_scmi/notify.c b/drivers/firmware/arm_scmi/notify.c
> index e160ecb22948..1e5a34dc36ab 100644
> --- a/drivers/firmware/arm_scmi/notify.c
> +++ b/drivers/firmware/arm_scmi/notify.c
> @@ -1184,6 +1184,11 @@ static inline int __scmi_enable_evt(struct scmi_registered_event *r_evt,
> src_id);
> if (!ret)
> refcount_set(sid, 1);
> + else
> + dev_err(r_evt->proto->ph->dev,
> + "Enable Notification failed - proto_id:%d evt_id:%d src_id:%d, %pe",
> + r_evt->proto->id, r_evt->evt->id,
> + src_id, ret);
> } else {
> refcount_inc(sid);
> }
> @@ -1313,12 +1318,7 @@ static void scmi_put_active_handler(struct scmi_notify_instance *ni,
> */
> static int scmi_event_handler_enable_events(struct scmi_event_handler *hndl)
> {
> - if (scmi_enable_events(hndl)) {
> - pr_err("Failed to ENABLE events for key:%X !\n", hndl->key);
> - return -EINVAL;
> - }
> -
> - return 0;
> + return scmi_enable_events(hndl)
> }
I was thinking more about something to cut way before the notifier
registration process...
I'll send you something I played with last week..
Thanks,
Cristian
Some platforms could be configured not to support notification events from
specific sources and such a case is already handled properly by avoiding
even to attempt to send a notification enable request since it would be
doomed to fail anyway.
In an extreme scenario, though, a platform could support not even one
single source on a specific event: in such a case would be meaningless to
even allow to register a notifier and we can bail-out immediately, saving
a lot of needless computation.
Flag such condition, when detected at protocol initialization time, and
reject upfront any attempt to register a notifier for such completely
unsupported events with -ENOTSUPP.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
NOT FOR MERGE until tested properly even with late loaded protocols.
DOES NOT address the issues with verobosity of messages and lack of
details about failures (which protos ? which resources ?)
---
drivers/firmware/arm_scmi/notify.c | 39 +++++++++++++++++++++++-------
1 file changed, 30 insertions(+), 9 deletions(-)
diff --git a/drivers/firmware/arm_scmi/notify.c b/drivers/firmware/arm_scmi/notify.c
index e160ecb22948..dee9f238f6fd 100644
--- a/drivers/firmware/arm_scmi/notify.c
+++ b/drivers/firmware/arm_scmi/notify.c
@@ -318,6 +318,9 @@ struct scmi_registered_events_desc {
* customized event report
* @num_sources: The number of possible sources for this event as stated at
* events' registration time
+ * @not_supported_by_platform: A flag to indicate that not even one source was
+ * found to be supported by the platform for this
+ * event
* @sources: A reference to a dynamically allocated array used to refcount the
* events' enable requests for all the existing sources
* @sources_mtx: A mutex to serialize the access to @sources
@@ -334,6 +337,7 @@ struct scmi_registered_event {
const struct scmi_event *evt;
void *report;
u32 num_sources;
+ bool not_supported_by_platform;
refcount_t *sources;
/* locking to serialize the access to sources */
struct mutex sources_mtx;
@@ -811,10 +815,19 @@ int scmi_register_protocol_events(const struct scmi_handle *handle, u8 proto_id,
if (!r_evt->report)
return -ENOMEM;
- for (id = 0; id < r_evt->num_sources; id++)
- if (ee->ops->is_notify_supported &&
- !ee->ops->is_notify_supported(ph, r_evt->evt->id, id))
- refcount_set(&r_evt->sources[id], NOTIF_UNSUPP);
+ if (ee->ops->is_notify_supported) {
+ int supported = 0;
+
+ for (id = 0; id < r_evt->num_sources; id++) {
+ if (!ee->ops->is_notify_supported(ph, r_evt->evt->id, id))
+ refcount_set(&r_evt->sources[id], NOTIF_UNSUPP);
+ else
+ supported++;
+ }
+
+ /* Not even one source has been found to be supported */
+ r_evt->not_supported_by_platform = !supported;
+ }
pd->registered_events[i] = r_evt;
/* Ensure events are updated */
@@ -936,6 +949,11 @@ static inline int scmi_bind_event_handler(struct scmi_notify_instance *ni,
* of protocol instance.
*/
hash_del(&hndl->hash);
+
+ /* Bailout if event is not supported at all */
+ if (r_evt->not_supported_by_platform)
+ return -EOPNOTSUPP;
+
/*
* Acquire protocols only for NON pending handlers, so as NOT to trigger
* protocol initialization when a notifier is registered against a still
@@ -1060,6 +1078,9 @@ __scmi_event_handler_get_ops(struct scmi_notify_instance *ni,
r_evt = SCMI_GET_REVT(ni, KEY_XTRACT_PROTO_ID(evt_key),
KEY_XTRACT_EVT_ID(evt_key));
+ if (r_evt && r_evt->not_supported_by_platform)
+ return ERR_PTR(-EOPNOTSUPP);
+
mutex_lock(&ni->pending_mtx);
/* Search registered events at first ... if possible at all */
if (r_evt) {
@@ -1087,7 +1108,7 @@ __scmi_event_handler_get_ops(struct scmi_notify_instance *ni,
hndl->key);
/* this hndl can be only a pending one */
scmi_put_handler_unlocked(ni, hndl);
- hndl = NULL;
+ hndl = ERR_PTR(-EINVAL);
}
}
mutex_unlock(&ni->pending_mtx);
@@ -1370,8 +1391,8 @@ static int scmi_notifier_register(const struct scmi_handle *handle,
evt_key = MAKE_HASH_KEY(proto_id, evt_id,
src_id ? *src_id : SRC_ID_MASK);
hndl = scmi_get_or_create_handler(ni, evt_key);
- if (!hndl)
- return -EINVAL;
+ if (IS_ERR(hndl))
+ return PTR_ERR(hndl);
blocking_notifier_chain_register(&hndl->chain, nb);
@@ -1416,8 +1437,8 @@ static int scmi_notifier_unregister(const struct scmi_handle *handle,
evt_key = MAKE_HASH_KEY(proto_id, evt_id,
src_id ? *src_id : SRC_ID_MASK);
hndl = scmi_get_handler(ni, evt_key);
- if (!hndl)
- return -EINVAL;
+ if (IS_ERR(hndl))
+ return PTR_ERR(hndl);
/*
* Note that this chain unregistration call is safe on its own
--
2.47.0Hi Cristian,
On Tue, Jun 17, 2025 at 02:50:38PM +0100, Cristian Marussi wrote:
>Some platforms could be configured not to support notification events from
>specific sources and such a case is already handled properly by avoiding
>even to attempt to send a notification enable request since it would be
>doomed to fail anyway.
>
>In an extreme scenario, though, a platform could support not even one
>single source on a specific event: in such a case would be meaningless to
>even allow to register a notifier and we can bail-out immediately, saving
>a lot of needless computation.
>
>Flag such condition, when detected at protocol initialization time, and
>reject upfront any attempt to register a notifier for such completely
>unsupported events with -ENOTSUPP.
>
>Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
>---
>NOT FOR MERGE until tested properly even with late loaded protocols.
>DOES NOT address the issues with verobosity of messages and lack of
>details about failures (which protos ? which resources ?)
I tested this patch on i.MX95, no error log anymore. Except
the one in cpufreq:
scmi-cpufreq scmi_dev.5: failed to register for limits change notifier for domain 8
The ret is -EOPNOTSUPP.
Thanks,
Peng
>---
> drivers/firmware/arm_scmi/notify.c | 39 +++++++++++++++++++++++-------
> 1 file changed, 30 insertions(+), 9 deletions(-)
>
>diff --git a/drivers/firmware/arm_scmi/notify.c b/drivers/firmware/arm_scmi/notify.c
>index e160ecb22948..dee9f238f6fd 100644
>--- a/drivers/firmware/arm_scmi/notify.c
>+++ b/drivers/firmware/arm_scmi/notify.c
>@@ -318,6 +318,9 @@ struct scmi_registered_events_desc {
> * customized event report
> * @num_sources: The number of possible sources for this event as stated at
> * events' registration time
>+ * @not_supported_by_platform: A flag to indicate that not even one source was
>+ * found to be supported by the platform for this
>+ * event
> * @sources: A reference to a dynamically allocated array used to refcount the
> * events' enable requests for all the existing sources
> * @sources_mtx: A mutex to serialize the access to @sources
>@@ -334,6 +337,7 @@ struct scmi_registered_event {
> const struct scmi_event *evt;
> void *report;
> u32 num_sources;
>+ bool not_supported_by_platform;
> refcount_t *sources;
> /* locking to serialize the access to sources */
> struct mutex sources_mtx;
>@@ -811,10 +815,19 @@ int scmi_register_protocol_events(const struct scmi_handle *handle, u8 proto_id,
> if (!r_evt->report)
> return -ENOMEM;
>
>- for (id = 0; id < r_evt->num_sources; id++)
>- if (ee->ops->is_notify_supported &&
>- !ee->ops->is_notify_supported(ph, r_evt->evt->id, id))
>- refcount_set(&r_evt->sources[id], NOTIF_UNSUPP);
>+ if (ee->ops->is_notify_supported) {
>+ int supported = 0;
>+
>+ for (id = 0; id < r_evt->num_sources; id++) {
>+ if (!ee->ops->is_notify_supported(ph, r_evt->evt->id, id))
>+ refcount_set(&r_evt->sources[id], NOTIF_UNSUPP);
>+ else
>+ supported++;
>+ }
>+
>+ /* Not even one source has been found to be supported */
>+ r_evt->not_supported_by_platform = !supported;
>+ }
>
> pd->registered_events[i] = r_evt;
> /* Ensure events are updated */
>@@ -936,6 +949,11 @@ static inline int scmi_bind_event_handler(struct scmi_notify_instance *ni,
> * of protocol instance.
> */
> hash_del(&hndl->hash);
>+
>+ /* Bailout if event is not supported at all */
>+ if (r_evt->not_supported_by_platform)
>+ return -EOPNOTSUPP;
>+
> /*
> * Acquire protocols only for NON pending handlers, so as NOT to trigger
> * protocol initialization when a notifier is registered against a still
>@@ -1060,6 +1078,9 @@ __scmi_event_handler_get_ops(struct scmi_notify_instance *ni,
> r_evt = SCMI_GET_REVT(ni, KEY_XTRACT_PROTO_ID(evt_key),
> KEY_XTRACT_EVT_ID(evt_key));
>
>+ if (r_evt && r_evt->not_supported_by_platform)
>+ return ERR_PTR(-EOPNOTSUPP);
>+
> mutex_lock(&ni->pending_mtx);
> /* Search registered events at first ... if possible at all */
> if (r_evt) {
>@@ -1087,7 +1108,7 @@ __scmi_event_handler_get_ops(struct scmi_notify_instance *ni,
> hndl->key);
> /* this hndl can be only a pending one */
> scmi_put_handler_unlocked(ni, hndl);
>- hndl = NULL;
>+ hndl = ERR_PTR(-EINVAL);
> }
> }
> mutex_unlock(&ni->pending_mtx);
>@@ -1370,8 +1391,8 @@ static int scmi_notifier_register(const struct scmi_handle *handle,
> evt_key = MAKE_HASH_KEY(proto_id, evt_id,
> src_id ? *src_id : SRC_ID_MASK);
> hndl = scmi_get_or_create_handler(ni, evt_key);
>- if (!hndl)
>- return -EINVAL;
>+ if (IS_ERR(hndl))
>+ return PTR_ERR(hndl);
>
> blocking_notifier_chain_register(&hndl->chain, nb);
>
>@@ -1416,8 +1437,8 @@ static int scmi_notifier_unregister(const struct scmi_handle *handle,
> evt_key = MAKE_HASH_KEY(proto_id, evt_id,
> src_id ? *src_id : SRC_ID_MASK);
> hndl = scmi_get_handler(ni, evt_key);
>- if (!hndl)
>- return -EINVAL;
>+ if (IS_ERR(hndl))
>+ return PTR_ERR(hndl);
>
> /*
> * Note that this chain unregistration call is safe on its own
>--
>2.47.0
>
On Tue, Jun 17, 2025 at 02:50:38PM +0100, Cristian Marussi wrote: > Some platforms could be configured not to support notification events from > specific sources and such a case is already handled properly by avoiding > even to attempt to send a notification enable request since it would be > doomed to fail anyway. > ... btw....not sure even if all of this is worth just to cut down on needless computation...maybe just reviewing the noise level of the emitted error message could be enough. Thanks, Cristian
© 2016 - 2025 Red Hat, Inc.