Re: [PATCH v4 4/6] arm64: dts: imx8mm: imx8mp: Add CM DTOs for Data Modul i.MX8M Mini and Plus eDM SBC

[Frank Li <Frank.li@oss.nxp.com>]

On Thu, Jul 16, 2026 at 01:30:17AM +0200, Marek Vasut wrote:
> On 7/15/26 11:37 PM, Frank Li wrote:
>
> Hello Frank,
>
> > > > > > > > > [Severity: Medium]
> > > > > > > > > Will this node name bypass the driver's carveout exclusion logic?
> > > > > > > > >
> > > > > > > > > Looking at imx_rproc_prepare(), it iterates over memory-regions and checks
> > > > > > > > > specifically for the name "vdev0buffer" to skip processing the vdev buffer:
> > > > > > > > >
> > ...
> > > > >
> > > > > never existed in imx_rproc.c:
> > > >
> > > > AI refer old version code, but problem is the same
> > >
> > > No, sorry, the aforementioned piece of code never existed in imx_rproc.c
> > > according to git log. There is no old version of the code that looked
> > > anything like what the AI produced above.
> > >
> > > > if (strstarts(res.name, "vdev0buffer"))
> > > >
> > > > >
> > > > > "
> > > > > $ git log --follow -p next/master -- drivers/remoteproc/imx_rproc.c | grep
> > > > > vdev0vring1
> > > >     ^^^^^^^^^^
> > > >
> > > > vdev0buffer
> > >
> > > The AI generated review content above does refer to vdev0vring1 , which is a
> >
> > No, AI talk about "vdev0buffer" at beginning, never said vdev0vring1 at all.
>
> This is the code the AI quoted in the review feedback:
>
> "
> 	if (!strcmp(it.node->name, "rsc-table") ||
> 	    !strcmp(it.node->name, "vdev0vring0") ||
> 	    !strcmp(it.node->name, "vdev0vring1") || <-------- HERE
> 	    strstarts(res.name, "vdev0buffer"))
> 		continue;
> "
>
> It does not matter which identifier we use to look up the AI quoted code
> snippet in git log, the important point is, that the aforementioned code
> snippet never existed in the Linux kernel as far as I can tell.
>
> But as far as I understand this, I should adjust the DT to cover the test in
> the aforementioned non-existent code snippet ?

AI is not 100% accurate. Need focus on the problem itself. AI find the
problem, vdev0buffer, not vdevbuffer, which is really existed at kernel
code, which use strstarts(res.name, "vdev0buffer").

But AI's provide reason or create refer code is wrong, like what you quoted
AI review feedback.

The same problem, AI provide difference report at
https://lore.kernel.org/imx/20260715071741.79CA81F000E9@smtp.kernel.org/

Or another words,  AI found the real problem, but provide partial correct
reason.

We focus on the problem itself, not partial wrong part of reason.

Frank

>
> > "   Looking at imx_rproc_prepare(), it iterates over memory-regions and checks
> >     specifically for the name "vdev0buffer" to skip processing the vdev buffer:
> > "
> >
> > > unique identifier, but that unique identifier exists only once is the entire
> > > history of drivers/remoteproc/imx_rproc.c and that is as a code comment .
> > > That proves my point that the aforementioned AI generated review feedback is
> > > not based on code that ever existed in the kernel.
> > >
> > > > >       vdev regions are vdev0vring0, vdev0vring1, vdevbuffer and similar.
> > > > > "
> > > > >
> > > > > It seems the AI hallucinated something which is not based in reality ?
> > > >
> > > > git log --follow -p linux-next/master -- drivers/remoteproc/imx_rproc.c | grep vdev0buffer
> > > > -		if (!strcmp(it.node->name, "vdev0buffer"))
> > > > +		if (strstarts(res.name, "vdev0buffer"))
> > >
> > > "
> > > if (strstarts(res.name, "vdev0buffer"))
> > > "
> > >
> > > and
> > >
> > > "
> > > 	    strstarts(res.name, "vdev0buffer"))
> > > "
> > >
> > > looks like different code , and the AI reported "strstarts(res.name,
> > > "vdev0buffer"))" which never existed in drivers/remoteproc/imx_rproc.c as is
> > > clearly visible from the command output you shared above.
> > >
> > > So, what exactly is the problem here , can you please clarify it without
> > > referencing the AI generated content above ?
> >
> > The problem is simple, node name should use
> >
> > 	vdevbuffer: vdev0buffer@b8400000
> >                          ^
> I see.