> -----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?
Thanks,
Shenwei
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> >>
> hub.co%2F&data=05%7C02%7Cshenwei.wang%40nxp.com%7C057bf7f0976749
> 5bcc3
> >>
> 108dea53e43f7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63912
> 98840
> >>
> 26686251%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiI
> wLjAu
> >>
> MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C
> %7C
> >>
> &sdata=iSxGWEvYSyu29loP9b1R2bw8bvwR7pbzQ7D%2FGeB%2BUYE%3D&reser
> ved=0
> >>
> 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().
> >>>>
