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

[Shenwei Wang]

> -----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, 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