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: <CAEnQRZC34KuJZDcv3TLJQrOcT9NFsYtD9q5Rj6+5MUKSBub6-w@mail.gmail.com>
Date: Fri, 19 Sep 2025 11:25:38 +0300
From: Daniel Baluta <daniel.baluta@...il.com>
To: Peng Fan <peng.fan@....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

On Fri, Sep 19, 2025 at 5:02 AM Peng Fan <peng.fan@....com> wrote:
>
> 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.


OK, makes sense. Thanks. With comment changed you can add my

Reviewed-by: Daniel Baluta <daniel.baluta@....com>


thanks,
Daniel.