On 4/30/2026 12:05 AM, Shenwei Wang wrote:
-----Original Message-----
From: Padhi, Beleswar <[email protected]>
Sent: Wednesday, April 29, 2026 1:07 PM
To: Mathieu Poirier <[email protected]>; Shenwei Wang
<[email protected]>
Cc: Andrew Lunn <[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]>; [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
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%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@1
b. ept2 -> gpio-controller@2
2. namespace/channel#2 = rpmsg-i2c
a. ept1 -> i2c@1
b. ept2 -> i2c@2
c. ept3 -> i2c@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/[email protected]/
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
