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]/
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
