Re: [PATCH v15 10/35] firmware: arm_scmi: Add Telemetry resources enumeration

[Cristian Marussi]

On Mon, Nov 09, 2026 at 05:36:41PM -0800, Jonathan Cameron wrote:
> On Mon,  9 Nov 2026 09:11:56 +0000
> Cristian Marussi <cristian.marussi@xxxxxxx> wrote:
> 

Just one eply down below, I will address and reply more in depth next
days while addressing the usual zillion Sashiko issues (tiny now at
least)

> > Add basic Telemetry allocation and initialization routines, introducing and
> > wiring-up the logic needed to enumerate all the SCMI Telemetry resources
> > optionally using a lazy on-demand scheme: this approach factors in the
> > flexibility needed to minimize the amount of initialization work based on
> > the effective access pattern used by the upper layer ABI.
> > 

[snip]

 
> > +
> > +/**
> > + * scmi_telemetry_resources_enumerate  - Enumeration helper
> > + * @ti: A reference to the telemetry info descriptor for this instance
> > + *
> > + * This helper is configured to be called once on the first enumeration
> > + * attempt, when triggered by invoking ti->res_get() from somewhere else.
> > + *
> > + * Once run it substitues itself in ti->res_get() with the simple accessor
> > + * __scmi_telemetry_resources_get, which returns a descriptor to the resources
> > + * that were possibly discovered.
> > + *
> > + * Note that, while it attempts to fully enumerate Data Events and Groups, it
> > + * does NOT fail when such enumerations fail, instead it simply gives up with
> > + * the end result that only a partially populated, but consistent, resources
> > + * descriptor will be returned; in such a case the incomplete descriptor will
> > + * be marked as NOT fully_enumerated: this design enables the kernel to deal
> > + * with badly implemented out-of-spec firmware support while keep on providing
> > + * a minimal sane, albeit possibly incomplete, set of telemetry respources.
> 
> I'm curious about this. What's the motivation for being nice to people who
> write buggy firmware?  I'd kind of prefer an opt in quirk for any that show
> up where a fix is impractical rather than a paper over the bad from the start.
>

Trust me it was never about being nice to FW guys :P

The reasoning, which I am indeed myself questioning these days, was to
be able to carry on and boot a minimal Telemetry working system even
without all of the detailed description retrieved by this command
enumeration process since all of that data descriptors are NOT strictly
needed, unless yout system defines groups or FastChannels.

Because on one side it is true thet DE_DESCRIPTION is a mandatory
command BUT on the other side it is also true that the spec does really
delegate any further detailed description of the Telemetry data to some
external JSON-like file: so you can really carry on without all of this
informational and topological data.

As an example if userspace does not want to use kernel mediated access
to the Telemetry data (most of the IOCTL ABI later on) but instead it
decides to grab and parse directly the RAW mmaped data from the SHMTI/TDCF,
in that case you just need the fds to the areas to mmap and its fully
comprehensive (hopefully) JSON file.

Another possible scenario is bring-up with a limited features FW.

This is also the reasoning behind having the lazy resource enumeration:
you can boot, get the SHMTIs fds and mmap those areas and that's it:
you're good to go without doing any enumeration at all.

There were more FW issues indeed that I used to 'survive' early in this
series that I stop being graceful about it, and even in this case, despite
surviving in a degraded state I printout a FW_BUG.

Now the bad side of the story is that keeping half-initialized stuff
in a degraded system lead to an increasing number of possible issues
flagged by Sashiko, mostly rare errors on path conditions to fix, but
I am starting to wonder if all of this is worth...

Thanks,
Cristian