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: <Z87sGF_jHKau_FMe@bogus>
Date: Mon, 10 Mar 2025 13:41:44 +0000
From: Sudeep Holla <sudeep.holla@....com>
To: Peng Fan <peng.fan@....com>
Cc: "Peng Fan (OSS)" <peng.fan@....nxp.com>,
	Sudeep Holla <sudeep.holla@....com>,
	Cristian Marussi <cristian.marussi@....com>,
	Saravana Kannan <saravanak@...gle.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Aisheng Dong <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" <arm-scmi@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"imx@...ts.linux.dev" <imx@...ts.linux.dev>
Subject: Re: [PATCH 1/4] firmware: arm_scmi: bus: Bypass setting fwnode for
 scmi cpufreq

On Mon, Mar 10, 2025 at 11:59:33AM +0000, Sudeep Holla wrote:
> On Mon, Mar 10, 2025 at 10:45:44AM +0000, Peng Fan wrote:
> > > Subject: Re: [PATCH 1/4] firmware: arm_scmi: bus: Bypass setting
> > > fwnode for scmi cpufreq
> > > 
> > > On Thu, Feb 20, 2025 at 08:59:18AM +0800, Peng Fan wrote:
> > > >
> > > > 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.
> > > >
> > > 
> > > Can you point me to the DTS with which you are seeing this issue ?
> > > I am trying to reproduce the issue but so far not successful. I did move
> > > to power-domains for CPUFreq on Juno. IIUC all we need is both
> > > cpufreq and performance genpd drivers in the kernel and then GPU
> > > using perf genpd fails with probe deferral right ? I need pointers to
> > > reproduce the issue so that I can check if what I have cooked up as a
> > > solution really works.
> >
> > This is in downstream tree:
> > https://github.com/nxp-imx/linux-imx/blob/lf-6.6.y/arch/arm64/boot/dts/freescale/imx95.dtsi#L2971
> > https://github.com/nxp-imx/linux-imx/blob/lf-6.6.y/arch/arm64/boot/dts/freescale/imx95.dtsi#L3043
> > https://github.com/nxp-imx/linux-imx/blob/lf-6.6.y/arch/arm64/boot/dts/freescale/imx95.dtsi#L80
> >
> > we are using "power-domains" property for cpu perf and gpu/vpu perf.
> >
> > If cpufreq.off=1 is set in bootargs, the vpu/gpu driver will defer probe.
> >
> 
> OK, does the probe of these drivers get called or they don't as the driver
> core doesn't allow that ? I just have a dummy driver for mali on Juno
> which just does dev_pm_domain_attach_list() in the probe and it seem to
> succeed even when cpufreq.off=1 is passed. I see scmi-cpufreq failing
> with -ENODEV as expected.
> 
> I need to follow the code and check if I can somehow reproduce. Also are
> you sure this is not with anything in the downstream code ? Also have you
> tried this with v6.14-rc* ? Are you sure all the fw_devlink code is backported
> in the tree you pointed me which is v6.6-stable ?
> 

I even tried the above branch, but no luck. The above is neither latest
stable version nor pure stable. It has few extra patches backported
though IIUC. Anyways any pointers to enable me to reproduce the issue
would be much appreciated.

-- 
Regards,
Sudeep