Thread (50 messages) 50 messages, 6 authors, 2025-06-20

Re: [PATCH 1/4] firmware: arm_scmi: bus: Bypass setting fwnode for scmi cpufreq

From: Peng Fan <hidden>
Date: 2025-02-20 00:59:46
Also in: arm-scmi, imx, linux-gpio, lkml

On Wed, Feb 19, 2025 at 10:17:46AM +0000, Sudeep Holla wrote:
On Tue, Feb 18, 2025 at 09:36:19PM +0800, Peng Fan wrote:
quoted
On Tue, Feb 18, 2025 at 10:24:52AM +0000, Sudeep Holla wrote:
quoted
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?
quoted
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.
I am not blocking you. What I mentioned is I don't agree that DT can be used
to resolve this issue, but I don't have time or alternate solution ATM. So
if you propose DT based solution and the maintainers agree for the proposed
bindings I will take a look and help you to make that work. But I will raise
any objections I may have if the proposal has issues mainly around the
compatibility and ease of maintenance.
Sorry, if I misunderstood.

I will give a look on this and propose a RFC.

DT maintainers may ask for a patchset including binding change and
driver changes to get a whole view on the compatible stuff.

BTW, Cristian, Saravana if you have any objections/ideas or would take on this
effort, please let me know.

Thanks,
Peng
quoted
No more ideas from me. Leave this to you in case you have better solution.
Unfortunately no, I don't have one. I haven't had time to sit and explore
the issue and think of any solution yet.

--
Regards,
Sudeep
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help