[PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver

[Shenwei Wang]

> -----Original Message-----
> From: Padhi, Beleswar <b-padhi at ti.com>
> Sent: Wednesday, April 29, 2026 9:36 AM
> To: Shenwei Wang <shenwei.wang at nxp.com>; Linus Walleij
> <linusw at kernel.org>; Bartosz Golaszewski <brgl at kernel.org>; Jonathan Corbet
> <corbet at lwn.net>; Rob Herring <robh at kernel.org>; Krzysztof Kozlowski
> <krzk+dt at kernel.org>; Conor Dooley <conor+dt at kernel.org>; Bjorn Andersson
> <andersson at kernel.org>; Mathieu Poirier <mathieu.poirier at linaro.org>; Frank Li
> <frank.li at nxp.com>; Sascha Hauer <s.hauer at pengutronix.de>
> Cc: Shuah Khan <skhan at linuxfoundation.org>; linux-gpio at vger.kernel.org; linux-
> doc at vger.kernel.org; linux-kernel at vger.kernel.org; Pengutronix Kernel Team
> <kernel at pengutronix.de>; Fabio Estevam <festevam at gmail.com>; Peng Fan
> <peng.fan at nxp.com>; devicetree at vger.kernel.org; linux-
> remoteproc at vger.kernel.org; imx at lists.linux.dev; linux-arm-
> kernel at lists.infradead.org; dl-linux-imx <linux-imx at nxp.com>; Bartosz
> Golaszewski <brgl at bgdev.pl>; Andrew Lunn <andrew at lunn.ch>
> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> On 4/28/2026 10:06 PM, Shenwei Wang wrote:
> >
> >> -----Original Message-----
> >> From: Padhi, Beleswar <b-padhi at ti.com>
> >> Sent: Tuesday, April 28, 2026 10:53 AM
> >> To: Shenwei Wang <shenwei.wang at nxp.com>; Linus Walleij
> >> <linusw at kernel.org>; Bartosz Golaszewski <brgl at kernel.org>; Jonathan
> >> Corbet <corbet at lwn.net>; Rob Herring <robh at kernel.org>; Krzysztof
> >> Kozlowski <krzk+dt at kernel.org>; Conor Dooley <conor+dt at kernel.org>;
> >> Bjorn Andersson <andersson at kernel.org>; Mathieu Poirier
> >> <mathieu.poirier at linaro.org>; Frank Li <frank.li at nxp.com>; Sascha
> >> Hauer <s.hauer at pengutronix.de>
> >> Cc: Shuah Khan <skhan at linuxfoundation.org>;
> >> linux-gpio at vger.kernel.org; linux- doc at vger.kernel.org;
> >> linux-kernel at vger.kernel.org; Pengutronix Kernel Team
> >> <kernel at pengutronix.de>; Fabio Estevam <festevam at gmail.com>; Peng Fan
> >> <peng.fan at nxp.com>; devicetree at vger.kernel.org; linux-
> >> remoteproc at vger.kernel.org; imx at lists.linux.dev; linux-arm-
> >> kernel at lists.infradead.org; dl-linux-imx <linux-imx at nxp.com>; Bartosz
> >> Golaszewski <brgl at bgdev.pl>; Andrew Lunn <andrew at lunn.ch>
> >> 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.
> 

In the v13 implementation, all GPIO instances share the default endpoint. As a result, the 
firmware does not need to track the port index, since the port index is embedded in each 
message.

With the new approach you proposed, we would create a separate endpoint for each GPIO 
controller. The GPIO controller information is derived from the corresponding DTS node, and 
the port index continues to be embedded in every message exchanged with the remote side, in 
accordance with the current message protocol.

However, in this model, the firmware still needs to add logic to track the mapping between the 
port index and the corresponding endpoint for notifications initiated by the remote side. Am I 
understanding this correctly?

Thanks,
Shenwei

> 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
> 
> [...]