On 4/28/2026 10:06 PM, Shenwei Wang wrote:
-----Original Message-----
From: Padhi, Beleswar <[email protected]>
Sent: Tuesday, April 28, 2026 10:53 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
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;
This explains how reply messages work in this scenario: the remote side can
simply send
the response back to the source address of the incoming message.
How does this work for notification messages initiated by the remote side?
Should the remote
system need to add additional logic to track the source address based on the
GPIO instance?
You should already have the tracking logic in firmware. How else are you
sending the notification messages from firmware with your current v13
implementation? Are you assuming the channel address to be always the
same? If so, this is a bug and should be fixed in firmware because the
address is generated dynamically. For example, if another core announces
its name service first, then the channel address for your core would be
different and the functionality would break.
Instead, you should have a map of ept to port idx in the firmware side
when you receive a message from Linux (just like we would maintain it
in struct rpmsg_gpio_port in Linux too).
Thanks,
Beleswar
[...]
