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

[Cristian Marussi]

On Wed, Jul 15, 2026 at 07:15:10PM +0530, Subrahmanya Lingappa wrote:
>  Hi David, Cristian,
> 
>  Thanks, both. Fair points.
> 

Hi Subrahmanya,

> On Fri, Jul 10, 2026 at 2:02 PM Cristian Marussi
> <cristian.marussi@xxxxxxx> wrote:
> >
> > On Tue, Jul 07, 2026 at 12:01:37PM +0530, Subrahmanya Lingappa wrote:
> > > Hi Cristian,
> >

[snip]

> 
>  I agree that asking this series to grow a generic telemetry subsystem now is
>  too much. With only SCMI in-tree, it would be easy to create a "generic"
>  interface that is really just SCMI with different names. I also agree that raw
>  SHMTI is not just a debug path if the expected users are high-rate tooling.
> 
>  So let me narrow the ask.
> 
>  I am not asking for `drivers/telemetry/` in v6. I am asking that the SCMI
>  chardev/UAPI not be tied too closely to the current SCMI core storage layout.
>  In particular, I think v6 should try to:
> 
>    - copy descriptor/config/sample data through fixed and extensible UAPI
>      structs, not structs mirroring SCMI internal objects;

If you mean by this adding a bit more of pad/reserved space scattered
here and there, it is not a problem; also, one thing that is still missing
and planned to be added is some ABI Versioning and related IOCTL,
should not this be enough to address future possible UAPI expansions ?

Regarding avoiding mapping internal SCMI object in the UAPI, I think I
am already NOT blindly sharing internal structures but instead I copy
explicitly internal representations into the UAPI fields....I think the
only exception to this is the sample (scmi_tlm_de_sample) that I take
care to keep aligned with the internals to avoid the overhead of the
double copy...but it seems one of the few pretty much general concept
that I felt confident to abstract no ?

...but of course this UAPI abstraction into which I copy the results
is mapped into SCMI inspired concepts/abstractions...for the reasons
we said....

>    - treat DE IDs, group IDs and SHMTI IDs as protocol identifiers, not as
>      implicit indexes into kernel arrays;

Not sure what you mean here... a shim layer used to acces info data
indirectly instead of the SCMI data structures ?

or some sort of layer/abstraction to be able to remap references
internally ? again it is not easy to imagine an abstraction without any
other example than SCMI...or you mean naming issue in the UAPI ?

>    - keep the TDCF/SHMTI parsing and SCMI command handling behind small
>      internal ops used by the chardev side;

well..if you refer to the telemetry_ops, this is an SCMI driver so it
has the structure of an SCMI driver, the Telemetry Operations exposed by
the core SCMI stack are the internal ops themselves that you ask for in
my opinion...I mean this is pretty much internal stuff that has nothing
to do with the UAPI itself and I imagine that when some future protocol
of yours, like the XXMI you mentioned, will appear you will write a new
driver on your own subsystem that will implement the UAPI itself for
your protocols (if you want to share that)...any possible future internal
reworking due to possible common abstractions on our side can be carried
out in the future...

>    - document the config model explicitly: per SCMI instance, last writer wins,
>      generation changes tell userspace that state changed;
>    - document the mmap contract: length, offsets, cache attributes, lifetime,
>      and reset/reconfiguration behaviour.

Completely agreed on this...Documentation is still lacking, including
extensive examples...I should have marked docs as RFC too...

> 
>  That keeps the ABI explicitly SCMI-specific and does not make SHMTI second
>  class. It just avoids baking too much of today's SCMI implementation shape into
>  the userspace contract.
> 
>  Cristian's point about policy being enforced by the SCMI server also makes
>  sense to me. I am not suggesting Linux should second-guess that partitioning.
>  Documenting the Linux-visible semantics is enough: what is shared per SCMI
>  instance, what userspace may race with, and how generation/poll reports that.

Yes it will be documented too...in one of the future series.

> 
>  So I would reduce my earlier suggestion to: no generic framework required now,
>  but please keep a clean provider/backend boundary inside the driver and leave
>  some UAPI growth room. That should make a later common layer possible, if a
>  second provider or an in-kernel user ever justifies it, without forcing this
>  series to solve that problem today.

No problem for UAPI growth and possible compatibility visa reserved
space and ABI versioning, but I dont see how a very susbsystem specific
driver like this SCMI Telemetry driver can be made more generic in terms of
provider/backend...the provider here is indeed already separated by the usage
of the SCMI telemetry protocol operations exposed by the core SCMI stack...

I think in order to have multiple backend providers pluggable/interchangeable
at will without the need to write a new driver for ecah one would mean, again,
having some sort common framework...thing that seems premature, as agreed.

Thanks,
Cristian