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

[Padhi, Beleswar]

Hi Mathieu,

On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang at nxp.com> wrote:
>>
>>
>>> -----Original Message-----
>>> From: Mathieu Poirier <mathieu.poirier at linaro.org>
>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>> To: Shenwei Wang <shenwei.wang at nxp.com>
>>> Cc: Andrew Lunn <andrew at lunn.ch>; Padhi, Beleswar <b-padhi at ti.com>; Linus
>>> Walleij <linusw at kernel.org>; Bartosz Golaszewski <brgl at kernel.org>; Jonathan
>>> Corbet <corbet at lwn.net>; Rob Herring <robh at kernel.org>; Krzysztof Kozlowski
>>> <krzk+dt at kernel.org>; Conor Dooley <conor+dt at kernel.org>; Bjorn Andersson
>>> <andersson at kernel.org>; Frank Li <frank.li at nxp.com>; Sascha Hauer
>>> <s.hauer at pengutronix.de>; Shuah Khan <skhan at linuxfoundation.org>; linux-
>>> gpio at vger.kernel.org; linux-doc at vger.kernel.org; linux-kernel at vger.kernel.org;
>>> Pengutronix Kernel Team <kernel at pengutronix.de>; Fabio Estevam
>>> <festevam at gmail.com>; Peng Fan <peng.fan at nxp.com>;
>>> devicetree at vger.kernel.org; linux-remoteproc at vger.kernel.org;
>>> imx at lists.linux.dev; linux-arm-kernel at lists.infradead.org; dl-linux-imx <linux-
>>> imx at nxp.com>; Bartosz Golaszewski <brgl at 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 at lunn.ch>
>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>> To: Shenwei Wang <shenwei.wang at nxp.com>
>>>>> Cc: Padhi, Beleswar <b-padhi at ti.com>; Linus Walleij
>>>>> <linusw at kernel.org>; Bartosz Golaszewski <brgl at kernel.org>; Jonathan
>>>>> Corbet <corbet at lwn.net>; Rob Herring <robh at kernel.org>; Krzysztof
>>>>> Kozlowski <krzk+dt at kernel.org>; Conor Dooley <conor+dt at kernel.org>;
>>>>> Bjorn Andersson <andersson at kernel.org>; Mathieu Poirier
>>>>> <mathieu.poirier at linaro.org>; Frank Li <frank.li at nxp.com>; Sascha
>>>>> Hauer <s.hauer at pengutronix.de>; Shuah Khan
>>>>> <skhan at linuxfoundation.org>; linux-gpio at vger.kernel.org; linux-
>>>>> doc at vger.kernel.org; linux-kernel at vger.kernel.org; Pengutronix
>>>>> Kernel Team <kernel at pengutronix.de>; Fabio Estevam
>>>>> <festevam at gmail.com>; Peng Fan <peng.fan at nxp.com>;
>>>>> devicetree at vger.kernel.org; linux- remoteproc at vger.kernel.org;
>>>>> imx at lists.linux.dev; linux-arm- kernel at lists.infradead.org;
>>>>> dl-linux-imx <linux-imx at nxp.com>; Bartosz Golaszewski
>>>>> <brgl at 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/

My mental model looks like this for the complete picture:

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

2. namespace/channel#2 = rpmsg-i2c
    a. ept1 -> i2c at 1
    b. ept2 -> i2c at 2
    c. ept3 -> i2c at 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