Re: [PATCH v15 29/35] uapi: Add ARM SCMI Telemetry definitions

[Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>]

On Mon,  9 Nov 2026 09:12:15 +0000
Cristian Marussi <cristian.marussi@arm.com> wrote:

> Add a number of structures and ioctls definitions used by the ARM
> SCMI Telemetry protocol.
> 
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> ---

> ---


> diff --git a/include/uapi/linux/scmi.h b/include/uapi/linux/scmi.h
> new file mode 100644
> index 000000000000..dd78220554a2
> --- /dev/null
> +++ b/include/uapi/linux/scmi.h
> @@ -0,0 +1,531 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +/*
> + * Copyright (C) 2026 ARM Ltd.
> + */
> +#ifndef _UAPI_LINUX_SCMI_H
> +#define _UAPI_LINUX_SCMI_H
> +
> +/*
> + * Userspace interface SCMI Telemetry
> + */
> +
> +#include <linux/ioctl.h>
> +#include <linux/types.h>
> +
> +#define SCMI_TLM_ABI_VERSION_V1			1
> +#define SCMI_TLM_CURRENT_ABI_VERSION		SCMI_TLM_ABI_VERSION_V1
> +#define SCMI_TLM_DE_IMPL_UUID_SZ		16
> +
> +#define SCMI_TLM_SHMTI_ID_INVALID		0xFFFFFFFF
> +
> +/**
> + * struct scmi_tlm_abi_info - Basic information on the ABI/instance
> + *
> + * SCMI Telemetry characteristics like number of DEs, Groups, Intervals and
> + * SHMTIs are statically determined by the platform and do not change within
> + * one boot/session; they are reported here so that they can be used to properly
> + * size the requests on other IOCTLs, without having to discover dynamically
> + * those sizes by issuing a zero-sized IOCTL request at first.
> + *
> + * @size: sizeof this structure - IN
> + * @abi_version: ABI Version - OUT

I'm curious what the plan is for ABI versioning.  Normally to have
any hope of backwards compatibility it needs to be a negotiation between
userspace and kernel (and then hardware if appropriate). Is there any route
to do that?

> + * @abi_features: ABI capabilities bitmap - OUT
> + * @primary_de_impl_version: SCMI Telemetry DE implementation revision - OUT
> + * @num_des: Number of defined DEs - OUT
> + * @num_groups: Number of defined DEs groups - OUT
> + * @num_intervals: Number of available update intervals (instance-level) - OUT
> + * @num_shmtis: Number of discovered SHMTI areas - OUT
> + * @features: Instance specific SCMI feature-support bitmap - OUT
> + * @reserved: Some room for future expansion without the need to resize.
> + *	      Must be zero.

Why?  I'd expect the input size to indicate what userspace supports.
As such what use is this reserved padding?

> + *
> + * Used by:
> + *	RW - SCMI_TLM_GET_ABI_INFO
> + */
> +struct scmi_tlm_abi_info {
> +	__u32 size;
> +	__u32 abi_version;
> +	__u32 abi_features;
> +#define SCMI_TLM_ABI_FEAT_RESET				(1 << 0)
> +#define SCMI_TLM_ABI_FEAT_EVENT				(1 << 1)
> +#define SCMI_TLM_ABI_FEAT_UUID_LIST			(1 << 2)
> +#define SCMI_TLM_ABI_FEAT_BATCH_STATE			(1 << 3)
> +#define SCMI_TLM_ABI_FEAT_BATCHED_CFG			(1 << 4)
> +#define SCMI_TLM_ABI_FEAT_DE_TRACKING			(1 << 5)
> +	__u8 primary_de_impl_version[SCMI_TLM_DE_IMPL_UUID_SZ];
> +	__u32 num_des;
> +	__u32 num_groups;
> +	__u32 num_intervals;
> +	__u32 num_shmtis;
> +	__u32 features;
> +#define SCMI_TLM_SCMI_SUPPORT_RESET			(1 << 0)
> +#define SCMI_TLM_SCMI_SUPPORT_SINGLE_SAMPLE		(1 << 1)
> +#define SCMI_TLM_SCMI_SUPPORT_GROUP_CONFIG		(1 << 2)
> +#define SCMI_TLM_SCMI_SUPPORT_UPDATE_NOTIFICATION	(1 << 3)
> +	__u64 reserved;
> +};
> +


> +/**
> + * struct scmi_tlm_config  - Whole instance or group configuration
> + *
> + * @enable: Get/Set Telemetry enabled state for the whole instance or the
> + *	    group specified in @grp_id - IN/OUT
> + * @t_enable: Get/Set timestamp state for the group specified in @grp_id - IN/OUT
> + * @flags: Bitmask to represent special characteristics - IN
> + * @pad: Padding fields to enforce alignment
> + * @grp_id: Identifier of the target group upon which this configuration will
> + *	    be applied: ignored if not marked as a group in @flags - IN/OUT
> + * @active: Get/Set currently active update interval for the whole instance
> + *	    or the group specified in @grp_id - IN/OUT
> + * @reserved: Some room for future expansion. Must be zero.

I'd add a size field for this one too to make it easier to expand.
Probably the same applies to all others.


> + *
> + * Used by:
> + *	RW - SCMI_TLM_GET_CFG
> + *	WO - SCMI_TLM_SET_CFG
> + */
> +struct scmi_tlm_config {
> +	__u8 enable;
> +	__u8 t_enable;
> +	__u8 flags;
> +#define SCMI_TLM_CONFIG_GROUP		(1 << 0)
> +#define SCMI_TLM_CONFIG_FLAGS		(SCMI_TLM_CONFIG_GROUP)
> +#define SCMI_TLM_CONFIG_IS_GROUP(f)	((f) & SCMI_TLM_CONFIG_GROUP)
> +	__u8 pad;
> +	__u32 grp_id;
> +	struct scmi_tlm_update_interval active;
> +	__u64 reserved;
> +};
> +
> +/**
> + * struct scmi_tlm_intervals  - Update intervals descriptor
> + *
> + * @grp_id: Identifier of the target group upon which this configuration
> + *	    will be applied: ignored if not marked as a group in @flags - IN
> + * @flags: Bitmask to represent special characteristics. When the interval
> + *	   is NOT marked as SCMI_TLM_INTERV_DISCRETE, @intervals will
> + *	   contain a triplet: min/max/step - OUT

I'd have a reference to this in the num_intervals text. What happens if the input
only allows for two intervals?

> + * @pad: Padding fields to enforce alignment
> + * @num_intervals: Number of entries of @intervals. On input this represents the
> + *		   size of @intervals, while on output carries the effective
> + *		   number of entries filled-in.
> + *		   On input this has an upper-bound determined as: