Hi Cristian,
Thanks for posting this. I think the direction of not forcing these
Telemetry Data Events into hwmon/IIO/perf prematurely is the right one.
The cover letter explains the core problem well: most DE IDs are
platform-defined, and without external metadata the kernel cannot reliably
know whether a DE is a thermal sensor, a performance counter, a power value,
or something entirely platform-specific.
That said, I think the current layering is still too SCMI-shaped for the
ABI it is trying to introduce.
The thing being exposed here is not only "SCMI Telemetry"; it is a more
general kernel concept of telemetry:
- enumerate provider-specific data/event descriptors
- expose capabilities, units, data format and topology/grouping metadata
- configure collection rate and collection mode where supported
- collect samples with timestamp/freshness/validity information
- track generation/state changes
- optionally expose provider-private raw backing storage for debugging
SCMI is one provider of that model. It happens to transport the data through
SCMI v4.0 concepts such as DEs, groups, SHMTIs and TDCF. But another firmware
or control-plane specification could show up later with the same broad
telemetry model and a different wire format. Call it XXMI or YYMI: the
protocol mechanics would differ, but the kernel consumers should not have to
learn a new in-kernel and userspace ABI for each one.
The common ABI should therefore avoid treating the DE numeric namespace or
the wire/storage format as the abstraction. The useful common contract is
closer to:
- what is being measured: component/type/instance/name;
- how to interpret it: unit, exponent/rate unit, data width and signedness;
- how it behaves: instantaneous, accumulating, average, state/counter, etc.;
- how it is controlled: individual event vs group-wide collection;
- how fresh it is: timestamp, sequence/generation and validity/error flags.
So I would strongly consider inserting a generic telemetry layer above SCMI,
with SCMI registering as a telemetry provider rather than owning the stable
userspace ABI directly.
Roughly:
drivers/telemetry/
provider registration
descriptor/sample/config abstractions
generation tracking and poll support
common userspace ABI
drivers/firmware/arm_scmi/telemetry.c
SCMI protocol implementation
TDCF/SHMTI/notification parsing
translation into generic telemetry descriptors/samples
optional provider-private raw/debug path
SCMI SHMTI mmap or dumps, if kept, behind explicit privilege/debug
policy rather than as the baseline telemetry ABI
With that shape, future in-kernel consumers could bind to generic telemetry
objects and capabilities instead of SCMI internals. Architected/well-known
DEs could later grow adapters into hwmon/IIO/perf where the semantics are
clear, while platform-specific DEs remain available through the generic
telemetry interface plus userspace metadata.
This would also help avoid making the SCMI protocol's internal resource
storage part of the ABI. Right now the public protocol header exposes
structures such as scmi_telemetry_res_info, scmi_telemetry_group and
scmi_telemetry_de, and the chardev indexes those objects directly. That feels
too tightly coupled for something that may need more consumers later. I would
prefer copy-out or iterator-style provider ops instead, for example:
info_get()
de_count_get()
de_info_get()
group_info_get()
intervals_get()
collection_set()
collection_get()
sample_read()
reset()
where the backing arrays, xarrays, lazy enumeration, SHMTI mappings and TDCF
parsing remain private to the SCMI provider.
The sample side probably needs an explicit common result contract too. A
sample is not only an integer value: it may have optional timestamping,
provider data width, stale/not-yet-valid state, partial collection failures,
hardware-fault indications, and a sequence/generation value that lets
userspace detect races against reconfiguration or shared-memory updates. Those
details can still be backed by SCMI-specific status codes and TDCF parsing
internally, but I think the stable ABI should expose them in provider-neutral
terms.
I would also be careful about freezing the raw SHMTI mmap part as a baseline
ABI. It is useful for bring-up and high-performance tooling, but it exposes
firmware-owned shared memory layout and TDCF parsing rules directly to
userspace. If this stays, I think it should be clearly separated as a
privileged/debug/raw provider facility, with a precise mmap contract:
- required mmap length
- vm_pgoff semantics
- page alignment
- VMA flags
- cache/coherency expectations
- lifetime across reset/remove/reprobe
- required capability, if any
Even outside the raw mmap case, telemetry can be a sensitive high-rate view
of system behavior. The ABI should make access policy explicit: who can
enumerate, who can read, who can change collection state, and whether
production systems can restrict sampling granularity or intervals
independently of what firmware advertises.
For the stable telemetry ABI, I would start smaller: descriptor enumeration,
sample reads with validity metadata, optional group-aware configuration, and a
generation counter/poll mechanism so userspace can detect reconfiguration or
partial re-enumeration races.
One other point related to this layering: configuration appears to be global
to the SCMI instance. Any process opening /dev/scmi/tlm_N can change
collection mode, sampling interval, DE enablement and timestamp state for
other users. That may be OK, but it should be an explicit policy decision.
A generic telemetry layer could make the model clearer: multi-reader with a
privileged/single writer, or fully shared global controls, with instance-level
locking and generation updates after each visible state change.
So my high-level suggestion for v6 would be:
1. define the generic telemetry provider/consumer model first;
2. make SCMI Telemetry one provider of that model;
3. keep SCMI/TDCF/SHMTI details below the provider boundary;
4. keep raw SHMTI access separate from the stable ABI;
5. define common sample validity/freshness/error semantics;
6. add generation/poll semantics to the common ABI;
7. make lifetime, access policy and configuration concurrency explicit.
I do not think this invalidates the protocol work in the series. Most of the
SCMI parsing and resource discovery can still be the provider implementation.
The main question is where the stable kernel/userspace contract should sit.
My preference would be that it sits at "telemetry", not at "SCMI Telemetry",
so that SCMI, and any future XXMI/YYMI-style provider, can share one consumer
interface.
Thanks,