Re: [PATCH] firmware: arm_scmi: clock: Relax check in scmi_clock_protocol_init

[Sudeep Holla]

On Tue, Mar 24, 2026 at 04:32:55PM +0100, Geert Uytterhoeven wrote:
> Hi Cristian,
> 
> On Tue, 24 Mar 2026 at 15:35, Cristian Marussi <cristian.marussi@xxxxxxx> wrote:
> > On Tue, Mar 24, 2026 at 02:15:36PM +0100, Geert Uytterhoeven wrote:
> > > On Tue, 24 Mar 2026 at 09:41, Cristian Marussi <cristian.marussi@xxxxxxx> wrote:
> > > > Looking at the spec 3.6.2.5 CLOCK_ATTRIBUTES
> > > >
> > > > "This command returns the attributes that are associated with a specific clock. An agent might be allowed access to only
> > > > a subset of the clocks available in the system. The platform must thus guarantee that clocks that an agent cannot access
> > > > are not visible to it."
> > > >
> > > > ...not sure if this sheds some light or it is ambiguos anyway...I'd say that
> > > > NOT_FOUND does NOT equate to be invisible...
> > > >
> > > > ...BUT at the same time I think that this practice of exposing a non-contiguos
> > > > set of resources IDs (a set with holes in it) is the a well-known spec-loophole
> > > > used by many vendors to deploy one single FW image across all of their platforms
> > > > without having to reconfigure their reosurces IDs ro expose a common set of
> > > > contiguos IDs like the spec would suggest...
> > > >
> > > > Having said that, since we unfortunately left this door open in the
> > > > implementation, now this loophole has become common practice
> > > > apparently...
> > >
> > > When I first read that paragraph, I was also confused.
> > > What does "not visible" mean?
> > >   - Not present in the clock ID space exposed to that client of
> > >     the system?
> > >     Yeah, multiple different sequences of contiguous IDs, depending
> > >     on client!
> >
> > Yes that is the most spec-compliant interpretation usually; in general
> > across all protocols the SCMI server, through customized enumeration
> > results, should provide a per-agent view of the system: this should help
> > handling shared or virtualized resources, since the agent always see
> > only the 'illusion' provided by the server...
> >
> > ...under this assumption if you dont even need a resource at all (not
> > RW nor RO) you should NOT even be able to see it...this in turn of
> > course means that in order to expose a contiguous set of IDs you should
> > be able to properly configure at build time the FW resources on a per
> > platform basis...
> >
> > >   - Return failure on CLOCK_ATTRIBUTES?
> > >     Which is what implementations seem to do.
> >
> > Yes this is what is done leveraging the gap in the implementation...I am
> > not sure that the non-contiguous set of IDs is supported if not by
> > chance as of now :P (especially in other protocols)
> >
> > > The next step in the fun is when the system actually needs to know the
> > > clock rate of such a clock...
> >
> > Well...that seems a bit of wishful thinking ...
> 
> Unfortunately it is real... [cliffhanger, to be continued... :-]
> 

I am late to the discussion. Based on all the discussion so far, I don't
want to rush the clk changes from Cristian that adds the hardening yet.
I won't make it part of my SCMI v7.1 PR. However is it good idea to keep
it in the next so that we can converge towards some solution in v7.2 ?

So, the question is if I add the fixes from Geert[1] to my queue, will it
be a good baseline for all these changes and discussions ?

-- 
Regards,
Sudeep