[PATCH v12 02/25] firmware: arm_scmi: Allow registration of unknown-size events/reports

[David Hildenbrand (Arm)]

On 9/20/26 11:19, Cristian Marussi wrote:
> Allow protocols to register events with build-time unknown sizes: such
> events can be declared zero-sized and let the core SCMI stack perform the
> needed safe-net boundary checks based on the configured transport size.

ok, so we have a maximum message size defined by the transport. We'll use that
as payload size, and the report size just gets the additional ktime_t.


>  	pd = scmi_allocate_registered_events_desc(ni, proto_id, ee->queue_sz,
> @@ -807,7 +821,8 @@ int scmi_register_protocol_events(const struct scmi_handle *handle, u8 proto_id,
>  		mutex_init(&r_evt->sources_mtx);
>  
>  		r_evt->report = devm_kzalloc(ni->handle->dev,
> -					     evt->max_report_sz, GFP_KERNEL);
> +					     evt->max_report_sz ?: max_report_sz,

Having two similarly named variables is a bit confusing. I wonder if you can
somehow make it clearer in the latter case that it is the max_report_sz
according to the transport.

> +					     GFP_KERNEL);
>  		if (!r_evt->report)
>  			return -ENOMEM;
>  
> diff --git a/drivers/firmware/arm_scmi/notify.h b/drivers/firmware/arm_scmi/notify.h
> index f18f98c5ab3b..c2eb4844c7db 100644
> --- a/drivers/firmware/arm_scmi/notify.h
> +++ b/drivers/firmware/arm_scmi/notify.h
> @@ -18,8 +18,12 @@
>  /**
>   * struct scmi_event  - Describes an event to be supported
>   * @id: Event ID
> - * @max_payld_sz: Max possible size for the payload of a notification message
> - * @max_report_sz: Max possible size for the report of a notification message
> + * @max_payld_sz: Max possible size for the payload of a notification message.
> + *		  Set to zero to use the maximum payload size allowed by the
> + *		  transport.

"maximum payload size" is ph->hops->get_max_msg_size(ph) ? Should we call this
"maximum message size" then?

> + * @max_report_sz: Max possible size for the report of a notification message.
> + *		   Set to zero to use the maximum payload size allowed by the
> + *		   transport plus the additional ktime_t timestamp.

Same here.

-- 
Cheers,

David