Re: [PATCH v13 1/4] docs: driver-api: gpio: rpmsg gpio driver over rpmsg bus

Re: [PATCH v13 1/4] docs: driver-api: gpio: rpmsg gpio driver over rpmsg bus

[Mathieu Poirier]

On Wed, Apr 22, 2026 at 04:28:46PM -0500, Shenwei Wang wrote:
> Describes the gpio rpmsg transport protocol over the rpmsg bus between
> the remote system and Linux.
> 
> Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
> ---
>  Documentation/driver-api/gpio/gpio-rpmsg.rst | 266 +++++++++++++++++++
>  Documentation/driver-api/gpio/index.rst      |   1 +
>  2 files changed, 267 insertions(+)
>  create mode 100644 Documentation/driver-api/gpio/gpio-rpmsg.rst
> 
> diff --git a/Documentation/driver-api/gpio/gpio-rpmsg.rst b/Documentation/driver-api/gpio/gpio-rpmsg.rst
> new file mode 100644
> index 000000000000..abfde68c9b0a
> --- /dev/null
> +++ b/Documentation/driver-api/gpio/gpio-rpmsg.rst
> @@ -0,0 +1,266 @@
> +.. SPDX-License-Identifier: GPL-2.0-or-later
> +
> +GPIO RPMSG (Remote Processor Messaging) Protocol
> +================================================
> +
> +The GPIO RPMSG transport protocol is used for communication and interaction
> +with GPIO controllers on remote processors via the RPMSG bus.
> +
> +Message Format
> +--------------
> +
> +The RPMSG message consists of a 6-byte packet with the following layout:
> +
> +.. code-block:: none
> +
> +   +-----+-----+-----+-----+-----+----+
> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> +   |type |cmd  |port |line |  data    |
> +   +-----+-----+-----+-----+-----+----+

I will take a final decision on the 'port' field when I'm done reading the
thread on how endpoints should be created.

> +
> +- **type (Message Type)**: The message type can be one of:
> +
> +  - 0: GPIO_RPMSG_SEND
> +  - 1: GPIO_RPMSG_REPLY
> +  - 2: GPIO_RPMSG_NOTIFY
> +
> +- **cmd**: Command code, used for GPIO_RPMSG_SEND messages.
> +
> +- **port**: The GPIO port (bank) index.
> +
> +- **line**: The GPIO line (pin) index of the port.
> +
> +- **data**: See details in the command description below.
> +
> +- **reply err**: Error code from the remote core.
> +
> +  - 0: Success
> +  - 1: General error (Early remote software only returns this unclassified error)
> +  - 2: Not supported (A command is not supported by the remote firmware)
> +  - 3: Resource not available (The resource is not allocated to Linux)
> +  - 4: Resource busy (The resource is already in use)
> +  - 5: Parameter error

No.  The virtio-GPIO specification does not define any of these.  We are not
re-inventing the specification, we are only using it on top of RPMSG.  The only
value for 'status' are VIRTIO_GPIO_STATUS_OK and VIRTIO_GPIO_STATUS_ERR.  Modify
the virtio-GPIO specification if you want to do something like this.

> +
> +
> +GPIO Commands
> +-------------
> +
> +Commands are specified in the **Cmd** field for **GPIO_RPMSG_SEND** (Type=0) messages.
> +
> +The SEND message is always sent from Linux to the remote firmware. Each
> +SEND corresponds to a single REPLY message. The GPIO driver should
> +serialize messages and determine whether a REPLY message is required. If a
> +REPLY message is expected but not received within the specified timeout
> +period (currently 1 second in the Linux driver), the driver should return
> +-ETIMEOUT.
> +
> +GET_DIRECTION (Cmd=2)
> +~~~~~~~~~~~~~~~~~~~~~
> +
> +**Request:**
> +
> +.. code-block:: none
> +
> +   +-----+-----+-----+-----+-----+----+
> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> +   | 0   | 2   |port |line | 0   | 0  |
> +   +-----+-----+-----+-----+-----+----+

'line' should be 16 bit followed by a 32 bit value.

> +
> +**Reply:**
> +
> +.. code-block:: none
> +
> +   +-----+-----+-----+-----+-----+----+
> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> +   | 1   | 2   |port |line | err | dir|
> +   +-----+-----+-----+-----+-----+----+

Same as above, 'line' should be 16 bit.  'err' should be 'status' and 'dir'
should be 'value'.

> +
> +- **err**: See above for definitions.
> +
> +- **dir**: Direction.
> +
> +  - 0: None
> +  - 1: Output
> +  - 2: Input
> +
> +SET_DIRECTION (Cmd=3)
> +~~~~~~~~~~~~~~~~~~~~~
> +
> +**Request:**
> +
> +.. code-block:: none
> +
> +   +-----+-----+-----+-----+-----+----+
> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> +   | 0   | 3   |port |line | dir | 0  |
> +   +-----+-----+-----+-----+-----+----+


Same as above, i.e 'line' is 16 bit follow by a 32 bit value.

> +
> +- **dir**: Direction.
> +
> +  - 0: None
> +  - 1: Output
> +  - 2: Input
> +
> +**Reply:**
> +
> +.. code-block:: none
> +
> +   +-----+-----+-----+-----+-----+----+
> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> +   | 1   | 3   |port |line | err | 0  |
> +   +-----+-----+-----+-----+-----+----+

Same as my reply for GET_DIRECTION.

The same for all the other messages below.  There should be a direct and obvious
connection between this protocol and virtio-gpio.  In fact I'm starting to
wonder if we should have two endpoints per GPIO controller, one for the requestq
and another one for the eventq.  That would make this entire protocol
unecessary.  I will elaborate more later when I read Beleswar and Arnaud's
conversation on that topic.   

> +
> +- **err**: See above for definitions.
> +
> +
> +GET_VALUE (Cmd=4)
> +~~~~~~~~~~~~~~~~~
> +
> +**Request:**
> +
> +.. code-block:: none
> +
> +   +-----+-----+-----+-----+-----+----+
> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> +   | 0   | 4   |port |line | 0   | 0  |
> +   +-----+-----+-----+-----+-----+----+
> +
> +**Reply:**
> +
> +.. code-block:: none
> +
> +   +-----+-----+-----+-----+-----+----+
> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> +   | 1   | 4   |port |line | err | val|
> +   +-----+-----+-----+-----+-----+----+
> +
> +- **err**: See above for definitions.
> +
> +- **val**: Line level.
> +
> +  - 0: Low
> +  - 1: High
> +
> +SET_VALUE (Cmd=5)
> +~~~~~~~~~~~~~~~~~
> +
> +**Request:**
> +
> +.. code-block:: none
> +
> +   +-----+-----+-----+-----+-----+----+
> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> +   | 0   | 5   |port |line | val | 0  |
> +   +-----+-----+-----+-----+-----+----+
> +
> +- **val**: Output level.
> +
> +  - 0: Low
> +  - 1: High
> +
> +**Reply:**
> +
> +.. code-block:: none
> +
> +   +-----+-----+-----+-----+-----+----+
> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> +   | 1   | 5   |port |line | err | 0  |
> +   +-----+-----+-----+-----+-----+----+
> +
> +- **err**: See above for definitions.
> +
> +SET_IRQ_TYPE (Cmd=6)
> +~~~~~~~~~~~~~~~~~~~~
> +
> +**Request:**
> +
> +.. code-block:: none
> +
> +   +-----+-----+-----+-----+-----+----+
> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> +   | 0   | 6   |port |line | val | wk |
> +   +-----+-----+-----+-----+-----+----+
> +
> +- **val**: IRQ types.
> +
> +  - 0: Interrupt disabled
> +  - 1: Rising edge trigger
> +  - 2: Falling edge trigger
> +  - 3: Both edge trigger
> +  - 4: High level trigger
> +  - 8: Low level trigger
> +
> +- **wk**: Wakeup enable.
> +
> +  The remote system should always aim to stay in a power-efficient state by
> +  shutting down or clock-gating the GPIO blocks that aren't in use. Since
> +  the remoteproc driver is responsible for managing the power states of the
> +  remote firmware, the GPIO driver does not require to know the firmware's
> +  running states.
> +
> +  When the wakeup bit is set, the remote firmware should configure the line
> +  as a wakeup source. The firmware should send the notification message to
> +  Linux after it is woken from the GPIO line.
> +
> +  - 0: Disable wakeup from GPIO
> +  - 1: Enable wakeup from GPIO

This is not part of the virtio-GPIO specification.  Again, modify the
virtio-GPIO specification to do this.

> +
> +**Reply:**
> +
> +.. code-block:: none
> +
> +   +-----+-----+-----+-----+-----+----+
> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> +   | 1   | 6   |port |line | err | 0  |
> +   +-----+-----+-----+-----+-----+----+
> +
> +- **err**: See above for definitions.
> +
> +NOTIFY_REPLY (Cmd=10)
> +~~~~~~~~~~~~~~~~~~~~~
> +The reply message for the notification is optional. The remote firmware can
> +implement it to simulate the interrupt acknowledgment behavior.
> +
> +**Request:**
> +
> +.. code-block:: none
> +
> +   +-----+-----+-----+-----+-----+----+
> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> +   | 0   | 10  |port |line |level| 0  |
> +   +-----+-----+-----+-----+-----+----+
> +
> +- **port**: The GPIO port (bank) index.
> +
> +- **line**: The GPIO line (pin) index of the port.
> +
> +- **level**: GPIO line status.


No.  In accordance with the specification, the only thing a device sends when an
interrupt occurs is VIRTIO_GPIO_IRQ_STATUS_VALID, or
VIRTIO_GPIO_IRQ_STATUS_INVALID to return the buffers back to the driver when
interrupts are disabled.


> +
> +Notification Message
> +--------------------
> +
> +Notifications are sent by the remote core and they have
> +**Type=2 (GPIO_RPMSG_NOTIFY)**:
> +

No.  Once again, we are not re-writing the specification.  Virtio-GPIO doesn't
need this so I don't see whey virtio-rpmsg-gpio would.

> +When a GPIO line asserts an interrupt on the remote processor, the firmware
> +should immediately mask the corresponding interrupt source and send a
> +notification message to the Linux. Upon completion of the interrupt
> +handling on the Linux side, the driver should issue a
> +command **SET_IRQ_TYPE** to the firmware to unmask the interrupt.
> +
> +A Notification message can arrive between a SEND and its REPLY message,
> +and the driver is expected to handle this scenario.
> +
> +.. code-block:: none
> +
> +   +-----+-----+-----+-----+-----+----+
> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> +   | 2   | 0   |port |line |type | 0  |
> +   +-----+-----+-----+-----+-----+----+
> +
> +- **port**: The GPIO port (bank) index.
> +
> +- **line**: The GPIO line (pin) index of the port.
> +
> +- **type**: Optional parameter to indicate the trigger event type.
> +
> diff --git a/Documentation/driver-api/gpio/index.rst b/Documentation/driver-api/gpio/index.rst
> index bee58f709b9a..e5eb1f82f01f 100644
> --- a/Documentation/driver-api/gpio/index.rst
> +++ b/Documentation/driver-api/gpio/index.rst
> @@ -16,6 +16,7 @@ Contents:
>     drivers-on-gpio
>     bt8xxgpio
>     pca953x
> +   gpio-rpmsg
>  
>  Core
>  ====
> -- 
> 2.43.0
> 

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

[Arnaud POULIQUEN]

Hi Beleswar,

On 5/4/26 10:17, Beleswar Prasad Padhi wrote:
> Hi Arnaud,
> 
> On 30/04/26 22:10, Arnaud POULIQUEN wrote:
>>
>>
>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>>> Hello Arnaud,
>>>
>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>>> Hello,
>>>>
>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>>>>>
>>>>>> Hi Mathieu,
>>>>>>
>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com> wrote:
>>>>>
> 
> [...]
> 
>>>>>> My mental model looks like this for the complete picture:
>>>>>>
>>>>>> 1. namespace/channel#1 = rpmsg-io
>>>>>>        a. ept1 -> gpio-controller@1
>>>>>>        b. ept2 -> gpio-controller@2
>>>>>>
>>>>>
>>>>> I've asked for one endpoint per GPIO controller since the very
>>>>> beginning.  I don't yet have a strong opinion on whether to use one
>>>>> namespace request per GPIO controller or a single request that spins
>>>>> off multiple endpoints.  I'll have to look at your link and reflect on
>>>>> that.  Regardless of how we proceed on that front, multiplexing needs
>>>>> to happen at the endpoint level rather than the packet level.  This is
>>>>> the only way this work can move forward.
>>>>>
>>>>
>>>> I would be more in favor of Mathieu’s proposal: “An endpoint is created with every namespace request.”
>>>>
>>>> If the endpoint is created only on the Linux side, how do we match the Linux endpoint address with the local port field on the remote side?
>>>
>>>
>>> Simply by sending a message to the remote containing the newly created
>>> endpoint and the port idx. Note that is this done just one time, after this
>>> Linux need not have the port field in the message everytime its sending
>>> a message.
>>>
>>>>
>>>> With a multi-namespace approach, the namespace could be rpmsg-io-[addr], where [addr] corresponds to the GPIO controller address in the DT. This would:
>>>
>>>
>>> You will face the same problem in this case also that you asked above:
>>> "how do we match the Linux endpoint address with the local port field
>>> on the remote side?"
>>
>> Sorry I probably introduced confusion here
>> my sentence should be;
>>   With a multi-namespace approach, the namespace could be rpmsg-io-[port],
>>   where [port] corresponds to the GPIO controller port in the DT.
>>
>>
>> For instance:
>>
>>        rpmsg {
>>          rpmsg-io {
>>            #address-cells = <1>;
>>            #size-cells = <0>;
>>
>>            gpio@25 {
>>              compatible = "rpmsg-gpio";
>>              reg = <25>;
>>              gpio-controller;
>>              #gpio-cells = <2>;
>>              #interrupt-cells = <2>;
>>              interrupt-controller;
>>            };
>>
>>            gpio@32 {
>>              compatible = "rpmsg-gpio";
>>              reg = <32>;
>>              gpio-controller;
>>              #gpio-cells = <2>;
>>              #interrupt-cells = <2>;
>>              interrupt-controller;
>>            };
>>          };
>>        };
>>
>>   rpmsg-io-25  would match with gpio@25
>>   rpmsg-io-32  would match with gpio@32
>>
>>
>>>
>>> Because the endpoint that is created on a namespace request is also
>>> dynamic in nature. How will the remote know which endpoint addr
>>> Linux allocated for a namespace that it announced?
>>>
>>> As an example/PoC, I created a firmware example which announces
>>> 2 name services to Linux, one is the standard "rpmsg_chrdev" and
>>> the other is a TI specific name service "ti.ipc4.ping-pong". You can
>>> see it created 2 different addresses (0x400 and 0x401) for each of
>>> the name service request from the same firmware:
>>>
>>> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
>>> [    9.290275] virtio_rpmsg_bus virtio0: creating channel ti.ipc4.ping-pong addr 0xd
>>> [    9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev addr 0xe
>>> [    9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel formed from src = 0x400 to dst = 0xe
>>> [    9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: new channel: 0x401 -> 0xd!
>>>
>>> So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
>>> Back to same problem. Simple solution is to reply to remote with the
>>> created ept addr and the index.
>>
>> That why I would like to suggest to use the name service field to identify the port/controller, instead of the endpoint address.
>>>   
>>>>
>>>> - match the RPMsg probe with the DT,
>>>
>>>
>>> We can probe from all controllers with a single name service
>>> announcement too.
>>>
>>>> - provide a simple mapping between the port and the endpoint on both sides,
>>>
>>>
>>> We are trying to get rid of this mapping from Linux side to adapt
>>> the gpio-virtio design.
>>>
>>>> - allow multiple endpoints on the remote side,
>>>
>>>
>>> We can support this as well with single nameservice model.
>>> There is no limitation. Remote has to send a message with
>>> its newly created ept that's all.
>>>
>>>> - provide a simple discovery mechanism for remote capabilities.
>>>
>>>
>>> A single announcement: "rpmsg-io" is also discovery mechanism.
>>>
>>> Feel free to let me know if you have concerns with any of the
>>> suggestions!
>>
>> My only concern, whatever the solution, is that we find a smart
>> solution to associate the correct endpoint with the correct GPIO
>> port/controller defined in the DT.
> 
> 
> In my solution, there is no need to have this map of endpoint to
> GPIO port at Linux side. This aligns more with virtio-gpio design
> as well.
> 
>>
>> I may have misunderstood your solution. Could you please help me
>> understand your proposal by explaining how you would handle three
>> GPIO ports defined in the DT, considering that the endpoint
>> addresses on the Linux side can be random?
>> If I assume there is a unique endpoint on the remote side,
>> I do not understand how you can match, on the firmware side,
>> the Linux endpoint address to the GPIO port.
> 
> 
> Sure, let me take an example:
> Assumptions: 3 GPIO ports in DT, 3 endpoints in Linux (one per port),
> 1 endpoint in remote (0xd) and 1 rpmsg channel (rpmsg-io)
> 
>         rpmsg {
>           rpmsg-io {
>             #address-cells = <1>;
>             #size-cells = <0>;
> 
>             gpio@25 {
>               compatible = "rpmsg-gpio";
>               reg = <25>;
>               gpio-controller;
>               #gpio-cells = <2>;
>               #interrupt-cells = <2>;
>               interrupt-controller;
>             };
> 
>             gpio@32 {
>               compatible = "rpmsg-gpio";
>               reg = <32>;
>               gpio-controller;
>               #gpio-cells = <2>;
>               #interrupt-cells = <2>;
>               interrupt-controller;
>             };
> 
>             gpio@35 {
>               compatible = "rpmsg-gpio";
>               reg = <35>;
>               gpio-controller;
>               #gpio-cells = <2>;
>               #interrupt-cells = <2>;
>               interrupt-controller;
>             };
>           };
>         };
> 
> Code Flow:
> 1. "rpmsg-io" channel is announced from remote firmware with unique dst
>      ept = 0xd.
> 
> 2. rpmsg_core.c creates the default dynamic local ept for the channel
>      ept = 0x405.
> 
> 3. rpmsg_core.c assigns the allocated addr to rpdev device:
>      rpdev->src = 0x405 and rpdev->dst = 0xd.
> 
> 4. rpmsg_gpio_channel_probe() is triggered. For *each* of the GPIO ports
>      in DT, it will trigger rpmsg_gpiochip_register() which will now:
>         a. Call port->ept = rpmsg_create_ept(rpdev,
>                                                                     rpmsg_gpio_channel_callback,
>                                                                     port,
>                                                                    {rpdev.id.name,
>                                                                     RPMSG_ADDR_ANY,
>                                                                     RPMSG_ADDR_ANY});
>             Ex- port->ept->addr = 0x408
> 
>         b. Prepare a 8-byte message having 2 fields:
>             port->ept->addr (0x408) and port->idx (25)
> 
>         c. Send this message to remote firmware on default channel ept
>             (0x405 -> 0xd) by:
>             rpmsg_send(rpdev->ept, &message, sizeof(message));
> 
>         d. Remote side receives this message and creates a map of the
>             linux_ept_addr to gpio_port. (0x408 <-> 25)
> 
> 5. After this point, any gpio messages sent from Linux from gpio port
>      endpoints (Ex- 0x408) can be decoded at remote side by looking up
>      its map (Ex- map[0x408] = 25).
> 
> 6. Any messages sent from remote to Linux for a particular gpio port can
>      also be decoded at Linux by simply fetching the priv pointer to get
>      the per-port device:
>      struct rpmsg_gpio_port *port = priv;
>

Thanks for the details!

To sum up:
- the default endpoint acts as the GPIO controller (0x405),
- one extra Linux endpoint is created per port defined in DT.

This should work, but my concerns remain the same:

   1) This implementation forces the remote processor to handle a single
      endpoint instead of one endpoint per port. This may add complexity to
      the remote firmware if each port is managed in a separate thread.

   2) Linux, as a consumer, should not expose its capabilities to the remote
      side (in your proposal it enumerates the ports defined in the DT). 
     In my view, the remote processor should expose its capabilities as the
      provider.

 From my perspective, based on your proposal:
  1) Linux should send a get_config message to the remote proc (0x405 -> 
0xD). 2) The remote processor would respond with the list of ports, 
associated
     with an remote endpoint addresses.
  3) Linux would parse the response, compare it with the DT, enable the GPIO
     ports accordingly, creating it local endpoint and associating it with
     the remote endpoint.
Using name service to identify the ports should avoid step 1 & 2 ...

At the end, whatever solution is implemented, my main concern is that the
Linux driver design should, if possible, avoid adding unnecessary complexity
or limitations on the remote side (for instance in openAMP project).

Thanks,
Arnaud


> So Linux does not need to send the port idx everytime while sending a
> gpio message anymore.
> 
> Thanks,
> Beleswar
> 
> [...]
> 

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

[Beleswar Prasad Padhi]

Hi Arnaud,

On 04/05/26 22:34, Arnaud POULIQUEN wrote:
> Hi Beleswar,
>
> On 5/4/26 10:17, Beleswar Prasad Padhi wrote: 
>

[...]

>>
>>>
>>> I may have misunderstood your solution. Could you please help me
>>> understand your proposal by explaining how you would handle three
>>> GPIO ports defined in the DT, considering that the endpoint
>>> addresses on the Linux side can be random?
>>> If I assume there is a unique endpoint on the remote side,
>>> I do not understand how you can match, on the firmware side,
>>> the Linux endpoint address to the GPIO port.
>>
>>
>> Sure, let me take an example:
>> Assumptions: 3 GPIO ports in DT, 3 endpoints in Linux (one per port),
>> 1 endpoint in remote (0xd) and 1 rpmsg channel (rpmsg-io)
>>
>>         rpmsg {
>>           rpmsg-io {
>>             #address-cells = <1>;
>>             #size-cells = <0>;
>>
>>             gpio@25 {
>>               compatible = "rpmsg-gpio";
>>               reg = <25>;
>>               gpio-controller;
>>               #gpio-cells = <2>;
>>               #interrupt-cells = <2>;
>>               interrupt-controller;
>>             };
>>
>>             gpio@32 {
>>               compatible = "rpmsg-gpio";
>>               reg = <32>;
>>               gpio-controller;
>>               #gpio-cells = <2>;
>>               #interrupt-cells = <2>;
>>               interrupt-controller;
>>             };
>>
>>             gpio@35 {
>>               compatible = "rpmsg-gpio";
>>               reg = <35>;
>>               gpio-controller;
>>               #gpio-cells = <2>;
>>               #interrupt-cells = <2>;
>>               interrupt-controller;
>>             };
>>           };
>>         };
>>
>> Code Flow:
>> 1. "rpmsg-io" channel is announced from remote firmware with unique dst
>>      ept = 0xd.
>>
>> 2. rpmsg_core.c creates the default dynamic local ept for the channel
>>      ept = 0x405.
>>
>> 3. rpmsg_core.c assigns the allocated addr to rpdev device:
>>      rpdev->src = 0x405 and rpdev->dst = 0xd.
>>
>> 4. rpmsg_gpio_channel_probe() is triggered. For *each* of the GPIO ports
>>      in DT, it will trigger rpmsg_gpiochip_register() which will now:
>>         a. Call port->ept = rpmsg_create_ept(rpdev,
>>                                                                     rpmsg_gpio_channel_callback,
>>                                                                     port,
>>                                                                    {rpdev.id.name,
>>                                                                     RPMSG_ADDR_ANY,
>>                                                                     RPMSG_ADDR_ANY});
>>             Ex- port->ept->addr = 0x408
>>
>>         b. Prepare a 8-byte message having 2 fields:
>>             port->ept->addr (0x408) and port->idx (25)
>>
>>         c. Send this message to remote firmware on default channel ept
>>             (0x405 -> 0xd) by:
>>             rpmsg_send(rpdev->ept, &message, sizeof(message));
>>
>>         d. Remote side receives this message and creates a map of the
>>             linux_ept_addr to gpio_port. (0x408 <-> 25)
>>
>> 5. After this point, any gpio messages sent from Linux from gpio port
>>      endpoints (Ex- 0x408) can be decoded at remote side by looking up
>>      its map (Ex- map[0x408] = 25).
>>
>> 6. Any messages sent from remote to Linux for a particular gpio port can
>>      also be decoded at Linux by simply fetching the priv pointer to get
>>      the per-port device:
>>      struct rpmsg_gpio_port *port = priv;
>>
>
> Thanks for the details!
>
> To sum up:
> - the default endpoint acts as the GPIO controller (0x405),
> - one extra Linux endpoint is created per port defined in DT.
>
> This should work, but my concerns remain the same:
>
>   1) This implementation forces the remote processor to handle a single
>      endpoint instead of one endpoint per port. This may add complexity to
>      the remote firmware if each port is managed in a separate thread. 


A. Not really, I just chose 1 remote endpoint for this example as you
    suggested to. We can scale it for two-way communication via the
    get_config message like you suggested below.

B. Isn't it a bad design of the firmware if it is handling 10 gpio ports
    in 10 threads? The logic to handle all the ports is the same, only
    the parameters (e.g. line number, msg) is different.

>
>   2) Linux, as a consumer, should not expose its capabilities to the remote
>      side (in your proposal it enumerates the ports defined in the DT).     In my view, the remote processor should expose its capabilities as the
>      provider. 


Agreed on this.

>
> From my perspective, based on your proposal:
>  1) Linux should send a get_config message to the remote proc (0x405 -> 0xD). 2) The remote processor would respond with the list of ports, associated
>     with an remote endpoint addresses. 


Agreed, we can scale it for multiple remote endpoints like this.

>  3) Linux would parse the response, compare it with the DT, enable the GPIO
>     ports accordingly, creating it local endpoint and associating it with
>     the remote endpoint.
> Using name service to identify the ports should avoid step 1 & 2 ... 


Yes, but won't that make a lot of hard-codings in the driver?

+static struct rpmsg_device_id rpmsg_gpio_channel_id_table[] = {
+    { .name = "rpmsg-io-25" },
+    { .name = "rpmsg-io-32" },
+    { .name = "rpmsg-io-35" },
+    { },
+};

What if tomorrow another vendor decides to add more remoteproc
controlled GPIO ports to Linux, they would have to update this struct in
the driver everytime. And the port indexes (25/32/35) could also differ
between vendors. We should make the driver dynamic i.e. vendor
agnostic.

I think querying the remote firmware at runtime (step 1 & 2 above) is a
common design pattern and makes the driver vendor agnostic. But feel
free to correct me.

>
> At the end, whatever solution is implemented, my main concern is that the
> Linux driver design should, if possible, avoid adding unnecessary complexity
> or limitations on the remote side (for instance in openAMP project). 


Yes definitely, I want the same. Feel free to let me know if this does
not suit with the OpenAMP project.

Thanks,
Beleswar

>
> Thanks,
> Arnaud
>
>
>> So Linux does not need to send the port idx everytime while sending a
>> gpio message anymore.
>>
>> Thanks,
>> Beleswar
>>
>> [...]
>>
>

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

[Arnaud POULIQUEN]

Hi Beleswar

On 5/5/26 07:25, Beleswar Prasad Padhi wrote:
> Hi Arnaud,
> 
> On 04/05/26 22:34, Arnaud POULIQUEN wrote:
>> Hi Beleswar,
>>
>> On 5/4/26 10:17, Beleswar Prasad Padhi wrote:
>>
> 
> [...]
> 
>>>
>>>>
>>>> I may have misunderstood your solution. Could you please help me
>>>> understand your proposal by explaining how you would handle three
>>>> GPIO ports defined in the DT, considering that the endpoint
>>>> addresses on the Linux side can be random?
>>>> If I assume there is a unique endpoint on the remote side,
>>>> I do not understand how you can match, on the firmware side,
>>>> the Linux endpoint address to the GPIO port.
>>>
>>>
>>> Sure, let me take an example:
>>> Assumptions: 3 GPIO ports in DT, 3 endpoints in Linux (one per port),
>>> 1 endpoint in remote (0xd) and 1 rpmsg channel (rpmsg-io)
>>>
>>>          rpmsg {
>>>            rpmsg-io {
>>>              #address-cells = <1>;
>>>              #size-cells = <0>;
>>>
>>>              gpio@25 {
>>>                compatible = "rpmsg-gpio";
>>>                reg = <25>;
>>>                gpio-controller;
>>>                #gpio-cells = <2>;
>>>                #interrupt-cells = <2>;
>>>                interrupt-controller;
>>>              };
>>>
>>>              gpio@32 {
>>>                compatible = "rpmsg-gpio";
>>>                reg = <32>;
>>>                gpio-controller;
>>>                #gpio-cells = <2>;
>>>                #interrupt-cells = <2>;
>>>                interrupt-controller;
>>>              };
>>>
>>>              gpio@35 {
>>>                compatible = "rpmsg-gpio";
>>>                reg = <35>;
>>>                gpio-controller;
>>>                #gpio-cells = <2>;
>>>                #interrupt-cells = <2>;
>>>                interrupt-controller;
>>>              };
>>>            };
>>>          };
>>>
>>> Code Flow:
>>> 1. "rpmsg-io" channel is announced from remote firmware with unique dst
>>>       ept = 0xd.
>>>
>>> 2. rpmsg_core.c creates the default dynamic local ept for the channel
>>>       ept = 0x405.
>>>
>>> 3. rpmsg_core.c assigns the allocated addr to rpdev device:
>>>       rpdev->src = 0x405 and rpdev->dst = 0xd.
>>>
>>> 4. rpmsg_gpio_channel_probe() is triggered. For *each* of the GPIO ports
>>>       in DT, it will trigger rpmsg_gpiochip_register() which will now:
>>>          a. Call port->ept = rpmsg_create_ept(rpdev,
>>>                                                                      rpmsg_gpio_channel_callback,
>>>                                                                      port,
>>>                                                                     {rpdev.id.name,
>>>                                                                      RPMSG_ADDR_ANY,
>>>                                                                      RPMSG_ADDR_ANY});
>>>              Ex- port->ept->addr = 0x408
>>>
>>>          b. Prepare a 8-byte message having 2 fields:
>>>              port->ept->addr (0x408) and port->idx (25)
>>>
>>>          c. Send this message to remote firmware on default channel ept
>>>              (0x405 -> 0xd) by:
>>>              rpmsg_send(rpdev->ept, &message, sizeof(message));
>>>
>>>          d. Remote side receives this message and creates a map of the
>>>              linux_ept_addr to gpio_port. (0x408 <-> 25)
>>>
>>> 5. After this point, any gpio messages sent from Linux from gpio port
>>>       endpoints (Ex- 0x408) can be decoded at remote side by looking up
>>>       its map (Ex- map[0x408] = 25).
>>>
>>> 6. Any messages sent from remote to Linux for a particular gpio port can
>>>       also be decoded at Linux by simply fetching the priv pointer to get
>>>       the per-port device:
>>>       struct rpmsg_gpio_port *port = priv;
>>>
>>
>> Thanks for the details!
>>
>> To sum up:
>> - the default endpoint acts as the GPIO controller (0x405),
>> - one extra Linux endpoint is created per port defined in DT.
>>
>> This should work, but my concerns remain the same:
>>
>>    1) This implementation forces the remote processor to handle a single
>>       endpoint instead of one endpoint per port. This may add complexity to
>>       the remote firmware if each port is managed in a separate thread.
> 
> 
> A. Not really, I just chose 1 remote endpoint for this example as you
>      suggested to. We can scale it for two-way communication via the
>      get_config message like you suggested below.
> 
> B. Isn't it a bad design of the firmware if it is handling 10 gpio ports
>      in 10 threads? The logic to handle all the ports is the same, only
>      the parameters (e.g. line number, msg) is different.
> 
>>
>>    2) Linux, as a consumer, should not expose its capabilities to the remote
>>       side (in your proposal it enumerates the ports defined in the DT).     In my view, the remote processor should expose its capabilities as the
>>       provider.
> 
> 
> Agreed on this.
> 
>>
>>  From my perspective, based on your proposal:
>>   1) Linux should send a get_config message to the remote proc (0x405 -> 0xD). 2) The remote processor would respond with the list of ports, associated
>>      with an remote endpoint addresses.
> 
> 
> Agreed, we can scale it for multiple remote endpoints like this.
> 
>>   3) Linux would parse the response, compare it with the DT, enable the GPIO
>>      ports accordingly, creating it local endpoint and associating it with
>>      the remote endpoint.
>> Using name service to identify the ports should avoid step 1 & 2 ...
> 
> 
> Yes, but won't that make a lot of hard-codings in the driver?
> 
> +static struct rpmsg_device_id rpmsg_gpio_channel_id_table[] = {
> +    { .name = "rpmsg-io-25" },
> +    { .name = "rpmsg-io-32" },
> +    { .name = "rpmsg-io-35" },
> +    { },
> +};
> 
> What if tomorrow another vendor decides to add more remoteproc
> controlled GPIO ports to Linux, they would have to update this struct in
> the driver everytime. And the port indexes (25/32/35) could also differ
> between vendors. We should make the driver dynamic i.e. vendor
> agnostic.
> 
> I think querying the remote firmware at runtime (step 1 & 2 above) is a
> common design pattern and makes the driver vendor agnostic. But feel
> free to correct me.
> 

You are right. My proposal would require a patch in rpmsg-core. The idea of
allowing a postfix in the compatible string has been discussed before, but,
if I remember correctly, it was not concluded.

/* rpmsg devices and drivers are matched using the service name */
static inline int rpmsg_id_match(const struct rpmsg_device *rpdev,
				  const struct rpmsg_device_id *id)
{
	size_t len;

+	len = strnlen(id->name, RPMSG_NAME_SIZE);
+	if (len && id->name[len - 1] == '*')
+		return !strncmp(id->name, rpdev->id.name, len - 1);

	return strncmp(id->name, rpdev->id.name, RPMSG_NAME_SIZE) == 0;
}

Then, in rpmsg-gpio, and possibly in other drivers such as rpmsg-tty and
a future rpmsg-i2c, we could use:
static struct rpmsg_device_id rpmsg_gpio_channel_id_table[] = {
     { .name = "rpmsg-io" },
     { .name = "rpmsg-io-*" },
     { },
};

If exact name matching is strongly required, then this proposal would 
not be suitable.

A third option would be a combination of both approaches: instantiate 
the device using the same name service from the remote side, as done in 
rpmsg-tty. In that case, a get_config message, or a similar mechanism, 
would also be needed to retrieve the port information from the remote side.

Tanmaya also proposed another alternative based on reserved addresses.

At this point, I suggest letting Mathieu review the discussion and 
recommend the most suitable approach.

Thanks,
Arnaud

>>
>> At the end, whatever solution is implemented, my main concern is that the
>> Linux driver design should, if possible, avoid adding unnecessary complexity
>> or limitations on the remote side (for instance in openAMP project).
> 
> 
> Yes definitely, I want the same. Feel free to let me know if this does
> not suit with the OpenAMP project.
> 
> Thanks,
> Beleswar
> 
>>
>> Thanks,
>> Arnaud
>>
>>
>>> So Linux does not need to send the port idx everytime while sending a
>>> gpio message anymore.
>>>
>>> Thanks,
>>> Beleswar
>>>
>>> [...]
>>>
>>

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

[Mathieu Poirier]

On Tue, May 05, 2026 at 10:46:11AM +0200, Arnaud POULIQUEN wrote:
> Hi Beleswar
> 
> On 5/5/26 07:25, Beleswar Prasad Padhi wrote:
> > Hi Arnaud,
> > 
> > On 04/05/26 22:34, Arnaud POULIQUEN wrote:
> > > Hi Beleswar,
> > > 
> > > On 5/4/26 10:17, Beleswar Prasad Padhi wrote:
> > > 
> > 
> > [...]
> > 
> > > > 
> > > > > 
> > > > > I may have misunderstood your solution. Could you please help me
> > > > > understand your proposal by explaining how you would handle three
> > > > > GPIO ports defined in the DT, considering that the endpoint
> > > > > addresses on the Linux side can be random?
> > > > > If I assume there is a unique endpoint on the remote side,
> > > > > I do not understand how you can match, on the firmware side,
> > > > > the Linux endpoint address to the GPIO port.
> > > > 
> > > > 
> > > > Sure, let me take an example:
> > > > Assumptions: 3 GPIO ports in DT, 3 endpoints in Linux (one per port),
> > > > 1 endpoint in remote (0xd) and 1 rpmsg channel (rpmsg-io)
> > > > 
> > > >          rpmsg {
> > > >            rpmsg-io {
> > > >              #address-cells = <1>;
> > > >              #size-cells = <0>;
> > > > 
> > > >              gpio@25 {
> > > >                compatible = "rpmsg-gpio";
> > > >                reg = <25>;
> > > >                gpio-controller;
> > > >                #gpio-cells = <2>;
> > > >                #interrupt-cells = <2>;
> > > >                interrupt-controller;
> > > >              };
> > > > 
> > > >              gpio@32 {
> > > >                compatible = "rpmsg-gpio";
> > > >                reg = <32>;
> > > >                gpio-controller;
> > > >                #gpio-cells = <2>;
> > > >                #interrupt-cells = <2>;
> > > >                interrupt-controller;
> > > >              };
> > > > 
> > > >              gpio@35 {
> > > >                compatible = "rpmsg-gpio";
> > > >                reg = <35>;
> > > >                gpio-controller;
> > > >                #gpio-cells = <2>;
> > > >                #interrupt-cells = <2>;
> > > >                interrupt-controller;
> > > >              };
> > > >            };
> > > >          };
> > > > 
> > > > Code Flow:
> > > > 1. "rpmsg-io" channel is announced from remote firmware with unique dst
> > > >       ept = 0xd.
> > > > 
> > > > 2. rpmsg_core.c creates the default dynamic local ept for the channel
> > > >       ept = 0x405.
> > > > 
> > > > 3. rpmsg_core.c assigns the allocated addr to rpdev device:
> > > >       rpdev->src = 0x405 and rpdev->dst = 0xd.
> > > > 
> > > > 4. rpmsg_gpio_channel_probe() is triggered. For *each* of the GPIO ports
> > > >       in DT, it will trigger rpmsg_gpiochip_register() which will now:
> > > >          a. Call port->ept = rpmsg_create_ept(rpdev,
> > > >                                                                      rpmsg_gpio_channel_callback,
> > > >                                                                      port,
> > > >                                                                     {rpdev.id.name,
> > > >                                                                      RPMSG_ADDR_ANY,
> > > >                                                                      RPMSG_ADDR_ANY});
> > > >              Ex- port->ept->addr = 0x408
> > > > 
> > > >          b. Prepare a 8-byte message having 2 fields:
> > > >              port->ept->addr (0x408) and port->idx (25)
> > > > 
> > > >          c. Send this message to remote firmware on default channel ept
> > > >              (0x405 -> 0xd) by:
> > > >              rpmsg_send(rpdev->ept, &message, sizeof(message));
> > > > 
> > > >          d. Remote side receives this message and creates a map of the
> > > >              linux_ept_addr to gpio_port. (0x408 <-> 25)
> > > > 
> > > > 5. After this point, any gpio messages sent from Linux from gpio port
> > > >       endpoints (Ex- 0x408) can be decoded at remote side by looking up
> > > >       its map (Ex- map[0x408] = 25).
> > > > 
> > > > 6. Any messages sent from remote to Linux for a particular gpio port can
> > > >       also be decoded at Linux by simply fetching the priv pointer to get
> > > >       the per-port device:
> > > >       struct rpmsg_gpio_port *port = priv;
> > > > 
> > > 
> > > Thanks for the details!
> > > 
> > > To sum up:
> > > - the default endpoint acts as the GPIO controller (0x405),
> > > - one extra Linux endpoint is created per port defined in DT.
> > > 
> > > This should work, but my concerns remain the same:
> > > 
> > >    1) This implementation forces the remote processor to handle a single
> > >       endpoint instead of one endpoint per port. This may add complexity to
> > >       the remote firmware if each port is managed in a separate thread.
> > 
> > 
> > A. Not really, I just chose 1 remote endpoint for this example as you
> >      suggested to. We can scale it for two-way communication via the
> >      get_config message like you suggested below.
> > 
> > B. Isn't it a bad design of the firmware if it is handling 10 gpio ports
> >      in 10 threads? The logic to handle all the ports is the same, only
> >      the parameters (e.g. line number, msg) is different.
> > 
> > > 
> > >    2) Linux, as a consumer, should not expose its capabilities to the remote
> > >       side (in your proposal it enumerates the ports defined in the DT).     In my view, the remote processor should expose its capabilities as the
> > >       provider.
> > 
> > 
> > Agreed on this.
> > 
> > > 
> > >  From my perspective, based on your proposal:
> > >   1) Linux should send a get_config message to the remote proc (0x405 -> 0xD). 2) The remote processor would respond with the list of ports, associated
> > >      with an remote endpoint addresses.
> > 
> > 
> > Agreed, we can scale it for multiple remote endpoints like this.
> > 
> > >   3) Linux would parse the response, compare it with the DT, enable the GPIO
> > >      ports accordingly, creating it local endpoint and associating it with
> > >      the remote endpoint.
> > > Using name service to identify the ports should avoid step 1 & 2 ...
> > 
> > 
> > Yes, but won't that make a lot of hard-codings in the driver?
> > 
> > +static struct rpmsg_device_id rpmsg_gpio_channel_id_table[] = {
> > +    { .name = "rpmsg-io-25" },
> > +    { .name = "rpmsg-io-32" },
> > +    { .name = "rpmsg-io-35" },
> > +    { },
> > +};
> > 
> > What if tomorrow another vendor decides to add more remoteproc
> > controlled GPIO ports to Linux, they would have to update this struct in
> > the driver everytime. And the port indexes (25/32/35) could also differ
> > between vendors. We should make the driver dynamic i.e. vendor
> > agnostic.
> > 
> > I think querying the remote firmware at runtime (step 1 & 2 above) is a
> > common design pattern and makes the driver vendor agnostic. But feel
> > free to correct me.
> > 
> 
> You are right. My proposal would require a patch in rpmsg-core. The idea of
> allowing a postfix in the compatible string has been discussed before, but,
> if I remember correctly, it was not concluded.
>

I also remember discussing this.  I even reviewed one of Arnaud's patch
and submitted one myself.  This must have been in 2020 and the reason why it
wasn't merged has escaped my memory.
 
> /* rpmsg devices and drivers are matched using the service name */
> static inline int rpmsg_id_match(const struct rpmsg_device *rpdev,
> 				  const struct rpmsg_device_id *id)
> {
> 	size_t len;
> 
> +	len = strnlen(id->name, RPMSG_NAME_SIZE);
> +	if (len && id->name[len - 1] == '*')
> +		return !strncmp(id->name, rpdev->id.name, len - 1);
> 
> 	return strncmp(id->name, rpdev->id.name, RPMSG_NAME_SIZE) == 0;
> }
> 
> Then, in rpmsg-gpio, and possibly in other drivers such as rpmsg-tty and
> a future rpmsg-i2c, we could use:
> static struct rpmsg_device_id rpmsg_gpio_channel_id_table[] = {
>     { .name = "rpmsg-io" },
>     { .name = "rpmsg-io-*" },
>     { },
> };

That was my initial approach.  We don't even need an additional "rpmsg-io-*" in
rpmsg_gpio_channel_id_table[].  All we need is:

/* rpmsg devices and drivers are matched using the service name */
static inline int rpmsg_id_match(const struct rpmsg_device *rpdev,
                                 const struct rpmsg_device_id *id)
{
 +     size_t len = strnlen(id->name, RPMSG_NAME_SIZE);

 -     return strncmp(id->name, rpdev->id.name, RPMSG_NAME_SIZE) == 0; 
 +     return strncmp(id->name, rpdev->id.name, len) == 0;
}

And let the rpmsg-virtio-gpio driver parse @rpdev->id.name to match with a
GPIO controller in the DT.

> 
> If exact name matching is strongly required, then this proposal would not be
> suitablea.
> 
> A third option would be a combination of both approaches: instantiate the
> device using the same name service from the remote side, as done in
> rpmsg-tty. In that case, a get_config message, or a similar mechanism, would
> also be needed to retrieve the port information from the remote side.
>

I'm not overly fond of a get_config message because it is one more thing we
have to define and maintain. 

Arnaud: is there a get_config message already defined for rpmsg_tty?

Beleswar: Can you provide a link to a virtio device that would use a get_config
message?
 
> Tanmaya also proposed another alternative based on reserved addresses.
> 
> At this point, I suggest letting Mathieu review the discussion and recommend
> the most suitable approach.
> 
> Thanks,
> Arnaud
> 
> > > 
> > > At the end, whatever solution is implemented, my main concern is that the
> > > Linux driver design should, if possible, avoid adding unnecessary complexity
> > > or limitations on the remote side (for instance in openAMP project).
> > 
> > 
> > Yes definitely, I want the same. Feel free to let me know if this does
> > not suit with the OpenAMP project.
> > 
> > Thanks,
> > Beleswar
> > 
> > > 
> > > Thanks,
> > > Arnaud
> > > 
> > > 
> > > > So Linux does not need to send the port idx everytime while sending a
> > > > gpio message anymore.
> > > > 
> > > > Thanks,
> > > > Beleswar
> > > > 
> > > > [...]
> > > > 
> > > 
> 

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

[Shenwei Wang]

> -----Original Message-----
> From: Mathieu Poirier <mathieu.poirier@linaro.org>
> Sent: Thursday, May 7, 2026 12:13 PM
> To: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
> Cc: Beleswar Prasad Padhi <b-padhi@ti.com>; Shenwei Wang
> <shenwei.wang@nxp.com>; Andrew Lunn <andrew@lunn.ch>; Linus Walleij
> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
> <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>; linux-
> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-
> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> > > >  From my perspective, based on your proposal:
> > > >   1) Linux should send a get_config message to the remote proc (0x405 ->
> 0xD). 2) The remote processor would respond with the list of ports, associated
> > > >      with an remote endpoint addresses.
> > >
> > >
> > > Agreed, we can scale it for multiple remote endpoints like this.
> > >
> > > >   3) Linux would parse the response, compare it with the DT, enable the
> GPIO
> > > >      ports accordingly, creating it local endpoint and associating it with
> > > >      the remote endpoint.
> > > > Using name service to identify the ports should avoid step 1 & 2 ...
> > >
> > >
> > > Yes, but won't that make a lot of hard-codings in the driver?
> > >
> > > +static struct rpmsg_device_id rpmsg_gpio_channel_id_table[] = {
> > > +    { .name = "rpmsg-io-25" },
> > > +    { .name = "rpmsg-io-32" },
> > > +    { .name = "rpmsg-io-35" },
> > > +    { },
> > > +};
> > >
> > > What if tomorrow another vendor decides to add more remoteproc
> > > controlled GPIO ports to Linux, they would have to update this
> > > struct in the driver everytime. And the port indexes (25/32/35)
> > > could also differ between vendors. We should make the driver dynamic
> > > i.e. vendor agnostic.
> > >
> > > I think querying the remote firmware at runtime (step 1 & 2 above)
> > > is a common design pattern and makes the driver vendor agnostic. But
> > > feel free to correct me.
> > >
> >
> > You are right. My proposal would require a patch in rpmsg-core. The
> > idea of allowing a postfix in the compatible string has been discussed
> > before, but, if I remember correctly, it was not concluded.
> >
> 
> I also remember discussing this.  I even reviewed one of Arnaud's patch and
> submitted one myself.  This must have been in 2020 and the reason why it wasn't
> merged has escaped my memory.
> 
> > /* rpmsg devices and drivers are matched using the service name */
> > static inline int rpmsg_id_match(const struct rpmsg_device *rpdev,
> >                                 const struct rpmsg_device_id *id) {
> >       size_t len;
> >
> > +     len = strnlen(id->name, RPMSG_NAME_SIZE);
> > +     if (len && id->name[len - 1] == '*')
> > +             return !strncmp(id->name, rpdev->id.name, len - 1);
> >
> >       return strncmp(id->name, rpdev->id.name, RPMSG_NAME_SIZE) == 0;
> > }
> >
> > Then, in rpmsg-gpio, and possibly in other drivers such as rpmsg-tty
> > and a future rpmsg-i2c, we could use:
> > static struct rpmsg_device_id rpmsg_gpio_channel_id_table[] = {
> >     { .name = "rpmsg-io" },
> >     { .name = "rpmsg-io-*" },
> >     { },
> > };
> 
> That was my initial approach.  We don't even need an additional "rpmsg-io-*" in
> rpmsg_gpio_channel_id_table[].  All we need is:
> 
> /* rpmsg devices and drivers are matched using the service name */ static inline
> int rpmsg_id_match(const struct rpmsg_device *rpdev,
>                                  const struct rpmsg_device_id *id) {
>  +     size_t len = strnlen(id->name, RPMSG_NAME_SIZE);
> 
>  -     return strncmp(id->name, rpdev->id.name, RPMSG_NAME_SIZE) == 0;
>  +     return strncmp(id->name, rpdev->id.name, len) == 0;
> }
> 

If we encode the port index directly into ept->src, for example:

    ept->src = (baseaddr << 8) | port_index;

where baseaddr can be derived from the channel address, we can avoid the possible address conflict.

With this approach, the patch to rpmsg-core would no longer be necessary.

Thanks,
Shenwei

> And let the rpmsg-virtio-gpio driver parse @rpdev->id.name to match with a
> GPIO controller in the DT.
> 
> >
> > If exact name matching is strongly required, then this proposal would
> > not be suitablea.
> >
> > A third option would be a combination of both approaches: instantiate
> > the device using the same name service from the remote side, as done
> > in rpmsg-tty. In that case, a get_config message, or a similar
> > mechanism, would also be needed to retrieve the port information from the
> remote side.
> >
> 
> I'm not overly fond of a get_config message because it is one more thing we have
> to define and maintain.
> 
> Arnaud: is there a get_config message already defined for rpmsg_tty?
> 
> Beleswar: Can you provide a link to a virtio device that would use a get_config
> message?
> 
> > Tanmaya also proposed another alternative based on reserved addresses.
> >
> > At this point, I suggest letting Mathieu review the discussion and
> > recommend the most suitable approach.
> >
> > Thanks,
> > Arnaud
> >
> > > >
> > > > At the end, whatever solution is implemented, my main concern is
> > > > that the Linux driver design should, if possible, avoid adding
> > > > unnecessary complexity or limitations on the remote side (for instance in
> openAMP project).
> > >
> > >
> > > Yes definitely, I want the same. Feel free to let me know if this
> > > does not suit with the OpenAMP project.
> > >
> > > Thanks,
> > > Beleswar
> > >
> > > >
> > > > Thanks,
> > > > Arnaud
> > > >
> > > >
> > > > > So Linux does not need to send the port idx everytime while
> > > > > sending a gpio message anymore.
> > > > >
> > > > > Thanks,
> > > > > Beleswar
> > > > >
> > > > > [...]
> > > > >
> > > >
> >

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

[Padhi, Beleswar]

Hi Mathieu,

On 5/7/2026 10:42 PM, Mathieu Poirier wrote:
> On Tue, May 05, 2026 at 10:46:11AM +0200, Arnaud POULIQUEN wrote:
>> Hi Beleswar
>>
>> On 5/5/26 07:25, Beleswar Prasad Padhi wrote:
>>> Hi Arnaud,
>>>
>>> On 04/05/26 22:34, Arnaud POULIQUEN wrote:
>>>> Hi Beleswar,
>>>>
>>>> On 5/4/26 10:17, Beleswar Prasad Padhi wrote:
>>>>
>>> [...]
>>>
>>>>>> I may have misunderstood your solution. Could you please help me
>>>>>> understand your proposal by explaining how you would handle three
>>>>>> GPIO ports defined in the DT, considering that the endpoint
>>>>>> addresses on the Linux side can be random?
>>>>>> If I assume there is a unique endpoint on the remote side,
>>>>>> I do not understand how you can match, on the firmware side,
>>>>>> the Linux endpoint address to the GPIO port.
>>>>>
>>>>> Sure, let me take an example:
>>>>> Assumptions: 3 GPIO ports in DT, 3 endpoints in Linux (one per port),
>>>>> 1 endpoint in remote (0xd) and 1 rpmsg channel (rpmsg-io)
>>>>>
>>>>>           rpmsg {
>>>>>             rpmsg-io {
>>>>>               #address-cells = <1>;
>>>>>               #size-cells = <0>;
>>>>>
>>>>>               gpio@25 {
>>>>>                 compatible = "rpmsg-gpio";
>>>>>                 reg = <25>;
>>>>>                 gpio-controller;
>>>>>                 #gpio-cells = <2>;
>>>>>                 #interrupt-cells = <2>;
>>>>>                 interrupt-controller;
>>>>>               };
>>>>>
>>>>>               gpio@32 {
>>>>>                 compatible = "rpmsg-gpio";
>>>>>                 reg = <32>;
>>>>>                 gpio-controller;
>>>>>                 #gpio-cells = <2>;
>>>>>                 #interrupt-cells = <2>;
>>>>>                 interrupt-controller;
>>>>>               };
>>>>>
>>>>>               gpio@35 {
>>>>>                 compatible = "rpmsg-gpio";
>>>>>                 reg = <35>;
>>>>>                 gpio-controller;
>>>>>                 #gpio-cells = <2>;
>>>>>                 #interrupt-cells = <2>;
>>>>>                 interrupt-controller;
>>>>>               };
>>>>>             };
>>>>>           };
>>>>>
>>>>> Code Flow:
>>>>> 1. "rpmsg-io" channel is announced from remote firmware with unique dst
>>>>>        ept = 0xd.
>>>>>
>>>>> 2. rpmsg_core.c creates the default dynamic local ept for the channel
>>>>>        ept = 0x405.
>>>>>
>>>>> 3. rpmsg_core.c assigns the allocated addr to rpdev device:
>>>>>        rpdev->src = 0x405 and rpdev->dst = 0xd.
>>>>>
>>>>> 4. rpmsg_gpio_channel_probe() is triggered. For *each* of the GPIO ports
>>>>>        in DT, it will trigger rpmsg_gpiochip_register() which will now:
>>>>>           a. Call port->ept = rpmsg_create_ept(rpdev,
>>>>>                                                                       rpmsg_gpio_channel_callback,
>>>>>                                                                       port,
>>>>>                                                                      {rpdev.id.name,
>>>>>                                                                       RPMSG_ADDR_ANY,
>>>>>                                                                       RPMSG_ADDR_ANY});
>>>>>               Ex- port->ept->addr = 0x408
>>>>>
>>>>>           b. Prepare a 8-byte message having 2 fields:
>>>>>               port->ept->addr (0x408) and port->idx (25)
>>>>>
>>>>>           c. Send this message to remote firmware on default channel ept
>>>>>               (0x405 -> 0xd) by:
>>>>>               rpmsg_send(rpdev->ept, &message, sizeof(message));
>>>>>
>>>>>           d. Remote side receives this message and creates a map of the
>>>>>               linux_ept_addr to gpio_port. (0x408 <-> 25)
>>>>>
>>>>> 5. After this point, any gpio messages sent from Linux from gpio port
>>>>>        endpoints (Ex- 0x408) can be decoded at remote side by looking up
>>>>>        its map (Ex- map[0x408] = 25).
>>>>>
>>>>> 6. Any messages sent from remote to Linux for a particular gpio port can
>>>>>        also be decoded at Linux by simply fetching the priv pointer to get
>>>>>        the per-port device:
>>>>>        struct rpmsg_gpio_port *port = priv;
>>>>>
>>>> Thanks for the details!
>>>>
>>>> To sum up:
>>>> - the default endpoint acts as the GPIO controller (0x405),
>>>> - one extra Linux endpoint is created per port defined in DT.
>>>>
>>>> This should work, but my concerns remain the same:
>>>>
>>>>     1) This implementation forces the remote processor to handle a single
>>>>        endpoint instead of one endpoint per port. This may add complexity to
>>>>        the remote firmware if each port is managed in a separate thread.
>>>
>>> A. Not really, I just chose 1 remote endpoint for this example as you
>>>       suggested to. We can scale it for two-way communication via the
>>>       get_config message like you suggested below.
>>>
>>> B. Isn't it a bad design of the firmware if it is handling 10 gpio ports
>>>       in 10 threads? The logic to handle all the ports is the same, only
>>>       the parameters (e.g. line number, msg) is different.
>>>
>>>>     2) Linux, as a consumer, should not expose its capabilities to the remote
>>>>        side (in your proposal it enumerates the ports defined in the DT).     In my view, the remote processor should expose its capabilities as the
>>>>        provider.
>>>
>>> Agreed on this.
>>>
>>>>   From my perspective, based on your proposal:
>>>>    1) Linux should send a get_config message to the remote proc (0x405 -> 0xD). 2) The remote processor would respond with the list of ports, associated
>>>>       with an remote endpoint addresses.
>>>
>>> Agreed, we can scale it for multiple remote endpoints like this.
>>>
>>>>    3) Linux would parse the response, compare it with the DT, enable the GPIO
>>>>       ports accordingly, creating it local endpoint and associating it with
>>>>       the remote endpoint.
>>>> Using name service to identify the ports should avoid step 1 & 2 ...
>>>
>>> Yes, but won't that make a lot of hard-codings in the driver?
>>>
>>> +static struct rpmsg_device_id rpmsg_gpio_channel_id_table[] = {
>>> +    { .name = "rpmsg-io-25" },
>>> +    { .name = "rpmsg-io-32" },
>>> +    { .name = "rpmsg-io-35" },
>>> +    { },
>>> +};
>>>
>>> What if tomorrow another vendor decides to add more remoteproc
>>> controlled GPIO ports to Linux, they would have to update this struct in
>>> the driver everytime. And the port indexes (25/32/35) could also differ
>>> between vendors. We should make the driver dynamic i.e. vendor
>>> agnostic.
>>>
>>> I think querying the remote firmware at runtime (step 1 & 2 above) is a
>>> common design pattern and makes the driver vendor agnostic. But feel
>>> free to correct me.
>>>
>> You are right. My proposal would require a patch in rpmsg-core. The idea of
>> allowing a postfix in the compatible string has been discussed before, but,
>> if I remember correctly, it was not concluded.
>>
> I also remember discussing this.  I even reviewed one of Arnaud's patch
> and submitted one myself.  This must have been in 2020 and the reason why it
> wasn't merged has escaped my memory.
>   
>> /* rpmsg devices and drivers are matched using the service name */
>> static inline int rpmsg_id_match(const struct rpmsg_device *rpdev,
>> 				  const struct rpmsg_device_id *id)
>> {
>> 	size_t len;
>>
>> +	len = strnlen(id->name, RPMSG_NAME_SIZE);
>> +	if (len && id->name[len - 1] == '*')
>> +		return !strncmp(id->name, rpdev->id.name, len - 1);
>>
>> 	return strncmp(id->name, rpdev->id.name, RPMSG_NAME_SIZE) == 0;
>> }
>>
>> Then, in rpmsg-gpio, and possibly in other drivers such as rpmsg-tty and
>> a future rpmsg-i2c, we could use:
>> static struct rpmsg_device_id rpmsg_gpio_channel_id_table[] = {
>>      { .name = "rpmsg-io" },
>>      { .name = "rpmsg-io-*" },
>>      { },
>> };
> That was my initial approach.  We don't even need an additional "rpmsg-io-*" in
> rpmsg_gpio_channel_id_table[].  All we need is:
>
> /* rpmsg devices and drivers are matched using the service name */
> static inline int rpmsg_id_match(const struct rpmsg_device *rpdev,
>                                   const struct rpmsg_device_id *id)
> {
>   +     size_t len = strnlen(id->name, RPMSG_NAME_SIZE);
>
>   -     return strncmp(id->name, rpdev->id.name, RPMSG_NAME_SIZE) == 0;
>   +     return strncmp(id->name, rpdev->id.name, len) == 0;
> }


This wildcard channel matching is interesting. It would be good to know
the reasons/cons why this patch was not concluded.

>
> And let the rpmsg-virtio-gpio driver parse @rpdev->id.name to match with a
> GPIO controller in the DT.
>
>> If exact name matching is strongly required, then this proposal would not be
>> suitablea.
>>
>> A third option would be a combination of both approaches: instantiate the
>> device using the same name service from the remote side, as done in
>> rpmsg-tty. In that case, a get_config message, or a similar mechanism, would
>> also be needed to retrieve the port information from the remote side.
>>
> I'm not overly fond of a get_config message because it is one more thing we
> have to define and maintain.
>
> Arnaud: is there a get_config message already defined for rpmsg_tty?
>
> Beleswar: Can you provide a link to a virtio device that would use a get_config
> message?


VirtIO typically uses the feature bits for negotiation and discovery.
And such a get_config message would not be needed in VirtIO layer, as
there is no multiplexing. It's a 1:1 mapping of device to driver
instance.

Thanks,
Beleswar

[...]

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

[Arnaud POULIQUEN]

Hello Mathieu,

[...]
>>
>> A third option would be a combination of both approaches: instantiate the
>> device using the same name service from the remote side, as done in
>> rpmsg-tty. In that case, a get_config message, or a similar mechanism, would
>> also be needed to retrieve the port information from the remote side.
>>
> 
> I'm not overly fond of a get_config message because it is one more thing we
> have to define and maintain.
> 
> Arnaud: is there a get_config message already defined for rpmsg_tty?

No there isn't.

Regards,
Arnaud

> 
> Beleswar: Can you provide a link to a virtio device that would use a get_config
> message?
>   
>> Tanmaya also proposed another alternative based on reserved addresses.
>>
>> At this point, I suggest letting Mathieu review the discussion and recommend
>> the most suitable approach.
>>
>> Thanks,
>> Arnaud
>>
>>>>
>>>> At the end, whatever solution is implemented, my main concern is that the
>>>> Linux driver design should, if possible, avoid adding unnecessary complexity
>>>> or limitations on the remote side (for instance in openAMP project).
>>>
>>>
>>> Yes definitely, I want the same. Feel free to let me know if this does
>>> not suit with the OpenAMP project.
>>>
>>> Thanks,
>>> Beleswar
>>>
>>>>
>>>> Thanks,
>>>> Arnaud
>>>>
>>>>
>>>>> So Linux does not need to send the port idx everytime while sending a
>>>>> gpio message anymore.
>>>>>
>>>>> Thanks,
>>>>> Beleswar
>>>>>
>>>>> [...]
>>>>>
>>>>
>>

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

[Shenwei Wang]

> -----Original Message-----
> From: Beleswar Prasad Padhi <b-padhi@ti.com>
> Sent: Monday, May 4, 2026 3:17 AM
> To: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>; Mathieu Poirier
> <mathieu.poirier@linaro.org>
> Cc: Shenwei Wang <shenwei.wang@nxp.com>; Andrew Lunn
> <andrew@lunn.ch>; Linus Walleij <linusw@kernel.org>; Bartosz Golaszewski
> <brgl@kernel.org>; Jonathan Corbet <corbet@lwn.net>; Rob Herring
> <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley
> <conor+dt@kernel.org>; Bjorn Andersson <andersson@kernel.org>; Frank Li
> <frank.li@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>; Shuah Khan
> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> <kernel@pengutronix.de>; Fabio Estevam <festevam@gmail.com>; Peng Fan
> <peng.fan@nxp.com>; devicetree@vger.kernel.org; linux-
> remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
> kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>; Bartosz
> Golaszewski <brgl@bgdev.pl>
> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> 
> Caution: This is an external email. Please take care when clicking links or opening
> attachments. When in doubt, report the message using the 'Report this email'
> button
> 
> 
> Hi Arnaud,
> 
> On 30/04/26 22:10, Arnaud POULIQUEN wrote:
> >
> >
> > On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
> >> Hello Arnaud,
> >>
> >> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
> >>> Hello,
> >>>
> >>> On 4/29/26 21:20, Mathieu Poirier wrote:
> >>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
> >>>>>
> >>>>> Hi Mathieu,
> >>>>>
> >>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
> >>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang
> <shenwei.wang@nxp.com> wrote:
> >>>>
> 
> [...]
> 
> >>>>> My mental model looks like this for the complete picture:
> >>>>>
> >>>>> 1. namespace/channel#1 = rpmsg-io
> >>>>>       a. ept1 -> gpio-controller@1
> >>>>>       b. ept2 -> gpio-controller@2
> >>>>>
> >>>>
> >>>> I've asked for one endpoint per GPIO controller since the very
> >>>> beginning.  I don't yet have a strong opinion on whether to use one
> >>>> namespace request per GPIO controller or a single request that
> >>>> spins off multiple endpoints.  I'll have to look at your link and
> >>>> reflect on that.  Regardless of how we proceed on that front,
> >>>> multiplexing needs to happen at the endpoint level rather than the
> >>>> packet level.  This is the only way this work can move forward.
> >>>>
> >>>
> >>> I would be more in favor of Mathieu’s proposal: “An endpoint is created with
> every namespace request.”
> >>>
> >>> If the endpoint is created only on the Linux side, how do we match the Linux
> endpoint address with the local port field on the remote side?
> >>
> >>
> >> Simply by sending a message to the remote containing the newly
> >> created endpoint and the port idx. Note that is this done just one
> >> time, after this Linux need not have the port field in the message
> >> everytime its sending a message.
> >>
> >>>
> >>> With a multi-namespace approach, the namespace could be rpmsg-io-[addr],
> where [addr] corresponds to the GPIO controller address in the DT. This would:
> >>
> >>
> >> You will face the same problem in this case also that you asked above:
> >> "how do we match the Linux endpoint address with the local port field
> >> on the remote side?"
> >
> > Sorry I probably introduced confusion here my sentence should be;
> > With a multi-namespace approach, the namespace could be
> > rpmsg-io-[port],  where [port] corresponds to the GPIO controller port in the
> DT.
> >
> >
> > For instance:
> >
> >       rpmsg {
> >         rpmsg-io {
> >           #address-cells = <1>;
> >           #size-cells = <0>;
> >
> >           gpio@25 {
> >             compatible = "rpmsg-gpio";
> >             reg = <25>;
> >             gpio-controller;
> >             #gpio-cells = <2>;
> >             #interrupt-cells = <2>;
> >             interrupt-controller;
> >           };
> >
> >           gpio@32 {
> >             compatible = "rpmsg-gpio";
> >             reg = <32>;
> >             gpio-controller;
> >             #gpio-cells = <2>;
> >             #interrupt-cells = <2>;
> >             interrupt-controller;
> >           };
> >         };
> >       };
> >
> >  rpmsg-io-25  would match with gpio@25
> >  rpmsg-io-32  would match with gpio@32
> >
> >
> >>
> >> Because the endpoint that is created on a namespace request is also
> >> dynamic in nature. How will the remote know which endpoint addr Linux
> >> allocated for a namespace that it announced?
> >>
> >> As an example/PoC, I created a firmware example which announces
> >> 2 name services to Linux, one is the standard "rpmsg_chrdev" and the
> >> other is a TI specific name service "ti.ipc4.ping-pong". You can see
> >> it created 2 different addresses (0x400 and 0x401) for each of the
> >> name service request from the same firmware:
> >>
> >> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
> >> [    9.290275] virtio_rpmsg_bus virtio0: creating channel ti.ipc4.ping-pong addr
> 0xd
> >> [    9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev addr
> 0xe
> >> [    9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel
> formed from src = 0x400 to dst = 0xe
> >> [    9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: new
> channel: 0x401 -> 0xd!
> >>
> >> So in this case, rpmsg-io-1 can have different ept addr than
> >> rpmsg-io-2 Back to same problem. Simple solution is to reply to
> >> remote with the created ept addr and the index.
> >
> > That why I would like to suggest to use the name service field to identify the
> port/controller, instead of the endpoint address.
> >>
> >>>
> >>> - match the RPMsg probe with the DT,
> >>
> >>
> >> We can probe from all controllers with a single name service
> >> announcement too.
> >>
> >>> - provide a simple mapping between the port and the endpoint on both
> >>> sides,
> >>
> >>
> >> We are trying to get rid of this mapping from Linux side to adapt the
> >> gpio-virtio design.
> >>
> >>> - allow multiple endpoints on the remote side,
> >>
> >>
> >> We can support this as well with single nameservice model.
> >> There is no limitation. Remote has to send a message with its newly
> >> created ept that's all.
> >>
> >>> - provide a simple discovery mechanism for remote capabilities.
> >>
> >>
> >> A single announcement: "rpmsg-io" is also discovery mechanism.
> >>
> >> Feel free to let me know if you have concerns with any of the
> >> suggestions!
> >
> > My only concern, whatever the solution, is that we find a smart
> > solution to associate the correct endpoint with the correct GPIO
> > port/controller defined in the DT.
> 
> 
> In my solution, there is no need to have this map of endpoint to GPIO port at
> Linux side. This aligns more with virtio-gpio design as well.
> 
> >
> > I may have misunderstood your solution. Could you please help me
> > understand your proposal by explaining how you would handle three GPIO
> > ports defined in the DT, considering that the endpoint addresses on
> > the Linux side can be random?
> > If I assume there is a unique endpoint on the remote side, I do not
> > understand how you can match, on the firmware side, the Linux endpoint
> > address to the GPIO port.
> 
> 
> Sure, let me take an example:
> Assumptions: 3 GPIO ports in DT, 3 endpoints in Linux (one per port),
> 1 endpoint in remote (0xd) and 1 rpmsg channel (rpmsg-io)
> 
>        rpmsg {
>          rpmsg-io {
>            #address-cells = <1>;
>            #size-cells = <0>;
> 
>            gpio@25 {
>              compatible = "rpmsg-gpio";
>              reg = <25>;
>              gpio-controller;
>              #gpio-cells = <2>;
>              #interrupt-cells = <2>;
>              interrupt-controller;
>            };
> 
>            gpio@32 {
>              compatible = "rpmsg-gpio";
>              reg = <32>;
>              gpio-controller;
>              #gpio-cells = <2>;
>              #interrupt-cells = <2>;
>              interrupt-controller;
>            };
> 
>            gpio@35 {
>              compatible = "rpmsg-gpio";
>              reg = <35>;
>              gpio-controller;
>              #gpio-cells = <2>;
>              #interrupt-cells = <2>;
>              interrupt-controller;
>            };
>          };
>        };
> 
> Code Flow:
> 1. "rpmsg-io" channel is announced from remote firmware with unique dst
>     ept = 0xd.
> 
> 2. rpmsg_core.c creates the default dynamic local ept for the channel
>     ept = 0x405.
> 
> 3. rpmsg_core.c assigns the allocated addr to rpdev device:
>     rpdev->src = 0x405 and rpdev->dst = 0xd.
> 
> 4. rpmsg_gpio_channel_probe() is triggered. For *each* of the GPIO ports
>     in DT, it will trigger rpmsg_gpiochip_register() which will now:
>        a. Call port->ept = rpmsg_create_ept(rpdev,
>                                                                    rpmsg_gpio_channel_callback,
>                                                                    port,
>                                                                   {rpdev.id.name,
>                                                                    RPMSG_ADDR_ANY,
>                                                                    RPMSG_ADDR_ANY});
>            Ex- port->ept->addr = 0x408
> 
>        b. Prepare a 8-byte message having 2 fields:
>            port->ept->addr (0x408) and port->idx (25)
> 
>        c. Send this message to remote firmware on default channel ept
>            (0x405 -> 0xd) by:
>            rpmsg_send(rpdev->ept, &message, sizeof(message));
> 
>        d. Remote side receives this message and creates a map of the
>            linux_ept_addr to gpio_port. (0x408 <-> 25)
> 
> 5. After this point, any gpio messages sent from Linux from gpio port
>     endpoints (Ex- 0x408) can be decoded at remote side by looking up
>     its map (Ex- map[0x408] = 25).
> 
> 6. Any messages sent from remote to Linux for a particular gpio port can
>     also be decoded at Linux by simply fetching the priv pointer to get
>     the per-port device:
>     struct rpmsg_gpio_port *port = priv;
> 
> So Linux does not need to send the port idx everytime while sending a gpio
> message anymore.
> 

I support the idea of encoding the port index directly into ept->addr.
To keep the design simple, we can rely on a predefined rule to derive ept->src, rather than 
exchanging additional configuration. One approach is to use the default channel address as 
the base address and encode the port index into the lower bits. For example:

    ept->src = (baseaddr << 8) | port_index;

With this scheme, the endpoint-to-port mapping can be encoded implicitly, eliminating the need 
for an extra message to exchange EPT and port mapping information.

Thanks,
Shenwei

> Thanks,
> Beleswar
> 
> [...]

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

[Shah, Tanmay]

Hello all,

I have started reviewing this work as well.
Thanks Shenwei for this work.

I have gone through only the current revision, and would like to provide
idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
Also, have some bindings related question.

Please see below:

On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
> 
> 
> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>> Hello Arnaud,
>>
>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>> Hello,
>>>
>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>>>>
>>>>> Hi Mathieu,
>>>>>
>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-
>>>>>>>> padhi@ti.com>; Linus
>>>>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski
>>>>>>>> <brgl@kernel.org>; Jonathan
>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
>>>>>>>> Krzysztof Kozlowski
>>>>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn
>>>>>>>> Andersson
>>>>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>>>>>>> <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>> <skhan@linuxfoundation.org>; linux-
>>>>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-
>>>>>>>> kernel@vger.kernel.org;
>>>>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>>>>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-
>>>>>>>> linux-imx <linux-
>>>>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>> rpmsg GPIO driver
>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
>>>>>>>>>> Jonathan
>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
>>>>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley
>>>>>>>>>> <conor+dt@kernel.org>;
>>>>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
>>>>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>>>>>>> <brgl@bgdev.pl>
>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>>>>>>>> GPIO driver
>>>>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>>>>            __u8 status;
>>>>>>>>>>>>            __u8 value;
>>>>>>>>>>>> };
>>>>>>>>>>> It is the same message format. Please see the message definition
>>>>>>>>>> (GET_DIRECTION) below:
>>>>>>>>>>
>>>>>>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>>>>>>>> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>>>>> +   | 1   | 2   |port |line | err | dir|
>>>>>>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same
>>>>>>>>>> message format.
>>>>>>>>>>
>>>>>>>>> Some changes to the message format are necessary.
>>>>>>>>>
>>>>>>>>> Virtio uses two communication channels (virtqueues): one for
>>>>>>>>> requests and
>>>>>>>> replies, and a second one for events.
>>>>>>>>> In contrast, rpmsg provides only a single communication
>>>>>>>>> channel, so a
>>>>>>>>> type field is required to distinguish between different kinds
>>>>>>>>> of messages.
>>>>>>>>>
>>>>>>>>> Since rpmsg replies and events share the same message format,
>>>>>>>>> an additional
>>>>>>>> line is introduced to handle both cases.
>>>>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port
>>>>>>>>> field is added to
>>>>>>>> uniquely identify the target controller.
>>>>>>>>
>>>>>>>> I have commented on this before - RPMSG is already providing
>>>>>>>> multiplexing
>>>>>>>> capability by way of endpoints.  There is no need for a port
>>>>>>>> field.  One endpoint,
>>>>>>>> one GPIO controller.
>>>>>>>>
>>>>>>> You still need a way to let the remote side know which port the
>>>>>>> endpoint maps to, either
>>>>>>> by embedding the port information in the message (the current
>>>>>>> way), or by sending it
>>>>>>> separately.
>>>>>>>
>>>>>> An endpoint is created with every namespace request.  There should be
>>>>>> one namespace request for every GPIO controller, which yields a
>>>>>> unique
>>>>>> endpoint for each controller and eliminates the need for an extra
>>>>>> field to identify them.
>>>>>
>>>>>
>>>>> Right, but this can still be done by just having one namespace
>>>>> request.
>>>>> We can create new endpoints bound to an existing namespace/channel by
>>>>> invoking rpmsg_create_ept(). This is what I suggested here too:
>>>>> https://lore.kernel.org/all/29485742-6e49-482e-
>>>>> b73d-228295daaeec@ti.com/
>>>>>
>>>>
>>>> I will look at your suggestion (i.e link above) later this week or
>>>> next week.
>>>>
>>>>> My mental model looks like this for the complete picture:
>>>>>
>>>>> 1. namespace/channel#1 = rpmsg-io
>>>>>       a. ept1 -> gpio-controller@1
>>>>>       b. ept2 -> gpio-controller@2
>>>>>

If my understanding of what gpio-controller is right, than this won't
work. We need one rpmsg channel per gpio-controller, and in most cases
there will be only one GPIO-controller on the remote side. If there are
multiple or multiple instances of same controller, than we need separate
channel name for that controller just like we would have separate device
on the Linux.

>>>>
>>>> I've asked for one endpoint per GPIO controller since the very
>>>> beginning.  I don't yet have a strong opinion on whether to use one
>>>> namespace request per GPIO controller or a single request that spins
>>>> off multiple endpoints.  I'll have to look at your link and reflect on
>>>> that.  Regardless of how we proceed on that front, multiplexing needs
>>>> to happen at the endpoint level rather than the packet level.  This is
>>>> the only way this work can move forward.
>>>>
>>>
>>> I would be more in favor of Mathieu’s proposal: “An endpoint is
>>> created with every namespace request.”
>>>
>>> If the endpoint is created only on the Linux side, how do we match
>>> the Linux endpoint address with the local port field on the remote side?
>>
>>
>> Simply by sending a message to the remote containing the newly created
>> endpoint and the port idx. Note that is this done just one time, after
>> this
>> Linux need not have the port field in the message everytime its sending
>> a message.
>>
>>>
>>> With a multi-namespace approach, the namespace could be rpmsg-io-
>>> [addr], where [addr] corresponds to the GPIO controller address in
>>> the DT. This would:
>>
>>
>> You will face the same problem in this case also that you asked above:
>> "how do we match the Linux endpoint address with the local port field
>> on the remote side?"
> 
> Sorry I probably introduced confusion here
> my sentence should be;
>  With a multi-namespace approach, the namespace could be rpmsg-io-[port],
>  where [port] corresponds to the GPIO controller port in the DT.
> 
> 
> For instance:
> 
>       rpmsg {
>         rpmsg-io {
>           #address-cells = <1>;
>           #size-cells = <0>;
> 
>           gpio@25 {
>             compatible = "rpmsg-gpio";
>             reg = <25>;
>             gpio-controller;
>             #gpio-cells = <2>;
>             #interrupt-cells = <2>;
>             interrupt-controller;
>           };
> 
>           gpio@32 {
>             compatible = "rpmsg-gpio";
>             reg = <32>;
>             gpio-controller;
>             #gpio-cells = <2>;
>             #interrupt-cells = <2>;
>             interrupt-controller;
>           };
>         };
>       };
> 
>  rpmsg-io-25  would match with gpio@25
>  rpmsg-io-32  would match with gpio@32
> 

The problem with this approach is, we will endup creating way too many
RPMsg devices/channels. i.e. one channel per one GPIO. That limits how
many GPIOs can be handled by remote from memory perspective. At
somepoint we might just run-out of number ept & channels created by the
remote. As of now, open-amp library supports 128 epts I think.

> 
>>
>> Because the endpoint that is created on a namespace request is also
>> dynamic in nature. How will the remote know which endpoint addr
>> Linux allocated for a namespace that it announced?
>>
>> As an example/PoC, I created a firmware example which announces
>> 2 name services to Linux, one is the standard "rpmsg_chrdev" and
>> the other is a TI specific name service "ti.ipc4.ping-pong". You can
>> see it created 2 different addresses (0x400 and 0x401) for each of
>> the name service request from the same firmware:
>>
>> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
>> [    9.290275] virtio_rpmsg_bus virtio0: creating channel
>> ti.ipc4.ping-pong addr 0xd
>> [    9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev
>> addr 0xe
>> [    9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel
>> formed from src = 0x400 to dst = 0xe
>> [    9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13:
>> new channel: 0x401 -> 0xd!
>>
>> So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
>> Back to same problem. Simple solution is to reply to remote with the
>> created ept addr and the index.
> 
> That why I would like to suggest to use the name service field to
> identify the port/controller, instead of the endpoint address.
>>  
>>>
>>> - match the RPMsg probe with the DT,
>>
>>
>> We can probe from all controllers with a single name service
>> announcement too.
>>
>>> - provide a simple mapping between the port and the endpoint on both
>>> sides,
>>
>>
>> We are trying to get rid of this mapping from Linux side to adapt
>> the gpio-virtio design.
>>
>>> - allow multiple endpoints on the remote side,
>>
>>
>> We can support this as well with single nameservice model.
>> There is no limitation. Remote has to send a message with
>> its newly created ept that's all.
>>
>>> - provide a simple discovery mechanism for remote capabilities.
>>
>>
>> A single announcement: "rpmsg-io" is also discovery mechanism.
>>
>> Feel free to let me know if you have concerns with any of the
>> suggestions!
> 
> My only concern, whatever the solution, is that we find a smart
> solution to associate the correct endpoint with the correct GPIO
> port/controller defined in the DT.
> 
> I may have misunderstood your solution. Could you please help me
> understand your proposal by explaining how you would handle three
> GPIO ports defined in the DT, considering that the endpoint
> addresses on the Linux side can be random?
> If I assume there is a unique endpoint on the remote side,
> I do not understand how you can match, on the firmware side,
> the Linux endpoint address to the GPIO port.
> 
> Thanks and Regards,Arnaud
> 
>>
>> Thanks,
>> Beleswar
>>
>>>
>>> Regards,
>>> Arnaud
>>>
>>>>> 2. namespace/channel#2 = rpmsg-i2c
>>>>>       a. ept1 -> i2c@1
>>>>>       b. ept2 -> i2c@2
>>>>>       c. ept3 -> i2c@3
>>>>>
>>>>> etc...
>>>>>

Just want to clear-up few terms before I jump to the solution:

**RPMsg channel/device**:
  - These are devices announced by the remote processor, and created by
linux. They are created at: /sys/bus/rpmsg/devices
  - The channel format: <name>.<src ept>.<dst ept>

**RPMsg endpoint**:
  - Endpoint is differnt than channel. Single channel can have multiple
endpoints, and represented in the linux with: /dev/rpmsg? devices.

To create endpoint device, we have rpmsg_create_ept API, which takes
channel information as input, which has src-ept, dst-ept.

Following is proposed solution:

1) Assign RPMsg channel/device per rpmsg-gpio controller (Not per GPIO
pin/port).
  - In our case that would be, single rpmsg-io node. (That makes me
question if bindings are correct or not).

2) Assign GPIO number as src ept.

i.e. *rpmsg-io.<GPIO number>.<dst ept>*. Do not randomly assign src
endpoint.

Now, RPMSG channel by spec reserves first 1024 endpoints [1], so we can
add 1024 offset to the GPIO number:

so, when calling rpmsg_create_ept() API, we assing src_endpoint as:
(GPIO_NUMBER + RPMSG_RESERVED_ADDRESSES)

Now on the remote side, there is single channel and only single-endpoint
is needed that is mapped to the rpmsg-io channel callback.

That callback will receive all the payloads from the Linux, which will
have src-ept i.e. (RPMSG_RESERVED_ADDRESSES + GPIO_NUMBER).

It can retrieve GPIO_NUMBER easily, and convert to appropriate pin based
on platform specific logic.

This doesn't need PORT information at all. Also it makes sure that
remote is using only single-endpoint so not much memory is used.

*Example*:
If only rpmsg-gpio channel is created by the remote side, than following
is the representation of the devices when GPIO 25, 26, 27 is assigned to
the rpmsg-io controller:

Linux                                                      Remote

rpmsg-channel: rpmsg-gpio.0x400.0x400

/dev/rpmsg0 - GPIO25 ept (rpmsg-gpio.0x419.0x400)-|
                                                  |
/dev/rpmsg1 - GPIO26 ept (rpmsg-gpio.0x41a.0x400)-|-> rpmsg-gpio.*.0x400
                                                  |
/dev/rpmsg2 - GPIO27 ept (rpmsg-gpio.0x41b.0x400)-|  0x400 ept callback.


*On remote side*:

ept_0x400_callback(..., int src_ept, ...,)
{
	int gpio_num = src_ept - RPMSG_RESERVED_ADDRESSES;
	// platform specific logic to convert gpio num to proper pin,
	// just like you would convert gpio num to pin on a linux gpio controller.
}

My question on the binding:

Why each GPIO is represented with the separate node? I think rpmsg-gpio
can be represented just any other GPIO controller? Please let me know if
I am missing something. So rpmsg channel/rpmsg device is not created per
GPIO, but per controller. GPIO number multiplexing should be done with
rpmsg src ept, that removes the need of having each GPIO as a separate node.


rpmsg_gpio: rpmsg-gpio@0 {
		compatible = "rpmsg-gpio";
		reg = <0>;
		gpio-controller;
		#gpio-cells = <2>;
		#interrupt-cells = <2>;
		interrupt-controller;
	};

Then in DT, use like regular GPIO, but with the rpmsg-gpio controller:

rpmsg-gpios = <&rpmsg_gpio (GPIO NUM) (flags)>;

If the intent to create separate gpio nodes was only for the channel
creation, then it's not really needed.

[1]
https://github.com/torvalds/linux/blob/6d35786de28116ecf78797a62b84e6bf3c45aa5a/drivers/rpmsg/virtio_rpmsg_bus.c#L136

>>>>> This way device groups are isolated with each channel/namespace, and
>>>>> instances within each device groups are also respected with specific
>>>>> endpoints.
>>>>>
>>>>> Thanks,
>>>>> Beleswar
>>>>>
>>>>
>>>
> 
> 

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

[Arnaud POULIQUEN]

Hi Tanmay,

On 5/4/26 21:19, Shah, Tanmay wrote:
> 
> Hello all,
> 
> I have started reviewing this work as well.
> Thanks Shenwei for this work.
> 
> I have gone through only the current revision, and would like to provide
> idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
> Also, have some bindings related question.
> 
> Please see below:
> 
> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
>>
>>
>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>>> Hello Arnaud,
>>>
>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>>> Hello,
>>>>
>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>>>>>
>>>>>> Hi Mathieu,
>>>>>>
>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-
>>>>>>>>> padhi@ti.com>; Linus
>>>>>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski
>>>>>>>>> <brgl@kernel.org>; Jonathan
>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
>>>>>>>>> Krzysztof Kozlowski
>>>>>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn
>>>>>>>>> Andersson
>>>>>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>>>>>>>> <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>> <skhan@linuxfoundation.org>; linux-
>>>>>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-
>>>>>>>>> kernel@vger.kernel.org;
>>>>>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>>>>>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-
>>>>>>>>> linux-imx <linux-
>>>>>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>> rpmsg GPIO driver
>>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
>>>>>>>>>>> Jonathan
>>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
>>>>>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley
>>>>>>>>>>> <conor+dt@kernel.org>;
>>>>>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>>>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
>>>>>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>>>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>>>>>>>> <brgl@bgdev.pl>
>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>>>>>>>>> GPIO driver
>>>>>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>>>>>             __u8 status;
>>>>>>>>>>>>>             __u8 value;
>>>>>>>>>>>>> };
>>>>>>>>>>>> It is the same message format. Please see the message definition
>>>>>>>>>>> (GET_DIRECTION) below:
>>>>>>>>>>>
>>>>>>>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>>>>>>>>> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>>>>>> +   | 1   | 2   |port |line | err | dir|
>>>>>>>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same
>>>>>>>>>>> message format.
>>>>>>>>>>>
>>>>>>>>>> Some changes to the message format are necessary.
>>>>>>>>>>
>>>>>>>>>> Virtio uses two communication channels (virtqueues): one for
>>>>>>>>>> requests and
>>>>>>>>> replies, and a second one for events.
>>>>>>>>>> In contrast, rpmsg provides only a single communication
>>>>>>>>>> channel, so a
>>>>>>>>>> type field is required to distinguish between different kinds
>>>>>>>>>> of messages.
>>>>>>>>>>
>>>>>>>>>> Since rpmsg replies and events share the same message format,
>>>>>>>>>> an additional
>>>>>>>>> line is introduced to handle both cases.
>>>>>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port
>>>>>>>>>> field is added to
>>>>>>>>> uniquely identify the target controller.
>>>>>>>>>
>>>>>>>>> I have commented on this before - RPMSG is already providing
>>>>>>>>> multiplexing
>>>>>>>>> capability by way of endpoints.  There is no need for a port
>>>>>>>>> field.  One endpoint,
>>>>>>>>> one GPIO controller.
>>>>>>>>>
>>>>>>>> You still need a way to let the remote side know which port the
>>>>>>>> endpoint maps to, either
>>>>>>>> by embedding the port information in the message (the current
>>>>>>>> way), or by sending it
>>>>>>>> separately.
>>>>>>>>
>>>>>>> An endpoint is created with every namespace request.  There should be
>>>>>>> one namespace request for every GPIO controller, which yields a
>>>>>>> unique
>>>>>>> endpoint for each controller and eliminates the need for an extra
>>>>>>> field to identify them.
>>>>>>
>>>>>>
>>>>>> Right, but this can still be done by just having one namespace
>>>>>> request.
>>>>>> We can create new endpoints bound to an existing namespace/channel by
>>>>>> invoking rpmsg_create_ept(). This is what I suggested here too:
>>>>>> https://lore.kernel.org/all/29485742-6e49-482e-
>>>>>> b73d-228295daaeec@ti.com/
>>>>>>
>>>>>
>>>>> I will look at your suggestion (i.e link above) later this week or
>>>>> next week.
>>>>>
>>>>>> My mental model looks like this for the complete picture:
>>>>>>
>>>>>> 1. namespace/channel#1 = rpmsg-io
>>>>>>        a. ept1 -> gpio-controller@1
>>>>>>        b. ept2 -> gpio-controller@2
>>>>>>
> 
> If my understanding of what gpio-controller is right, than this won't
> work. We need one rpmsg channel per gpio-controller, and in most cases
> there will be only one GPIO-controller on the remote side. If there are
> multiple or multiple instances of same controller, than we need separate
> channel name for that controller just like we would have separate device
> on the Linux.

As done in ehe rpmsg_tty driver it could be instantiated several times with
the same channel/service name. This would imply a specific rpmsg to retreive
the gpio controller index from the remote side.
> 
>>>>>
>>>>> I've asked for one endpoint per GPIO controller since the very
>>>>> beginning.  I don't yet have a strong opinion on whether to use one
>>>>> namespace request per GPIO controller or a single request that spins
>>>>> off multiple endpoints.  I'll have to look at your link and reflect on
>>>>> that.  Regardless of how we proceed on that front, multiplexing needs
>>>>> to happen at the endpoint level rather than the packet level.  This is
>>>>> the only way this work can move forward.
>>>>>
>>>>
>>>> I would be more in favor of Mathieu’s proposal: “An endpoint is
>>>> created with every namespace request.”
>>>>
>>>> If the endpoint is created only on the Linux side, how do we match
>>>> the Linux endpoint address with the local port field on the remote side?
>>>
>>>
>>> Simply by sending a message to the remote containing the newly created
>>> endpoint and the port idx. Note that is this done just one time, after
>>> this
>>> Linux need not have the port field in the message everytime its sending
>>> a message.
>>>
>>>>
>>>> With a multi-namespace approach, the namespace could be rpmsg-io-
>>>> [addr], where [addr] corresponds to the GPIO controller address in
>>>> the DT. This would:
>>>
>>>
>>> You will face the same problem in this case also that you asked above:
>>> "how do we match the Linux endpoint address with the local port field
>>> on the remote side?"
>>
>> Sorry I probably introduced confusion here
>> my sentence should be;
>>   With a multi-namespace approach, the namespace could be rpmsg-io-[port],
>>   where [port] corresponds to the GPIO controller port in the DT.
>>
>>
>> For instance:
>>
>>        rpmsg {
>>          rpmsg-io {
>>            #address-cells = <1>;
>>            #size-cells = <0>;
>>
>>            gpio@25 {
>>              compatible = "rpmsg-gpio";
>>              reg = <25>;
>>              gpio-controller;
>>              #gpio-cells = <2>;
>>              #interrupt-cells = <2>;
>>              interrupt-controller;
>>            };
>>
>>            gpio@32 {
>>              compatible = "rpmsg-gpio";
>>              reg = <32>;
>>              gpio-controller;
>>              #gpio-cells = <2>;
>>              #interrupt-cells = <2>;
>>              interrupt-controller;
>>            };
>>          };
>>        };
>>
>>   rpmsg-io-25  would match with gpio@25
>>   rpmsg-io-32  would match with gpio@32
>>
> 
> The problem with this approach is, we will endup creating way too many
> RPMsg devices/channels. i.e. one channel per one GPIO. That limits how
> many GPIOs can be handled by remote from memory perspective. At
> somepoint we might just run-out of number ept & channels created by the
> remote. As of now, open-amp library supports 128 epts I think.

Right, I proposed a solution in my previous answer to Beleswar who has
the same concern.

> 
>>
>>>
>>> Because the endpoint that is created on a namespace request is also
>>> dynamic in nature. How will the remote know which endpoint addr
>>> Linux allocated for a namespace that it announced?
>>>
>>> As an example/PoC, I created a firmware example which announces
>>> 2 name services to Linux, one is the standard "rpmsg_chrdev" and
>>> the other is a TI specific name service "ti.ipc4.ping-pong". You can
>>> see it created 2 different addresses (0x400 and 0x401) for each of
>>> the name service request from the same firmware:
>>>
>>> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
>>> [    9.290275] virtio_rpmsg_bus virtio0: creating channel
>>> ti.ipc4.ping-pong addr 0xd
>>> [    9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev
>>> addr 0xe
>>> [    9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel
>>> formed from src = 0x400 to dst = 0xe
>>> [    9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13:
>>> new channel: 0x401 -> 0xd!
>>>
>>> So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
>>> Back to same problem. Simple solution is to reply to remote with the
>>> created ept addr and the index.
>>
>> That why I would like to suggest to use the name service field to
>> identify the port/controller, instead of the endpoint address.
>>>   
>>>>
>>>> - match the RPMsg probe with the DT,
>>>
>>>
>>> We can probe from all controllers with a single name service
>>> announcement too.
>>>
>>>> - provide a simple mapping between the port and the endpoint on both
>>>> sides,
>>>
>>>
>>> We are trying to get rid of this mapping from Linux side to adapt
>>> the gpio-virtio design.
>>>
>>>> - allow multiple endpoints on the remote side,
>>>
>>>
>>> We can support this as well with single nameservice model.
>>> There is no limitation. Remote has to send a message with
>>> its newly created ept that's all.
>>>
>>>> - provide a simple discovery mechanism for remote capabilities.
>>>
>>>
>>> A single announcement: "rpmsg-io" is also discovery mechanism.
>>>
>>> Feel free to let me know if you have concerns with any of the
>>> suggestions!
>>
>> My only concern, whatever the solution, is that we find a smart
>> solution to associate the correct endpoint with the correct GPIO
>> port/controller defined in the DT.
>>
>> I may have misunderstood your solution. Could you please help me
>> understand your proposal by explaining how you would handle three
>> GPIO ports defined in the DT, considering that the endpoint
>> addresses on the Linux side can be random?
>> If I assume there is a unique endpoint on the remote side,
>> I do not understand how you can match, on the firmware side,
>> the Linux endpoint address to the GPIO port.
>>
>> Thanks and Regards,Arnaud
>>
>>>
>>> Thanks,
>>> Beleswar
>>>
>>>>
>>>> Regards,
>>>> Arnaud
>>>>
>>>>>> 2. namespace/channel#2 = rpmsg-i2c
>>>>>>        a. ept1 -> i2c@1
>>>>>>        b. ept2 -> i2c@2
>>>>>>        c. ept3 -> i2c@3
>>>>>>
>>>>>> etc...
>>>>>>
> 
> Just want to clear-up few terms before I jump to the solution:
> 
> **RPMsg channel/device**:
>    - These are devices announced by the remote processor, and created by
> linux. They are created at: /sys/bus/rpmsg/devices
>    - The channel format: <name>.<src ept>.<dst ept>
> 
> **RPMsg endpoint**:
>    - Endpoint is differnt than channel. Single channel can have multiple
> endpoints, and represented in the linux with: /dev/rpmsg? devices.
> 
> To create endpoint device, we have rpmsg_create_ept API, which takes
> channel information as input, which has src-ept, dst-ept.
> 
> Following is proposed solution:
> 
> 1) Assign RPMsg channel/device per rpmsg-gpio controller (Not per GPIO
> pin/port).
>    - In our case that would be, single rpmsg-io node. (That makes me
> question if bindings are correct or not).
> 
> 2) Assign GPIO number as src ept.
> 
> i.e. *rpmsg-io.<GPIO number>.<dst ept>*. Do not randomly assign src
> endpoint.
> 
> Now, RPMSG channel by spec reserves first 1024 endpoints [1], so we can
> add 1024 offset to the GPIO number:
> 
> so, when calling rpmsg_create_ept() API, we assing src_endpoint as:
> (GPIO_NUMBER + RPMSG_RESERVED_ADDRESSES)
> 
> Now on the remote side, there is single channel and only single-endpoint
> is needed that is mapped to the rpmsg-io channel callback.
> 
> That callback will receive all the payloads from the Linux, which will
> have src-ept i.e. (RPMSG_RESERVED_ADDRESSES + GPIO_NUMBER).


Interesting approach. I also tried to find a similar solution.

The question here is: how can we guarantee continuous addresses? Given 
the static and dynamic allocation of endpoint addresses that are 
implemented, my conclusion was that it is not reliable enough.

but perhaps I missed something...

> 
> It can retrieve GPIO_NUMBER easily, and convert to appropriate pin based
> on platform specific logic.
> 
> This doesn't need PORT information at all. Also it makes sure that
> remote is using only single-endpoint so not much memory is used.
> 
> *Example*:
> If only rpmsg-gpio channel is created by the remote side, than following
> is the representation of the devices when GPIO 25, 26, 27 is assigned to
> the rpmsg-io controller:
> 
> Linux                                                      Remote
> 
> rpmsg-channel: rpmsg-gpio.0x400.0x400
> 
> /dev/rpmsg0 - GPIO25 ept (rpmsg-gpio.0x419.0x400)-|
>                                                    |
> /dev/rpmsg1 - GPIO26 ept (rpmsg-gpio.0x41a.0x400)-|-> rpmsg-gpio.*.0x400
>                                                    |
> /dev/rpmsg2 - GPIO27 ept (rpmsg-gpio.0x41b.0x400)-|  0x400 ept callback.
> 
> 
> *On remote side*:
> 
> ept_0x400_callback(..., int src_ept, ...,)
> {
> 	int gpio_num = src_ept - RPMSG_RESERVED_ADDRESSES;
> 	// platform specific logic to convert gpio num to proper pin,
> 	// just like you would convert gpio num to pin on a linux gpio controller.
> }
> 
> My question on the binding:
> 
> Why each GPIO is represented with the separate node? I think rpmsg-gpio
> can be represented just any other GPIO controller? Please let me know if
> I am missing something. So rpmsg channel/rpmsg device is not created per
> GPIO, but per controller. GPIO number multiplexing should be done with
> rpmsg src ept, that removes the need of having each GPIO as a separate node.
> 
> 
> rpmsg_gpio: rpmsg-gpio@0 {
> 		compatible = "rpmsg-gpio";
> 		reg = <0>;
> 		gpio-controller;
> 		#gpio-cells = <2>;
> 		#interrupt-cells = <2>;
> 		interrupt-controller;
> 	};
> 
> Then in DT, use like regular GPIO, but with the rpmsg-gpio controller:
> 
> rpmsg-gpios = <&rpmsg_gpio (GPIO NUM) (flags)>;
> 
> If the intent to create separate gpio nodes was only for the channel
> creation, then it's not really needed.
> 
> [1]
> https://github.com/torvalds/linux/blob/6d35786de28116ecf78797a62b84e6bf3c45aa5a/drivers/rpmsg/virtio_rpmsg_bus.c#L136
>

It is already the case. bindings declare GPIO controllers, not directly 
GPIOs in:

[PATCH v13 2/4] dt-bindings: remoteproc: imx_rproc: Add "rpmsg" subnode 
support

The discussion is around having an unique RPmsg endpoint for all
GPIO controller or one RPmsg endpoint per GPIO controller.

Or did I misunderstand your questions?

Thanks,
Arnaud


>>>>>> This way device groups are isolated with each channel/namespace, and
>>>>>> instances within each device groups are also respected with specific
>>>>>> endpoints.
>>>>>>
>>>>>> Thanks,
>>>>>> Beleswar
>>>>>>
>>>>>
>>>>
>>
>>
> 

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

[Shah, Tanmay]

On 5/5/2026 4:28 AM, Arnaud POULIQUEN wrote:
> Hi Tanmay,
> 
> On 5/4/26 21:19, Shah, Tanmay wrote:
>>
>> Hello all,
>>
>> I have started reviewing this work as well.
>> Thanks Shenwei for this work.
>>
>> I have gone through only the current revision, and would like to provide
>> idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
>> Also, have some bindings related question.
>>
>> Please see below:
>>
>> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
>>>
>>>
>>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>>>> Hello Arnaud,
>>>>
>>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>>>> Hello,
>>>>>
>>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>>>>>>
>>>>>>> Hi Mathieu,
>>>>>>>
>>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-
>>>>>>>>>> padhi@ti.com>; Linus
>>>>>>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski
>>>>>>>>>> <brgl@kernel.org>; Jonathan
>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
>>>>>>>>>> Krzysztof Kozlowski
>>>>>>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn
>>>>>>>>>> Andersson
>>>>>>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>>>>>>>>> <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>>> <skhan@linuxfoundation.org>; linux-
>>>>>>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-
>>>>>>>>>> kernel@vger.kernel.org;
>>>>>>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>>>>>>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-
>>>>>>>>>> linux-imx <linux-
>>>>>>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>>> rpmsg GPIO driver
>>>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>>>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
>>>>>>>>>>>> Jonathan
>>>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
>>>>>>>>>>>> Krzysztof
>>>>>>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley
>>>>>>>>>>>> <conor+dt@kernel.org>;
>>>>>>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>>>>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>;
>>>>>>>>>>>> Sascha
>>>>>>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>>>>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>>>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>>>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>>>>>>>>> <brgl@bgdev.pl>
>>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>>>>> rpmsg
>>>>>>>>>>>> GPIO driver
>>>>>>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>>>>>>             __u8 status;
>>>>>>>>>>>>>>             __u8 value;
>>>>>>>>>>>>>> };
>>>>>>>>>>>>> It is the same message format. Please see the message
>>>>>>>>>>>>> definition
>>>>>>>>>>>> (GET_DIRECTION) below:
>>>>>>>>>>>>
>>>>>>>>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>>>>>>>>>> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>>>>>>> +   | 1   | 2   |port |line | err | dir|
>>>>>>>>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>>>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same
>>>>>>>>>>>> message format.
>>>>>>>>>>>>
>>>>>>>>>>> Some changes to the message format are necessary.
>>>>>>>>>>>
>>>>>>>>>>> Virtio uses two communication channels (virtqueues): one for
>>>>>>>>>>> requests and
>>>>>>>>>> replies, and a second one for events.
>>>>>>>>>>> In contrast, rpmsg provides only a single communication
>>>>>>>>>>> channel, so a
>>>>>>>>>>> type field is required to distinguish between different kinds
>>>>>>>>>>> of messages.
>>>>>>>>>>>
>>>>>>>>>>> Since rpmsg replies and events share the same message format,
>>>>>>>>>>> an additional
>>>>>>>>>> line is introduced to handle both cases.
>>>>>>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port
>>>>>>>>>>> field is added to
>>>>>>>>>> uniquely identify the target controller.
>>>>>>>>>>
>>>>>>>>>> I have commented on this before - RPMSG is already providing
>>>>>>>>>> multiplexing
>>>>>>>>>> capability by way of endpoints.  There is no need for a port
>>>>>>>>>> field.  One endpoint,
>>>>>>>>>> one GPIO controller.
>>>>>>>>>>
>>>>>>>>> You still need a way to let the remote side know which port the
>>>>>>>>> endpoint maps to, either
>>>>>>>>> by embedding the port information in the message (the current
>>>>>>>>> way), or by sending it
>>>>>>>>> separately.
>>>>>>>>>
>>>>>>>> An endpoint is created with every namespace request.  There
>>>>>>>> should be
>>>>>>>> one namespace request for every GPIO controller, which yields a
>>>>>>>> unique
>>>>>>>> endpoint for each controller and eliminates the need for an extra
>>>>>>>> field to identify them.
>>>>>>>
>>>>>>>
>>>>>>> Right, but this can still be done by just having one namespace
>>>>>>> request.
>>>>>>> We can create new endpoints bound to an existing namespace/
>>>>>>> channel by
>>>>>>> invoking rpmsg_create_ept(). This is what I suggested here too:
>>>>>>> https://lore.kernel.org/all/29485742-6e49-482e-
>>>>>>> b73d-228295daaeec@ti.com/
>>>>>>>
>>>>>>
>>>>>> I will look at your suggestion (i.e link above) later this week or
>>>>>> next week.
>>>>>>
>>>>>>> My mental model looks like this for the complete picture:
>>>>>>>
>>>>>>> 1. namespace/channel#1 = rpmsg-io
>>>>>>>        a. ept1 -> gpio-controller@1
>>>>>>>        b. ept2 -> gpio-controller@2
>>>>>>>
>>
>> If my understanding of what gpio-controller is right, than this won't
>> work. We need one rpmsg channel per gpio-controller, and in most cases
>> there will be only one GPIO-controller on the remote side. If there are
>> multiple or multiple instances of same controller, than we need separate
>> channel name for that controller just like we would have separate device
>> on the Linux.
> 
> As done in ehe rpmsg_tty driver it could be instantiated several times with
> the same channel/service name. This would imply a specific rpmsg to
> retreive
> the gpio controller index from the remote side.
>>
>>>>>>
>>>>>> I've asked for one endpoint per GPIO controller since the very
>>>>>> beginning.  I don't yet have a strong opinion on whether to use one
>>>>>> namespace request per GPIO controller or a single request that spins
>>>>>> off multiple endpoints.  I'll have to look at your link and
>>>>>> reflect on
>>>>>> that.  Regardless of how we proceed on that front, multiplexing needs
>>>>>> to happen at the endpoint level rather than the packet level. 
>>>>>> This is
>>>>>> the only way this work can move forward.
>>>>>>
>>>>>
>>>>> I would be more in favor of Mathieu’s proposal: “An endpoint is
>>>>> created with every namespace request.”
>>>>>
>>>>> If the endpoint is created only on the Linux side, how do we match
>>>>> the Linux endpoint address with the local port field on the remote
>>>>> side?
>>>>
>>>>
>>>> Simply by sending a message to the remote containing the newly created
>>>> endpoint and the port idx. Note that is this done just one time, after
>>>> this
>>>> Linux need not have the port field in the message everytime its sending
>>>> a message.
>>>>
>>>>>
>>>>> With a multi-namespace approach, the namespace could be rpmsg-io-
>>>>> [addr], where [addr] corresponds to the GPIO controller address in
>>>>> the DT. This would:
>>>>
>>>>
>>>> You will face the same problem in this case also that you asked above:
>>>> "how do we match the Linux endpoint address with the local port field
>>>> on the remote side?"
>>>
>>> Sorry I probably introduced confusion here
>>> my sentence should be;
>>>   With a multi-namespace approach, the namespace could be rpmsg-io-
>>> [port],
>>>   where [port] corresponds to the GPIO controller port in the DT.
>>>
>>>
>>> For instance:
>>>
>>>        rpmsg {
>>>          rpmsg-io {
>>>            #address-cells = <1>;
>>>            #size-cells = <0>;
>>>
>>>            gpio@25 {
>>>              compatible = "rpmsg-gpio";
>>>              reg = <25>;
>>>              gpio-controller;
>>>              #gpio-cells = <2>;
>>>              #interrupt-cells = <2>;
>>>              interrupt-controller;
>>>            };
>>>
>>>            gpio@32 {
>>>              compatible = "rpmsg-gpio";
>>>              reg = <32>;
>>>              gpio-controller;
>>>              #gpio-cells = <2>;
>>>              #interrupt-cells = <2>;
>>>              interrupt-controller;
>>>            };
>>>          };
>>>        };
>>>
>>>   rpmsg-io-25  would match with gpio@25
>>>   rpmsg-io-32  would match with gpio@32
>>>
>>
>> The problem with this approach is, we will endup creating way too many
>> RPMsg devices/channels. i.e. one channel per one GPIO. That limits how
>> many GPIOs can be handled by remote from memory perspective. At
>> somepoint we might just run-out of number ept & channels created by the
>> remote. As of now, open-amp library supports 128 epts I think.
> 
> Right, I proposed a solution in my previous answer to Beleswar who has
> the same concern.
> 
>>
>>>
>>>>
>>>> Because the endpoint that is created on a namespace request is also
>>>> dynamic in nature. How will the remote know which endpoint addr
>>>> Linux allocated for a namespace that it announced?
>>>>
>>>> As an example/PoC, I created a firmware example which announces
>>>> 2 name services to Linux, one is the standard "rpmsg_chrdev" and
>>>> the other is a TI specific name service "ti.ipc4.ping-pong". You can
>>>> see it created 2 different addresses (0x400 and 0x401) for each of
>>>> the name service request from the same firmware:
>>>>
>>>> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
>>>> [    9.290275] virtio_rpmsg_bus virtio0: creating channel
>>>> ti.ipc4.ping-pong addr 0xd
>>>> [    9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev
>>>> addr 0xe
>>>> [    9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel
>>>> formed from src = 0x400 to dst = 0xe
>>>> [    9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13:
>>>> new channel: 0x401 -> 0xd!
>>>>
>>>> So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
>>>> Back to same problem. Simple solution is to reply to remote with the
>>>> created ept addr and the index.
>>>
>>> That why I would like to suggest to use the name service field to
>>> identify the port/controller, instead of the endpoint address.
>>>>  
>>>>>
>>>>> - match the RPMsg probe with the DT,
>>>>
>>>>
>>>> We can probe from all controllers with a single name service
>>>> announcement too.
>>>>
>>>>> - provide a simple mapping between the port and the endpoint on both
>>>>> sides,
>>>>
>>>>
>>>> We are trying to get rid of this mapping from Linux side to adapt
>>>> the gpio-virtio design.
>>>>
>>>>> - allow multiple endpoints on the remote side,
>>>>
>>>>
>>>> We can support this as well with single nameservice model.
>>>> There is no limitation. Remote has to send a message with
>>>> its newly created ept that's all.
>>>>
>>>>> - provide a simple discovery mechanism for remote capabilities.
>>>>
>>>>
>>>> A single announcement: "rpmsg-io" is also discovery mechanism.
>>>>
>>>> Feel free to let me know if you have concerns with any of the
>>>> suggestions!
>>>
>>> My only concern, whatever the solution, is that we find a smart
>>> solution to associate the correct endpoint with the correct GPIO
>>> port/controller defined in the DT.
>>>
>>> I may have misunderstood your solution. Could you please help me
>>> understand your proposal by explaining how you would handle three
>>> GPIO ports defined in the DT, considering that the endpoint
>>> addresses on the Linux side can be random?
>>> If I assume there is a unique endpoint on the remote side,
>>> I do not understand how you can match, on the firmware side,
>>> the Linux endpoint address to the GPIO port.
>>>
>>> Thanks and Regards,Arnaud
>>>
>>>>
>>>> Thanks,
>>>> Beleswar
>>>>
>>>>>
>>>>> Regards,
>>>>> Arnaud
>>>>>
>>>>>>> 2. namespace/channel#2 = rpmsg-i2c
>>>>>>>        a. ept1 -> i2c@1
>>>>>>>        b. ept2 -> i2c@2
>>>>>>>        c. ept3 -> i2c@3
>>>>>>>
>>>>>>> etc...
>>>>>>>
>>
>> Just want to clear-up few terms before I jump to the solution:
>>
>> **RPMsg channel/device**:
>>    - These are devices announced by the remote processor, and created by
>> linux. They are created at: /sys/bus/rpmsg/devices
>>    - The channel format: <name>.<src ept>.<dst ept>
>>
>> **RPMsg endpoint**:
>>    - Endpoint is differnt than channel. Single channel can have multiple
>> endpoints, and represented in the linux with: /dev/rpmsg? devices.
>>
>> To create endpoint device, we have rpmsg_create_ept API, which takes
>> channel information as input, which has src-ept, dst-ept.
>>
>> Following is proposed solution:
>>
>> 1) Assign RPMsg channel/device per rpmsg-gpio controller (Not per GPIO
>> pin/port).
>>    - In our case that would be, single rpmsg-io node. (That makes me
>> question if bindings are correct or not).
>>
>> 2) Assign GPIO number as src ept.
>>
>> i.e. *rpmsg-io.<GPIO number>.<dst ept>*. Do not randomly assign src
>> endpoint.
>>
>> Now, RPMSG channel by spec reserves first 1024 endpoints [1], so we can
>> add 1024 offset to the GPIO number:
>>
>> so, when calling rpmsg_create_ept() API, we assing src_endpoint as:
>> (GPIO_NUMBER + RPMSG_RESERVED_ADDRESSES)
>>
>> Now on the remote side, there is single channel and only single-endpoint
>> is needed that is mapped to the rpmsg-io channel callback.
>>
>> That callback will receive all the payloads from the Linux, which will
>> have src-ept i.e. (RPMSG_RESERVED_ADDRESSES + GPIO_NUMBER).
> 
> 
> Interesting approach. I also tried to find a similar solution.
> 
> The question here is: how can we guarantee continuous addresses? Given
> the static and dynamic allocation of endpoint addresses that are
> implemented, my conclusion was that it is not reliable enough.
> 
> but perhaps I missed something...
> 
>>
>> It can retrieve GPIO_NUMBER easily, and convert to appropriate pin based
>> on platform specific logic.
>>
>> This doesn't need PORT information at all. Also it makes sure that
>> remote is using only single-endpoint so not much memory is used.
>>
>> *Example*:
>> If only rpmsg-gpio channel is created by the remote side, than following
>> is the representation of the devices when GPIO 25, 26, 27 is assigned to
>> the rpmsg-io controller:
>>
>> Linux                                                      Remote
>>
>> rpmsg-channel: rpmsg-gpio.0x400.0x400
>>
>> /dev/rpmsg0 - GPIO25 ept (rpmsg-gpio.0x419.0x400)-|
>>                                                    |
>> /dev/rpmsg1 - GPIO26 ept (rpmsg-gpio.0x41a.0x400)-|-> rpmsg-gpio.*.0x400
>>                                                    |
>> /dev/rpmsg2 - GPIO27 ept (rpmsg-gpio.0x41b.0x400)-|  0x400 ept callback.
>>
>>
>> *On remote side*:
>>
>> ept_0x400_callback(..., int src_ept, ...,)
>> {
>>     int gpio_num = src_ept - RPMSG_RESERVED_ADDRESSES;
>>     // platform specific logic to convert gpio num to proper pin,
>>     // just like you would convert gpio num to pin on a linux gpio
>> controller.
>> }
>>
>> My question on the binding:
>>
>> Why each GPIO is represented with the separate node? I think rpmsg-gpio
>> can be represented just any other GPIO controller? Please let me know if
>> I am missing something. So rpmsg channel/rpmsg device is not created per
>> GPIO, but per controller. GPIO number multiplexing should be done with
>> rpmsg src ept, that removes the need of having each GPIO as a separate
>> node.
>>
>>
>> rpmsg_gpio: rpmsg-gpio@0 {
>>         compatible = "rpmsg-gpio";
>>         reg = <0>;
>>         gpio-controller;
>>         #gpio-cells = <2>;
>>         #interrupt-cells = <2>;
>>         interrupt-controller;
>>     };
>>
>> Then in DT, use like regular GPIO, but with the rpmsg-gpio controller:
>>
>> rpmsg-gpios = <&rpmsg_gpio (GPIO NUM) (flags)>;
>>
>> If the intent to create separate gpio nodes was only for the channel
>> creation, then it's not really needed.
>>
>> [1]
>> https://github.com/torvalds/linux/
>> blob/6d35786de28116ecf78797a62b84e6bf3c45aa5a/drivers/rpmsg/
>> virtio_rpmsg_bus.c#L136
>>
> 
> It is already the case. bindings declare GPIO controllers, not directly
> GPIOs in:
> 
> [PATCH v13 2/4] dt-bindings: remoteproc: imx_rproc: Add "rpmsg" subnode
> support
> 
> The discussion is around having an unique RPmsg endpoint for all
> GPIO controller or one RPmsg endpoint per GPIO controller.
> 

Endpoint where remote side or linux side?

If unique endpoint on remote side per gpio controller then it makes sense.

Unique endpoint on linux side doesn't make sense. Instead, unique
channel per gpio controller makes sense, and each channel will have
multiple endpoints on linux side. As I replied to Beleswar on the other
email, I will copy past my answer here too:


To be more specific:

Linux:                               remote:

ch1: rpmsg-gpio.-1.1024 ->     gpio-controller@1024
    - gpio-line ept1
    - gpio-line ept2    ->     They all map to same callback_ept_1024.
    - gpio-line ept3

ch2: rpmsg-gpio.-1.1025 ->     gpio-controller@1025
    - gpio-line ept1
    - gpio-line ept2    ->     They all map to same callback_ept_1025.
    - gpio-line ept3

On the remote side, we have to hardcode Which rpmsg controller is mapped
to which endpoint.

> Or did I misunderstand your questions?
> 
> Thanks,
> Arnaud
> 


I gave this patch more time yesterday, and I think the 'reg' property
should represent remote endpoint, instead of the gpio-controller index.

So in this approach remote implementation is expected to provide
hard-coded (static) endpoints for each gpio-controller instance, and
that same number should be represented with the 'reg' property.

On remote side:

#define RPMSG_GPIO_0_CONTROLLER_EPT (RPMSG_RESERVED_ADDRESSES + 1) // 1024

ept_1024_callback() {

	// handle appropriate gpio port ()

}

On linux side:

So new representation of controller:

 rpmsg_gpio_0:   gpio@1024 {
             compatible = "rpmsg-gpio";
             reg = <1024>;
             gpio-controller;
             #gpio-cells = <2>;
             #interrupt-cells = <2>;
             interrupt-controller;
          };

 rpmsg_gpio_1:   gpio@1025 {
             compatible = "rpmsg-gpio";
             reg = <1025>;
             gpio-controller;
             #gpio-cells = <2>;
             #interrupt-cells = <2>;
             interrupt-controller;
          };

gpios = <&rpmsg_gpio_0 (GPIO NUM or PIN) flags>,
	<&rpmsg_gpio_1 (GPIO NUM or PIN) flags>;

Now in the linux driver:

You can easily retrieve destination endpoint when we want to send the
command to the gpio controller via device's "reg" property.

This approach also provides built-in security as well. Because now
gpio-controller instance is hardcoded with the endpoint callback, it
can't be modified/addressed without changing the 'reg' property.

Just like you wouldn't change device address for the instance of the
gpio-controller right?

This approach can be easily adapted to all the other rpmsg controllers
as well.

So, dynamic endpoint allocation doesn't make sense in this case. Dynamic
endpoint allocation makes more sense for user-space apps which don't
really care about endpoints and only payloads.

But, here we are multiplexing device-addresses with endpoints, and so it
has to be fixed, and presented via 'reg' property. So, firmware can't
change device-address without Linux knowing it.

Thanks,
Tanmay


> 
>>>>>>> This way device groups are isolated with each channel/namespace, and
>>>>>>> instances within each device groups are also respected with specific
>>>>>>> endpoints.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Beleswar
>>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
> 

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

[Shah, Tanmay]

On 5/5/2026 10:52 AM, Shah, Tanmay wrote:
> 
> 
> On 5/5/2026 4:28 AM, Arnaud POULIQUEN wrote:
>> Hi Tanmay,
>>
>> On 5/4/26 21:19, Shah, Tanmay wrote:
>>>
>>> Hello all,
>>>
>>> I have started reviewing this work as well.
>>> Thanks Shenwei for this work.
>>>
>>> I have gone through only the current revision, and would like to provide
>>> idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
>>> Also, have some bindings related question.
>>>
>>> Please see below:
>>>
>>> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
>>>>
>>>>
>>>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>>>>> Hello Arnaud,
>>>>>
>>>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>>>>> Hello,
>>>>>>
>>>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>>>>>>>
>>>>>>>> Hi Mathieu,
>>>>>>>>
>>>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-
>>>>>>>>>>> padhi@ti.com>; Linus
>>>>>>>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski
>>>>>>>>>>> <brgl@kernel.org>; Jonathan
>>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
>>>>>>>>>>> Krzysztof Kozlowski
>>>>>>>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn
>>>>>>>>>>> Andersson
>>>>>>>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>>>>>>>>>> <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>>>> <skhan@linuxfoundation.org>; linux-
>>>>>>>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-
>>>>>>>>>>> kernel@vger.kernel.org;
>>>>>>>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>>>>>>>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-
>>>>>>>>>>> linux-imx <linux-
>>>>>>>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>>>> rpmsg GPIO driver
>>>>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>>>>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
>>>>>>>>>>>>> Jonathan
>>>>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
>>>>>>>>>>>>> Krzysztof
>>>>>>>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley
>>>>>>>>>>>>> <conor+dt@kernel.org>;
>>>>>>>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>>>>>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>;
>>>>>>>>>>>>> Sascha
>>>>>>>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>>>>>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>>>>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>>>>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>>>>>>>>>> <brgl@bgdev.pl>
>>>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>>>>>> rpmsg
>>>>>>>>>>>>> GPIO driver
>>>>>>>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>>>>>>>             __u8 status;
>>>>>>>>>>>>>>>             __u8 value;
>>>>>>>>>>>>>>> };
>>>>>>>>>>>>>> It is the same message format. Please see the message
>>>>>>>>>>>>>> definition
>>>>>>>>>>>>> (GET_DIRECTION) below:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>>>>>>>>>>> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>>>>>>>> +   | 1   | 2   |port |line | err | dir|
>>>>>>>>>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>>>>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same
>>>>>>>>>>>>> message format.
>>>>>>>>>>>>>
>>>>>>>>>>>> Some changes to the message format are necessary.
>>>>>>>>>>>>
>>>>>>>>>>>> Virtio uses two communication channels (virtqueues): one for
>>>>>>>>>>>> requests and
>>>>>>>>>>> replies, and a second one for events.
>>>>>>>>>>>> In contrast, rpmsg provides only a single communication
>>>>>>>>>>>> channel, so a
>>>>>>>>>>>> type field is required to distinguish between different kinds
>>>>>>>>>>>> of messages.
>>>>>>>>>>>>
>>>>>>>>>>>> Since rpmsg replies and events share the same message format,
>>>>>>>>>>>> an additional
>>>>>>>>>>> line is introduced to handle both cases.
>>>>>>>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port
>>>>>>>>>>>> field is added to
>>>>>>>>>>> uniquely identify the target controller.
>>>>>>>>>>>
>>>>>>>>>>> I have commented on this before - RPMSG is already providing
>>>>>>>>>>> multiplexing
>>>>>>>>>>> capability by way of endpoints.  There is no need for a port
>>>>>>>>>>> field.  One endpoint,
>>>>>>>>>>> one GPIO controller.
>>>>>>>>>>>
>>>>>>>>>> You still need a way to let the remote side know which port the
>>>>>>>>>> endpoint maps to, either
>>>>>>>>>> by embedding the port information in the message (the current
>>>>>>>>>> way), or by sending it
>>>>>>>>>> separately.
>>>>>>>>>>
>>>>>>>>> An endpoint is created with every namespace request.  There
>>>>>>>>> should be
>>>>>>>>> one namespace request for every GPIO controller, which yields a
>>>>>>>>> unique
>>>>>>>>> endpoint for each controller and eliminates the need for an extra
>>>>>>>>> field to identify them.
>>>>>>>>
>>>>>>>>
>>>>>>>> Right, but this can still be done by just having one namespace
>>>>>>>> request.
>>>>>>>> We can create new endpoints bound to an existing namespace/
>>>>>>>> channel by
>>>>>>>> invoking rpmsg_create_ept(). This is what I suggested here too:
>>>>>>>> https://lore.kernel.org/all/29485742-6e49-482e-
>>>>>>>> b73d-228295daaeec@ti.com/
>>>>>>>>
>>>>>>>
>>>>>>> I will look at your suggestion (i.e link above) later this week or
>>>>>>> next week.
>>>>>>>
>>>>>>>> My mental model looks like this for the complete picture:
>>>>>>>>
>>>>>>>> 1. namespace/channel#1 = rpmsg-io
>>>>>>>>        a. ept1 -> gpio-controller@1
>>>>>>>>        b. ept2 -> gpio-controller@2
>>>>>>>>
>>>
>>> If my understanding of what gpio-controller is right, than this won't
>>> work. We need one rpmsg channel per gpio-controller, and in most cases
>>> there will be only one GPIO-controller on the remote side. If there are
>>> multiple or multiple instances of same controller, than we need separate
>>> channel name for that controller just like we would have separate device
>>> on the Linux.
>>
>> As done in ehe rpmsg_tty driver it could be instantiated several times with
>> the same channel/service name. This would imply a specific rpmsg to
>> retreive
>> the gpio controller index from the remote side.
>>>
>>>>>>>
>>>>>>> I've asked for one endpoint per GPIO controller since the very
>>>>>>> beginning.  I don't yet have a strong opinion on whether to use one
>>>>>>> namespace request per GPIO controller or a single request that spins
>>>>>>> off multiple endpoints.  I'll have to look at your link and
>>>>>>> reflect on
>>>>>>> that.  Regardless of how we proceed on that front, multiplexing needs
>>>>>>> to happen at the endpoint level rather than the packet level. 
>>>>>>> This is
>>>>>>> the only way this work can move forward.
>>>>>>>
>>>>>>
>>>>>> I would be more in favor of Mathieu’s proposal: “An endpoint is
>>>>>> created with every namespace request.”
>>>>>>
>>>>>> If the endpoint is created only on the Linux side, how do we match
>>>>>> the Linux endpoint address with the local port field on the remote
>>>>>> side?
>>>>>
>>>>>
>>>>> Simply by sending a message to the remote containing the newly created
>>>>> endpoint and the port idx. Note that is this done just one time, after
>>>>> this
>>>>> Linux need not have the port field in the message everytime its sending
>>>>> a message.
>>>>>
>>>>>>
>>>>>> With a multi-namespace approach, the namespace could be rpmsg-io-
>>>>>> [addr], where [addr] corresponds to the GPIO controller address in
>>>>>> the DT. This would:
>>>>>
>>>>>
>>>>> You will face the same problem in this case also that you asked above:
>>>>> "how do we match the Linux endpoint address with the local port field
>>>>> on the remote side?"
>>>>
>>>> Sorry I probably introduced confusion here
>>>> my sentence should be;
>>>>   With a multi-namespace approach, the namespace could be rpmsg-io-
>>>> [port],
>>>>   where [port] corresponds to the GPIO controller port in the DT.
>>>>
>>>>
>>>> For instance:
>>>>
>>>>        rpmsg {
>>>>          rpmsg-io {
>>>>            #address-cells = <1>;
>>>>            #size-cells = <0>;
>>>>
>>>>            gpio@25 {
>>>>              compatible = "rpmsg-gpio";
>>>>              reg = <25>;
>>>>              gpio-controller;
>>>>              #gpio-cells = <2>;
>>>>              #interrupt-cells = <2>;
>>>>              interrupt-controller;
>>>>            };
>>>>
>>>>            gpio@32 {
>>>>              compatible = "rpmsg-gpio";
>>>>              reg = <32>;
>>>>              gpio-controller;
>>>>              #gpio-cells = <2>;
>>>>              #interrupt-cells = <2>;
>>>>              interrupt-controller;
>>>>            };
>>>>          };
>>>>        };
>>>>
>>>>   rpmsg-io-25  would match with gpio@25
>>>>   rpmsg-io-32  would match with gpio@32
>>>>
>>>
>>> The problem with this approach is, we will endup creating way too many
>>> RPMsg devices/channels. i.e. one channel per one GPIO. That limits how
>>> many GPIOs can be handled by remote from memory perspective. At
>>> somepoint we might just run-out of number ept & channels created by the
>>> remote. As of now, open-amp library supports 128 epts I think.
>>
>> Right, I proposed a solution in my previous answer to Beleswar who has
>> the same concern.
>>
>>>
>>>>
>>>>>
>>>>> Because the endpoint that is created on a namespace request is also
>>>>> dynamic in nature. How will the remote know which endpoint addr
>>>>> Linux allocated for a namespace that it announced?
>>>>>
>>>>> As an example/PoC, I created a firmware example which announces
>>>>> 2 name services to Linux, one is the standard "rpmsg_chrdev" and
>>>>> the other is a TI specific name service "ti.ipc4.ping-pong". You can
>>>>> see it created 2 different addresses (0x400 and 0x401) for each of
>>>>> the name service request from the same firmware:
>>>>>
>>>>> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
>>>>> [    9.290275] virtio_rpmsg_bus virtio0: creating channel
>>>>> ti.ipc4.ping-pong addr 0xd
>>>>> [    9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev
>>>>> addr 0xe
>>>>> [    9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel
>>>>> formed from src = 0x400 to dst = 0xe
>>>>> [    9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13:
>>>>> new channel: 0x401 -> 0xd!
>>>>>
>>>>> So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
>>>>> Back to same problem. Simple solution is to reply to remote with the
>>>>> created ept addr and the index.
>>>>
>>>> That why I would like to suggest to use the name service field to
>>>> identify the port/controller, instead of the endpoint address.
>>>>>  
>>>>>>
>>>>>> - match the RPMsg probe with the DT,
>>>>>
>>>>>
>>>>> We can probe from all controllers with a single name service
>>>>> announcement too.
>>>>>
>>>>>> - provide a simple mapping between the port and the endpoint on both
>>>>>> sides,
>>>>>
>>>>>
>>>>> We are trying to get rid of this mapping from Linux side to adapt
>>>>> the gpio-virtio design.
>>>>>
>>>>>> - allow multiple endpoints on the remote side,
>>>>>
>>>>>
>>>>> We can support this as well with single nameservice model.
>>>>> There is no limitation. Remote has to send a message with
>>>>> its newly created ept that's all.
>>>>>
>>>>>> - provide a simple discovery mechanism for remote capabilities.
>>>>>
>>>>>
>>>>> A single announcement: "rpmsg-io" is also discovery mechanism.
>>>>>
>>>>> Feel free to let me know if you have concerns with any of the
>>>>> suggestions!
>>>>
>>>> My only concern, whatever the solution, is that we find a smart
>>>> solution to associate the correct endpoint with the correct GPIO
>>>> port/controller defined in the DT.
>>>>
>>>> I may have misunderstood your solution. Could you please help me
>>>> understand your proposal by explaining how you would handle three
>>>> GPIO ports defined in the DT, considering that the endpoint
>>>> addresses on the Linux side can be random?
>>>> If I assume there is a unique endpoint on the remote side,
>>>> I do not understand how you can match, on the firmware side,
>>>> the Linux endpoint address to the GPIO port.
>>>>
>>>> Thanks and Regards,Arnaud
>>>>
>>>>>
>>>>> Thanks,
>>>>> Beleswar
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Arnaud
>>>>>>
>>>>>>>> 2. namespace/channel#2 = rpmsg-i2c
>>>>>>>>        a. ept1 -> i2c@1
>>>>>>>>        b. ept2 -> i2c@2
>>>>>>>>        c. ept3 -> i2c@3
>>>>>>>>
>>>>>>>> etc...
>>>>>>>>
>>>
>>> Just want to clear-up few terms before I jump to the solution:
>>>
>>> **RPMsg channel/device**:
>>>    - These are devices announced by the remote processor, and created by
>>> linux. They are created at: /sys/bus/rpmsg/devices
>>>    - The channel format: <name>.<src ept>.<dst ept>
>>>
>>> **RPMsg endpoint**:
>>>    - Endpoint is differnt than channel. Single channel can have multiple
>>> endpoints, and represented in the linux with: /dev/rpmsg? devices.
>>>
>>> To create endpoint device, we have rpmsg_create_ept API, which takes
>>> channel information as input, which has src-ept, dst-ept.
>>>
>>> Following is proposed solution:
>>>
>>> 1) Assign RPMsg channel/device per rpmsg-gpio controller (Not per GPIO
>>> pin/port).
>>>    - In our case that would be, single rpmsg-io node. (That makes me
>>> question if bindings are correct or not).
>>>
>>> 2) Assign GPIO number as src ept.
>>>
>>> i.e. *rpmsg-io.<GPIO number>.<dst ept>*. Do not randomly assign src
>>> endpoint.
>>>
>>> Now, RPMSG channel by spec reserves first 1024 endpoints [1], so we can
>>> add 1024 offset to the GPIO number:
>>>
>>> so, when calling rpmsg_create_ept() API, we assing src_endpoint as:
>>> (GPIO_NUMBER + RPMSG_RESERVED_ADDRESSES)
>>>
>>> Now on the remote side, there is single channel and only single-endpoint
>>> is needed that is mapped to the rpmsg-io channel callback.
>>>
>>> That callback will receive all the payloads from the Linux, which will
>>> have src-ept i.e. (RPMSG_RESERVED_ADDRESSES + GPIO_NUMBER).
>>
>>
>> Interesting approach. I also tried to find a similar solution.
>>
>> The question here is: how can we guarantee continuous addresses? Given
>> the static and dynamic allocation of endpoint addresses that are
>> implemented, my conclusion was that it is not reliable enough.
>>
>> but perhaps I missed something...
>>
>>>
>>> It can retrieve GPIO_NUMBER easily, and convert to appropriate pin based
>>> on platform specific logic.
>>>
>>> This doesn't need PORT information at all. Also it makes sure that
>>> remote is using only single-endpoint so not much memory is used.
>>>
>>> *Example*:
>>> If only rpmsg-gpio channel is created by the remote side, than following
>>> is the representation of the devices when GPIO 25, 26, 27 is assigned to
>>> the rpmsg-io controller:
>>>
>>> Linux                                                      Remote
>>>
>>> rpmsg-channel: rpmsg-gpio.0x400.0x400
>>>
>>> /dev/rpmsg0 - GPIO25 ept (rpmsg-gpio.0x419.0x400)-|
>>>                                                    |
>>> /dev/rpmsg1 - GPIO26 ept (rpmsg-gpio.0x41a.0x400)-|-> rpmsg-gpio.*.0x400
>>>                                                    |
>>> /dev/rpmsg2 - GPIO27 ept (rpmsg-gpio.0x41b.0x400)-|  0x400 ept callback.
>>>
>>>
>>> *On remote side*:
>>>
>>> ept_0x400_callback(..., int src_ept, ...,)
>>> {
>>>     int gpio_num = src_ept - RPMSG_RESERVED_ADDRESSES;
>>>     // platform specific logic to convert gpio num to proper pin,
>>>     // just like you would convert gpio num to pin on a linux gpio
>>> controller.
>>> }
>>>
>>> My question on the binding:
>>>
>>> Why each GPIO is represented with the separate node? I think rpmsg-gpio
>>> can be represented just any other GPIO controller? Please let me know if
>>> I am missing something. So rpmsg channel/rpmsg device is not created per
>>> GPIO, but per controller. GPIO number multiplexing should be done with
>>> rpmsg src ept, that removes the need of having each GPIO as a separate
>>> node.
>>>
>>>
>>> rpmsg_gpio: rpmsg-gpio@0 {
>>>         compatible = "rpmsg-gpio";
>>>         reg = <0>;
>>>         gpio-controller;
>>>         #gpio-cells = <2>;
>>>         #interrupt-cells = <2>;
>>>         interrupt-controller;
>>>     };
>>>
>>> Then in DT, use like regular GPIO, but with the rpmsg-gpio controller:
>>>
>>> rpmsg-gpios = <&rpmsg_gpio (GPIO NUM) (flags)>;
>>>
>>> If the intent to create separate gpio nodes was only for the channel
>>> creation, then it's not really needed.
>>>
>>> [1]
>>> https://github.com/torvalds/linux/
>>> blob/6d35786de28116ecf78797a62b84e6bf3c45aa5a/drivers/rpmsg/
>>> virtio_rpmsg_bus.c#L136
>>>
>>
>> It is already the case. bindings declare GPIO controllers, not directly
>> GPIOs in:
>>
>> [PATCH v13 2/4] dt-bindings: remoteproc: imx_rproc: Add "rpmsg" subnode
>> support
>>
>> The discussion is around having an unique RPmsg endpoint for all
>> GPIO controller or one RPmsg endpoint per GPIO controller.
>>
> 
> Endpoint where remote side or linux side?
> 
> If unique endpoint on remote side per gpio controller then it makes sense.
> 
> Unique endpoint on linux side doesn't make sense. Instead, unique
> channel per gpio controller makes sense, and each channel will have
> multiple endpoints on linux side. As I replied to Beleswar on the other
> email, I will copy past my answer here too:
> 
> 
> To be more specific:
> 
> Linux:                               remote:
> 
> ch1: rpmsg-gpio.-1.1024 ->     gpio-controller@1024
>     - gpio-line ept1
>     - gpio-line ept2    ->     They all map to same callback_ept_1024.
>     - gpio-line ept3
> 
> ch2: rpmsg-gpio.-1.1025 ->     gpio-controller@1025
>     - gpio-line ept1
>     - gpio-line ept2    ->     They all map to same callback_ept_1025.
>     - gpio-line ept3
> 


Hi Mathieu,

So upon more brain storming in this approach I found limitation:

This approach won't work if host OS is any other OS but Linux. For
example, if the remote OS is zephyr/baremetal using open-amp, then Only
Linux <-> zephyr combination will work, and we won't be able to re-use
this approach for zephyr <-> zephyr use case. The concept of rpmsg
channel/device exist only in the linux kernel implementation. This
brings another question: Should the protocol we decide work on other use
cases as well? Or Linux must be the Host OS for this protocol ?


I think your & Arnaud's proposed approach of single endpoint per
gpio-controller on both side makes more sense, as it will work
regardless of any OS on host or remote side.

To be more specific this will look like following:

Host (Linux)                       Remote (baremetal/RTOS)

rpmsg ch/device 1:
    - rpmsg ept 1   <------>     rpmsg ept 1 gpio-controller 0

rpmsg ch/device 2:
     - rpmsg ept 2   <------>     rpmsg ept 2 gpio-controller 1


The question is, how to decide src ept, and dest ept on both sides?
I still think it should be static endpoints.

I will get back with more reasoning on that.

> On the remote side, we have to hardcode Which rpmsg controller is mapped
> to which endpoint.
> 
>> Or did I misunderstand your questions?
>>
>> Thanks,
>> Arnaud
>>
> 
> 
> I gave this patch more time yesterday, and I think the 'reg' property
> should represent remote endpoint, instead of the gpio-controller index.
> 
> So in this approach remote implementation is expected to provide
> hard-coded (static) endpoints for each gpio-controller instance, and
> that same number should be represented with the 'reg' property.
> 
> On remote side:
> 
> #define RPMSG_GPIO_0_CONTROLLER_EPT (RPMSG_RESERVED_ADDRESSES + 1) // 1024
> 
> ept_1024_callback() {
> 
> 	// handle appropriate gpio port ()
> 
> }
> 
> On linux side:
> 
> So new representation of controller:
> 
>  rpmsg_gpio_0:   gpio@1024 {
>              compatible = "rpmsg-gpio";
>              reg = <1024>;
>              gpio-controller;
>              #gpio-cells = <2>;
>              #interrupt-cells = <2>;
>              interrupt-controller;
>           };
> 
>  rpmsg_gpio_1:   gpio@1025 {
>              compatible = "rpmsg-gpio";
>              reg = <1025>;
>              gpio-controller;
>              #gpio-cells = <2>;
>              #interrupt-cells = <2>;
>              interrupt-controller;
>           };
> 
> gpios = <&rpmsg_gpio_0 (GPIO NUM or PIN) flags>,
> 	<&rpmsg_gpio_1 (GPIO NUM or PIN) flags>;
> 
> Now in the linux driver:
> 
> You can easily retrieve destination endpoint when we want to send the
> command to the gpio controller via device's "reg" property.
> 
> This approach also provides built-in security as well. Because now
> gpio-controller instance is hardcoded with the endpoint callback, it
> can't be modified/addressed without changing the 'reg' property.
> 
> Just like you wouldn't change device address for the instance of the
> gpio-controller right?
> 
> This approach can be easily adapted to all the other rpmsg controllers
> as well.
> 
> So, dynamic endpoint allocation doesn't make sense in this case. Dynamic
> endpoint allocation makes more sense for user-space apps which don't
> really care about endpoints and only payloads.
> 
> But, here we are multiplexing device-addresses with endpoints, and so it
> has to be fixed, and presented via 'reg' property. So, firmware can't
> change device-address without Linux knowing it.
> 
> Thanks,
> Tanmay
> 
> 
>>
>>>>>>>> This way device groups are isolated with each channel/namespace, and
>>>>>>>> instances within each device groups are also respected with specific
>>>>>>>> endpoints.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Beleswar
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
> 

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

[Mathieu Poirier]

On Mon, 11 May 2026 at 10:47, Shah, Tanmay <tanmays@amd.com> wrote:
>
>
>
> On 5/5/2026 10:52 AM, Shah, Tanmay wrote:
> >
> >
> > On 5/5/2026 4:28 AM, Arnaud POULIQUEN wrote:
> >> Hi Tanmay,
> >>
> >> On 5/4/26 21:19, Shah, Tanmay wrote:
> >>>
> >>> Hello all,
> >>>
> >>> I have started reviewing this work as well.
> >>> Thanks Shenwei for this work.
> >>>
> >>> I have gone through only the current revision, and would like to provide
> >>> idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
> >>> Also, have some bindings related question.
> >>>
> >>> Please see below:
> >>>
> >>> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
> >>>>
> >>>>
> >>>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
> >>>>> Hello Arnaud,
> >>>>>
> >>>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
> >>>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
> >>>>>>>>
> >>>>>>>> Hi Mathieu,
> >>>>>>>>
> >>>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
> >>>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com>
> >>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
> >>>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
> >>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
> >>>>>>>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-
> >>>>>>>>>>> padhi@ti.com>; Linus
> >>>>>>>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski
> >>>>>>>>>>> <brgl@kernel.org>; Jonathan
> >>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
> >>>>>>>>>>> Krzysztof Kozlowski
> >>>>>>>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn
> >>>>>>>>>>> Andersson
> >>>>>>>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
> >>>>>>>>>>> <s.hauer@pengutronix.de>; Shuah Khan
> >>>>>>>>>>> <skhan@linuxfoundation.org>; linux-
> >>>>>>>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-
> >>>>>>>>>>> kernel@vger.kernel.org;
> >>>>>>>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> >>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
> >>>>>>>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
> >>>>>>>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-
> >>>>>>>>>>> linux-imx <linux-
> >>>>>>>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
> >>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
> >>>>>>>>>>> rpmsg GPIO driver
> >>>>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
> >>>>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
> >>>>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
> >>>>>>>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
> >>>>>>>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
> >>>>>>>>>>>>> Jonathan
> >>>>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
> >>>>>>>>>>>>> Krzysztof
> >>>>>>>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley
> >>>>>>>>>>>>> <conor+dt@kernel.org>;
> >>>>>>>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
> >>>>>>>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>;
> >>>>>>>>>>>>> Sascha
> >>>>>>>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
> >>>>>>>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
> >>>>>>>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
> >>>>>>>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> >>>>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
> >>>>>>>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
> >>>>>>>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
> >>>>>>>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
> >>>>>>>>>>>>> <brgl@bgdev.pl>
> >>>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
> >>>>>>>>>>>>> rpmsg
> >>>>>>>>>>>>> GPIO driver
> >>>>>>>>>>>>>>> struct virtio_gpio_response {
> >>>>>>>>>>>>>>>             __u8 status;
> >>>>>>>>>>>>>>>             __u8 value;
> >>>>>>>>>>>>>>> };
> >>>>>>>>>>>>>> It is the same message format. Please see the message
> >>>>>>>>>>>>>> definition
> >>>>>>>>>>>>> (GET_DIRECTION) below:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> +   +-----+-----+-----+-----+-----+----+
> >>>>>>>>>>>>>> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> >>>>>>>>>>>>>> +   | 1   | 2   |port |line | err | dir|
> >>>>>>>>>>>>>> +   +-----+-----+-----+-----+-----+----+
> >>>>>>>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same
> >>>>>>>>>>>>> message format.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> Some changes to the message format are necessary.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Virtio uses two communication channels (virtqueues): one for
> >>>>>>>>>>>> requests and
> >>>>>>>>>>> replies, and a second one for events.
> >>>>>>>>>>>> In contrast, rpmsg provides only a single communication
> >>>>>>>>>>>> channel, so a
> >>>>>>>>>>>> type field is required to distinguish between different kinds
> >>>>>>>>>>>> of messages.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Since rpmsg replies and events share the same message format,
> >>>>>>>>>>>> an additional
> >>>>>>>>>>> line is introduced to handle both cases.
> >>>>>>>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port
> >>>>>>>>>>>> field is added to
> >>>>>>>>>>> uniquely identify the target controller.
> >>>>>>>>>>>
> >>>>>>>>>>> I have commented on this before - RPMSG is already providing
> >>>>>>>>>>> multiplexing
> >>>>>>>>>>> capability by way of endpoints.  There is no need for a port
> >>>>>>>>>>> field.  One endpoint,
> >>>>>>>>>>> one GPIO controller.
> >>>>>>>>>>>
> >>>>>>>>>> You still need a way to let the remote side know which port the
> >>>>>>>>>> endpoint maps to, either
> >>>>>>>>>> by embedding the port information in the message (the current
> >>>>>>>>>> way), or by sending it
> >>>>>>>>>> separately.
> >>>>>>>>>>
> >>>>>>>>> An endpoint is created with every namespace request.  There
> >>>>>>>>> should be
> >>>>>>>>> one namespace request for every GPIO controller, which yields a
> >>>>>>>>> unique
> >>>>>>>>> endpoint for each controller and eliminates the need for an extra
> >>>>>>>>> field to identify them.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Right, but this can still be done by just having one namespace
> >>>>>>>> request.
> >>>>>>>> We can create new endpoints bound to an existing namespace/
> >>>>>>>> channel by
> >>>>>>>> invoking rpmsg_create_ept(). This is what I suggested here too:
> >>>>>>>> https://lore.kernel.org/all/29485742-6e49-482e-
> >>>>>>>> b73d-228295daaeec@ti.com/
> >>>>>>>>
> >>>>>>>
> >>>>>>> I will look at your suggestion (i.e link above) later this week or
> >>>>>>> next week.
> >>>>>>>
> >>>>>>>> My mental model looks like this for the complete picture:
> >>>>>>>>
> >>>>>>>> 1. namespace/channel#1 = rpmsg-io
> >>>>>>>>        a. ept1 -> gpio-controller@1
> >>>>>>>>        b. ept2 -> gpio-controller@2
> >>>>>>>>
> >>>
> >>> If my understanding of what gpio-controller is right, than this won't
> >>> work. We need one rpmsg channel per gpio-controller, and in most cases
> >>> there will be only one GPIO-controller on the remote side. If there are
> >>> multiple or multiple instances of same controller, than we need separate
> >>> channel name for that controller just like we would have separate device
> >>> on the Linux.
> >>
> >> As done in ehe rpmsg_tty driver it could be instantiated several times with
> >> the same channel/service name. This would imply a specific rpmsg to
> >> retreive
> >> the gpio controller index from the remote side.
> >>>
> >>>>>>>
> >>>>>>> I've asked for one endpoint per GPIO controller since the very
> >>>>>>> beginning.  I don't yet have a strong opinion on whether to use one
> >>>>>>> namespace request per GPIO controller or a single request that spins
> >>>>>>> off multiple endpoints.  I'll have to look at your link and
> >>>>>>> reflect on
> >>>>>>> that.  Regardless of how we proceed on that front, multiplexing needs
> >>>>>>> to happen at the endpoint level rather than the packet level.
> >>>>>>> This is
> >>>>>>> the only way this work can move forward.
> >>>>>>>
> >>>>>>
> >>>>>> I would be more in favor of Mathieu’s proposal: “An endpoint is
> >>>>>> created with every namespace request.”
> >>>>>>
> >>>>>> If the endpoint is created only on the Linux side, how do we match
> >>>>>> the Linux endpoint address with the local port field on the remote
> >>>>>> side?
> >>>>>
> >>>>>
> >>>>> Simply by sending a message to the remote containing the newly created
> >>>>> endpoint and the port idx. Note that is this done just one time, after
> >>>>> this
> >>>>> Linux need not have the port field in the message everytime its sending
> >>>>> a message.
> >>>>>
> >>>>>>
> >>>>>> With a multi-namespace approach, the namespace could be rpmsg-io-
> >>>>>> [addr], where [addr] corresponds to the GPIO controller address in
> >>>>>> the DT. This would:
> >>>>>
> >>>>>
> >>>>> You will face the same problem in this case also that you asked above:
> >>>>> "how do we match the Linux endpoint address with the local port field
> >>>>> on the remote side?"
> >>>>
> >>>> Sorry I probably introduced confusion here
> >>>> my sentence should be;
> >>>>   With a multi-namespace approach, the namespace could be rpmsg-io-
> >>>> [port],
> >>>>   where [port] corresponds to the GPIO controller port in the DT.
> >>>>
> >>>>
> >>>> For instance:
> >>>>
> >>>>        rpmsg {
> >>>>          rpmsg-io {
> >>>>            #address-cells = <1>;
> >>>>            #size-cells = <0>;
> >>>>
> >>>>            gpio@25 {
> >>>>              compatible = "rpmsg-gpio";
> >>>>              reg = <25>;
> >>>>              gpio-controller;
> >>>>              #gpio-cells = <2>;
> >>>>              #interrupt-cells = <2>;
> >>>>              interrupt-controller;
> >>>>            };
> >>>>
> >>>>            gpio@32 {
> >>>>              compatible = "rpmsg-gpio";
> >>>>              reg = <32>;
> >>>>              gpio-controller;
> >>>>              #gpio-cells = <2>;
> >>>>              #interrupt-cells = <2>;
> >>>>              interrupt-controller;
> >>>>            };
> >>>>          };
> >>>>        };
> >>>>
> >>>>   rpmsg-io-25  would match with gpio@25
> >>>>   rpmsg-io-32  would match with gpio@32
> >>>>
> >>>
> >>> The problem with this approach is, we will endup creating way too many
> >>> RPMsg devices/channels. i.e. one channel per one GPIO. That limits how
> >>> many GPIOs can be handled by remote from memory perspective. At
> >>> somepoint we might just run-out of number ept & channels created by the
> >>> remote. As of now, open-amp library supports 128 epts I think.
> >>
> >> Right, I proposed a solution in my previous answer to Beleswar who has
> >> the same concern.
> >>
> >>>
> >>>>
> >>>>>
> >>>>> Because the endpoint that is created on a namespace request is also
> >>>>> dynamic in nature. How will the remote know which endpoint addr
> >>>>> Linux allocated for a namespace that it announced?
> >>>>>
> >>>>> As an example/PoC, I created a firmware example which announces
> >>>>> 2 name services to Linux, one is the standard "rpmsg_chrdev" and
> >>>>> the other is a TI specific name service "ti.ipc4.ping-pong". You can
> >>>>> see it created 2 different addresses (0x400 and 0x401) for each of
> >>>>> the name service request from the same firmware:
> >>>>>
> >>>>> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
> >>>>> [    9.290275] virtio_rpmsg_bus virtio0: creating channel
> >>>>> ti.ipc4.ping-pong addr 0xd
> >>>>> [    9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev
> >>>>> addr 0xe
> >>>>> [    9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel
> >>>>> formed from src = 0x400 to dst = 0xe
> >>>>> [    9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13:
> >>>>> new channel: 0x401 -> 0xd!
> >>>>>
> >>>>> So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
> >>>>> Back to same problem. Simple solution is to reply to remote with the
> >>>>> created ept addr and the index.
> >>>>
> >>>> That why I would like to suggest to use the name service field to
> >>>> identify the port/controller, instead of the endpoint address.
> >>>>>
> >>>>>>
> >>>>>> - match the RPMsg probe with the DT,
> >>>>>
> >>>>>
> >>>>> We can probe from all controllers with a single name service
> >>>>> announcement too.
> >>>>>
> >>>>>> - provide a simple mapping between the port and the endpoint on both
> >>>>>> sides,
> >>>>>
> >>>>>
> >>>>> We are trying to get rid of this mapping from Linux side to adapt
> >>>>> the gpio-virtio design.
> >>>>>
> >>>>>> - allow multiple endpoints on the remote side,
> >>>>>
> >>>>>
> >>>>> We can support this as well with single nameservice model.
> >>>>> There is no limitation. Remote has to send a message with
> >>>>> its newly created ept that's all.
> >>>>>
> >>>>>> - provide a simple discovery mechanism for remote capabilities.
> >>>>>
> >>>>>
> >>>>> A single announcement: "rpmsg-io" is also discovery mechanism.
> >>>>>
> >>>>> Feel free to let me know if you have concerns with any of the
> >>>>> suggestions!
> >>>>
> >>>> My only concern, whatever the solution, is that we find a smart
> >>>> solution to associate the correct endpoint with the correct GPIO
> >>>> port/controller defined in the DT.
> >>>>
> >>>> I may have misunderstood your solution. Could you please help me
> >>>> understand your proposal by explaining how you would handle three
> >>>> GPIO ports defined in the DT, considering that the endpoint
> >>>> addresses on the Linux side can be random?
> >>>> If I assume there is a unique endpoint on the remote side,
> >>>> I do not understand how you can match, on the firmware side,
> >>>> the Linux endpoint address to the GPIO port.
> >>>>
> >>>> Thanks and Regards,Arnaud
> >>>>
> >>>>>
> >>>>> Thanks,
> >>>>> Beleswar
> >>>>>
> >>>>>>
> >>>>>> Regards,
> >>>>>> Arnaud
> >>>>>>
> >>>>>>>> 2. namespace/channel#2 = rpmsg-i2c
> >>>>>>>>        a. ept1 -> i2c@1
> >>>>>>>>        b. ept2 -> i2c@2
> >>>>>>>>        c. ept3 -> i2c@3
> >>>>>>>>
> >>>>>>>> etc...
> >>>>>>>>
> >>>
> >>> Just want to clear-up few terms before I jump to the solution:
> >>>
> >>> **RPMsg channel/device**:
> >>>    - These are devices announced by the remote processor, and created by
> >>> linux. They are created at: /sys/bus/rpmsg/devices
> >>>    - The channel format: <name>.<src ept>.<dst ept>
> >>>
> >>> **RPMsg endpoint**:
> >>>    - Endpoint is differnt than channel. Single channel can have multiple
> >>> endpoints, and represented in the linux with: /dev/rpmsg? devices.
> >>>
> >>> To create endpoint device, we have rpmsg_create_ept API, which takes
> >>> channel information as input, which has src-ept, dst-ept.
> >>>
> >>> Following is proposed solution:
> >>>
> >>> 1) Assign RPMsg channel/device per rpmsg-gpio controller (Not per GPIO
> >>> pin/port).
> >>>    - In our case that would be, single rpmsg-io node. (That makes me
> >>> question if bindings are correct or not).
> >>>
> >>> 2) Assign GPIO number as src ept.
> >>>
> >>> i.e. *rpmsg-io.<GPIO number>.<dst ept>*. Do not randomly assign src
> >>> endpoint.
> >>>
> >>> Now, RPMSG channel by spec reserves first 1024 endpoints [1], so we can
> >>> add 1024 offset to the GPIO number:
> >>>
> >>> so, when calling rpmsg_create_ept() API, we assing src_endpoint as:
> >>> (GPIO_NUMBER + RPMSG_RESERVED_ADDRESSES)
> >>>
> >>> Now on the remote side, there is single channel and only single-endpoint
> >>> is needed that is mapped to the rpmsg-io channel callback.
> >>>
> >>> That callback will receive all the payloads from the Linux, which will
> >>> have src-ept i.e. (RPMSG_RESERVED_ADDRESSES + GPIO_NUMBER).
> >>
> >>
> >> Interesting approach. I also tried to find a similar solution.
> >>
> >> The question here is: how can we guarantee continuous addresses? Given
> >> the static and dynamic allocation of endpoint addresses that are
> >> implemented, my conclusion was that it is not reliable enough.
> >>
> >> but perhaps I missed something...
> >>
> >>>
> >>> It can retrieve GPIO_NUMBER easily, and convert to appropriate pin based
> >>> on platform specific logic.
> >>>
> >>> This doesn't need PORT information at all. Also it makes sure that
> >>> remote is using only single-endpoint so not much memory is used.
> >>>
> >>> *Example*:
> >>> If only rpmsg-gpio channel is created by the remote side, than following
> >>> is the representation of the devices when GPIO 25, 26, 27 is assigned to
> >>> the rpmsg-io controller:
> >>>
> >>> Linux                                                      Remote
> >>>
> >>> rpmsg-channel: rpmsg-gpio.0x400.0x400
> >>>
> >>> /dev/rpmsg0 - GPIO25 ept (rpmsg-gpio.0x419.0x400)-|
> >>>                                                    |
> >>> /dev/rpmsg1 - GPIO26 ept (rpmsg-gpio.0x41a.0x400)-|-> rpmsg-gpio.*.0x400
> >>>                                                    |
> >>> /dev/rpmsg2 - GPIO27 ept (rpmsg-gpio.0x41b.0x400)-|  0x400 ept callback.
> >>>
> >>>
> >>> *On remote side*:
> >>>
> >>> ept_0x400_callback(..., int src_ept, ...,)
> >>> {
> >>>     int gpio_num = src_ept - RPMSG_RESERVED_ADDRESSES;
> >>>     // platform specific logic to convert gpio num to proper pin,
> >>>     // just like you would convert gpio num to pin on a linux gpio
> >>> controller.
> >>> }
> >>>
> >>> My question on the binding:
> >>>
> >>> Why each GPIO is represented with the separate node? I think rpmsg-gpio
> >>> can be represented just any other GPIO controller? Please let me know if
> >>> I am missing something. So rpmsg channel/rpmsg device is not created per
> >>> GPIO, but per controller. GPIO number multiplexing should be done with
> >>> rpmsg src ept, that removes the need of having each GPIO as a separate
> >>> node.
> >>>
> >>>
> >>> rpmsg_gpio: rpmsg-gpio@0 {
> >>>         compatible = "rpmsg-gpio";
> >>>         reg = <0>;
> >>>         gpio-controller;
> >>>         #gpio-cells = <2>;
> >>>         #interrupt-cells = <2>;
> >>>         interrupt-controller;
> >>>     };
> >>>
> >>> Then in DT, use like regular GPIO, but with the rpmsg-gpio controller:
> >>>
> >>> rpmsg-gpios = <&rpmsg_gpio (GPIO NUM) (flags)>;
> >>>
> >>> If the intent to create separate gpio nodes was only for the channel
> >>> creation, then it's not really needed.
> >>>
> >>> [1]
> >>> https://github.com/torvalds/linux/
> >>> blob/6d35786de28116ecf78797a62b84e6bf3c45aa5a/drivers/rpmsg/
> >>> virtio_rpmsg_bus.c#L136
> >>>
> >>
> >> It is already the case. bindings declare GPIO controllers, not directly
> >> GPIOs in:
> >>
> >> [PATCH v13 2/4] dt-bindings: remoteproc: imx_rproc: Add "rpmsg" subnode
> >> support
> >>
> >> The discussion is around having an unique RPmsg endpoint for all
> >> GPIO controller or one RPmsg endpoint per GPIO controller.
> >>
> >
> > Endpoint where remote side or linux side?
> >
> > If unique endpoint on remote side per gpio controller then it makes sense.
> >
> > Unique endpoint on linux side doesn't make sense. Instead, unique
> > channel per gpio controller makes sense, and each channel will have
> > multiple endpoints on linux side. As I replied to Beleswar on the other
> > email, I will copy past my answer here too:
> >
> >
> > To be more specific:
> >
> > Linux:                               remote:
> >
> > ch1: rpmsg-gpio.-1.1024 ->     gpio-controller@1024
> >     - gpio-line ept1
> >     - gpio-line ept2    ->     They all map to same callback_ept_1024.
> >     - gpio-line ept3
> >
> > ch2: rpmsg-gpio.-1.1025 ->     gpio-controller@1025
> >     - gpio-line ept1
> >     - gpio-line ept2    ->     They all map to same callback_ept_1025.
> >     - gpio-line ept3
> >
>
>
> Hi Mathieu,
>
> So upon more brain storming in this approach I found limitation:
>
> This approach won't work if host OS is any other OS but Linux. For
> example, if the remote OS is zephyr/baremetal using open-amp, then Only
> Linux <-> zephyr combination will work, and we won't be able to re-use
> this approach for zephyr <-> zephyr use case. The concept of rpmsg
> channel/device exist only in the linux kernel implementation. This
> brings another question: Should the protocol we decide work on other use
> cases as well? Or Linux must be the Host OS for this protocol ?
>

Linux and Zephyr are very distinct OS, each with their own subsystems
and characteristics.  The design we choose here involves RPMSG and,
inherently, Linux.  We can't make decisions based on what may
potentially happen in Zephyr.

>
> I think your & Arnaud's proposed approach of single endpoint per
> gpio-controller on both side makes more sense, as it will work
> regardless of any OS on host or remote side.
>

Arnaud, Beleswar, Andrew and I are all advocating for one endpoint per
GPIO controller.  The remaining issue it about the best way to work
out source and destination addresses between Linux and the remote
processor.  I'm running out of time for today but I'll return to this
thread with a final analysis by the end of the week.

> To be more specific this will look like following:
>
> Host (Linux)                       Remote (baremetal/RTOS)
>
> rpmsg ch/device 1:
>     - rpmsg ept 1   <------>     rpmsg ept 1 gpio-controller 0
>
> rpmsg ch/device 2:
>      - rpmsg ept 2   <------>     rpmsg ept 2 gpio-controller 1
>
>
> The question is, how to decide src ept, and dest ept on both sides?
> I still think it should be static endpoints.
>
> I will get back with more reasoning on that.
>
> > On the remote side, we have to hardcode Which rpmsg controller is mapped
> > to which endpoint.
> >
> >> Or did I misunderstand your questions?
> >>
> >> Thanks,
> >> Arnaud
> >>
> >
> >
> > I gave this patch more time yesterday, and I think the 'reg' property
> > should represent remote endpoint, instead of the gpio-controller index.
> >
> > So in this approach remote implementation is expected to provide
> > hard-coded (static) endpoints for each gpio-controller instance, and
> > that same number should be represented with the 'reg' property.
> >
> > On remote side:
> >
> > #define RPMSG_GPIO_0_CONTROLLER_EPT (RPMSG_RESERVED_ADDRESSES + 1) // 1024
> >
> > ept_1024_callback() {
> >
> >       // handle appropriate gpio port ()
> >
> > }
> >
> > On linux side:
> >
> > So new representation of controller:
> >
> >  rpmsg_gpio_0:   gpio@1024 {
> >              compatible = "rpmsg-gpio";
> >              reg = <1024>;
> >              gpio-controller;
> >              #gpio-cells = <2>;
> >              #interrupt-cells = <2>;
> >              interrupt-controller;
> >           };
> >
> >  rpmsg_gpio_1:   gpio@1025 {
> >              compatible = "rpmsg-gpio";
> >              reg = <1025>;
> >              gpio-controller;
> >              #gpio-cells = <2>;
> >              #interrupt-cells = <2>;
> >              interrupt-controller;
> >           };
> >
> > gpios = <&rpmsg_gpio_0 (GPIO NUM or PIN) flags>,
> >       <&rpmsg_gpio_1 (GPIO NUM or PIN) flags>;
> >
> > Now in the linux driver:
> >
> > You can easily retrieve destination endpoint when we want to send the
> > command to the gpio controller via device's "reg" property.
> >
> > This approach also provides built-in security as well. Because now
> > gpio-controller instance is hardcoded with the endpoint callback, it
> > can't be modified/addressed without changing the 'reg' property.
> >
> > Just like you wouldn't change device address for the instance of the
> > gpio-controller right?
> >
> > This approach can be easily adapted to all the other rpmsg controllers
> > as well.
> >
> > So, dynamic endpoint allocation doesn't make sense in this case. Dynamic
> > endpoint allocation makes more sense for user-space apps which don't
> > really care about endpoints and only payloads.
> >
> > But, here we are multiplexing device-addresses with endpoints, and so it
> > has to be fixed, and presented via 'reg' property. So, firmware can't
> > change device-address without Linux knowing it.
> >
> > Thanks,
> > Tanmay
> >
> >
> >>
> >>>>>>>> This way device groups are isolated with each channel/namespace, and
> >>>>>>>> instances within each device groups are also respected with specific
> >>>>>>>> endpoints.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Beleswar
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>
> >>
> >
>

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

[Andrew Lunn]

> Arnaud, Beleswar, Andrew and I are all advocating for one endpoint per
> GPIO controller.  The remaining issue it about the best way to work
> out source and destination addresses between Linux and the remote
> processor.  I'm running out of time for today but I'll return to this
> thread with a final analysis by the end of the week.

How many of the participants here will be in Minneapolis next week for
the Embedded Linux Conference? There is even a talk about this:

https://osselcna2026.sched.com/event/2JQpx/building-virtual-drivers-with-rpmsg-key-design-principles-challenges-trade-offs-beleswar-prasad-padhi-texas-instruments?iframe=yes&w=100%&sidebar=yes&bg=no

Maybe we can get together and decide on the final design after the
session.

	Andrew

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

[Shah, Tanmay]

On 5/11/2026 12:58 PM, Mathieu Poirier wrote:
> On Mon, 11 May 2026 at 10:47, Shah, Tanmay <tanmays@amd.com> wrote:
>>
>>
>>
>> On 5/5/2026 10:52 AM, Shah, Tanmay wrote:
>>>
>>>
>>> On 5/5/2026 4:28 AM, Arnaud POULIQUEN wrote:
>>>> Hi Tanmay,
>>>>
>>>> On 5/4/26 21:19, Shah, Tanmay wrote:
>>>>>
>>>>> Hello all,
>>>>>
>>>>> I have started reviewing this work as well.
>>>>> Thanks Shenwei for this work.
>>>>>
>>>>> I have gone through only the current revision, and would like to provide
>>>>> idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
>>>>> Also, have some bindings related question.
>>>>>
>>>>> Please see below:
>>>>>
>>>>> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
>>>>>>
>>>>>>
>>>>>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>>>>>>> Hello Arnaud,
>>>>>>>
>>>>>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>>>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Mathieu,
>>>>>>>>>>
>>>>>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-
>>>>>>>>>>>>> padhi@ti.com>; Linus
>>>>>>>>>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski
>>>>>>>>>>>>> <brgl@kernel.org>; Jonathan
>>>>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
>>>>>>>>>>>>> Krzysztof Kozlowski
>>>>>>>>>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn
>>>>>>>>>>>>> Andersson
>>>>>>>>>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>>>>>>>>>>>> <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>>>>>> <skhan@linuxfoundation.org>; linux-
>>>>>>>>>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-
>>>>>>>>>>>>> kernel@vger.kernel.org;
>>>>>>>>>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>>>>>>>>>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-
>>>>>>>>>>>>> linux-imx <linux-
>>>>>>>>>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>>>>>> rpmsg GPIO driver
>>>>>>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>>>>>>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
>>>>>>>>>>>>>>> Jonathan
>>>>>>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
>>>>>>>>>>>>>>> Krzysztof
>>>>>>>>>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley
>>>>>>>>>>>>>>> <conor+dt@kernel.org>;
>>>>>>>>>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>>>>>>>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>;
>>>>>>>>>>>>>>> Sascha
>>>>>>>>>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>>>>>>>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>>>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>>>>>>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>>>>>>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>>>>>>>>>>>> <brgl@bgdev.pl>
>>>>>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>>>>>>>> rpmsg
>>>>>>>>>>>>>>> GPIO driver
>>>>>>>>>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>>>>>>>>>             __u8 status;
>>>>>>>>>>>>>>>>>             __u8 value;
>>>>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>>> It is the same message format. Please see the message
>>>>>>>>>>>>>>>> definition
>>>>>>>>>>>>>>> (GET_DIRECTION) below:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>>>>>>>>>>>>> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>>>>>>>>>> +   | 1   | 2   |port |line | err | dir|
>>>>>>>>>>>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>>>>>>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same
>>>>>>>>>>>>>>> message format.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Some changes to the message format are necessary.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Virtio uses two communication channels (virtqueues): one for
>>>>>>>>>>>>>> requests and
>>>>>>>>>>>>> replies, and a second one for events.
>>>>>>>>>>>>>> In contrast, rpmsg provides only a single communication
>>>>>>>>>>>>>> channel, so a
>>>>>>>>>>>>>> type field is required to distinguish between different kinds
>>>>>>>>>>>>>> of messages.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Since rpmsg replies and events share the same message format,
>>>>>>>>>>>>>> an additional
>>>>>>>>>>>>> line is introduced to handle both cases.
>>>>>>>>>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port
>>>>>>>>>>>>>> field is added to
>>>>>>>>>>>>> uniquely identify the target controller.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have commented on this before - RPMSG is already providing
>>>>>>>>>>>>> multiplexing
>>>>>>>>>>>>> capability by way of endpoints.  There is no need for a port
>>>>>>>>>>>>> field.  One endpoint,
>>>>>>>>>>>>> one GPIO controller.
>>>>>>>>>>>>>
>>>>>>>>>>>> You still need a way to let the remote side know which port the
>>>>>>>>>>>> endpoint maps to, either
>>>>>>>>>>>> by embedding the port information in the message (the current
>>>>>>>>>>>> way), or by sending it
>>>>>>>>>>>> separately.
>>>>>>>>>>>>
>>>>>>>>>>> An endpoint is created with every namespace request.  There
>>>>>>>>>>> should be
>>>>>>>>>>> one namespace request for every GPIO controller, which yields a
>>>>>>>>>>> unique
>>>>>>>>>>> endpoint for each controller and eliminates the need for an extra
>>>>>>>>>>> field to identify them.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Right, but this can still be done by just having one namespace
>>>>>>>>>> request.
>>>>>>>>>> We can create new endpoints bound to an existing namespace/
>>>>>>>>>> channel by
>>>>>>>>>> invoking rpmsg_create_ept(). This is what I suggested here too:
>>>>>>>>>> https://lore.kernel.org/all/29485742-6e49-482e-
>>>>>>>>>> b73d-228295daaeec@ti.com/
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I will look at your suggestion (i.e link above) later this week or
>>>>>>>>> next week.
>>>>>>>>>
>>>>>>>>>> My mental model looks like this for the complete picture:
>>>>>>>>>>
>>>>>>>>>> 1. namespace/channel#1 = rpmsg-io
>>>>>>>>>>        a. ept1 -> gpio-controller@1
>>>>>>>>>>        b. ept2 -> gpio-controller@2
>>>>>>>>>>
>>>>>
>>>>> If my understanding of what gpio-controller is right, than this won't
>>>>> work. We need one rpmsg channel per gpio-controller, and in most cases
>>>>> there will be only one GPIO-controller on the remote side. If there are
>>>>> multiple or multiple instances of same controller, than we need separate
>>>>> channel name for that controller just like we would have separate device
>>>>> on the Linux.
>>>>
>>>> As done in ehe rpmsg_tty driver it could be instantiated several times with
>>>> the same channel/service name. This would imply a specific rpmsg to
>>>> retreive
>>>> the gpio controller index from the remote side.
>>>>>
>>>>>>>>>
>>>>>>>>> I've asked for one endpoint per GPIO controller since the very
>>>>>>>>> beginning.  I don't yet have a strong opinion on whether to use one
>>>>>>>>> namespace request per GPIO controller or a single request that spins
>>>>>>>>> off multiple endpoints.  I'll have to look at your link and
>>>>>>>>> reflect on
>>>>>>>>> that.  Regardless of how we proceed on that front, multiplexing needs
>>>>>>>>> to happen at the endpoint level rather than the packet level.
>>>>>>>>> This is
>>>>>>>>> the only way this work can move forward.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I would be more in favor of Mathieu’s proposal: “An endpoint is
>>>>>>>> created with every namespace request.”
>>>>>>>>
>>>>>>>> If the endpoint is created only on the Linux side, how do we match
>>>>>>>> the Linux endpoint address with the local port field on the remote
>>>>>>>> side?
>>>>>>>
>>>>>>>
>>>>>>> Simply by sending a message to the remote containing the newly created
>>>>>>> endpoint and the port idx. Note that is this done just one time, after
>>>>>>> this
>>>>>>> Linux need not have the port field in the message everytime its sending
>>>>>>> a message.
>>>>>>>
>>>>>>>>
>>>>>>>> With a multi-namespace approach, the namespace could be rpmsg-io-
>>>>>>>> [addr], where [addr] corresponds to the GPIO controller address in
>>>>>>>> the DT. This would:
>>>>>>>
>>>>>>>
>>>>>>> You will face the same problem in this case also that you asked above:
>>>>>>> "how do we match the Linux endpoint address with the local port field
>>>>>>> on the remote side?"
>>>>>>
>>>>>> Sorry I probably introduced confusion here
>>>>>> my sentence should be;
>>>>>>   With a multi-namespace approach, the namespace could be rpmsg-io-
>>>>>> [port],
>>>>>>   where [port] corresponds to the GPIO controller port in the DT.
>>>>>>
>>>>>>
>>>>>> For instance:
>>>>>>
>>>>>>        rpmsg {
>>>>>>          rpmsg-io {
>>>>>>            #address-cells = <1>;
>>>>>>            #size-cells = <0>;
>>>>>>
>>>>>>            gpio@25 {
>>>>>>              compatible = "rpmsg-gpio";
>>>>>>              reg = <25>;
>>>>>>              gpio-controller;
>>>>>>              #gpio-cells = <2>;
>>>>>>              #interrupt-cells = <2>;
>>>>>>              interrupt-controller;
>>>>>>            };
>>>>>>
>>>>>>            gpio@32 {
>>>>>>              compatible = "rpmsg-gpio";
>>>>>>              reg = <32>;
>>>>>>              gpio-controller;
>>>>>>              #gpio-cells = <2>;
>>>>>>              #interrupt-cells = <2>;
>>>>>>              interrupt-controller;
>>>>>>            };
>>>>>>          };
>>>>>>        };
>>>>>>
>>>>>>   rpmsg-io-25  would match with gpio@25
>>>>>>   rpmsg-io-32  would match with gpio@32
>>>>>>
>>>>>
>>>>> The problem with this approach is, we will endup creating way too many
>>>>> RPMsg devices/channels. i.e. one channel per one GPIO. That limits how
>>>>> many GPIOs can be handled by remote from memory perspective. At
>>>>> somepoint we might just run-out of number ept & channels created by the
>>>>> remote. As of now, open-amp library supports 128 epts I think.
>>>>
>>>> Right, I proposed a solution in my previous answer to Beleswar who has
>>>> the same concern.
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> Because the endpoint that is created on a namespace request is also
>>>>>>> dynamic in nature. How will the remote know which endpoint addr
>>>>>>> Linux allocated for a namespace that it announced?
>>>>>>>
>>>>>>> As an example/PoC, I created a firmware example which announces
>>>>>>> 2 name services to Linux, one is the standard "rpmsg_chrdev" and
>>>>>>> the other is a TI specific name service "ti.ipc4.ping-pong". You can
>>>>>>> see it created 2 different addresses (0x400 and 0x401) for each of
>>>>>>> the name service request from the same firmware:
>>>>>>>
>>>>>>> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
>>>>>>> [    9.290275] virtio_rpmsg_bus virtio0: creating channel
>>>>>>> ti.ipc4.ping-pong addr 0xd
>>>>>>> [    9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev
>>>>>>> addr 0xe
>>>>>>> [    9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel
>>>>>>> formed from src = 0x400 to dst = 0xe
>>>>>>> [    9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13:
>>>>>>> new channel: 0x401 -> 0xd!
>>>>>>>
>>>>>>> So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
>>>>>>> Back to same problem. Simple solution is to reply to remote with the
>>>>>>> created ept addr and the index.
>>>>>>
>>>>>> That why I would like to suggest to use the name service field to
>>>>>> identify the port/controller, instead of the endpoint address.
>>>>>>>
>>>>>>>>
>>>>>>>> - match the RPMsg probe with the DT,
>>>>>>>
>>>>>>>
>>>>>>> We can probe from all controllers with a single name service
>>>>>>> announcement too.
>>>>>>>
>>>>>>>> - provide a simple mapping between the port and the endpoint on both
>>>>>>>> sides,
>>>>>>>
>>>>>>>
>>>>>>> We are trying to get rid of this mapping from Linux side to adapt
>>>>>>> the gpio-virtio design.
>>>>>>>
>>>>>>>> - allow multiple endpoints on the remote side,
>>>>>>>
>>>>>>>
>>>>>>> We can support this as well with single nameservice model.
>>>>>>> There is no limitation. Remote has to send a message with
>>>>>>> its newly created ept that's all.
>>>>>>>
>>>>>>>> - provide a simple discovery mechanism for remote capabilities.
>>>>>>>
>>>>>>>
>>>>>>> A single announcement: "rpmsg-io" is also discovery mechanism.
>>>>>>>
>>>>>>> Feel free to let me know if you have concerns with any of the
>>>>>>> suggestions!
>>>>>>
>>>>>> My only concern, whatever the solution, is that we find a smart
>>>>>> solution to associate the correct endpoint with the correct GPIO
>>>>>> port/controller defined in the DT.
>>>>>>
>>>>>> I may have misunderstood your solution. Could you please help me
>>>>>> understand your proposal by explaining how you would handle three
>>>>>> GPIO ports defined in the DT, considering that the endpoint
>>>>>> addresses on the Linux side can be random?
>>>>>> If I assume there is a unique endpoint on the remote side,
>>>>>> I do not understand how you can match, on the firmware side,
>>>>>> the Linux endpoint address to the GPIO port.
>>>>>>
>>>>>> Thanks and Regards,Arnaud
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Beleswar
>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Arnaud
>>>>>>>>
>>>>>>>>>> 2. namespace/channel#2 = rpmsg-i2c
>>>>>>>>>>        a. ept1 -> i2c@1
>>>>>>>>>>        b. ept2 -> i2c@2
>>>>>>>>>>        c. ept3 -> i2c@3
>>>>>>>>>>
>>>>>>>>>> etc...
>>>>>>>>>>
>>>>>
>>>>> Just want to clear-up few terms before I jump to the solution:
>>>>>
>>>>> **RPMsg channel/device**:
>>>>>    - These are devices announced by the remote processor, and created by
>>>>> linux. They are created at: /sys/bus/rpmsg/devices
>>>>>    - The channel format: <name>.<src ept>.<dst ept>
>>>>>
>>>>> **RPMsg endpoint**:
>>>>>    - Endpoint is differnt than channel. Single channel can have multiple
>>>>> endpoints, and represented in the linux with: /dev/rpmsg? devices.
>>>>>
>>>>> To create endpoint device, we have rpmsg_create_ept API, which takes
>>>>> channel information as input, which has src-ept, dst-ept.
>>>>>
>>>>> Following is proposed solution:
>>>>>
>>>>> 1) Assign RPMsg channel/device per rpmsg-gpio controller (Not per GPIO
>>>>> pin/port).
>>>>>    - In our case that would be, single rpmsg-io node. (That makes me
>>>>> question if bindings are correct or not).
>>>>>
>>>>> 2) Assign GPIO number as src ept.
>>>>>
>>>>> i.e. *rpmsg-io.<GPIO number>.<dst ept>*. Do not randomly assign src
>>>>> endpoint.
>>>>>
>>>>> Now, RPMSG channel by spec reserves first 1024 endpoints [1], so we can
>>>>> add 1024 offset to the GPIO number:
>>>>>
>>>>> so, when calling rpmsg_create_ept() API, we assing src_endpoint as:
>>>>> (GPIO_NUMBER + RPMSG_RESERVED_ADDRESSES)
>>>>>
>>>>> Now on the remote side, there is single channel and only single-endpoint
>>>>> is needed that is mapped to the rpmsg-io channel callback.
>>>>>
>>>>> That callback will receive all the payloads from the Linux, which will
>>>>> have src-ept i.e. (RPMSG_RESERVED_ADDRESSES + GPIO_NUMBER).
>>>>
>>>>
>>>> Interesting approach. I also tried to find a similar solution.
>>>>
>>>> The question here is: how can we guarantee continuous addresses? Given
>>>> the static and dynamic allocation of endpoint addresses that are
>>>> implemented, my conclusion was that it is not reliable enough.
>>>>
>>>> but perhaps I missed something...
>>>>
>>>>>
>>>>> It can retrieve GPIO_NUMBER easily, and convert to appropriate pin based
>>>>> on platform specific logic.
>>>>>
>>>>> This doesn't need PORT information at all. Also it makes sure that
>>>>> remote is using only single-endpoint so not much memory is used.
>>>>>
>>>>> *Example*:
>>>>> If only rpmsg-gpio channel is created by the remote side, than following
>>>>> is the representation of the devices when GPIO 25, 26, 27 is assigned to
>>>>> the rpmsg-io controller:
>>>>>
>>>>> Linux                                                      Remote
>>>>>
>>>>> rpmsg-channel: rpmsg-gpio.0x400.0x400
>>>>>
>>>>> /dev/rpmsg0 - GPIO25 ept (rpmsg-gpio.0x419.0x400)-|
>>>>>                                                    |
>>>>> /dev/rpmsg1 - GPIO26 ept (rpmsg-gpio.0x41a.0x400)-|-> rpmsg-gpio.*.0x400
>>>>>                                                    |
>>>>> /dev/rpmsg2 - GPIO27 ept (rpmsg-gpio.0x41b.0x400)-|  0x400 ept callback.
>>>>>
>>>>>
>>>>> *On remote side*:
>>>>>
>>>>> ept_0x400_callback(..., int src_ept, ...,)
>>>>> {
>>>>>     int gpio_num = src_ept - RPMSG_RESERVED_ADDRESSES;
>>>>>     // platform specific logic to convert gpio num to proper pin,
>>>>>     // just like you would convert gpio num to pin on a linux gpio
>>>>> controller.
>>>>> }
>>>>>
>>>>> My question on the binding:
>>>>>
>>>>> Why each GPIO is represented with the separate node? I think rpmsg-gpio
>>>>> can be represented just any other GPIO controller? Please let me know if
>>>>> I am missing something. So rpmsg channel/rpmsg device is not created per
>>>>> GPIO, but per controller. GPIO number multiplexing should be done with
>>>>> rpmsg src ept, that removes the need of having each GPIO as a separate
>>>>> node.
>>>>>
>>>>>
>>>>> rpmsg_gpio: rpmsg-gpio@0 {
>>>>>         compatible = "rpmsg-gpio";
>>>>>         reg = <0>;
>>>>>         gpio-controller;
>>>>>         #gpio-cells = <2>;
>>>>>         #interrupt-cells = <2>;
>>>>>         interrupt-controller;
>>>>>     };
>>>>>
>>>>> Then in DT, use like regular GPIO, but with the rpmsg-gpio controller:
>>>>>
>>>>> rpmsg-gpios = <&rpmsg_gpio (GPIO NUM) (flags)>;
>>>>>
>>>>> If the intent to create separate gpio nodes was only for the channel
>>>>> creation, then it's not really needed.
>>>>>
>>>>> [1]
>>>>> https://github.com/torvalds/linux/
>>>>> blob/6d35786de28116ecf78797a62b84e6bf3c45aa5a/drivers/rpmsg/
>>>>> virtio_rpmsg_bus.c#L136
>>>>>
>>>>
>>>> It is already the case. bindings declare GPIO controllers, not directly
>>>> GPIOs in:
>>>>
>>>> [PATCH v13 2/4] dt-bindings: remoteproc: imx_rproc: Add "rpmsg" subnode
>>>> support
>>>>
>>>> The discussion is around having an unique RPmsg endpoint for all
>>>> GPIO controller or one RPmsg endpoint per GPIO controller.
>>>>
>>>
>>> Endpoint where remote side or linux side?
>>>
>>> If unique endpoint on remote side per gpio controller then it makes sense.
>>>
>>> Unique endpoint on linux side doesn't make sense. Instead, unique
>>> channel per gpio controller makes sense, and each channel will have
>>> multiple endpoints on linux side. As I replied to Beleswar on the other
>>> email, I will copy past my answer here too:
>>>
>>>
>>> To be more specific:
>>>
>>> Linux:                               remote:
>>>
>>> ch1: rpmsg-gpio.-1.1024 ->     gpio-controller@1024
>>>     - gpio-line ept1
>>>     - gpio-line ept2    ->     They all map to same callback_ept_1024.
>>>     - gpio-line ept3
>>>
>>> ch2: rpmsg-gpio.-1.1025 ->     gpio-controller@1025
>>>     - gpio-line ept1
>>>     - gpio-line ept2    ->     They all map to same callback_ept_1025.
>>>     - gpio-line ept3
>>>
>>
>>
>> Hi Mathieu,
>>
>> So upon more brain storming in this approach I found limitation:
>>
>> This approach won't work if host OS is any other OS but Linux. For
>> example, if the remote OS is zephyr/baremetal using open-amp, then Only
>> Linux <-> zephyr combination will work, and we won't be able to re-use
>> this approach for zephyr <-> zephyr use case. The concept of rpmsg
>> channel/device exist only in the linux kernel implementation. This
>> brings another question: Should the protocol we decide work on other use
>> cases as well? Or Linux must be the Host OS for this protocol ?
>>
> 
> Linux and Zephyr are very distinct OS, each with their own subsystems
> and characteristics.  The design we choose here involves RPMSG and,
> inherently, Linux.  We can't make decisions based on what may
> potentially happen in Zephyr.
> 
>>
>> I think your & Arnaud's proposed approach of single endpoint per
>> gpio-controller on both side makes more sense, as it will work
>> regardless of any OS on host or remote side.
>>
> 
> Arnaud, Beleswar, Andrew and I are all advocating for one endpoint per
> GPIO controller.  The remaining issue it about the best way to work
> out source and destination addresses between Linux and the remote
> processor.  I'm running out of time for today but I'll return to this
> thread with a final analysis by the end of the week.
> 

Okay. Then that means multiple endpoints on Linux side can be considered.

If we decide to go single-endpoint per device on both side, then for
that here is the proposal to represent src ept and dst ept:

When we represent any device under rpmsg bus node, I think it should be
considered remote's view of the adddress space. So ideally we can
convert it to Linux view of the address space, via 'ranges' property.

So bindings should include 'ranges' property in the parent node. Then
linux view of the start address becomes src ept, and remote view of the
start address becomes dest ept. The remote view of the start address is
expected to be the static src endpoint on the remote side.

Following representation of the rpmsg devices (gpio, i2c, spi or any other):

rpmsg {
  #address-cells = <1>;
  #size-cells = <1>;

  rpmsg-io {
    compatible = "rpmsg-io-bus";
    ranges = <remote_view_addr(dst ept) linux_view_addr(src ept) size>;
    #address-cells = <1>;
    #size-cells = <1>;

    gpio@remote_view_addr(or dst ept) {
      compatible = "rpmsg-io";
      reg = <remote_view_addr addr_space_size>;
      gpio-controller;
      #gpio-cells = <2>;
      interrupt-controller;
      #interrupt-cells = <2>;
    };

    ...

  };

};

Example device-tree:

rpmsg {
  #address-cells = <1>;
  #size-cells = <1>;

  rpmsg-io {
    compatible = "rpmsg-io-bus";
    ranges = <0x10000 0x50000 0x1000>,
             <0x20000 0x60000 0x1000>;
    #address-cells = <1>;
    #size-cells = <1>;

    gpio@10000 {
      compatible = "rpmsg-io";
      reg = <0x10000 0x1000>;
      gpio-controller;
      #gpio-cells = <2>;
      interrupt-controller;
      #interrupt-cells = <2>;
    };

    gpio@20000 {
      compatible = "rpmsg-io";
      reg = <0x20000 0x1000>;
      gpio-controller;
      #gpio-cells = <2>;
      interrupt-controller;
      #interrupt-cells = <2>;
    };

  };

};


Thanks,
Tanmay


>> To be more specific this will look like following:
>>
>> Host (Linux)                       Remote (baremetal/RTOS)
>>
>> rpmsg ch/device 1:
>>     - rpmsg ept 1   <------>     rpmsg ept 1 gpio-controller 0
>>
>> rpmsg ch/device 2:
>>      - rpmsg ept 2   <------>     rpmsg ept 2 gpio-controller 1
>>
>>
>> The question is, how to decide src ept, and dest ept on both sides?
>> I still think it should be static endpoints.
>>
>> I will get back with more reasoning on that.
>>
>>> On the remote side, we have to hardcode Which rpmsg controller is mapped
>>> to which endpoint.
>>>
>>>> Or did I misunderstand your questions?
>>>>
>>>> Thanks,
>>>> Arnaud
>>>>
>>>
>>>
>>> I gave this patch more time yesterday, and I think the 'reg' property
>>> should represent remote endpoint, instead of the gpio-controller index.
>>>
>>> So in this approach remote implementation is expected to provide
>>> hard-coded (static) endpoints for each gpio-controller instance, and
>>> that same number should be represented with the 'reg' property.
>>>
>>> On remote side:
>>>
>>> #define RPMSG_GPIO_0_CONTROLLER_EPT (RPMSG_RESERVED_ADDRESSES + 1) // 1024
>>>
>>> ept_1024_callback() {
>>>
>>>       // handle appropriate gpio port ()
>>>
>>> }
>>>
>>> On linux side:
>>>
>>> So new representation of controller:
>>>
>>>  rpmsg_gpio_0:   gpio@1024 {
>>>              compatible = "rpmsg-gpio";
>>>              reg = <1024>;
>>>              gpio-controller;
>>>              #gpio-cells = <2>;
>>>              #interrupt-cells = <2>;
>>>              interrupt-controller;
>>>           };
>>>
>>>  rpmsg_gpio_1:   gpio@1025 {
>>>              compatible = "rpmsg-gpio";
>>>              reg = <1025>;
>>>              gpio-controller;
>>>              #gpio-cells = <2>;
>>>              #interrupt-cells = <2>;
>>>              interrupt-controller;
>>>           };
>>>
>>> gpios = <&rpmsg_gpio_0 (GPIO NUM or PIN) flags>,
>>>       <&rpmsg_gpio_1 (GPIO NUM or PIN) flags>;
>>>
>>> Now in the linux driver:
>>>
>>> You can easily retrieve destination endpoint when we want to send the
>>> command to the gpio controller via device's "reg" property.
>>>
>>> This approach also provides built-in security as well. Because now
>>> gpio-controller instance is hardcoded with the endpoint callback, it
>>> can't be modified/addressed without changing the 'reg' property.
>>>
>>> Just like you wouldn't change device address for the instance of the
>>> gpio-controller right?
>>>
>>> This approach can be easily adapted to all the other rpmsg controllers
>>> as well.
>>>
>>> So, dynamic endpoint allocation doesn't make sense in this case. Dynamic
>>> endpoint allocation makes more sense for user-space apps which don't
>>> really care about endpoints and only payloads.
>>>
>>> But, here we are multiplexing device-addresses with endpoints, and so it
>>> has to be fixed, and presented via 'reg' property. So, firmware can't
>>> change device-address without Linux knowing it.
>>>
>>> Thanks,
>>> Tanmay
>>>
>>>
>>>>
>>>>>>>>>> This way device groups are isolated with each channel/namespace, and
>>>>>>>>>> instances within each device groups are also respected with specific
>>>>>>>>>> endpoints.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Beleswar
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>

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

[Beleswar Prasad Padhi]

Hi Tanmay,

On 05/05/26 00:49, Shah, Tanmay wrote:
> Hello all,
>
> I have started reviewing this work as well.
> Thanks Shenwei for this work.
>
> I have gone through only the current revision, and would like to provide
> idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
> Also, have some bindings related question.
>
> Please see below:
>
> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
>>
>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>>> Hello Arnaud,
>>>
>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>>> Hello,
>>>>
>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>>>>> Hi Mathieu,
>>>>>>
>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-
>>>>>>>>> padhi@ti.com>; Linus
>>>>>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski
>>>>>>>>> <brgl@kernel.org>; Jonathan
>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
>>>>>>>>> Krzysztof Kozlowski
>>>>>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn
>>>>>>>>> Andersson
>>>>>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>>>>>>>> <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>> <skhan@linuxfoundation.org>; linux-
>>>>>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-
>>>>>>>>> kernel@vger.kernel.org;
>>>>>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>>>>>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-
>>>>>>>>> linux-imx <linux-
>>>>>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>> rpmsg GPIO driver
>>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
>>>>>>>>>>> Jonathan
>>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
>>>>>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley
>>>>>>>>>>> <conor+dt@kernel.org>;
>>>>>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>>>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
>>>>>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>>>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>>>>>>>> <brgl@bgdev.pl>
>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>>>>>>>>> GPIO driver
>>>>>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>>>>>            __u8 status;
>>>>>>>>>>>>>            __u8 value;
>>>>>>>>>>>>> };
>>>>>>>>>>>> It is the same message format. Please see the message definition
>>>>>>>>>>> (GET_DIRECTION) below:
>>>>>>>>>>>
>>>>>>>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>>>>>>>>> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>>>>>> +   | 1   | 2   |port |line | err | dir|
>>>>>>>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same
>>>>>>>>>>> message format.
>>>>>>>>>>>
>>>>>>>>>> Some changes to the message format are necessary.
>>>>>>>>>>
>>>>>>>>>> Virtio uses two communication channels (virtqueues): one for
>>>>>>>>>> requests and
>>>>>>>>> replies, and a second one for events.
>>>>>>>>>> In contrast, rpmsg provides only a single communication
>>>>>>>>>> channel, so a
>>>>>>>>>> type field is required to distinguish between different kinds
>>>>>>>>>> of messages.
>>>>>>>>>>
>>>>>>>>>> Since rpmsg replies and events share the same message format,
>>>>>>>>>> an additional
>>>>>>>>> line is introduced to handle both cases.
>>>>>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port
>>>>>>>>>> field is added to
>>>>>>>>> uniquely identify the target controller.
>>>>>>>>>
>>>>>>>>> I have commented on this before - RPMSG is already providing
>>>>>>>>> multiplexing
>>>>>>>>> capability by way of endpoints.  There is no need for a port
>>>>>>>>> field.  One endpoint,
>>>>>>>>> one GPIO controller.
>>>>>>>>>
>>>>>>>> You still need a way to let the remote side know which port the
>>>>>>>> endpoint maps to, either
>>>>>>>> by embedding the port information in the message (the current
>>>>>>>> way), or by sending it
>>>>>>>> separately.
>>>>>>>>
>>>>>>> An endpoint is created with every namespace request.  There should be
>>>>>>> one namespace request for every GPIO controller, which yields a
>>>>>>> unique
>>>>>>> endpoint for each controller and eliminates the need for an extra
>>>>>>> field to identify them.
>>>>>>
>>>>>> Right, but this can still be done by just having one namespace
>>>>>> request.
>>>>>> We can create new endpoints bound to an existing namespace/channel by
>>>>>> invoking rpmsg_create_ept(). This is what I suggested here too:
>>>>>> https://lore.kernel.org/all/29485742-6e49-482e-
>>>>>> b73d-228295daaeec@ti.com/
>>>>>>
>>>>> I will look at your suggestion (i.e link above) later this week or
>>>>> next week.
>>>>>
>>>>>> My mental model looks like this for the complete picture:
>>>>>>
>>>>>> 1. namespace/channel#1 = rpmsg-io
>>>>>>       a. ept1 -> gpio-controller@1
>>>>>>       b. ept2 -> gpio-controller@2
>>>>>>
> If my understanding of what gpio-controller is right, than this won't
> work. We need one rpmsg channel per gpio-controller, and in most cases
> there will be only one GPIO-controller on the remote side.


Why so? In the current v13 version, the remote side already
handles 2 GPIO controllers.

>  If there are
> multiple or multiple instances of same controller, than we need separate
> channel name for that controller just like we would have separate device
> on the Linux.


Why so? I think there is some confusion in the terminology:

GPIO controller = GPIO port (gpio@xyz) defined in the
Device tree = struct rpmsg_gpio_port in code

GPIO line = Individual lines within each GPIO port (max =
GPIOS_PER_PORT_DEFAULT) = struct rpmsg_gpio_line in code

>
>>>>> I've asked for one endpoint per GPIO controller since the very
>>>>> beginning.  I don't yet have a strong opinion on whether to use one
>>>>> namespace request per GPIO controller or a single request that spins
>>>>> off multiple endpoints.  I'll have to look at your link and reflect on
>>>>> that.  Regardless of how we proceed on that front, multiplexing needs
>>>>> to happen at the endpoint level rather than the packet level.  This is
>>>>> the only way this work can move forward.
>>>>>
>>>> I would be more in favor of Mathieu’s proposal: “An endpoint is
>>>> created with every namespace request.”
>>>>
>>>> If the endpoint is created only on the Linux side, how do we match
>>>> the Linux endpoint address with the local port field on the remote side?
>>>
>>> Simply by sending a message to the remote containing the newly created
>>> endpoint and the port idx. Note that is this done just one time, after
>>> this
>>> Linux need not have the port field in the message everytime its sending
>>> a message.
>>>
>>>> With a multi-namespace approach, the namespace could be rpmsg-io-
>>>> [addr], where [addr] corresponds to the GPIO controller address in
>>>> the DT. This would:
>>>
>>> You will face the same problem in this case also that you asked above:
>>> "how do we match the Linux endpoint address with the local port field
>>> on the remote side?"
>> Sorry I probably introduced confusion here
>> my sentence should be;
>>  With a multi-namespace approach, the namespace could be rpmsg-io-[port],
>>  where [port] corresponds to the GPIO controller port in the DT.
>>
>>
>> For instance:
>>
>>       rpmsg {
>>         rpmsg-io {
>>           #address-cells = <1>;
>>           #size-cells = <0>;
>>
>>           gpio@25 {
>>             compatible = "rpmsg-gpio";
>>             reg = <25>;
>>             gpio-controller;
>>             #gpio-cells = <2>;
>>             #interrupt-cells = <2>;
>>             interrupt-controller;
>>           };
>>
>>           gpio@32 {
>>             compatible = "rpmsg-gpio";
>>             reg = <32>;
>>             gpio-controller;
>>             #gpio-cells = <2>;
>>             #interrupt-cells = <2>;
>>             interrupt-controller;
>>           };
>>         };
>>       };
>>
>>  rpmsg-io-25  would match with gpio@25
>>  rpmsg-io-32  would match with gpio@32
>>
> The problem with this approach is, we will endup creating way too many
> RPMsg devices/channels. i.e. one channel per one GPIO. That limits how
> many GPIOs can be handled by remote from memory perspective. At
> somepoint we might just run-out of number ept & channels created by the
> remote. As of now, open-amp library supports 128 epts I think.


Arnaud was suggesting one channel per gpio controller,
not per line. We will not have 128 gpio controllers....

>
>>> Because the endpoint that is created on a namespace request is also
>>> dynamic in nature. How will the remote know which endpoint addr
>>> Linux allocated for a namespace that it announced?
>>>
>>> As an example/PoC, I created a firmware example which announces
>>> 2 name services to Linux, one is the standard "rpmsg_chrdev" and
>>> the other is a TI specific name service "ti.ipc4.ping-pong". You can
>>> see it created 2 different addresses (0x400 and 0x401) for each of
>>> the name service request from the same firmware:
>>>
>>> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
>>> [    9.290275] virtio_rpmsg_bus virtio0: creating channel
>>> ti.ipc4.ping-pong addr 0xd
>>> [    9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev
>>> addr 0xe
>>> [    9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel
>>> formed from src = 0x400 to dst = 0xe
>>> [    9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13:
>>> new channel: 0x401 -> 0xd!
>>>
>>> So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
>>> Back to same problem. Simple solution is to reply to remote with the
>>> created ept addr and the index.
>> That why I would like to suggest to use the name service field to
>> identify the port/controller, instead of the endpoint address.
>>>  
>>>> - match the RPMsg probe with the DT,
>>>
>>> We can probe from all controllers with a single name service
>>> announcement too.
>>>
>>>> - provide a simple mapping between the port and the endpoint on both
>>>> sides,
>>>
>>> We are trying to get rid of this mapping from Linux side to adapt
>>> the gpio-virtio design.
>>>
>>>> - allow multiple endpoints on the remote side,
>>>
>>> We can support this as well with single nameservice model.
>>> There is no limitation. Remote has to send a message with
>>> its newly created ept that's all.
>>>
>>>> - provide a simple discovery mechanism for remote capabilities.
>>>
>>> A single announcement: "rpmsg-io" is also discovery mechanism.
>>>
>>> Feel free to let me know if you have concerns with any of the
>>> suggestions!
>> My only concern, whatever the solution, is that we find a smart
>> solution to associate the correct endpoint with the correct GPIO
>> port/controller defined in the DT.
>>
>> I may have misunderstood your solution. Could you please help me
>> understand your proposal by explaining how you would handle three
>> GPIO ports defined in the DT, considering that the endpoint
>> addresses on the Linux side can be random?
>> If I assume there is a unique endpoint on the remote side,
>> I do not understand how you can match, on the firmware side,
>> the Linux endpoint address to the GPIO port.
>>
>> Thanks and Regards,Arnaud
>>
>>> Thanks,
>>> Beleswar
>>>
>>>> Regards,
>>>> Arnaud
>>>>
>>>>>> 2. namespace/channel#2 = rpmsg-i2c
>>>>>>       a. ept1 -> i2c@1
>>>>>>       b. ept2 -> i2c@2
>>>>>>       c. ept3 -> i2c@3
>>>>>>
>>>>>> etc...
>>>>>>
> Just want to clear-up few terms before I jump to the solution:
>
> **RPMsg channel/device**:
>   - These are devices announced by the remote processor, and created by
> linux. They are created at: /sys/bus/rpmsg/devices
>   - The channel format: <name>.<src ept>.<dst ept>
>
> **RPMsg endpoint**:
>   - Endpoint is differnt than channel. Single channel can have multiple
> endpoints, and represented in the linux with: /dev/rpmsg? devices.
>
> To create endpoint device, we have rpmsg_create_ept API, which takes
> channel information as input, which has src-ept, dst-ept.
>
> Following is proposed solution:
>
> 1) Assign RPMsg channel/device per rpmsg-gpio controller (Not per GPIO
> pin/port).


One channel per pin was not suggested earlier...

>   - In our case that would be, single rpmsg-io node. (That makes me
> question if bindings are correct or not).
>
> 2) Assign GPIO number as src ept.
>
> i.e. *rpmsg-io.<GPIO number>.<dst ept>*. Do not randomly assign src
> endpoint.
>
> Now, RPMSG channel by spec reserves first 1024 endpoints [1], so we can
> add 1024 offset to the GPIO number:
>
> so, when calling rpmsg_create_ept() API, we assing src_endpoint as:
> (GPIO_NUMBER + RPMSG_RESERVED_ADDRESSES)
>
> Now on the remote side, there is single channel and only single-endpoint
> is needed that is mapped to the rpmsg-io channel callback.
>
> That callback will receive all the payloads from the Linux, which will
> have src-ept i.e. (RPMSG_RESERVED_ADDRESSES + GPIO_NUMBER).
>
> It can retrieve GPIO_NUMBER easily, and convert to appropriate pin based
> on platform specific logic.
>
> This doesn't need PORT information at all. Also it makes sure that
> remote is using only single-endpoint so not much memory is used.
>
> *Example*:
> If only rpmsg-gpio channel is created by the remote side, than following
> is the representation of the devices when GPIO 25, 26, 27 is assigned to
> the rpmsg-io controller:
>
> Linux                                                      Remote
>
> rpmsg-channel: rpmsg-gpio.0x400.0x400
>
> /dev/rpmsg0 - GPIO25 ept (rpmsg-gpio.0x419.0x400)-|
>                                                   |
> /dev/rpmsg1 - GPIO26 ept (rpmsg-gpio.0x41a.0x400)-|-> rpmsg-gpio.*.0x400
>                                                   |
> /dev/rpmsg2 - GPIO27 ept (rpmsg-gpio.0x41b.0x400)-|  0x400 ept callback.
>
>
> *On remote side*:
>
> ept_0x400_callback(..., int src_ept, ...,)
> {
> 	int gpio_num = src_ept - RPMSG_RESERVED_ADDRESSES;
> 	// platform specific logic to convert gpio num to proper pin,
> 	// just like you would convert gpio num to pin on a linux gpio controller.
> }
>
> My question on the binding:
>
> Why each GPIO is represented with the separate node? I think rpmsg-gpio
> can be represented just any other GPIO controller? Please let me know if
> I am missing something.


These are separate GPIO controllers, not separate pins within
the same GPIO controller. Could you revisit your solution with
this update.

Thanks for your time,
Beleswar

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

[Shah, Tanmay]

On 5/5/2026 6:16 AM, Beleswar Prasad Padhi wrote:
> Hi Tanmay,
> 
> On 05/05/26 00:49, Shah, Tanmay wrote:
>> Hello all,
>>
>> I have started reviewing this work as well.
>> Thanks Shenwei for this work.
>>
>> I have gone through only the current revision, and would like to provide
>> idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
>> Also, have some bindings related question.
>>
>> Please see below:
>>
>> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
>>>
>>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>>>> Hello Arnaud,
>>>>
>>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>>>> Hello,
>>>>>
>>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>>>>>> Hi Mathieu,
>>>>>>>
>>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-
>>>>>>>>>> padhi@ti.com>; Linus
>>>>>>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski
>>>>>>>>>> <brgl@kernel.org>; Jonathan
>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
>>>>>>>>>> Krzysztof Kozlowski
>>>>>>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn
>>>>>>>>>> Andersson
>>>>>>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>>>>>>>>> <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>>> <skhan@linuxfoundation.org>; linux-
>>>>>>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-
>>>>>>>>>> kernel@vger.kernel.org;
>>>>>>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>>>>>>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-
>>>>>>>>>> linux-imx <linux-
>>>>>>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>>> rpmsg GPIO driver
>>>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>>>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
>>>>>>>>>>>> Jonathan
>>>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
>>>>>>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley
>>>>>>>>>>>> <conor+dt@kernel.org>;
>>>>>>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>>>>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
>>>>>>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>>>>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>>>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>>>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>>>>>>>>> <brgl@bgdev.pl>
>>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>>>>>>>>>> GPIO driver
>>>>>>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>>>>>>            __u8 status;
>>>>>>>>>>>>>>            __u8 value;
>>>>>>>>>>>>>> };
>>>>>>>>>>>>> It is the same message format. Please see the message definition
>>>>>>>>>>>> (GET_DIRECTION) below:
>>>>>>>>>>>>
>>>>>>>>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>>>>>>>>>> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>>>>>>> +   | 1   | 2   |port |line | err | dir|
>>>>>>>>>>>>> +   +-----+-----+-----+-----+-----+----+
>>>>>>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same
>>>>>>>>>>>> message format.
>>>>>>>>>>>>
>>>>>>>>>>> Some changes to the message format are necessary.
>>>>>>>>>>>
>>>>>>>>>>> Virtio uses two communication channels (virtqueues): one for
>>>>>>>>>>> requests and
>>>>>>>>>> replies, and a second one for events.
>>>>>>>>>>> In contrast, rpmsg provides only a single communication
>>>>>>>>>>> channel, so a
>>>>>>>>>>> type field is required to distinguish between different kinds
>>>>>>>>>>> of messages.
>>>>>>>>>>>
>>>>>>>>>>> Since rpmsg replies and events share the same message format,
>>>>>>>>>>> an additional
>>>>>>>>>> line is introduced to handle both cases.
>>>>>>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port
>>>>>>>>>>> field is added to
>>>>>>>>>> uniquely identify the target controller.
>>>>>>>>>>
>>>>>>>>>> I have commented on this before - RPMSG is already providing
>>>>>>>>>> multiplexing
>>>>>>>>>> capability by way of endpoints.  There is no need for a port
>>>>>>>>>> field.  One endpoint,
>>>>>>>>>> one GPIO controller.
>>>>>>>>>>
>>>>>>>>> You still need a way to let the remote side know which port the
>>>>>>>>> endpoint maps to, either
>>>>>>>>> by embedding the port information in the message (the current
>>>>>>>>> way), or by sending it
>>>>>>>>> separately.
>>>>>>>>>
>>>>>>>> An endpoint is created with every namespace request.  There should be
>>>>>>>> one namespace request for every GPIO controller, which yields a
>>>>>>>> unique
>>>>>>>> endpoint for each controller and eliminates the need for an extra
>>>>>>>> field to identify them.
>>>>>>>
>>>>>>> Right, but this can still be done by just having one namespace
>>>>>>> request.
>>>>>>> We can create new endpoints bound to an existing namespace/channel by
>>>>>>> invoking rpmsg_create_ept(). This is what I suggested here too:
>>>>>>> https://lore.kernel.org/all/29485742-6e49-482e-
>>>>>>> b73d-228295daaeec@ti.com/
>>>>>>>
>>>>>> I will look at your suggestion (i.e link above) later this week or
>>>>>> next week.
>>>>>>
>>>>>>> My mental model looks like this for the complete picture:
>>>>>>>
>>>>>>> 1. namespace/channel#1 = rpmsg-io
>>>>>>>       a. ept1 -> gpio-controller@1
>>>>>>>       b. ept2 -> gpio-controller@2
>>>>>>>
>> If my understanding of what gpio-controller is right, than this won't
>> work. We need one rpmsg channel per gpio-controller, and in most cases
>> there will be only one GPIO-controller on the remote side.
> 
> 
> Why so? In the current v13 version, the remote side already
> handles 2 GPIO controllers.
> 
>>  If there are
>> multiple or multiple instances of same controller, than we need separate
>> channel name for that controller just like we would have separate device
>> on the Linux.
> 
> 
> Why so? I think there is some confusion in the terminology:
> 
> GPIO controller = GPIO port (gpio@xyz) defined in the
> Device tree = struct rpmsg_gpio_port in code
> 
> GPIO line = Individual lines within each GPIO port (max =
> GPIOS_PER_PORT_DEFAULT) = struct rpmsg_gpio_line in code
> 

Okay, I understand now. So, same gpio controller has multiple instances.

>>>>>>> 1. namespace/channel#1 = rpmsg-io
>>>>>>>       a. ept1 -> gpio-controller@1
>>>>>>>       b. ept2 -> gpio-controller@2

So, In that case above mentioned approach doesn't work.

Because, this approach is mapping endpoint to the gpio-controller. From
linux's perspective, it needs to map rpmsg *channel* to the
gpio-controller not the endpoint.

To be more specific:

Linux:                               remote:

ch1: rpmsg-gpio.-1.1024 ->     gpio-controller@1024
    - gpio-line ept1
    - gpio-line ept2    ->     They all map to same callback_ept_1024.
    - gpio-line ept3

ch2: rpmsg-gpio.-1.1025 ->     gpio-controller@1025
    - gpio-line ept1
    - gpio-line ept2    ->     They all map to same callback_ept_1025.
    - gpio-line ept3

On the remote side, we have to hardcode Which rpmsg controller is mapped
to which endpoint.



>>
>>>>>> I've asked for one endpoint per GPIO controller since the very
>>>>>> beginning.  I don't yet have a strong opinion on whether to use one
>>>>>> namespace request per GPIO controller or a single request that spins
>>>>>> off multiple endpoints.  I'll have to look at your link and reflect on
>>>>>> that.  Regardless of how we proceed on that front, multiplexing needs
>>>>>> to happen at the endpoint level rather than the packet level.  This is
>>>>>> the only way this work can move forward.
>>>>>>
>>>>> I would be more in favor of Mathieu’s proposal: “An endpoint is
>>>>> created with every namespace request.”
>>>>>
>>>>> If the endpoint is created only on the Linux side, how do we match
>>>>> the Linux endpoint address with the local port field on the remote side?
>>>>
>>>> Simply by sending a message to the remote containing the newly created
>>>> endpoint and the port idx. Note that is this done just one time, after
>>>> this
>>>> Linux need not have the port field in the message everytime its sending
>>>> a message.
>>>>
>>>>> With a multi-namespace approach, the namespace could be rpmsg-io-
>>>>> [addr], where [addr] corresponds to the GPIO controller address in
>>>>> the DT. This would:
>>>>
>>>> You will face the same problem in this case also that you asked above:
>>>> "how do we match the Linux endpoint address with the local port field
>>>> on the remote side?"
>>> Sorry I probably introduced confusion here
>>> my sentence should be;
>>>  With a multi-namespace approach, the namespace could be rpmsg-io-[port],
>>>  where [port] corresponds to the GPIO controller port in the DT.
>>>
>>>
>>> For instance:
>>>
>>>       rpmsg {
>>>         rpmsg-io {
>>>           #address-cells = <1>;
>>>           #size-cells = <0>;
>>>
>>>           gpio@25 {
>>>             compatible = "rpmsg-gpio";
>>>             reg = <25>;
>>>             gpio-controller;
>>>             #gpio-cells = <2>;
>>>             #interrupt-cells = <2>;
>>>             interrupt-controller;
>>>           };
>>>
>>>           gpio@32 {
>>>             compatible = "rpmsg-gpio";
>>>             reg = <32>;
>>>             gpio-controller;
>>>             #gpio-cells = <2>;
>>>             #interrupt-cells = <2>;
>>>             interrupt-controller;
>>>           };
>>>         };
>>>       };
>>>
>>>  rpmsg-io-25  would match with gpio@25
>>>  rpmsg-io-32  would match with gpio@32
>>>
>> The problem with this approach is, we will endup creating way too many
>> RPMsg devices/channels. i.e. one channel per one GPIO. That limits how
>> many GPIOs can be handled by remote from memory perspective. At
>> somepoint we might just run-out of number ept & channels created by the
>> remote. As of now, open-amp library supports 128 epts I think.
> 
> 
> Arnaud was suggesting one channel per gpio controller,
> not per line. We will not have 128 gpio controllers....
> 
>>
>>>> Because the endpoint that is created on a namespace request is also
>>>> dynamic in nature. How will the remote know which endpoint addr
>>>> Linux allocated for a namespace that it announced?
>>>>
>>>> As an example/PoC, I created a firmware example which announces
>>>> 2 name services to Linux, one is the standard "rpmsg_chrdev" and
>>>> the other is a TI specific name service "ti.ipc4.ping-pong". You can
>>>> see it created 2 different addresses (0x400 and 0x401) for each of
>>>> the name service request from the same firmware:
>>>>
>>>> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
>>>> [    9.290275] virtio_rpmsg_bus virtio0: creating channel
>>>> ti.ipc4.ping-pong addr 0xd
>>>> [    9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev
>>>> addr 0xe
>>>> [    9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel
>>>> formed from src = 0x400 to dst = 0xe
>>>> [    9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13:
>>>> new channel: 0x401 -> 0xd!
>>>>
>>>> So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
>>>> Back to same problem. Simple solution is to reply to remote with the
>>>> created ept addr and the index.
>>> That why I would like to suggest to use the name service field to
>>> identify the port/controller, instead of the endpoint address.
>>>>  
>>>>> - match the RPMsg probe with the DT,
>>>>
>>>> We can probe from all controllers with a single name service
>>>> announcement too.
>>>>
>>>>> - provide a simple mapping between the port and the endpoint on both
>>>>> sides,
>>>>
>>>> We are trying to get rid of this mapping from Linux side to adapt
>>>> the gpio-virtio design.
>>>>
>>>>> - allow multiple endpoints on the remote side,
>>>>
>>>> We can support this as well with single nameservice model.
>>>> There is no limitation. Remote has to send a message with
>>>> its newly created ept that's all.
>>>>
>>>>> - provide a simple discovery mechanism for remote capabilities.
>>>>
>>>> A single announcement: "rpmsg-io" is also discovery mechanism.
>>>>
>>>> Feel free to let me know if you have concerns with any of the
>>>> suggestions!
>>> My only concern, whatever the solution, is that we find a smart
>>> solution to associate the correct endpoint with the correct GPIO
>>> port/controller defined in the DT.
>>>
>>> I may have misunderstood your solution. Could you please help me
>>> understand your proposal by explaining how you would handle three
>>> GPIO ports defined in the DT, considering that the endpoint
>>> addresses on the Linux side can be random?
>>> If I assume there is a unique endpoint on the remote side,
>>> I do not understand how you can match, on the firmware side,
>>> the Linux endpoint address to the GPIO port.
>>>
>>> Thanks and Regards,Arnaud
>>>
>>>> Thanks,
>>>> Beleswar
>>>>
>>>>> Regards,
>>>>> Arnaud
>>>>>
>>>>>>> 2. namespace/channel#2 = rpmsg-i2c
>>>>>>>       a. ept1 -> i2c@1
>>>>>>>       b. ept2 -> i2c@2
>>>>>>>       c. ept3 -> i2c@3
>>>>>>>
>>>>>>> etc...
>>>>>>>
>> Just want to clear-up few terms before I jump to the solution:
>>
>> **RPMsg channel/device**:
>>   - These are devices announced by the remote processor, and created by
>> linux. They are created at: /sys/bus/rpmsg/devices
>>   - The channel format: <name>.<src ept>.<dst ept>
>>
>> **RPMsg endpoint**:
>>   - Endpoint is differnt than channel. Single channel can have multiple
>> endpoints, and represented in the linux with: /dev/rpmsg? devices.
>>
>> To create endpoint device, we have rpmsg_create_ept API, which takes
>> channel information as input, which has src-ept, dst-ept.
>>
>> Following is proposed solution:
>>
>> 1) Assign RPMsg channel/device per rpmsg-gpio controller (Not per GPIO
>> pin/port).
> 
> 
> One channel per pin was not suggested earlier...
> 
>>   - In our case that would be, single rpmsg-io node. (That makes me
>> question if bindings are correct or not).
>>
>> 2) Assign GPIO number as src ept.
>>
>> i.e. *rpmsg-io.<GPIO number>.<dst ept>*. Do not randomly assign src
>> endpoint.
>>
>> Now, RPMSG channel by spec reserves first 1024 endpoints [1], so we can
>> add 1024 offset to the GPIO number:
>>
>> so, when calling rpmsg_create_ept() API, we assing src_endpoint as:
>> (GPIO_NUMBER + RPMSG_RESERVED_ADDRESSES)
>>
>> Now on the remote side, there is single channel and only single-endpoint
>> is needed that is mapped to the rpmsg-io channel callback.
>>
>> That callback will receive all the payloads from the Linux, which will
>> have src-ept i.e. (RPMSG_RESERVED_ADDRESSES + GPIO_NUMBER).
>>
>> It can retrieve GPIO_NUMBER easily, and convert to appropriate pin based
>> on platform specific logic.
>>
>> This doesn't need PORT information at all. Also it makes sure that
>> remote is using only single-endpoint so not much memory is used.
>>
>> *Example*:
>> If only rpmsg-gpio channel is created by the remote side, than following
>> is the representation of the devices when GPIO 25, 26, 27 is assigned to
>> the rpmsg-io controller:
>>
>> Linux                                                      Remote
>>
>> rpmsg-channel: rpmsg-gpio.0x400.0x400
>>
>> /dev/rpmsg0 - GPIO25 ept (rpmsg-gpio.0x419.0x400)-|
>>                                                   |
>> /dev/rpmsg1 - GPIO26 ept (rpmsg-gpio.0x41a.0x400)-|-> rpmsg-gpio.*.0x400
>>                                                   |
>> /dev/rpmsg2 - GPIO27 ept (rpmsg-gpio.0x41b.0x400)-|  0x400 ept callback.
>>
>>
>> *On remote side*:
>>
>> ept_0x400_callback(..., int src_ept, ...,)
>> {
>> 	int gpio_num = src_ept - RPMSG_RESERVED_ADDRESSES;
>> 	// platform specific logic to convert gpio num to proper pin,
>> 	// just like you would convert gpio num to pin on a linux gpio controller.
>> }
>>
>> My question on the binding:
>>
>> Why each GPIO is represented with the separate node? I think rpmsg-gpio
>> can be represented just any other GPIO controller? Please let me know if
>> I am missing something.
> 
> 
> These are separate GPIO controllers, not separate pins within
> the same GPIO controller. Could you revisit your solution with
> this update.
> 
> Thanks for your time,
> Beleswar
> 

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

[Padhi, Beleswar]

On 5/5/2026 9:08 PM, Shah, Tanmay wrote:


[...]

>
>>>   If there are
>>> multiple or multiple instances of same controller, than we need separate
>>> channel name for that controller just like we would have separate device
>>> on the Linux.
>>
>> Why so? I think there is some confusion in the terminology:
>>
>> GPIO controller = GPIO port (gpio@xyz) defined in the
>> Device tree = struct rpmsg_gpio_port in code
>>
>> GPIO line = Individual lines within each GPIO port (max =
>> GPIOS_PER_PORT_DEFAULT) = struct rpmsg_gpio_line in code
>>
> Okay, I understand now. So, same gpio controller has multiple instances.
>
>>>>>>>> 1. namespace/channel#1 = rpmsg-io
>>>>>>>>        a. ept1 -> gpio-controller@1
>>>>>>>>        b. ept2 -> gpio-controller@2
> So, In that case above mentioned approach doesn't work.
>
> Because, this approach is mapping endpoint to the gpio-controller.


And what is the problem with that?

>   From
> linux's perspective, it needs to map rpmsg *channel* to the
> gpio-controller not the endpoint.


Can you explain why it *needs* to?

>
> To be more specific:
>
> Linux:                               remote:
>
> ch1: rpmsg-gpio.-1.1024 ->     gpio-controller@1024
>      - gpio-line ept1
>      - gpio-line ept2    ->     They all map to same callback_ept_1024.
>      - gpio-line ept3


This is a weird mapping. I am not suggesting one ept per gpio-line,
rather one per gpio-controller. You can refer my detailed proposal
here:

https://lore.kernel.org/all/268f8e00-91bc-43ea-ba95-077cf859e7f3@ti.com/

>
> ch2: rpmsg-gpio.-1.1025 ->     gpio-controller@1025
>      - gpio-line ept1
>      - gpio-line ept2    ->     They all map to same callback_ept_1025.
>      - gpio-line ept3


[...]

>
> On the remote side, we have to hardcode Which rpmsg controller is mapped
> to which endpoint.


Not necessarily, we can exchange this info at runtime.

Thanks,
Beleswar

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

[Mathieu Poirier]

On Thu, Apr 30, 2026 at 09:35:09AM +0200, Arnaud POULIQUEN wrote:
> Hello,
> 
> On 4/29/26 21:20, Mathieu Poirier wrote:
> > On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
> > > 
> > > Hi Mathieu,
> > > 
> > > On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
> > > > On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com> wrote:
> > > > > 
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Mathieu Poirier <mathieu.poirier@linaro.org>
> > > > > > Sent: Wednesday, April 29, 2026 10:42 AM
> > > > > > To: Shenwei Wang <shenwei.wang@nxp.com>
> > > > > > Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-padhi@ti.com>; Linus
> > > > > > Walleij <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
> > > > > > Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> > > > > > <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
> > > > > > <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
> > > > > > <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>; linux-
> > > > > > gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > > > > Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> > > > > > <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
> > > > > > devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
> > > > > > imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-
> > > > > > imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
> > > > > > Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> > > > > > On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
> > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Andrew Lunn <andrew@lunn.ch>
> > > > > > > > Sent: Monday, April 27, 2026 3:49 PM
> > > > > > > > To: Shenwei Wang <shenwei.wang@nxp.com>
> > > > > > > > Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
> > > > > > > > <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
> > > > > > > > Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
> > > > > > > > Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
> > > > > > > > Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
> > > > > > > > <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
> > > > > > > > Hauer <s.hauer@pengutronix.de>; Shuah Khan
> > > > > > > > <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
> > > > > > > > doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
> > > > > > > > Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> > > > > > > > <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
> > > > > > > > devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
> > > > > > > > imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
> > > > > > > > dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
> > > > > > > > <brgl@bgdev.pl>
> > > > > > > > Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
> > > > > > > > GPIO driver
> > > > > > > > > > struct virtio_gpio_response {
> > > > > > > > > >           __u8 status;
> > > > > > > > > >           __u8 value;
> > > > > > > > > > };
> > > > > > > > > It is the same message format. Please see the message definition
> > > > > > > > (GET_DIRECTION) below:
> > > > > > > > 
> > > > > > > > > +   +-----+-----+-----+-----+-----+----+
> > > > > > > > > +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> > > > > > > > > +   | 1   | 2   |port |line | err | dir|
> > > > > > > > > +   +-----+-----+-----+-----+-----+----+
> > > > > > > > Sorry, but i don't see how two u8 vs six u8 are the same message format.
> > > > > > > > 
> > > > > > > Some changes to the message format are necessary.
> > > > > > > 
> > > > > > > Virtio uses two communication channels (virtqueues): one for requests and
> > > > > > replies, and a second one for events.
> > > > > > > In contrast, rpmsg provides only a single communication channel, so a
> > > > > > > type field is required to distinguish between different kinds of messages.
> > > > > > > 
> > > > > > > Since rpmsg replies and events share the same message format, an additional
> > > > > > line is introduced to handle both cases.
> > > > > > > Finally, rpmsg supports multiple GPIO controllers, so a port field is added to
> > > > > > uniquely identify the target controller.
> > > > > > 
> > > > > > I have commented on this before - RPMSG is already providing multiplexing
> > > > > > capability by way of endpoints.  There is no need for a port field.  One endpoint,
> > > > > > one GPIO controller.
> > > > > > 
> > > > > You still need a way to let the remote side know which port the endpoint maps to, either
> > > > > by embedding the port information in the message (the current way), or by sending it
> > > > > separately.
> > > > > 
> > > > An endpoint is created with every namespace request.  There should be
> > > > one namespace request for every GPIO controller, which yields a unique
> > > > endpoint for each controller and eliminates the need for an extra
> > > > field to identify them.
> > > 
> > > 
> > > Right, but this can still be done by just having one namespace request.
> > > We can create new endpoints bound to an existing namespace/channel by
> > > invoking rpmsg_create_ept(). This is what I suggested here too:
> > > https://lore.kernel.org/all/29485742-6e49-482e-b73d-228295daaeec@ti.com/
> > > 
> > 
> > I will look at your suggestion (i.e link above) later this week or next week.
> > 
> > > My mental model looks like this for the complete picture:
> > > 
> > > 1. namespace/channel#1 = rpmsg-io
> > >      a. ept1 -> gpio-controller@1
> > >      b. ept2 -> gpio-controller@2
> > > 
> > 
> > I've asked for one endpoint per GPIO controller since the very
> > beginning.  I don't yet have a strong opinion on whether to use one
> > namespace request per GPIO controller or a single request that spins
> > off multiple endpoints.  I'll have to look at your link and reflect on
> > that.  Regardless of how we proceed on that front, multiplexing needs
> > to happen at the endpoint level rather than the packet level.  This is
> > the only way this work can move forward.
> > 
> 
> I would be more in favor of Mathieu’s proposal: “An endpoint is created with
> every namespace request.”
> 
> If the endpoint is created only on the Linux side, how do we match the Linux
> endpoint address with the local port field on the remote side?
> 
> With a multi-namespace approach, the namespace could be rpmsg-io-[addr],
> where [addr] corresponds to the GPIO controller address in the DT. This
> would:
> 
> - match the RPMsg probe with the DT,
> - provide a simple mapping between the port and the endpoint on both sides,
> - allow multiple endpoints on the remote side,
> - provide a simple discovery mechanism for remote capabilities.
>

This is exactly what I had in mind but I'll finish reading this thread before
expressing a final point of view.  That said, the namespace announcement should
be "rpmsg-gpio-[addr]" rather than "rpmsg-io-[addr]" to make sure there is no
ambiguity on the meaning of "io".

More comments to come...
 
> Regards,
> Arnaud
> 
> > > 2. namespace/channel#2 = rpmsg-i2c
> > >      a. ept1 -> i2c@1
> > >      b. ept2 -> i2c@2
> > >      c. ept3 -> i2c@3
> > > 
> > > etc...
> > > 
> > > This way device groups are isolated with each channel/namespace, and
> > > instances within each device groups are also respected with specific
> > > endpoints.
> > > 
> > > Thanks,
> > > Beleswar
> > > 
> > 
>