On 4/28/2026 11:35 PM, Andrew Lunn wrote:
Remote side learns the endpoint when it receives any message from Linux from the dynamic endpoint. Lets say rpmsg_create_ept() allocates a dynamic local ept of 1026. When you send the message from this endpoint, the standard rpmsg header would have: 85 struct rpmsg_hdr { 86 __rpmsg32 src; // 1026 87 __rpmsg32 dst; // rpdev->dst (e.g. 400) 88 __rpmsg32 reserved; 89 __rpmsg16 len; 90 __rpmsg16 flags; 91 u8 data[]; 92 } __packed; Remote side tracks the dynamic endpoint by reading src = 1026. And while sending the response it fills the header as:I've never used rpmsg, so this might be a FAQ. How does the remote side know what the endpoint is to be used for? Here we are talking about GPIO. But the same hardware implements I2C, and a few other things. How do we indicate this endpoint is for GPIO?
That's where the channel level isolation helps. GPIO ports are announced over "rpmsg-io" channel (parent of endpoint), i2c devices would be announced over "rpmsg-i2c" channel. The default epts in those channels would have separate addresses (e.g. 0xd for rpmsg-io and 0xe for rpmsg-i2c). The remote side would have bound a gpio_handling callback on addr 0xd and a i2c_handling callback on addr 0xe while doing the channel announcement. So while sending a GPIO msg from Linux, we should direct it to 0xd dst endpoint, and for sending a i2c message, we should direct it to 0xe dst endpoint (src ept can be anything). And without any extra effort, messages sent from dynamic epts at Linux land in the appropriate handler at remote even for separate device types.
Maybe also related, this hardware also supports a number of GPIO controllers. There has been some argument about if one endpoint should support multiple GPIO controllers.
IMO no...
Or, like gpio-virtio, one endpoint represents one GPIO controller, and you instantiate multiple endpoints, one per controller.
Yes, this is what I am suggesting in the review of this version. Basically there should be one rpmsg channel per device type (e.g. gpio/i2c), and multiple rpmsg endpoints in one channel representing each instance of the device (e.g. gpio1, gpio2 etc.)
How can you tell the different instances of GPIO endpoints apart when they are dynamically created?
Well by 2 ways: 1. We can maintain a map of the dynamically created ept and its corresponding instance number.This is useful while sending a message for a particular instance. 2. rpmsg_create_ept() takes a private data argument, so we just bind the per-instance data (struct rpmsg_gpio_port * in this case) to the ept. This is useful while receiving a message for a particular instance. I have suggested an implementation for the same here: https://lore.kernel.org/all/[email protected]/ Thanks, Beleswar
