The RPMsg is comm channel between two CPUs in system. The main reason why do you want to use it is its master-side support in Linux kernel.

It is quite natural reuse of VirtIO subsystem however I don't understand some design decisions yet.

• Both IMX and STM uses fixed size MAX_RPMSG_BUF_SIZE=512 which is compile time constant (!). Regular question on support forums is how to enlarge it. Why not from DM ?

• Usage from userspace is not easy. There is drivers/rpmsg/rpmsg_char.c driver but it doesn't bind to rpmsg bus automatically. There is /sys/bus/rpmsg/devices/virtio0.chrdev.-1.1/driver_override which can be used to bind rpmsg_char to the channel. I used this patch to bind all chrdev named channels to it.

  @@ -532,9 +533,11 @@ static void rpmsg_chrdev_remove(struct rpmsg_device *rpdev)
      put_device(&ctrldev->dev);
   }
  
  +static const struct rpmsg_device_id id_table[2] = { { "chrdev" }, { "" } };
   static struct rpmsg_driver rpmsg_chrdev_driver = {
      .probe = rpmsg_chrdev_probe,
      .remove = rpmsg_chrdev_remove,
  +       .id_table = id_table,
      .drv = {
          .name = "rpmsg_chrdev",
      },
  

• Is there any reason not to use VirtIO of type network ? It is well optimized, can use MAC for addressing, no size restrictions, userspace control via sockets. Probably whole existence of RPMsg is because it is allocated from defined DMA-like memory (often SRAM). SKB's on other side are typically in main DRAM.