Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver

["Padhi, Beleswar" <b-padhi@ti.com>]

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/29485742-6e49-482e-b73d-228295daaeec@ti.com/

Thanks,
Beleswar