RE: [PATCH V3] remoteproc: imx_rproc: Ignore create mem entry for resource table

From: Peng Fan <peng.fan@nxp.com>
To: Mathieu Poirier <mathieu.poirier@linaro.org>,
	"Peng Fan (OSS)" <peng.fan@oss.nxp.com>
Cc: "bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>,
	"shawnguo@kernel.org" <shawnguo@kernel.org>,
	"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
	"linux-remoteproc@vger.kernel.org"
	<linux-remoteproc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"festevam@gmail.com" <festevam@gmail.com>,
	dl-linux-imx <linux-imx@nxp.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: RE: [PATCH V3] remoteproc: imx_rproc: Ignore create mem entry for resource table
Date: Fri, 15 Apr 2022 02:47:38 +0000	[thread overview]
Message-ID: <DU0PR04MB941769592D17F5E590803B3C88EE9@DU0PR04MB9417.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <20220414161003.GA698343@p14s>

> Subject: Re: [PATCH V3] remoteproc: imx_rproc: Ignore create mem entry for
> resource table
> 
> On Thu, Mar 31, 2022 at 04:40:07PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > Resource table is used by Linux to get information pubished by
> 
> s/pubished/published

Fix in v4.

> 
> > remote processor. It should be not be used for memory allocation, so
> > not create rproc mem entry.
> >
> > Fixes: b29b4249f8f0 ("remoteproc: imx_rproc: add i.MX specific parse
> > fw hook")
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> >
> > V3:
> >  Update commit log
> >  Update Fixes tag
> >
> > V2:
> >  Add Fixes tag
> >  Separate the patch from
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> > hwork.kernel.org%2Fproject%2Flinux-
> remoteproc%2Fpatch%2F20220111033333
> > .403448-7-
> peng.fan%40oss.nxp.com%2F&amp;data=04%7C01%7Cpeng.fan%40nxp.
> >
> com%7C091803e93988488b2cbc08da1e313fe7%7C686ea1d3bc2b4c6fa92cd99c
> 5c301
> >
> 635%7C0%7C0%7C637855494116073554%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wL
> >
> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;s
> data
> >
> =TDWgH8DNxGTQsen64f6Bqvr5t%2FmB7bA8qOF6Q9TlP34%3D&amp;reserved=
> 0
> >  Address typo
> >
> >  drivers/remoteproc/imx_rproc.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/remoteproc/imx_rproc.c
> > b/drivers/remoteproc/imx_rproc.c index 7a096f1891e6..f2bfc9077c19
> > 100644
> > --- a/drivers/remoteproc/imx_rproc.c
> > +++ b/drivers/remoteproc/imx_rproc.c
> > @@ -423,6 +423,9 @@ static int imx_rproc_prepare(struct rproc *rproc)
> >  		if (!strcmp(it.node->name, "vdev0buffer"))
> >  			continue;
> >
> > +		if (!strncmp(it.node->name, "rsc-table", strlen("rsc-table")))
> > +			continue;
> > +
> 
> Any reason the handling of vdev0buffer is using strcmp() and the resource table
> strncmp()?

I thought rsc-table0/1 maybe there for cm40/cm41, but rsc-table should also be
ok, will use strcmp in v4.

Thanks,
Peng.

> 
> Thanks,
> Mathieu
> 
> >  		rmem = of_reserved_mem_lookup(it.node);
> >  		if (!rmem) {
> >  			dev_err(priv->dev, "unable to acquire memory-
> region\n");
> > --
> > 2.25.1
> >