On Wed, Feb 26, 2025 at 05:44:56PM +0800, Peng Fan (OSS) wrote: > From: Peng Fan <peng.fan@xxxxxxx> > > 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
