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

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

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@nxp.com>

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.

Fixes: 0d8b0c8068a8f ("firmware: arm_scmi: Harden clock protocol initialization")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 drivers/firmware/arm_scmi/clock.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/arm_scmi/clock.c b/drivers/firmware/arm_scmi/clock.c
index 082fb0db8681aed7fa30ffb915a8c61530fc5c2d..49ceebae53107fb79a8a07d644c5682a6f704d2f 100644
--- a/drivers/firmware/arm_scmi/clock.c
+++ b/drivers/firmware/arm_scmi/clock.c
@@ -1253,8 +1253,11 @@ static int scmi_clock_protocol_init(const struct scmi_protocol_handle *ph)
 	for (clkid = 0; clkid < cinfo->num_clocks; clkid++) {
 		cinfo->clkds[clkid].id = clkid;
 		ret = scmi_clock_attributes_get(ph, clkid, cinfo);
-		if (ret)
+		if (ret) {
+			if (ret == -ENOENT)
+				continue;
 			return ret;
+		}
 
 		ret = scmi_clock_describe_rates_get(ph, clkid, cinfo);
 		if (ret)

---
base-commit: 09c0f7f1bcdbc3c37a5a760cbec76bf18f278406
change-id: 20260324-scmi-clock-fix-v1-b935e04f9243

Best regards,
-- 
Peng Fan <peng.fan@nxp.com>

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

[Sudeep Holla]

On Tue, Mar 24, 2026 at 02:24:14PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
> 
> 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 ?


-- 
Regards,
Sudeep

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

[Cristian Marussi]

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:
> > From: Peng Fan <peng.fan@nxp.com>
> > 

Hi,

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

...I am more concerned about the impact that this COULD have on underlying
resources allocations that at the driver level was certainly conceived
to manage a contiguos set of IDs, even though it was certanly the
usecase until my harden patches...so it could be safe but to be double
checked...

Quirk or core I suppose it depends on how much we want to 'legalize' this
trick for the future (thinking also about other protocols)...

...a middle ground could be to implement it as an always-on quirk that
matches any FW (like the existing out_of_spec_triplet quirk)... as a way
to keep on allowing the existing behaviour but sort of discouraging it...

Not really strong opinions about this, BUT at this point, in general I
would keep all of this series on hold for further testing, given these
issues together the bugs fixed by Geert on iterators and the lack of
clock-MAINTs acks...

...also Geert was investigating the need of a different quirks in these
regards for the Renesas boards...

Thanks,
Cristian

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

[Geert Uytterhoeven]

Hi Cristian,

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!
  - Return failure on CLOCK_ATTRIBUTES?
    Which is what implementations seem to do.

The next step in the fun is when the system actually needs to know the
clock rate of such a clock...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Cristian Marussi]

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

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

[Geert Uytterhoeven]

Hi Cristian,

On Tue, 24 Mar 2026 at 15:35, Cristian Marussi <cristian.marussi@arm.com> 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@arm.com> 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... :-]

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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@arm.com> 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@arm.com> 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

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

[Cristian Marussi]

On Wed, Mar 25, 2026 at 12:06:15PM +0000, Sudeep Holla wrote:
> On Tue, Mar 24, 2026 at 04:32:55PM +0100, Geert Uytterhoeven wrote:
> > Hi Cristian,
> > 

Hi Sudeep,

> > On Tue, 24 Mar 2026 at 15:35, Cristian Marussi <cristian.marussi@arm.com> 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@arm.com> 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.

Agreed, the whole series with the iterators and hardening needs fixes from
Geert upfront...

> 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 ?

Yes having my iterator series plus Geert fixes on top would be a good
starting point to have a sane kernel...then we'll see how many quirks or
de-Hardening will be needed on top of that to make all firmware
survive...

I will re-test on my side in the coming days but anything that goes on
linux-next from your next of course has a more broad audience...

Thanks,
Cristian 

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

[Sudeep Holla]

On Tue, Mar 24, 2026 at 08:18:54AM +0000, Cristian Marussi 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:
> > > From: Peng Fan <peng.fan@nxp.com>
> > > 
> 
> Hi,
> 
> > > 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...
> 

Indeed, I agree. I wasn't fully convinced to relax and this discussion
seem to strive towards right direction IMO.

> ...I am more concerned about the impact that this COULD have on underlying
> resources allocations that at the driver level was certainly conceived
> to manage a contiguos set of IDs, even though it was certanly the
> usecase until my harden patches...so it could be safe but to be double
> checked...
> 
> Quirk or core I suppose it depends on how much we want to 'legalize' this
> trick for the future (thinking also about other protocols)...
> 

Agreed. I am more nervous about legalising it. Let us see what are the
issues with the firmware in the wild before we can decide. That's one reason
I would like keep your changes in -next even though I have now dropped the
idea of pushing in for v7.1

> ...a middle ground could be to implement it as an always-on quirk that
> matches any FW (like the existing out_of_spec_triplet quirk)... as a way
> to keep on allowing the existing behaviour but sort of discouraging it...
> 

Fair enough, worth an attempt at the least.

> Not really strong opinions about this, BUT at this point, in general I
> would keep all of this series on hold for further testing, given these
> issues together the bugs fixed by Geert on iterators and the lack of
> clock-MAINTs acks...
> 

Agreed.

> ...also Geert was investigating the need of a different quirks in these
> regards for the Renesas boards...
> 

Yes still waiting for the outcome from the cliffhanger Geert left us 😉.
Just kidding take your time Geert, no rush.

-- 
Regards,
Sudeep