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

[Marek Vasut <marex@nabladev.com>]

On 7/15/26 6:22 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:
>>>>>>
>>>>>> 	if (!strcmp(it.node->name, "rsc-table") ||
>>>>>> 	    !strcmp(it.node->name, "vdev0vring0") ||
>>>>>> 	    !strcmp(it.node->name, "vdev0vring1") ||
>>>>>> 	    strstarts(res.name, "vdev0buffer"))
>>>>>> 		continue;
>>>>>>
>>>>>> Because this node is named "vdevbuffer" instead of "vdev0buffer", it appears
>>>>>> it will be mapped as a generic carveout via ioremap_wc() and unintentionally
>>>>>> included in the remoteproc coredump.
>>>>>>
>>>>>> Could this node be renamed to "vdev0buffer" to avoid wasting vmalloc space
>>>>>> and bloating the coredump?
>>>>>
>>>>> Look like make sense, please check it.
>>>>>
>>>>> It is not good to use node-name as ABI. Laurentiu is working on use
>>>>> memory-region-namses.
>>>> The memory regionss are referenced from imx8mm-cm4 { } node via the
>>>> memory-region property:
>>>>
>>>> memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>;
>>>
>>> I known, but now code parser node-name, At your case, it.node->name is
>>> vdevbuffer, but driver expected vdev0buffer.  so above check will be failure.
>>>
>>> suppose it should be
>>>
>>>    vdevbuffer: vdev0buffer@b8400000
>>>                ^^^^^^^^^^^
>>>
>>> I know it is bad, but waiting for Laurentiu to fix it.
>> Actually, if I look at "git log -p drivers/remoteproc/imx_rproc.c" in
>> current linux-next 20260714 , which has the entire history of imx_rproc.c
>> and the latest content, the code cited by the AI:
>>
>> "
>> 	if (!strcmp(it.node->name, "rsc-table") ||
>> 	    !strcmp(it.node->name, "vdev0vring0") ||
>> 	    !strcmp(it.node->name, "vdev0vring1") ||
>> 	    strstarts(res.name, "vdev0buffer"))
>> 		continue;
>> "
>>
>> 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 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 ?

Thank you for your help !