Re: [EXT] Re: [RFC] firmware: arm_scmi: clock: add fixed clock attribute support

From: Sudeep Holla <sudeep.holla@arm.com>
To: Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com>
Cc: Cristian Marussi <cristian.marussi@arm.com>,
	"Peng Fan (OSS)" <peng.fan@oss.nxp.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"souvik.chakravarty@arm.com" <souvik.chakravarty@arm.com>,
	Glen G Wienecke <glen.wienecke@nxp.com>,
	Peng Fan <peng.fan@nxp.com>
Subject: Re: [EXT] Re: [RFC] firmware: arm_scmi: clock: add fixed clock attribute support
Date: Wed, 11 Oct 2023 14:40:03 +0100	[thread overview]
Message-ID: <20231011134003.lhb5yiicgr5cbzr2@bogus> (raw)
In-Reply-To: <PA4PR04MB94859C7729B19C8B88541F8692CCA@PA4PR04MB9485.eurprd04.prod.outlook.com>

On Wed, Oct 11, 2023 at 03:54:59AM +0000, Ranjani Vaidyanathan wrote:
> From what I see SCMI clock protocol could benefit from an attribute for the
> clock that describes what operations are possible on a clock. There are many
> bus clocks that only the SCMI server manages and the error code DENIED
> should be handled gracefully by the agent.
>

Agreed, but we need to understand if we need it per operation basis or
at the higher granularity such as any write or set operations not allowed.
Just my initial thoughts, we can discuss.

> In the case of Linux, perhaps this should be handled by the SCMI clock
> driver, instead of allowing the error to propagate up the Linux clock
> framework?

Yes but even for that we need information from the firmware.

> It seems strange that the SCMI server should swallow the error (silently
> fail) only for certain agents.

I am bit confused by this statement. The SCMI server/platform must not
ignore or fail silently. Since the agent is not allowed, if it attempts
it must return the apt error.

While Linux may choose to ignore the error but I think this is what
we are discussing to figure out what is the best way to avoid it or
worst case handle it gracefully. With any extra info from the firmware,
the former option must be possible and we need not think of the latter
option IMO.

> I would think this would make debug quite difficult and having a "DENIED"
> error code not very useful.
>

Agreed especially if it can and is expected to continue functioning as normal.

-- 
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel