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

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

On Tue, Mar 24, 2026 at 02:15:36PM +0100, Geert Uytterhoeven wrote:
> Hi Cristian,

Hi Geert,

> 
> On Tue, 24 Mar 2026 at 09:41, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > On Tue, Mar 24, 2026 at 07:49:22AM +0000, Sudeep Holla wrote:
> > > On Tue, Mar 24, 2026 at 02:24:14PM +0800, Peng Fan (OSS) wrote:
> > > > On i.MX95, the SCMI Clock protocol defines several reserved clock IDs that
> > > > are not backed by real clock devices
> > > > (see arch/arm64/boot/dts/freescale/imx95-clock.h).
> > > >
> > > > For these reserved IDs, the SCMI firmware correctly returns NOT_FOUND in
> > > > response to the CLOCK_ATTRIBUTES command. According to the SCMI Clock
> > > > specification, NOT_FOUND is expected when a clock_id does not correspond to
> > > > a valid clock device.
> > > >
> > > > The recent hardening added in scmi_clock_protocol_init() treats any error
> > > > return as fatal, causing SCMI clock probe to fail and preventing i.MX9
> > > > platforms from booting.
> > > >
> > > > Relax the check so that -ENOENT is treated as a non-fatal condition.
> > >
> > > I understand the use-case and the fix here, but still wonder if this
> > > should be treated as quirk or handle it in the core. I am inclined to
> > > latter as reserved SCMI clock/resource ID seems to be trend in its usage
> > > and hard to classify as quirks.
> > >
> > > Cristain, agree or have a different view ?
> >
> > I was just replying...
> >
> > 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 ...

...sort of a Schrödinger's clock :P .. it is NOT_FOUND but does have rates ?

Thanks,
Cristian