On Tue, Feb 18, 2025 at 10:24:52AM +0000, Sudeep Holla wrote:
On Tue, Feb 18, 2025 at 09:09:49AM +0800, Peng Fan wrote:
quoted
A potential solution is not using reg in the protocol nodes. Define nodes
as below:
devperf {
compatible ="arm,scmi-devperf";
}
cpuperf {
compatible ="arm,scmi-cpuperf";
}
pinctrl {
compatible ="arm,scmi-pinctrl";
}
The reg is coded in driver.
But the upper requires restruction of scmi framework.
Put the above away, could we first purse a simple way first to address
the current bug in kernel? Just as I prototyped here:
https://github.com/MrVan/linux/tree/b4/scmi-fwdevlink-v2
Good luck getting these bindings merged. I don't like it as it is pushing
software policy or issues into to the devicetree. What we have as SCMI
binding is more than required for a firmware interface IMO. So, you are
Would you mind share more info on other cases that SCMI not as firmware
interface?
on your own to get these bindings approved as I am not on board with
these but if you convince DT maintainers, I will have a look at it then
to see if we can make that work really.
The issues are common to SCMI, not i.MX specific.
I just propose potential solutions. You are the SCMI maintainer, there
is no chance to get bindings approved without you.
No more ideas from me. Leave this to you in case you have better solution.
Regards,
Peng
--
Regards,
Sudeep