This patch series introduces the RPMSG Ethernet driver, which provides a
virtual Ethernet interface for communication between a host processor and
a remote processor using the RPMSG framework. The driver enables
Ethernet-like packet transmission and reception over shared memory,
facilitating inter-core communication in systems with heterogeneous
processors.

Key features of this driver:

1. Virtual Ethernet interface using RPMSG framework
2. Shared memory-based packet transmission and reception
3. Support for multicast address filtering
4. Dynamic MAC address assignment
5. NAPI support for efficient packet processing
6. State machine for managing interface states

This driver is designed to be generic and vendor-agnostic. Vendors can
develop firmware for the remote processor to make it compatible with this
driver by adhering to the shared memory layout and communication protocol
described in the documentation.

This patch series has been tested on a TI AM64xx platform with a
compatible remote processor firmware. Feedback and suggestions for
improvement are welcome.

Changes from v3 to v4:
- Addressed comments from Parthiban Veerasooran regarding return values in
  patch 4/7
- Added "depends on REMOTEPROC" in Kconfig entry for RPMSG_ETH as it uses a
  symbol from REMOTEPROC driver.

Changes from v2 to v3:
- Removed the binding patches as suggested by Krzysztof Kozlowski <krzk@kernel.org>
- Dropped the rpmsg-eth node. The shared memory region is directly added to the
  "memory-region" in rproc device.
- Added #include <linux/io.h> header for memory mapping operations
- Added vendor-specific configuration through rpmsg_eth_data structure
- Added shared memory region index support with shm_region_index parameter
- Changed RPMSG channel name from generic "shm-eth" to vendor-specific "ti.shm-eth"
- Fixed format string warning using %zu instead of %lu for size_t type
- Updated Documentation to include shm_region_index
- Added MAINTAINERS entry for the driver

v3 https://lore.kernel.org/all/20250908090746.862407-1-danishanwar@ti.com/
v2 https://lore.kernel.org/all/20250902090746.3221225-1-danishanwar@ti.com/
v1 https://lore.kernel.org/all/20250723080322.3047826-1-danishanwar@ti.com/

MD Danish Anwar (7):
  net: rpmsg-eth: Add Documentation for RPMSG-ETH Driver
  net: rpmsg-eth: Add basic rpmsg skeleton
  net: rpmsg-eth: Register device as netdev
  net: rpmsg-eth: Add netdev ops
  net: rpmsg-eth: Add support for multicast filtering
  MAINTAINERS: Add entry for RPMSG Ethernet driver
  arch: arm64: dts: k3-am64*: Add shared memory region

 .../device_drivers/ethernet/index.rst         |   1 +
 .../device_drivers/ethernet/rpmsg_eth.rst     | 424 ++++++++++++
 MAINTAINERS                                   |   6 +
 arch/arm64/boot/dts/ti/k3-am642-evm.dts       |  11 +-
 drivers/net/ethernet/Kconfig                  |  11 +
 drivers/net/ethernet/Makefile                 |   1 +
 drivers/net/ethernet/rpmsg_eth.c              | 653 ++++++++++++++++++
 drivers/net/ethernet/rpmsg_eth.h              | 294 ++++++++
 8 files changed, 1399 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/networking/device_drivers/ethernet/rpmsg_eth.rst
 create mode 100644 drivers/net/ethernet/rpmsg_eth.c
 create mode 100644 drivers/net/ethernet/rpmsg_eth.h


base-commit: 1f24a240974589ce42f70502ccb3ff3f5189d69a
-- 
2.34.1

On 9/11/25 6:36 AM, MD Danish Anwar wrote:
> This patch series introduces the RPMSG Ethernet driver, which provides a
> virtual Ethernet interface for communication between a host processor and
> a remote processor using the RPMSG framework. The driver enables
> Ethernet-like packet transmission and reception over shared memory,
> facilitating inter-core communication in systems with heterogeneous
> processors.
> 

This is neat and all but I have to ask: why? What does this provide
that couldn't be done with normal RPMSG messages? Or from a userspace
TAP/TUN driver on top of RPMSG?

This also feels like some odd layering, as RPMSG sits on virtio, and
we have virtio-net, couldn't we have a firmware just expose that (or
would the firmware be vhost-net..)?

Andrew

> Key features of this driver:
> 
> 1. Virtual Ethernet interface using RPMSG framework
> 2. Shared memory-based packet transmission and reception
> 3. Support for multicast address filtering
> 4. Dynamic MAC address assignment
> 5. NAPI support for efficient packet processing
> 6. State machine for managing interface states
> 
> This driver is designed to be generic and vendor-agnostic. Vendors can
> develop firmware for the remote processor to make it compatible with this
> driver by adhering to the shared memory layout and communication protocol
> described in the documentation.
> 
> This patch series has been tested on a TI AM64xx platform with a
> compatible remote processor firmware. Feedback and suggestions for
> improvement are welcome.
> 
> Changes from v3 to v4:
> - Addressed comments from Parthiban Veerasooran regarding return values in
>    patch 4/7
> - Added "depends on REMOTEPROC" in Kconfig entry for RPMSG_ETH as it uses a
>    symbol from REMOTEPROC driver.
> 
> Changes from v2 to v3:
> - Removed the binding patches as suggested by Krzysztof Kozlowski <krzk@kernel.org>
> - Dropped the rpmsg-eth node. The shared memory region is directly added to the
>    "memory-region" in rproc device.
> - Added #include <linux/io.h> header for memory mapping operations
> - Added vendor-specific configuration through rpmsg_eth_data structure
> - Added shared memory region index support with shm_region_index parameter
> - Changed RPMSG channel name from generic "shm-eth" to vendor-specific "ti.shm-eth"
> - Fixed format string warning using %zu instead of %lu for size_t type
> - Updated Documentation to include shm_region_index
> - Added MAINTAINERS entry for the driver
> 
> v3 https://lore.kernel.org/all/20250908090746.862407-1-danishanwar@ti.com/
> v2 https://lore.kernel.org/all/20250902090746.3221225-1-danishanwar@ti.com/
> v1 https://lore.kernel.org/all/20250723080322.3047826-1-danishanwar@ti.com/
> 
> MD Danish Anwar (7):
>    net: rpmsg-eth: Add Documentation for RPMSG-ETH Driver
>    net: rpmsg-eth: Add basic rpmsg skeleton
>    net: rpmsg-eth: Register device as netdev
>    net: rpmsg-eth: Add netdev ops
>    net: rpmsg-eth: Add support for multicast filtering
>    MAINTAINERS: Add entry for RPMSG Ethernet driver
>    arch: arm64: dts: k3-am64*: Add shared memory region
> 
>   .../device_drivers/ethernet/index.rst         |   1 +
>   .../device_drivers/ethernet/rpmsg_eth.rst     | 424 ++++++++++++
>   MAINTAINERS                                   |   6 +
>   arch/arm64/boot/dts/ti/k3-am642-evm.dts       |  11 +-
>   drivers/net/ethernet/Kconfig                  |  11 +
>   drivers/net/ethernet/Makefile                 |   1 +
>   drivers/net/ethernet/rpmsg_eth.c              | 653 ++++++++++++++++++
>   drivers/net/ethernet/rpmsg_eth.h              | 294 ++++++++
>   8 files changed, 1399 insertions(+), 2 deletions(-)
>   create mode 100644 Documentation/networking/device_drivers/ethernet/rpmsg_eth.rst
>   create mode 100644 drivers/net/ethernet/rpmsg_eth.c
>   create mode 100644 drivers/net/ethernet/rpmsg_eth.h
> 
> 
> base-commit: 1f24a240974589ce42f70502ccb3ff3f5189d69a

Hi Andrew,

On 11/09/25 9:34 pm, Andrew Davis wrote:
> On 9/11/25 6:36 AM, MD Danish Anwar wrote:
>> This patch series introduces the RPMSG Ethernet driver, which provides a
>> virtual Ethernet interface for communication between a host processor and
>> a remote processor using the RPMSG framework. The driver enables
>> Ethernet-like packet transmission and reception over shared memory,
>> facilitating inter-core communication in systems with heterogeneous
>> processors.
>>
> 
> This is neat and all but I have to ask: why? What does this provide
> that couldn't be done with normal RPMSG messages? Or from a userspace
> TAP/TUN driver on top of RPMSG?
> 

This is different from RPMSG because here I am not using RPMSG to do the
actual TX / RX. RPMSG is only used to share information (tx / rx
offsets, buffer size, etc) between driver and firmware. The TX / RX
happens in the shared memory. This implementation uses a shared memory
circular buffer with head/tail pointers for efficient data passing
without copies between cores.

> This also feels like some odd layering, as RPMSG sits on virtio, and
> we have virtio-net, couldn't we have a firmware just expose that (or
> would the firmware be vhost-net..)?
> 

PMSG sits on virtio, and we do have virtio-net but I am not trying to do
ethernet communication over RPMSG. RPMSG is only used to exchange
information between cores regarding the shared memory where the actual
ethernet communication happens.

> Andrew
> 


-- 
Thanks and Regards,
Danish

On 9/17/25 6:44 AM, MD Danish Anwar wrote:
> Hi Andrew,
> 
> On 11/09/25 9:34 pm, Andrew Davis wrote:
>> On 9/11/25 6:36 AM, MD Danish Anwar wrote:
>>> This patch series introduces the RPMSG Ethernet driver, which provides a
>>> virtual Ethernet interface for communication between a host processor and
>>> a remote processor using the RPMSG framework. The driver enables
>>> Ethernet-like packet transmission and reception over shared memory,
>>> facilitating inter-core communication in systems with heterogeneous
>>> processors.
>>>
>>
>> This is neat and all but I have to ask: why? What does this provide
>> that couldn't be done with normal RPMSG messages? Or from a userspace
>> TAP/TUN driver on top of RPMSG?
>>
> 
> This is different from RPMSG because here I am not using RPMSG to do the
> actual TX / RX. RPMSG is only used to share information (tx / rx
> offsets, buffer size, etc) between driver and firmware. The TX / RX
> happens in the shared memory. This implementation uses a shared memory

This is how RPMSG is supposed to be used, it is meant for small messages
and signaling, bulk data should be send out-of-band. We have examples
specifically showing how this should be done when using RPMSG[0], and our
RPMSG backed frameworks do the same (like DSP audio[1] and OpenVX[2]).

> circular buffer with head/tail pointers for efficient data passing
> without copies between cores.
> 
>> This also feels like some odd layering, as RPMSG sits on virtio, and
>> we have virtio-net, couldn't we have a firmware just expose that (or
>> would the firmware be vhost-net..)?
>>
> 
> PMSG sits on virtio, and we do have virtio-net but I am not trying to do
> ethernet communication over RPMSG. RPMSG is only used to exchange
> information between cores regarding the shared memory where the actual
> ethernet communication happens.
> 

Again nothing new here, virtio-net does control plane work though a
message channel but the data plane is done using fast shared memory
vqueues with vhost-net[3]. Using RPMSG would just be an extra unneeded
middle layer and cause you to re-implement what is already done with
virtio-net/vhost-net.

Andrew

[0] https://git.ti.com/cgit/rpmsg/rpmsg_char_zerocopy
[1] https://github.com/TexasInstruments/rpmsg-dma
[2] https://github.com/TexasInstruments/tiovx
[3] https://www.redhat.com/en/blog/deep-dive-virtio-networking-and-vhost-net

>> Andrew
>>
> 
>

Hi Andrew

On 17/09/25 10:07 pm, Andrew Davis wrote:
> On 9/17/25 6:44 AM, MD Danish Anwar wrote:
>> Hi Andrew,
>>
>> On 11/09/25 9:34 pm, Andrew Davis wrote:
>>> On 9/11/25 6:36 AM, MD Danish Anwar wrote:
>>>> This patch series introduces the RPMSG Ethernet driver, which
>>>> provides a
>>>> virtual Ethernet interface for communication between a host
>>>> processor and
>>>> a remote processor using the RPMSG framework. The driver enables
>>>> Ethernet-like packet transmission and reception over shared memory,
>>>> facilitating inter-core communication in systems with heterogeneous
>>>> processors.
>>>>
>>>
>>> This is neat and all but I have to ask: why? What does this provide
>>> that couldn't be done with normal RPMSG messages? Or from a userspace
>>> TAP/TUN driver on top of RPMSG?
>>>
>>
>> This is different from RPMSG because here I am not using RPMSG to do the
>> actual TX / RX. RPMSG is only used to share information (tx / rx
>> offsets, buffer size, etc) between driver and firmware. The TX / RX
>> happens in the shared memory. This implementation uses a shared memory
> 
> This is how RPMSG is supposed to be used, it is meant for small messages
> and signaling, bulk data should be send out-of-band. We have examples
> specifically showing how this should be done when using RPMSG[0], and our
> RPMSG backed frameworks do the same (like DSP audio[1] and OpenVX[2]).
> 
>> circular buffer with head/tail pointers for efficient data passing
>> without copies between cores.
>>
>>> This also feels like some odd layering, as RPMSG sits on virtio, and
>>> we have virtio-net, couldn't we have a firmware just expose that (or
>>> would the firmware be vhost-net..)?
>>>
>>
>> PMSG sits on virtio, and we do have virtio-net but I am not trying to do
>> ethernet communication over RPMSG. RPMSG is only used to exchange
>> information between cores regarding the shared memory where the actual
>> ethernet communication happens.
>>
> 
> Again nothing new here, virtio-net does control plane work though a
> message channel but the data plane is done using fast shared memory
> vqueues with vhost-net[3]. Using RPMSG would just be an extra unneeded
> middle layer and cause you to re-implement what is already done with
> virtio-net/vhost-net.
> 

virtio-net provides a solution for virtual ethernet interface in a
virtualized environment. Our use-case here is traffic tunneling between
heterogeneous processors in a non virtualized environment such as TI's
AM64x that has Cortex A53 and Cortex R5 where Linux runs on A53 and a
flavour of RTOS on R5(FreeRTOS) and the ethernet controller is managed
by R5 and needs to pass some low priority data to A53. The data plane is
over the shared memory while the control plane is over RPMsg end point
channel.

We had aligned with Andrew L [1] and the ask was to create a generic
Linux Ethernet driver that can be used for heterogeneous system. Similar
to rpmsg_tty.c. It was suggested to create a new rpmsg_eth.c driver that
can be used for this purpose.

Here I have implemented what was suggested in [1]

[1]
https://lore.kernel.org/all/8f5d2448-bfd7-48a5-be12-fb16cdc4de79@lunn.ch/

> Andrew
> 
> [0] https://git.ti.com/cgit/rpmsg/rpmsg_char_zerocopy
> [1] https://github.com/TexasInstruments/rpmsg-dma
> [2] https://github.com/TexasInstruments/tiovx
> [3] https://www.redhat.com/en/blog/deep-dive-virtio-networking-and-
> vhost-net
> 


-- 
Thanks and Regards,
Danish