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

[Shenwei Wang]

> -----Original Message-----
> From: Padhi, Beleswar <b-padhi at ti.com>
> Sent: Tuesday, April 28, 2026 10:11 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: 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 <b-padhi at ti.com>
> >> Sent: Tuesday, April 28, 2026 2:25 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 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?

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().
> >>