hi Shenwei

On 11/6/25 17:26, Shenwei Wang wrote:

Hi Arnaud,

quoted

-----Original Message-----
From: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
Sent: Thursday, November 6, 2025 4:17 AM
To: Shenwei Wang <shenwei.wang@nxp.com>; Peng Fan <peng.fan@nxp.com>;
Bjorn Andersson [off-list ref]; Mathieu Poirier
[off-list ref]; Rob Herring [off-list ref]; Krzysztof
Kozlowski [off-list ref]; Conor Dooley [off-list ref]; Shawn
Guo [off-list ref]; Sascha Hauer [off-list ref];
Jonathan Corbet [off-list ref]; Linus Walleij [off-list ref];
Bartosz Golaszewski [off-list ref]
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
[off-list ref]; linux-remoteproc@vger.kernel.org;
devicetree@vger.kernel.org; imx@lists.linux.dev; linux-arm-
kernel@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
doc@vger.kernel.org; dl-linux-imx [off-list ref]; Randy Dunlap
[off-list ref]; Andrew Lunn [off-list ref]; linux-
gpio@vger.kernel.org
Subject: [EXT] Re: [PATCH v5 0/5] Enable Remote GPIO over RPMSG on i.MX
Platform

Hi Shenwei,

On 11/5/25 15:12, Shenwei Wang wrote:

quoted

Hi Arnaud,

quoted

-----Original Message-----

On 11/5/25 02:12, Peng Fan wrote:

quoted

Hi Shenwei

quoted

Subject: [PATCH v5 0/5] Enable Remote GPIO over RPMSG on i.MX
Platform

Support the remote devices on the remote processor via the RPMSG
bus on i.MX platform.

I have not look into the details of new version, but before that,
just want to check, have we agreed on what Arnaud suggested?
or continue to proceed to be this as i.MX specific?

Thanks, Peng, for pointing this out. Regarding the V3 discussions, it
seems that I am not the only one suggesting a generic driver.

As I mentioned before, the only i.MX-specific part is the transport protocol over

the RPMSG bus.

quoted

In this v5 patches, we’ve included detailed documentation for the
protocol in a separate file. Any platform that follows the same protocol should

work right out of the box.

quoted

If you spot anything that could be improved, please let me know!

My concerns remain the same as those shared previously:

1) The simpler one: gpio-imx-rpmsg.c should be renamed to gpio-rpmsg.c.

Agree. Will fix it in the next version.

quoted

2) The more complex one: the driver should be independent of the remoteproc
driver. The rpmsg protocol relies on virtio and can be used in contexts other than
remoteproc. In other words, the struct rpmsg_driver and its associated
operations should be defined within the rpmsg-gpio driver, not in the remoteproc
driver.

The GPIO driver operates independently of the remoteproc driver. 

The channel_device_map table in imx_rproc.c would give me the opposite 
feeling

It functions based

on the defined GPIO-RPMSG transport protocol. Any remoteproc that supports
this protocol can exchange data with the GPIO driver via the underlying rpmsg bus.
Placing the rpmsg_driver (which manages the rpmsg channel) within the remoteproc
driver is more logical, as rpmsg channels run on the rpmsg bus. This bus is defined inside
the remoteproc device tree node and is populated by the corresponding remoteproc driver.

Regarding imx_of_rpmsg_node_init(), It seems you rely on device tree in 
the rproc platform to register rpmsg drivers. This implies you are 
creating drivers based on a device description. To me, this does not 
appear to be a valid implementation, but perhaps such an approach 
already exists in the Linux kernel?


For your information, I'm facing a similar issue with my remoteproc_tee 
series [1]. The advice I received was to look at the PCIe DT 
implementation (I haven't had time to explore it yet). This advice also 
seems relevant to your series.

Do you also have a look to rpmsg_virtio_bus ? it seems a good candidate 
to match the device tree properties with the rpmsg device?

In the end, this is my point of view. Perhaps it is better to wait for 
others before deciding on the direction...

Thanks,
Arnaud

[1]https://lists.infradead.org/pipermail/linux-arm-kernel/2025-October/1069154.html

Thanks,
Shenwei

quoted

Thanks,
Arnaud

quoted

Thanks,
Shenwei

quoted

Thanks,
Arnaud

quoted

Thanks
Peng.