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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250218133619.GA22647@nxa18884-linux>
Date: Tue, 18 Feb 2025 21:36:19 +0800
From: Peng Fan <peng.fan@....nxp.com>
To: Sudeep Holla <sudeep.holla@....com>
Cc: Cristian Marussi <cristian.marussi@....com>,
	Saravana Kannan <saravanak@...gle.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Dong Aisheng <aisheng.dong@....com>,
	Fabio Estevam <festevam@...il.com>, Shawn Guo <shawnguo@...nel.org>,
	Jacky Bai <ping.bai@....com>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Sascha Hauer <s.hauer@...gutronix.de>, arm-scmi@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-gpio@...r.kernel.org, imx@...ts.linux.dev,
	Peng Fan <peng.fan@....com>
Subject: Re: [PATCH 1/4] firmware: arm_scmi: bus: Bypass setting fwnode for
 scmi cpufreq

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:
>> 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
>