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: <20241230020519.GE28662@localhost.localdomain>
Date: Mon, 30 Dec 2024 10:05:19 +0800
From: Peng Fan <peng.fan@....nxp.com>
To: Sudeep Holla <sudeep.holla@....com>
Cc: Cristian Marussi <cristian.marussi@....com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Saravana Kannan <saravanak@...gle.com>,
	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 Fri, Dec 27, 2024 at 03:13:06PM +0000, Sudeep Holla wrote:
>On Wed, Dec 25, 2024 at 04:20:44PM +0800, Peng Fan (OSS) wrote:
>> From: Peng Fan <peng.fan@....com>
>>
>> Two drivers scmi_cpufreq.c and scmi_perf_domain.c both use
>> SCMI_PROTCOL_PERF protocol, but with different name, so two scmi devices
>> will be created. But the fwnode->dev could only point to one device.
>>
>> If scmi cpufreq device created earlier, the fwnode->dev will point to
>> the scmi cpufreq device. Then the fw_devlink will link performance
>> domain user device(consumer) to the scmi cpufreq device(supplier).
>> But actually the performance domain user device, such as GPU, should use
>> the scmi perf device as supplier. Also if 'cpufreq.off=1' in bootargs,
>> the GPU driver will defer probe always, because of the scmi cpufreq
>> device not ready.
>>
>> Because for cpufreq, no need use fw_devlink. So bypass setting fwnode
>> for scmi cpufreq device.
>>
>> Fixes: 96da4a99ce50 ("firmware: arm_scmi: Set fwnode for the scmi_device")
>> Signed-off-by: Peng Fan <peng.fan@....com>
>> ---
>>  drivers/firmware/arm_scmi/bus.c | 15 ++++++++++++++-
>>  1 file changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
>> index 157172a5f2b577ce4f04425f967f548230c1ebed..12190d4dabb65484543044b4424fbe3b67245466 100644
>> --- a/drivers/firmware/arm_scmi/bus.c
>> +++ b/drivers/firmware/arm_scmi/bus.c
>> @@ -345,6 +345,19 @@ static void __scmi_device_destroy(struct scmi_device *scmi_dev)
>>  	device_unregister(&scmi_dev->dev);
>>  }
>>
>> +static int
>> +__scmi_device_set_node(struct scmi_device *scmi_dev, struct device_node *np,
>> +		       int protocol, const char *name)
>> +{
>> +	/* cpufreq device does not need to be supplier from devlink perspective */
>> +	if ((protocol == SCMI_PROTOCOL_PERF) && !strcmp(name, "cpufreq"))
>> +		return 0;
>>
>
>This is just a assumption based on current implementation. What happens
>if this is needed. Infact, it is used in the current implementation to
>create a dummy clock provider, so for sure with this change that will
>break IMO.

If cpufreq needs the deivce_node, it will be parsed as a supplier from
devlink view. Then come to the issue, multiple scmi devices match one
of node, Saravana replied before in below thread

https://lore.kernel.org/arm-scmi/CAGETcx8m48cy-EzP6_uoGN7KWsQw=CfZWQ-hNUzz_7LZ0voG8A@mail.gmail.com/

So quote here
"
The best fw_devlink could do is just not enforce any dependencies if
there is more than one device instantiated for a given supplier DT
node.
"

Since we are here that fw_devlink not support multiple devices match one
of node and will not support(per my understanding), what scmi part could
do is: only set of node to the scmi device that needs to be supplier

Or we introduce compatible string to scmi node, and subnodes if
one protocol supports mutilple function, such as cpufreq and device performance
using PERF protocol. But this needs big change to scmi framework.

Thanks
Peng

>
>--
>Regards,
>Sudeep