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

From: Jonathan Cameron

Date: Tue Nov 10 2026 - 18:18:28 EST


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

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

> ---


> 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: