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

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

[Shenwei Wang]

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

Changes in v5:
 - move the gpio-rpmsg.rst from admin-guide to staging directory after
   discussion with Randy Dunlap.
 - add include files with some code improvements per Bartosz's comments.

Changes in v4:
 - add a documentation to describe the transport protocol per Andrew's
   comments.
 - add a new handler to get the gpio direction.

Changes in v3:
 - fix various format issue and return value check per Peng 's review
   comments.
 - add the logic to also populate the subnodes which are not in the
   device map per Arnaud's request. (in imx_rproc.c)
 - update the yaml per Frank's review comments.

Changes in v2:
 - re-implemented the gpio driver per Linus Walleij's feedback by using
   GPIOLIB_IRQCHIP helper library.
 - fix various format issue per Mathieu/Peng 's review comments.
 - update the yaml doc per Rob's feedback

Cc: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio@vger.kernel.org

Shenwei Wang (5):
  dt-bindings: remoteproc: imx_rproc: Add "rpmsg" subnode support
  remoteproc: imx_rproc: Populate devices under "rpmsg" subnode
  docs: staging: gpio-rpmsg: gpio over rpmsg bus
  gpio: imx-rpmsg: add imx-rpmsg GPIO driver
  arm64: dts: imx8ulp: Add rpmsg node under imx_rproc

 .../bindings/remoteproc/fsl,imx-rproc.yaml    | 123 +++++
 Documentation/staging/gpio-rpmsg.rst          | 202 ++++++++
 Documentation/staging/index.rst               |   1 +
 arch/arm64/boot/dts/freescale/imx8ulp.dtsi    |  27 +
 drivers/gpio/Kconfig                          |  17 +
 drivers/gpio/Makefile                         |   1 +
 drivers/gpio/gpio-imx-rpmsg.c                 | 475 ++++++++++++++++++
 drivers/remoteproc/imx_rproc.c                | 146 ++++++
 include/linux/rpmsg/imx_rpmsg.h               |  48 ++
 9 files changed, 1040 insertions(+)
 create mode 100644 Documentation/staging/gpio-rpmsg.rst
 create mode 100644 drivers/gpio/gpio-imx-rpmsg.c
 create mode 100644 include/linux/rpmsg/imx_rpmsg.h

--
2.43.0

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

[Peng Fan]

Hi Shenwei

> 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.

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

[Arnaud POULIQUEN]

Hi,

On 11/5/25 02:12, Peng Fan wrote:
> Hi Shenwei
> 
>> 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.

Thanks,
Arnaud

> 
> Thanks
> Peng.

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

[Shenwei Wang]

Hi Arnaud,

> -----Original Message-----
> From: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
> Sent: Wednesday, November 5, 2025 4:26 AM
> To: Peng Fan <peng.fan@nxp.com>; Shenwei Wang <shenwei.wang@nxp.com>;
> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
> <mathieu.poirier@linaro.org>; Rob Herring <robh@kernel.org>; Krzysztof
> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Shawn
> Guo <shawnguo@kernel.org>; Sascha Hauer <s.hauer@pengutronix.de>;
> Jonathan Corbet <corbet@lwn.net>; Linus Walleij <linus.walleij@linaro.org>;
> Bartosz Golaszewski <brgl@bgdev.pl>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> <festevam@gmail.com>; 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 <linux-imx@nxp.com>; Randy Dunlap
> <rdunlap@infradead.org>; Andrew Lunn <andrew@lunn.ch>; linux-
> gpio@vger.kernel.org
> Subject: [EXT] Re: [PATCH v5 0/5] Enable Remote GPIO over RPMSG on i.MX
> Platform
> Hi,
> 
> On 11/5/25 02:12, Peng Fan wrote:
> > Hi Shenwei
> >
> >> 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. 
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. 

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

Thanks,
Shenwei 

> Thanks,
> Arnaud
> 
> >
> > Thanks
> > Peng.

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

[Arnaud POULIQUEN]

Hi Shenwei,

On 11/5/25 15:12, Shenwei Wang wrote:
> Hi Arnaud,
> 
>> -----Original Message-----
>> From: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
>> Sent: Wednesday, November 5, 2025 4:26 AM
>> To: Peng Fan <peng.fan@nxp.com>; Shenwei Wang <shenwei.wang@nxp.com>;
>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>> <mathieu.poirier@linaro.org>; Rob Herring <robh@kernel.org>; Krzysztof
>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Shawn
>> Guo <shawnguo@kernel.org>; Sascha Hauer <s.hauer@pengutronix.de>;
>> Jonathan Corbet <corbet@lwn.net>; Linus Walleij <linus.walleij@linaro.org>;
>> Bartosz Golaszewski <brgl@bgdev.pl>
>> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>> <festevam@gmail.com>; 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 <linux-imx@nxp.com>; Randy Dunlap
>> <rdunlap@infradead.org>; Andrew Lunn <andrew@lunn.ch>; linux-
>> gpio@vger.kernel.org
>> Subject: [EXT] Re: [PATCH v5 0/5] Enable Remote GPIO over RPMSG on i.MX
>> Platform
>> Hi,
>>
>> On 11/5/25 02:12, Peng Fan wrote:
>>> Hi Shenwei
>>>
>>>> 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.
> 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.
> 
> 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.

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.


Thanks,
Arnaud

> 
> Thanks,
> Shenwei
> 
>> Thanks,
>> Arnaud
>>
>>>
>>> Thanks
>>> Peng.
> 

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

[Shenwei Wang]

Hi Arnaud,

> -----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 <andersson@kernel.org>; Mathieu Poirier
> <mathieu.poirier@linaro.org>; Rob Herring <robh@kernel.org>; Krzysztof
> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Shawn
> Guo <shawnguo@kernel.org>; Sascha Hauer <s.hauer@pengutronix.de>;
> Jonathan Corbet <corbet@lwn.net>; Linus Walleij <linus.walleij@linaro.org>;
> Bartosz Golaszewski <brgl@bgdev.pl>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> <festevam@gmail.com>; 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 <linux-imx@nxp.com>; Randy Dunlap
> <rdunlap@infradead.org>; Andrew Lunn <andrew@lunn.ch>; 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:
> > Hi Arnaud,
> >
> >> -----Original Message-----
> >>
> >> On 11/5/25 02:12, Peng Fan wrote:
> >>> Hi Shenwei
> >>>
> >>>> 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.
> > 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.
> >
> > 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.

> 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. 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. 

Thanks,
Shenwei

> 
> Thanks,
> Arnaud
> 
> >
> > Thanks,
> > Shenwei
> >
> >> Thanks,
> >> Arnaud
> >>
> >>>
> >>> Thanks
> >>> Peng.
> >

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

[Arnaud POULIQUEN]

hi Shenwei

On 11/6/25 17:26, Shenwei Wang wrote:
> Hi Arnaud,
> 
>> -----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 <andersson@kernel.org>; Mathieu Poirier
>> <mathieu.poirier@linaro.org>; Rob Herring <robh@kernel.org>; Krzysztof
>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Shawn
>> Guo <shawnguo@kernel.org>; Sascha Hauer <s.hauer@pengutronix.de>;
>> Jonathan Corbet <corbet@lwn.net>; Linus Walleij <linus.walleij@linaro.org>;
>> Bartosz Golaszewski <brgl@bgdev.pl>
>> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>> <festevam@gmail.com>; 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 <linux-imx@nxp.com>; Randy Dunlap
>> <rdunlap@infradead.org>; Andrew Lunn <andrew@lunn.ch>; 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:
>>> Hi Arnaud,
>>>
>>>> -----Original Message-----
>>>>
>>>> On 11/5/25 02:12, Peng Fan wrote:
>>>>> Hi Shenwei
>>>>>
>>>>>> 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.
>>> 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.
>>>
>>> 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.
> 
>> 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
> 
>>
>> Thanks,
>> Arnaud
>>
>>>
>>> Thanks,
>>> Shenwei
>>>
>>>> Thanks,
>>>> Arnaud
>>>>
>>>>>
>>>>> Thanks
>>>>> Peng.
>>>
> 

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

[Andrew Lunn]

> 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...

There might also be some ideas which can be take from greybus. It also
implements remote devices over a communication medium. 

	Andrew

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

[Shenwei Wang]

> -----Original Message-----
> From: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
> Sent: Friday, November 7, 2025 11:18 AM
> To: Shenwei Wang <shenwei.wang@nxp.com>; Peng Fan <peng.fan@nxp.com>;
> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
> <mathieu.poirier@linaro.org>; Rob Herring <robh@kernel.org>; Krzysztof
> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Shawn
> Guo <shawnguo@kernel.org>; Sascha Hauer <s.hauer@pengutronix.de>;
> Jonathan Corbet <corbet@lwn.net>; Linus Walleij <linus.walleij@linaro.org>;
> Bartosz Golaszewski <brgl@bgdev.pl>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> <festevam@gmail.com>; 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 <linux-imx@nxp.com>; Randy Dunlap
> <rdunlap@infradead.org>; Andrew Lunn <andrew@lunn.ch>; linux-
> gpio@vger.kernel.org
> Subject: [EXT] Re: [PATCH v5 0/5] Enable Remote GPIO over RPMSG 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.
> >>> 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.
> >>>
> >>> 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.
> >
> >> 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

The channel_device_map is used to control the order in which devices are populated.
This mechanism is key to implementing the probe-defer feature for the GPIO driver.
For those who don't care about the probe DEFER, you don't need to put the devices in the map.

> > 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?
>

This follows a standard DTS population approach. Regardless of how the code is organized,
you need the logic somewhere to populate the devices. Placing the "rpmsg" bus under the
remoteproc node is more straightforward because the bus depends on the remote processor.

>
> 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?
>

The implementation is actually based on the rpmsg_virtio_bus. The rpmsg_send
Will finally call virtio_rpmsg_send.

Thanks,
Shenwei

> 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.infr/
> adead.org%2Fpipermail%2Flinux-arm-kernel%2F2025-
> October%2F1069154.html&data=05%7C02%7Cshenwei.wang%40nxp.com%7C0
> 2b24edd459f4d349b2608de1e21b45d%7C686ea1d3bc2b4c6fa92cd99c5c301635
> %7C0%7C0%7C638981327288728022%7CUnknown%7CTWFpbGZsb3d8eyJFbXB
> 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI
> sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=KHeu3GVR%2BYvFnNh%2FgwizEr
> bu%2B0UnwkB5vf%2BuLrRQReE%3D&reserved=0
>
> >
> > Thanks,
> > Shenwei
> >
> >>
> >> Thanks,
> >> Arnaud
> >>
> >>>
> >>> Thanks,
> >>> Shenwei
> >>>
> >>>> Thanks,
> >>>> Arnaud
> >>>>
> >>>>>
> >>>>> Thanks
> >>>>> Peng.
> >>>
> >