Message-ID: <Z8BRFezgiWDtmdd4@pluto>
Date: Thu, 27 Feb 2025 11:48:51 +0000
From: Cristian Marussi <cristian.marussi@....com>
To: "Peng Fan (OSS)" <peng.fan@....nxp.com>
Cc: sudeep.holla@....com, cristian.marussi@....com, saravanak@...gle.com,
	robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
	arm-scmi@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	Peng Fan <peng.fan@....com>
Subject: Re: [RFC] dt-bindings: firmware: scmi: Introduce compatible string

On Wed, Feb 26, 2025 at 05:44:56PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@....com>
> 
> Add compatible string for the protocols by adding new nodes
> The current nodename pattern is "protocol@[0-9a-f]+$", the new node

Hi Peng,

> name will be "scmi-[a-z\-]+$".
> With compatible string and new nodename, cpufreq and devfreq could be
> separated into two nodes. And fwdevlink could correctly link suppliers
> and consumers.

beside the backward compatibility issues that Rob mentioned, the thing
that worries me most is that, while the current bindings describe the
SCMI protocols because the protocols are WHAT the platform FW exposes
(and that is all that is needed by drivers to refer to a protocol and
its resources)...here you are getting rid of all of this, and moving to
describe basically the various devices that will use a protocol,
potentially the same protocol, just to have a distinct fw_node ...
(...I mean my understanding is that there wont be any protocol nodes
left when the scmi- variant are present and, once, somehow, we will
have transitioned into this...right ?)

I haven't really had the time to go through properly your proposed
solution to understand fully all its possible side-effects and how
many SCMI features could be destroyed by removing protocol nodes
descriptor as a whole...but...off the top of my head, as a quick
example, how you will define a per-protocol dedicated transport
channel in this new scenario ?
...because You wont have anymore a protocol descriptor where to fit
this AND you could have multiple DT nodes describing drivers that use
that SAME protocol, so using this new nodes to fit the same
transport-chan descriptors wont be possible either....

IOW, sincerely, I understand you want to resolve the problem with
fw_devlink (me too), but nuking down everything, while loosing, possibly,
a number of the existing functionalities of the SCMI stack just to make
it work with fw_devlink at all cost it does not seem to me an acceptable
trade-off...

...killing the whole existing protocols descriptors structure seems to
me a recipe for disaster, also because, it just goes against the very
essence of the objects that the FW exposes and the bindings can describe:
as an example, the SCMI platform server manage and exposes PERF_PROTOCOL
and its related DOMAINS (all fully discoverable without any bindings),
so, THAT is what is described in the bindings and referred by SCMI driver
users: SCMI FW does NOT handle/expose TWO distinct perf devices, like the
cpufreq/devfreq-device that you are trying to describe...

As Sudeep mentioned, IMHO this seems mostly an *unsolved* implementation
problem more than an actual issue with the bindings and how we describe
SCMI resources that we need to refer to..

> With compatible string, and driver updated.
> - Differnet vendor drivers with same SCMI protocol ID could be built in
>   without concerning vendor A's driver got probed when using vendor B's
>   SoC

as said, this is a corner case that is easily solvable with the current
layout (and I will post a patch soon-ish to addess this...)

> - NXP scmi pinctrl and ARM scmi pinctrl could be both built in, without
>   concerning arm scmi platform takes nxp scmi pinctrl node as supplier.
> 

..the only real issue is the general fw_devlink issue as in cpufreq vs
devfreq...

Thanks,
Cristian

Powered by blists - more mailing lists