Re: [PATCH v15 23/35] firmware: arm_scmi: Add Telemetry generation counter event

[Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>]

On Thu, 12 Nov 2026 20:17:35 +0000
Cristian Marussi <cristian.marussi@arm.com> wrote:

> On Tue, Nov 10, 2026 at 02:46:35PM -0800, Jonathan Cameron wrote:
> > On Mon,  9 Nov 2026 09:12:09 +0000
> > Cristian Marussi <cristian.marussi@arm.com> wrote:
> >   
> > > Add a per-instance generation counter to track configuration changes which
> > > uses the common telemetry events framework.  
> > Why?  What's the usecase for this?
> > Needs some more information or I'd leave it for now.
> >   
> 
> SCMI Telemetry is specified and designed FW/Kernel side to allow for
> multiple readers and multiple writers issuing configuration changes:
> give that there is NO HW/FW/SPEC limitation in allowing such concurrency
> (unlike e.g. for a serial or an RTC) the telemetry driver does NOT
> enfroce any kind of exclusive access...last one wins when multiple
> acctors tries to configure overlapping stuff...none of kernel problem
> userspace should co-ordinate...and I suspect most of the time having
> multiple apps trying to concurrently issue conflicting Telemetry request
> would be a matter of wrong platform configuration/setup (similarly to
> what would happen by running together all the lovely varied network
> configiratio solution on a Linux box...)
> 
> As said the Kernel SHOULD NOT care, going back to the networking example
> Kernel indeed does NOT active policy netlink access..you are free to shot
> into your foot...
> 
> Anyway, co-ordinating access to the Telemetry resources in userspace can
> be a pain, so the the generation counter is an optional mechanism to be
> alerted when some of the Telemetry has been changed, so that userspace
> can spot that something odd is happening (if it was unexpected) and
> avoid to sample and analyze bogus data...
> 
> The generic event support upon which this is based, it is meant to
> support future events like relaying notifications to userspace...but
> given that notifs were NOT implemented for real, it is not present (NOR
> the related ABI...)
> 
Ok. That explanation makes sense.  Given it effects how userspace will
be written against this stack (maybe assuming folk don't just bind a single
daemon process to it) it does have to be there fairly early. Maybe
a follow up to the initial set like the stuff for already events.

Anyhow, add this info to the patch description!

Jonathan

> Thanks,
> Cristian