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

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

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...)

Thanks,
Cristian