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 [off-list ref] wrote:

quoted

On Tue, Mar 24, 2026 at 07:49:22AM +0000, Sudeep Holla wrote:

quoted

On Tue, Mar 24, 2026 at 02:24:14PM +0800, Peng Fan (OSS) wrote:

quoted

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