linux-kernel - RE: [PATCH 1/5] remoteproc: imx_rproc: Simplify clock enable logic using dcfg flags

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:
 <PAXPR04MB8459216DAA827DB05BF675AA8811A@PAXPR04MB8459.eurprd04.prod.outlook.com>
Date: Fri, 19 Sep 2025 02:02:33 +0000
From: Peng Fan <peng.fan@....com>
To: Daniel Baluta <daniel.baluta@...il.com>
CC: Bjorn Andersson <andersson@...nel.org>, Mathieu Poirier
	<mathieu.poirier@...aro.org>, Shawn Guo <shawnguo@...nel.org>, Sascha Hauer
	<s.hauer@...gutronix.de>, Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>, Frank Li <frank.li@....com>, Daniel
 Baluta <daniel.baluta@....com>, "linux-remoteproc@...r.kernel.org"
	<linux-remoteproc@...r.kernel.org>, "imx@...ts.linux.dev"
	<imx@...ts.linux.dev>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/5] remoteproc: imx_rproc: Simplify clock enable logic
 using dcfg flags

Hi Daniel,

> Subject: Re: [PATCH 1/5] remoteproc: imx_rproc: Simplify clock enable
> logic using dcfg flags
> > +       /* Remote core is under control of Linux or clock is not
> > + managed by firmware */
> 
> I see that you negate the comment from imx_rproc_clk_enable but
> with the negation OR becomes AND.
> 
> So, the comment should be:
> 
> /* Handle clocks when remote core is under control of Linux AND the
> clocks are not managed by remote side  FW */

I thought this flag is clear that clk should be managed by driver.
I will update the comment.

> 
> Also, do we really need this flag?
> Shouldn't we just make a decision based on the fact that clk is in the
> device tree or not?

From hardware perspective, there is always clk for the remote cores.
So DT describe hardware, a clk property should be there.

But NXP system firmware manages the CLK automatically, no need
driver to do that.  So this flag is required here.

Thanks,
Peng.

> 
> > +       if (dcfg->flags & IMX_RPROC_NEED_CLKS) {
> > +               priv->clk = devm_clk_get_enabled(dev, NULL);
> > +               if (IS_ERR(priv->clk))
> > +                       return dev_err_probe(dev, PTR_ERR(priv->clk),
> > + "Failed to enable clock\n");