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

[Cristian Marussi <cristian.marussi@arm.com>]

On Thu, Nov 12, 2026 at 10:01:45AM -0800, Jonathan Cameron wrote:
> On Mon,  9 Nov 2026 09:11:56 +0000
> Cristian Marussi <cristian.marussi@arm.com> wrote:
> 
> > 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.
> > 
> > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> 
> Hi Cristian,
> 
> This stretches across the patch set but first elements related to it are
> in this patch.  How do we handle larger values of de_data_sz?
> 

We dont. This was somethig that was on my todo list initially, but then
I realized that there was NO FW-side plan to actually implement anything
larger than 64bit.

> The spec allows (and it's useful for things like histograms)
> DEs to have an integer multiple of 64 bits for a single element.
> In the shared memory buffer that just ends up with a bunch of matching
> IDs with discovery via the parsing done in this patch.

And I know that the spec allows it, but supporting this possible, but
currently NON-implemented, feature would have added some non trivial
complexity across all the stack to the benefit of no one.

When someone will implement for real such big DE FW-side, the change
will follow and of course there will need to be an ABI change.

Given that I am currently in fact shedding a lot of already supported
and tested features (groups/single_sample/notifs etc etc) to slim down
the series dropping stuff that is indeed not implemented FW side (as we
discussed), and would never be used, I would put this kind of support
for big-data DEs in the same category of future possible work...

This remind me, though, that I wanted to place a check on de_data_sz
so as to bailout with -ENOTSUPP when such data appears with the current
implementation...

> 
> The only (I think) today to dump that from this patch set is
> to use the shmti dump interface.  That's not exactly nice!
> 
> I messed around with (well chatted with an LLM about) a couple of
> options.
> 
> 1. Make the whole stack aware of multi line DEs. So all the requests
>    get to return more data.
> 2. Adding indexing so you can get a multi line DE in multiple calls.
>    That makes the interface for a bulk read a bit odd.  Userspace will
>    have to be cleverer given variable sized elements.
> 
> Given this is a ABI related aspect, needs figuring out sooner rather
> than later I think.
> 

Talking about the ABI, since you mentioned in the other patches:

As of now only the ABI_VERSION IOCTL is 'size-versioned' and there are
flags to indicate supported features (both HW and ABI feats) AND fields
with reserved spare space scattered all around IOCTLs so that it should
be possible to add minor features using spare space and flags without
changing ABI version, up to a certain point of course: if the changes
are too radical a new ABI needs to be introduced and  ABI VERSION will
be bumped.

This seemed an acceptable middle ground to me to avoid the complexity of
having all the IOCTL structs 'size-versioned' and related flexibility that
maybe is unneeded in this case...but I could be wrong (maybe the delayed
future possible work to support >64bit DEs is a good reason to have an
ABI that is more flexibile without the new of breaking changes...)

Beside this I did not find really so many examples of ABIs using full
per-IOCTL size versioning, and given my relative small experience on
this and the lack of feedback till now (beside a lot of chats witth LLMs
:P) I stick with this easier ABI layout.

Thanks,
Cristian