Re: [PATCH v7 00/23] Introduce SCMI Telemetry support

On 8/5/26 07:21, Subrahmanya Lingappa wrote:
> Cristian and David,
> 
> On Sun, Aug 2, 2026 at 8:27 PM Cristian Marussi
> <[email protected]> wrote:
>>
>> Hi all,
>>
>> [TLDR Summary]
>>  [V7 highlights]
>>  - V7 focus was on making the ABI complete feature-wise by adding:
>>    + UUID enumerations
>>    + BATCHED DE_CFG
>>    + BATCH ops with per-DE status
>>    + Generic EVENT Subscription with GENERATION_COUNTER support
>>    + Better UAPI Doxygen docs
>>    + Reserved space to grow scattered all-over
>>  - V7 cleans up all the residual known sparse issues
>>  - While aiming for ABI-completeness, V7 addressed also a few reported
>>    general driver/protocol issues BUT the bulk of remanining Sashiko-V6
>>    complains are still to be tackled
>>
>>  [V8 TODO (getting merge-able)]
>>   - Tackle outstanding Sashiko issues
>>   - [ABI]: more DOCS and examples
>>
>> The upcoming SCMI v4.0 specification [0] introduces a new SCMI protocol
>> dedicated to System Telemetry.
>>
>> In a nutshell, the SCMI Telemetry protocol allows an agent to discover at
>> runtime the set of Telemetry Data Events (DEs) available on a specific
>> platform and provides the means to configure the set of DEs that a user is
>> interested into, while reading them back using the collection method that
>> is deeemed more suitable for the usecase at hand. (...amongst the various
>> possible collection methods allowed by SCMI specification)
>>
>> Without delving into the gory details of the whole SCMI Telemetry protocol
>> let's just say that the SCMI platform/server firmware advertises a number
>> of Telemetry Data Events, each one identified by a 32bit unique ID, and an
>> SCMI agent/client, like Linux, can discover them and read back at will the
>> associated data value in a number of ways.
>>
>> Data collection is mainly intended to happen on demand via shared memory
>> areas exposed by the platform firmware, discovered dynamically via SCMI
>> Telemetry and accessed by Linux on-demand, but some DE can also be reported
>> via SCMI Notifications asynchronous messages or via direct dedicated
>> FastChannels (another kind of SCMI memory based access): all of this
>> underlying mechanism is anyway hidden to the user since it is mediated by
>> the kernel driver which will return the proper data value when queried.
>>
>> Anyway, the set of well-known architected DE IDs defined by the spec is
>> limited to a dozen IDs, which means that the vast majority of DE IDs are
>> customizable per-platform: as a consequence, though, the same ID, say
>> '0x1234', could represent completely different things on different systems.
>>
>> Precise definitions and semantic of such custom Data Event IDs are out of
>> the scope of the SCMI Telemetry specification and of this implementation:
>> they are supposed to be provided using some kind of JSON-like description
>> file that will have to be consumed by a userspace tool which would be
>> finally in charge of making sense of the set of available DEs.
>>
>> IOW, in turn, this means that even though the DEs enumerated via SCMI come
>> with some sort of topological and qualitative description provided by the
>> protocol (like unit of measurements, name, topology info etc), kernel-wise
>> we CANNOT be completely sure of "what is what" without being fed-back some
>> sort of information about the DEs by the afore mentioned userspace tool.
>>
>> For these reasons, currently this series does NOT attempt to register any
>> of these DEs with any of the usual in-kernel subsystems (like HWMON, IIO,
>> PERF etc), simply because we cannot be sure which DE is suitable, or even
>> desirable, for a given subsystem. This also means there are NO in-kernel
>> users of these Telemetry data events as of now.
>>
>> So, while we do not exclude, for the future, to feed/register some of the
>> discovered DEs to/with some of the above mentioned Kernel subsystems, as
>> of now we have ONLY modeled a custom userspace API to make SCMI Telemetry
>> available to userspace tools.
>>
>> With V5 we adopted a pure chardev/IOCTL ABI approach, refining the IOCTL
>> based interface already present with the previous FS-based ABI.
>>
>> INTERFACES
>>
>> For each discovered SCMI Instance a character device named tlm_<N> is
>> created under /dev/scmi/ subtree.
>>
>> The IOCTL interface described at 'include/uapi/linux/scmi.h' is made
>> available to enumerate and configure Telemetry resources: Telemetry data
>> can be collected using a few different IOCTls, depending on the required
>> granularity.
>>
>> Alternatively it is possible to obtain a list of the file descriptors
>> referencing directly the underlying SCMI Telemetry SHMTI memory areas and
>> implement in user space an SCMI Telemetry parser accessing directly the
>> SHMTI, while staying in compliance with the SCMI TDCF format.
>>
>> NOTE THAT from v3 onwards the firmware interface level NOW supports ONLY
>> the latest SCMI v4.0 specification [0].
>>
>> Based on V7.2-rc4, tested on an emulated setup.
>>
>> This series is available also at [1].
>>
>> If you still reading...any feedback welcome :P
>>
>> Thanks,
>> Cristian
>>
>> ---
>> v6 --> v7
>>  - [ABI] IOCTL EVENTS support: GENERATION COUNTER (stlm monitor)
>>  - [ABI] expose DE tracking: UUID/SHMTI/OFFS
>>  - [ABI] IOCTL BATCHED DE_CFG
>>  - [ABI] added per-DE IOCTL BATCH status
>>  - [ABI] new ABI feats flags
>>  - [ABI] improved description in Doxygen docs
>>  - [ABI] added reserved space to grow
>>  - [STLM] added new ABI feats support (generation, UUIDs, location...)
>>  - [SYS/TLM] fixed module_init error path
>>  - [SYS/TLM] fixed interval DISCRETE flags reporting
>>  - [SYS/TLM] check open FMODE before executing a config change
>>  - [SYS/TLM] fixing DEs data cleanup on RESET
>>  - [SYS/TLM] added _RAW helpers to handle non-MMIO TDCF-like accesses
>>    (like Notification payload)
>>  - [SYS/TLM] added UUID rescan logic at DE enable, when DE/UUID association
>>  - [TLM] reworked UUID internal handling (endianity) and use uuid_t type
>>  - [TLM] added generic Telemetry protocol support for events subscription
>>    unknown
>>  - residual sparse fixes
>> v5 --> v6
>>  - rebased on v7.2-rc4
>>  - fixed a lot of Sashiko complains
>>  - fixed ABI issues reported by review (Fayssal)
>>  - added IOCTL TLM_RESET
>>  - added ABI versioning
>>  - added compat_ioctl support
>>  - use a new IOCTL magic name
>>  - better handling of UUID endianity
>>  - reworked all bounds checks in UAPI implementation
>>  - reject oversized SHMTI mmap request
>>  - refined 'stlm' testing tool to be more interactive and to
>>    exercise the full spectrum of IOCTLs ('stlm -h' is your manual
>>    for now :P)
>>  - fully reworked per-protocol notification handling
>>  - dropped the last bit of human readable data attached to the
>>    chardev .read
>> v4 --> v5
>>  - rebased on v7.2-rc1
>>  - dropped FileSystem based driver
>>  - introduced a new simple chardev SCMI driver using Telemetry
>>  - reworked/reviewed the v4 IOCTLs based UAPI
>>  - UAPI: better struct alignment and comments
>>  - UAI: Removed flexible array members
>>  - UAPI: make SCMI Telemetry protocol stack completely independent from
>>          uapi defs
>>  - UAPI: new ioctls support to enable RAW mmap direct access to SCMI SHMTI
>>          areas from userspace
>>  - added new ABI Documentation
>>  - added new SCMI core facility to lookup the current SCMI instance ID
>> v3 --> v4
>>  - rebased on v7.1-rc7
>>  - updatded doc to detail Concurrency model
>>  - bail out on FW_BUG errors
>>  - make all_des_enable/all_des_tstamp_enable entry readable
>>  - refactored access to TDE values
>>  - refactored common accessors for tlm_priv (FIX WARN on kfree)
>>  - make all files by default world readable and user writable (if needed)
>>  - added uid/god/umask mount options (and docs)
>>  - added generation counter to aid spotting config changes (and docs)
>>  - added DebugFS configurable support to debug/dump SHMTI areas (and docs)
>>  - hide FS entries when NOT supported (like des_simple_sample_read)
>>  - fixed output format of des/<NNN>/value to -> <TS> <VALUE>
>>  - renamed top-dir by_components to by-components
>>  - add a .remove method to SCMI System Telemetry Driver
>>  - use kzalloc_obj
>> V2 --> V3
>>  - rebased on v7.0-rc5
>>  - ported the firmware interface to SCMI v4.0 BETA
>>  - split the SCMI protocol layer in a lot of small patches
>>  - completd filesystem and ABI documentation
>>  - renamed components subtree to by_components
>>  - fixed uninitialized var in scmi_telemetry_de_subdir_symlink
>>  - renamd tstamp_exp to tstamp_rate
>>  - swap logic in scmi_telemetry_initial_state_lookup
>>  - use memcpy_from_le32 where required
>>  - changed a dfew dev_err into Telemetry traces
>>  - define and use new helper scmi_telemetry_de_unlink
>>  - simplify a few assignments with ternary ops
>>  - added a missing __mmust_check on the internal SCMI API
>>  - reworked and clarified de_data_read returned errno:
>>         ENODATA vs EINVAL vs ENODEV/ENOENT
>>  - removed some risky/unneeded devres allocations
>>  - various checkpatch fixes
>>  - reworked and clarified usage of traces in Telemetry
>>  - added the missing DT binding for protocol 0x1B
>>  - split out unrelated change around notification from patch
>>    adding support for protocol internal notifier
>>  - more comments
>>
>> V1 --> V2
>>  - rebased on v6.19-rc3
>>  - harden TDCF shared memory areas accesses by using proper accessors
>>  - reworked protocol resources lifecycle to allow lazy enumeration
>>  - using NEW FS mount API
>>  - reworked FS inode allocation to use a std kmem_cache
>>  - fixed a few IOCTLs support routine to support lazy enumeration
>>  - added (RFC) a new FS lazy mount option to support lazily population of
>>    some subtrees of the FS (des/ groups/ components/)
>>  - reworked implementation of components/ alternative FS view to use
>>    symlinks instead of hardlinks
>>  - added a basic simple (RFC) testing tool to exercise UAPI ioctls interface
>>  - hardened Telmetry protocol and driver to support partial out-of-spec FW
>>    lacking some cmds (best effort)
>>  - reworked probing races handling
>>  - reviewed behaviour on unmount/unload
>>  - added support for Boot_ON Telemetry by supporting SCMI Telemetry cmds:
>>    + DE_ENABLED_LIST
>>    + CONFIG_GET
>>  - added FS and ABI docs
>>
>> RFC --> V1
>> ---
>>  - moved from SysFS/chardev to a full fledged FS
>>  - added support for SCMI Telemetry BLK timestamps
>>
>> [0]: https://developer.arm.com/documentation/den0056/f/?lang=en
>> [1]: https://git.kernel.org/pub/scm/linux/kernel/git/cris/linux.git/log/?h=scmi_telemetry_ng_V7
>>
>> Cristian Marussi (23):
>>   firmware: arm_scmi: Add new SCMIv4.0 error codes definitions
>>   firmware: arm_scmi: Allow registration of unknown-size events/reports
>>   firmware: arm_scmi: Introduce protocol instance notifiers
>>   dt-bindings: firmware: arm,scmi: Add support for telemetry protocol
>>   include: trace: Add Telemetry trace events
>>   firmware: arm_scmi: Add basic Telemetry support
>>   firmware: arm_scmi: Add support to parse SHMTIs areas
>>   firmware: arm_scmi: Add Telemetry configuration operations
>>   firmware: arm_scmi: Add Telemetry DataEvent read capabilities
>>   firmware: arm_scmi: Add support for Telemetry reset
>>   firmware: arm_scmi: Add Telemetry notification support
>>   firmware: arm_scmi: Add support for boot-on Telemetry
>>   firmware: arm-scmi: Add telemetry generic event support
>>   firmware: arm_scmi: Add Telemetry generation counter event
>>   firmware: arm_scmi: Add common per-protocol debugfs support
>>   firmware: arm_scmi: Add Telemetry debugfs SHMTI dump support
>>   firmware: arm_scmi: Add Telemetry debugfs ABI documentation
>>   firmware: arm_scmi: Expose per-instance identifier
>>   uapi: Add ARM SCMI Telemetry definitions
>>   firmware: arm_scmi: Add System Telemetry driver
>>   docs: ioctl-number: Add SCMI Ioctls
>>   [RFC] Documentation: Add SCMI System Telemetry documentation
>>   [RFC] tools/scmi: Add SCMI Telemetry testing tool
>>
>>  Documentation/ABI/testing/debugfs-scmi        |   22 +
>>  .../bindings/firmware/arm,scmi.yaml           |    8 +
>>  Documentation/userspace-api/index.rst         |    1 +
>>  .../userspace-api/ioctl/ioctl-number.rst      |    1 +
>>  Documentation/userspace-api/stlm.rst          |  148 +
>>  MAINTAINERS                                   |    1 +
>>  drivers/firmware/arm_scmi/Kconfig             |   24 +
>>  drivers/firmware/arm_scmi/Makefile            |    3 +-
>>  drivers/firmware/arm_scmi/common.h            |   18 +
>>  drivers/firmware/arm_scmi/driver.c            |  119 +-
>>  drivers/firmware/arm_scmi/notify.c            |   38 +-
>>  drivers/firmware/arm_scmi/notify.h            |    8 +-
>>  drivers/firmware/arm_scmi/protocols.h         |   17 +
>>  .../firmware/arm_scmi/scmi_system_telemetry.c | 1515 +++++++
>>  drivers/firmware/arm_scmi/telemetry.c         | 3762 +++++++++++++++++
>>  include/linux/scmi_protocol.h                 |  261 +-
>>  include/trace/events/scmi.h                   |   48 +-
>>  include/uapi/linux/scmi.h                     |  517 +++
>>  tools/testing/scmi/Makefile                   |   25 +
>>  tools/testing/scmi/stlm.c                     | 1371 ++++++
>>  20 files changed, 7877 insertions(+), 30 deletions(-)
>>  create mode 100644 Documentation/userspace-api/stlm.rst
>>  create mode 100644 drivers/firmware/arm_scmi/scmi_system_telemetry.c
>>  create mode 100644 drivers/firmware/arm_scmi/telemetry.c
>>  create mode 100644 include/uapi/linux/scmi.h
>>  create mode 100644 tools/testing/scmi/Makefile
>>  create mode 100644 tools/testing/scmi/stlm.c
>>
>> --
>> 2.54.0
>>
>>
> 
>   Just to close the loop on my earlier comment: the second telemetry provider
>   I  had in mind is now public, RISC-V RPMI Specifications Telemetry
> service group:
> 
>     https://github.com/riscv-non-isa/riscv-rpmi/pull/162
> 
>   V7 has already moved the SCMI ABI in a better direction: explicit ABI
>   features,  reserved growth space, UUID tracking, batched operations,
> per-item status
>   and a  generation event make the interface less brittle than the
> version I first
>   commented on.
> 
>   So I am not asking to block SCMI Telemetry on a generic telemetry UAPI. That
>   would still be premature. My remaining ask is smaller: please keep the
>   chardev-facing descriptor/group/config/sample/mmap handling cleanly
>   separated  from SCMI-private storage and TDCF parsing.

IIRC, this is not a ABI concern, right?

Any kernel internal refactorings can be had later, once RPMI actually lands.

-- 
Cheers,

David