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

Wed Apr 29 11:57:39 PDT 2026

On 4/30/2026 12:05 AM, Shenwei Wang wrote:
>
>> -----Original Message-----
>> From: Padhi, Beleswar <b-padhi at ti.com>
>> Sent: Wednesday, April 29, 2026 1:07 PM
>> To: Mathieu Poirier <mathieu.poirier at linaro.org>; Shenwei Wang
>> <shenwei.wang at nxp.com>
>> Cc: Andrew Lunn <andrew at lunn.ch>; 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
>> 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%2Fall%2F29485742-6e49-482e-b73d-
>> 228295daaeec%40ti.com%2F&data=05%7C02%7Cshenwei.wang%40nxp.com%7
>> Caba62d7a899849fd57f708dea61a1d8b%7C686ea1d3bc2b4c6fa92cd99c5c3016
>> 35%7C0%7C0%7C639130828278097401%7CUnknown%7CTWFpbGZsb3d8eyJFb
>> XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb
>> CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NLLYQ0NZCnYKLT%2F2OMDZE
>> SKgC%2Fme3FoUNqqEGBOIY2k%3D&reserved=0
>>
>> 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
>>
> The GPIO nodes will act as providers.
> Mapping the port index into the service name is a possible solution,

I am not suggesting this. Infact the opposite. Let there be a single
rpmsg service "rpmsg-io" for gpio. And multiple endpoints within
the service, each for one controller. Once you have relayed this info
(dynamic ept addr corresponding to each port) back to the
firmware, you no longer need the "port" field in the message
anymore.

Did you get a chance to analyze this?:
https://lore.kernel.org/all/a067452a-9a8d-45ea-8bef-b44f851da7b2@ti.com/

Thanks,
Beleswar

>   but I don't believe it's better than
> embedding that information in the message. A stateless approach feels simpler and cleaner overall.
>
> Thanks,
> Shenwei
>
>
>> 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