On 4/28/2026 9:01 PM, Shenwei Wang wrote:
-----Original Message-----
From: Padhi, Beleswar <[email protected]>
Sent: Tuesday, April 28, 2026 10:11 AM
To: Shenwei Wang <[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]>
Cc: 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]>; Andrew Lunn <[email protected]>
Subject: Re: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO
driver
Caution: This is an external email. Please take care when clicking links or
opening
attachments. When in doubt, report the message using the 'Report this email'
button
On 4/28/2026 8:13 PM, Shenwei Wang wrote:
-----Original Message-----
From: Beleswar Prasad Padhi <[email protected]>
Sent: Tuesday, April 28, 2026 2:25 AM
To: Shenwei Wang <[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]>
Cc: 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]>; Andrew Lunn <[email protected]>
Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
GPIO driver On 28/04/26 00:53, Shenwei Wang wrote:
[...]
+ void *channel_devices[MAX_PORT_PER_CHANNEL];
So this is technically a rpmsg endpoint (struct rpmsg_endpoint)
without naming it "endpoint". Every rpmsg endpoint has a reference
to its parent rpmsg channel (struct rpmsg_device) which represents
the same information here. So we should use the framework standard here.
Yes, agree to use "endpoint_devices".
I did not mean to say to just change the variable name from
"channel_devices" to "endpoint_devices". Infact you would not need to
have this field & struct anymore.
Pseudo-code:
1. Add a 'struct rpmsg_endpoint *ept' field to struct rpmsg_gpio_port
to maintain the ept to port idx map.
2. Call port->ept = rpmsg_create_ept(rpdev,
rpmsg_gpio_channel_callback,
port,
{rpdev.id.name,
RPMSG_ADDR_ANY,
RPMSG_ADDR_ANY})
from rpmsg_gpiochip_register().
On the Linux side, we invoke rpmsg_create_ept. What is expected from the
remote system in this case?
Nothing extra in my opinion. rpmsg_create_ept() just creates a dynamic local
endpoint address for Linux's usage. The firmware just has to make sure to reply
to the same endpoint address where it received the message. This should already
be in place IMO, because currently you are sending all messages in the default
Since rpmsg_create_ept creates a new local endpoint address on the Linux side,
how is
the remote system expected to learn and use this new address for communication
if no
additional logic is added on the remote side?
Remote side learns the endpoint when it receives any message from Linux
from the dynamic endpoint.
Lets say rpmsg_create_ept() allocates a dynamic local ept of 1026. When
you send the message from this endpoint, the standard rpmsg header
would have:
85 struct rpmsg_hdr {
86 __rpmsg32 src; // 1026
87 __rpmsg32 dst; // rpdev->dst (e.g. 400)
88 __rpmsg32 reserved;
89 __rpmsg16 len;
90 __rpmsg16 flags;
91 u8 data[];
92 } __packed;
Remote side tracks the dynamic endpoint by reading src = 1026. And while
sending the response it fills the header as:
85 struct rpmsg_hdr {
86 __rpmsg32 src; // 400
87 __rpmsg32 dst; // 1026
88 __rpmsg32 reserved;
89 __rpmsg16 len;
90 __rpmsg16 flags;
91 u8 data[];
92 } __packed;
Note: Remote firmware can also send messages from dynamically created
endpoints on its side, and Linux can learn those in the same manner. The
dynamic endpoint address is passed to the callback as 'u32 src'. So you
could pass on the 'src' from rpmsg_gpio_channel_callback() to
rpmsg_gpio_send_message() as 'dst' and call
rpmsg_sendto(port->ept, msg, sizeof(*msg), dst) to reply to the dynamic
endpoint on firmware's side.
Thanks,
Beleswar
Is this handled automatically by the rpmsg stack software, or does it require
explicit support
on the remote system to exchange and track endpoint addresses?
Thanks,
Shenwei
endpoint (rpdev->ept) which is also dynamic[1] and is created when the channel
is created. And you receive the responses correctly. (Unless you have hard-coded
the default ept address in the firmware)
[1]:
https://github.co/
m%2Ftorvalds%2Flinux%2Fblob%2Fmaster%2Fdrivers%2Frpmsg%2Frpmsg_core.
c%23L480&data=05%7C02%7Cshenwei.wang%40nxp.com%7C4ec06bf01bb14dd
2625708dea5387471%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6
39129859078622527%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd
WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%
3D%7C0%7C%7C%7C&sdata=OUmjqOdWqiXSTjPDv1TUvrjKP1YTx9ji44SdGlIR2n
Q%3D&reserved=0
(chinfo.src is RPMSG_ADDR_ANY)
Thanks,
Beleswar
If the remote side does not need any extra support, this would be an excellent
solution.
Thanks,
Shenwei
3. Send msgs from local ept in rpmsg_gpio_send_message() by:
rpmsg_send(port->ept, msg, sizeof(*msg));
4. Get the port info in rpmsg_gpio_channel_callback() by:
struct rpmsg_gpio_port *port = priv;
Which also eliminates the need for struct rpdev_drvdata as you can
just do
rpmsg_get_rproc_node_name(rpdev) from rpmsg_gpiochip_register().
