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