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

From: Mathieu Poirier <[email-masked]>
Date: Tue, 5 May 2026 11:19:15 -0600

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 <[email-masked]> wrote:
> > > 
> > > Hi Mathieu,
> > > 
> > > On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
> > > > On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <[email-masked]> wrote:
> > > > > 
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Mathieu Poirier <[email-masked]>
> > > > > > Sent: Wednesday, April 29, 2026 10:42 AM
> > > > > > To: Shenwei Wang <[email-masked]>
> > > > > > Cc: Andrew Lunn <[email-masked]>; Padhi, Beleswar <[email-masked]>; Linus
> > > > > > Walleij <[email-masked]>; Bartosz Golaszewski <[email-masked]>; Jonathan
> > > > > > Corbet <[email-masked]>; Rob Herring <[email-masked]>; Krzysztof Kozlowski
> > > > > > <[email-masked]>; Conor Dooley <[email-masked]>; Bjorn Andersson
> > > > > > <[email-masked]>; Frank Li <[email-masked]>; Sascha Hauer
> > > > > > <[email-masked]>; Shuah Khan <[email-masked]>; linux-
> > > > > > [email-masked]; [email-masked]; [email-masked];
> > > > > > Pengutronix Kernel Team <[email-masked]>; Fabio Estevam
> > > > > > <[email-masked]>; Peng Fan <[email-masked]>;
> > > > > > [email-masked]; [email-masked];
> > > > > > [email-masked]; [email-masked]; dl-linux-imx <linux-
> > > > > > [email-masked]>; Bartosz Golaszewski <[email-masked]>
> > > > > > 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 <[email-masked]>
> > > > > > > > Sent: Monday, April 27, 2026 3:49 PM
> > > > > > > > To: Shenwei Wang <[email-masked]>
> > > > > > > > Cc: Padhi, Beleswar <[email-masked]>; Linus Walleij
> > > > > > > > <[email-masked]>; Bartosz Golaszewski <[email-masked]>; Jonathan
> > > > > > > > Corbet <[email-masked]>; Rob Herring <[email-masked]>; Krzysztof
> > > > > > > > Kozlowski <[email-masked]>; Conor Dooley <[email-masked]>;
> > > > > > > > Bjorn Andersson <[email-masked]>; Mathieu Poirier
> > > > > > > > <[email-masked]>; Frank Li <[email-masked]>; Sascha
> > > > > > > > Hauer <[email-masked]>; Shuah Khan
> > > > > > > > <[email-masked]>; [email-masked]; linux-
> > > > > > > > [email-masked]; [email-masked]; Pengutronix
> > > > > > > > Kernel Team <[email-masked]>; Fabio Estevam
> > > > > > > > <[email-masked]>; Peng Fan <[email-masked]>;
> > > > > > > > [email-masked]; linux- [email-masked];
> > > > > > > > [email-masked]; linux-arm- [email-masked];
> > > > > > > > dl-linux-imx <[email-masked]>; Bartosz Golaszewski
> > > > > > > > <[email-masked]>
> > > > > > > > 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/[email-masked]/
> > > 
> > 
> > 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
> > > 
> > 
>