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

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

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/

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

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