Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4;
Date:   Wed, 11 Oct 2023 14:40:03 +0100
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
Message-ID: <20231011134003.lhb5yiicgr5cbzr2@bogus>
References: <20231010022911.4106863-1-peng.fan@oss.nxp.com>
 <20231010091223.rvcyrgbjcrmjzmvp@bogus>
 <ZSUXu65bOYVG689E@pluto>
 <20231010093509.ddy75og4jd72n6cq@bogus>
 <PA4PR04MB94859C7729B19C8B88541F8692CCA@PA4PR04MB9485.eurprd04.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <PA4PR04MB94859C7729B19C8B88541F8692CCA@PA4PR04MB9485.eurprd04.prod.outlook.com>
Precedence: bulk

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