kernel/drivers/firmware/arm_scmi/notify.c, branch master

firmware: arm_scmi: Fix NULL dereference on notify error path

2026-03-07T19:49:52Z

Since commit b5daf93b809d1 ("firmware: arm_scmi: Avoid notifier registration for unsupported events") the call chains leading to the helper __scmi_event_handler_get_ops expect an ERR_PTR to be returned on failure to get an handler for the requested event key, while the current helper can still return a NULL when no handler could be found or created. Fix by forcing an ERR_PTR return value when the handler reference is NULL. Fixes: b5daf93b809d1 ("firmware: arm_scmi: Avoid notifier registration for unsupported events") Signed-off-by: Cristian Marussi Reviewed-by: Dan Carpenter Message-Id: <20260305131011.541444-1-cristian.marussi@arm.com> Signed-off-by: Sudeep Holla

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51Z

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28Z

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

firmware: arm_scmi: Avoid notifier registration for unsupported events

2025-07-08T15:13:55Z

Some platforms may be configured to not support notification events from certain sources. This scenario is already handled gracefully by avoiding any attempt to send a notification enable request for those sources, as such requests would inevitably fail. However, in a more extreme case, a platform might not support even a single source for a given event type. In this situation, allowing notifier registration is meaningless. Attempting to register a notifier would serve no purpose and only result in unnecessary overhead. To address this, we now detect such conditions during the protocol initialization. When identified, we flag the unsupported event types and reject any subsequent notifier registration attempts for them with -ENOTSUPP. This early rejection avoids redundant processing and simplifies runtime logic. Signed-off-by: Cristian Marussi Message-Id: <20250707144220.485365-1-cristian.marussi@arm.com> Signed-off-by: Sudeep Holla

firmware: arm_scmi: Simplify scmi_devm_notifier_unregister

2024-03-26T11:33:33Z

Unregistering SCMI notifications using the managed devres interface can be done providing as a reference simply the previously successfully registered notification block since it could have been registered only on one kernel notification_chain: drop any reference to SCMI protocol, events and sources. Devres internal helpers can search for the provided notification block reference and, once found, the associated devres object will already provide the above SCMI references for the event. Signed-off-by: Cristian Marussi Link: https://lore.kernel.org/r/20240325204620.1437237-5-cristian.marussi@arm.com Signed-off-by: Sudeep Holla

firmware: arm_scmi: Check for notification support

2024-02-20T06:35:55Z

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 Link: https://lore.kernel.org/r/20240212123233.1230090-2-cristian.marussi@arm.com Signed-off-by: Sudeep Holla

firmware: arm_scmi: Fix kernel doc warnings about return values

2021-07-13T10:39:54Z

Kernel doc validation script still complains about the following: |No description found for return value of 'scmi_get_protocol_device' |No description found for return value of 'scmi_devm_notifier_register' |No description found for return value of 'scmi_devm_notifier_unregister' Fix adding missing Return kernel-doc statements. Link: https://lore.kernel.org/r/20210712143504.33541-1-cristian.marussi@arm.com Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Rename non devres notify_ops

2021-03-30T15:35:16Z

Rename non devres managed notify_ops to use a naming pattern which exposes the performed action verb as last token. No functional change. Link: https://lore.kernel.org/r/20210316124903.35011-37-cristian.marussi@arm.com Tested-by: Florian Fainelli Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Make notify_priv really private

2021-03-30T15:35:15Z

Notification private data is currently accessible via handle->notify_priv, this data was indeed meant to be private to the notification core support and not to be accessible by SCMI drivers. Make it private hiding it inside instance descriptor struct scmi_info and accessible only via dedicated helpers. Link: https://lore.kernel.org/r/20210316124903.35011-36-cristian.marussi@arm.com Tested-by: Florian Fainelli Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Convert events registration to protocol handles

2021-03-29T09:00:35Z

Convert all refactored events registration routines to use protocol handles. In order to maintain bisectability and to allow protocols and drivers to be later ported to the new protocol handle interface one by one, introduce here also some transient code that will be removed later in order to ease such transition. Link: https://lore.kernel.org/r/20210316124903.35011-8-cristian.marussi@arm.com Tested-by: Florian Fainelli Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla