Re: [PATCH v15 00/35] Introduce SCMI Telemetry support

[Cristian Marussi]

On Tue, Nov 10, 2026 at 04:38:09PM -0800, Jonathan Cameron wrote:
> > The upcoming SCMI v4.0 specification [0] introduces a new SCMI protocol
> > dedicated to System Telemetry.
> > 
> 
> Hi Cristian,

Hi Jonathan,

thanks for your time...I sincerely hope you're travelling abroad on some
remote timezone given the time these reviews came in :D

> 
> So, the main issue here is pretty much summarized by:
> 
>  28 files changed, 12801 insertions(+), 99 deletions(-)
> (obviously there are tests etc, but it's still > 10k lines)
>

Usually I try to implement the complete set of features of a new protocol
but indeed this new Telemetry thing is huge by itself so it became quickly
overwhelming to review...imagine to code and test it.

> There are relatively few reviewers who would even consider taking that on.
> I foolishly thought it wouldn't be too bad (and I review a lot of code).
> By about 3/4 of the way though, probably much earlier, I know the quality
> of review went down considerably. Honestly it was probably a waste of
> time continuing but I'm stubborn like that.
> 
> So, unless you have a path to bribing or sweet talking various folk to
> deal with reviewing this with each having to set aside multiple days
> to do it, likely repeating for a couple of versions yet, I think you've
> got to figure out out how to make the first patch set more manageable.
> Probably don't split it up as much as the mpam or CCA folk have had to,
> but you have a lot of colleagues who are experiencing the same problem
> at the moment. They may be able to advise.
> 
> So it would be nice if what was in that first patch set was 'functional'
> but I don't think it needs to function on every systems or support more
> than an absolutely minimal feature set.  Just fail to probe when you see
> something that isn't supported by that minimal set if that means
> the thing won't be functional.
> 
> Once that's in place, over a couple of additional patch sets you can
> get to everything you have here.
> 
> So what if you choose one data path (shmti perhaps), no notifications,
> events, maybe even simplify to one of the readback paths.
> Maybe even drop event groups initially. 

Based on our real world initial customer of this I can certainly drop a
few features that are not supported anyway by the real FW and move it to
a later patchset, stuff like groups, notifications and single sample
reads, but all of the rest is hardly removable while keeping the system
functional and usable.

> Possibly even drop timestamps.  Definitely drop things like boot-on
> support and debugfs (unless you are using that as a cheeky 'functional'
> test ahead of the main userspace interface.

Not sure what you mean by drop timestamps, definitelly cannot drop
boot-on (it is how systems are configured indeed) neither debugfs used
for bring-up and FW debug.

> 
> How much would that slim things down?  It doesn't even have to be
> useful, just testable.  Realistically I think the hope of getting
> enough review doubles if you can halve the size of what you are asking
> people to look at.

I am not sure how many lines I can shed with the above features drops but
I'll give it a go anyway at slimming down the series after I have gone
through this round of Sashiko pains.

> 
> Anyhow, gut feeling only but the code felt like it was in a much
> better state than some of the versions I've looked at in the past,
> so I think the game is now how to get it over the line!
> 

>From the testing/functional/performance standpoints the series has
definitely improved especially, but still some road to go.

Thanks,
Cristian