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

[Shah, Tanmay]

On 5/18/2026 9:24 AM, Shenwei Wang wrote:
> 
> 
>  
>>
>> On Thu, May 07, 2026 at 07:43:33PM +, Shenwei Wang wrote:
>>>
>>>
 That was my initial approach.  We don't even need an additional
 "rpmsg-io-*" in rpmsg_gpio_channel_id_table[].  All we need is:

 /* rpmsg devices and drivers are matched using the service name */
 static inline int rpmsg_id_match(const struct rpmsg_device *rpdev,
  const struct rpmsg_device_id *id) {
  + size_t len = strnlen(id->name, RPMSG_NAME_SIZE);

  - return strncmp(id->name, rpdev->id.name, RPMSG_NAME_SIZE) == 0;
  + return strncmp(id->name, rpdev->id.name, len) == 0;
 }

>>>
>>> If we encode the port index directly into ept->src, for example:
>>>
>>> ept->src = (baseaddr << 8) | port_index;
>>>
>>
>> There is no rpmsg_endpoint::src.  You likely meant ept->addr.  This would 
>> work
>> but not optimal on two front:
>>
>> (1) rpms_endpoint::addr is a u32 and idr_alloc() returns an 'int'.  As such 
>> there is a
>> possibility of conflict.  I concede the possibility is marginal, but it 
>> still exists.
>>
> 
> I think there may be a misunderstanding in the implementation. In this case, 
> we do not 
> need the return value from idr_alloc.
> 
> When the driver calls rpmsg_create_ept, it can pass an rpmsg_channel_info 
> structure as an
>  input parameter. This allows you to specify the source address you want to 
> bind.
> Please refer to the definitions below:
> 
> struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_device *rpdev,
>   rpmsg_rx_cb_t cb, void *priv,
>   struct rpmsg_channel_info chinfo)
> 
> struct rpmsg_channel_info {
>   char name[RPMSG_NAME_SIZE];
>   u32 src;
>   u32 dst;
> };
> 
>> (2) By proceeding this way, the kernel exposes the GPIO controller it knows
>> about.  It is preferrable to have the remote processor tell the kernel about 
>> the
>> GPIO controller it wants.
>>
> 
> If everyone agrees with this namespace announcement approach, I will prepare 
> the 
> next revision based on it, even though it is not as clean as the source 
> address encoding solution.
> 

I have ack on the namespace announcement approach. To me it is very
simple contract between the firmware and the Linux which allows dynamic
endpoint allocation without giving up security concerns. Also this
approach can be easily extended for any other rpmsg devices like i2c,
spi etc..  With the fix in the rpmsg_core.c, this will work. I will have
to see the actual implementation in the next rev to provide further
feedback.

Thanks,
Tanmay

> Shenwei
> 
>> I am done reviewing this revision.  Given the amount of refactoring needed, 
>> I will
>> not look at the code.  Please refer to this reply [1] for what I am 
>> expecting in the
>> next revision.
>>
> 

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

[Shenwei Wang]

 
> 
> On Thu, May 07, 2026 at 07:43:33PM +, Shenwei Wang wrote:
> >
> >
> > > That was my initial approach.  We don't even need an additional
> > > "rpmsg-io-*" in rpmsg_gpio_channel_id_table[].  All we need is:
> > >
> > > /* rpmsg devices and drivers are matched using the service name */
> > > static inline int rpmsg_id_match(const struct rpmsg_device *rpdev,
> > >  const struct rpmsg_device_id *id) {
> > >  + size_t len = strnlen(id->name, RPMSG_NAME_SIZE);
> > >
> > >  - return strncmp(id->name, rpdev->id.name, RPMSG_NAME_SIZE) == 0;
> > >  + return strncmp(id->name, rpdev->id.name, len) == 0;
> > > }
> > >
> >
> > If we encode the port index directly into ept->src, for example:
> >
> > ept->src = (baseaddr << 8) | port_index;
> >
> 
> There is no rpmsg_endpoint::src.  You likely meant ept->addr.  This would work
> but not optimal on two front:
> 
> (1) rpms_endpoint::addr is a u32 and idr_alloc() returns an 'int'.  As such 
> there is a
> possibility of conflict.  I concede the possibility is marginal, but it still 
> exists.
> 

I think there may be a misunderstanding in the implementation. In this case, we 
do not 
need the return value from idr_alloc.

When the driver calls rpmsg_create_ept, it can pass an rpmsg_channel_info 
structure as an
 input parameter. This allows you to specify the source address you want to 
bind.
Please refer to the definitions below:

struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_device *rpdev,
rpmsg_rx_cb_t cb, void *priv,
struct rpmsg_channel_info chinfo)

struct rpmsg_channel_info {
char name[RPMSG_NAME_SIZE];
u32 src;
u32 dst;
};

> (2) By proceeding this way, the kernel exposes the GPIO controller it knows
> about.  It is preferrable to have the remote processor tell the kernel about 
> the
> GPIO controller it wants.
> 

If everyone agrees with this namespace announcement approach, I will prepare 
the 
next revision based on it, even though it is not as clean as the source address 
encoding solution.

Shenwei

> I am done reviewing this revision.  Given the amount of refactoring needed, I 
> will
> not look at the code.  Please refer to this reply [1] for what I am expecting 
> in the
> next revision.
> 

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

[Padhi, Beleswar]

On 5/12/2026 8:51 PM, Mathieu Poirier wrote:

On Mon, 11 May 2026 at 12:18, Andrew Lunn  wrote:

Arnaud, Beleswar, Andrew and I are all advocating for one endpoint per
GPIO controller.  The remaining issue it about the best way to work
out source and destination addresses between Linux and the remote
processor.  I'm running out of time for today but I'll return to this
thread with a final analysis by the end of the week.

How many of the participants here will be in Minneapolis next week for
the Embedded Linux Conference? There is even a talk about this:

https://osselcna2026.sched.com/event/2JQpx/building-virtual-drivers-with-rpmsg-key-design-principles-challenges-trade-offs-beleswar-prasad-padhi-texas-instruments?iframe=yes&w=100%&sidebar=yes&bg=no

Maybe we can get together and decide on the final design after the
session.


I will not be in Minneapolis next week.  At this point I think things
are converging into 2 main takeaways:

1) A serious refactoring of the protocol to include only what is
available in the virtio-gpio specification [1].
2) The specification of GPIO controller number in an extension of the
namespace announcement [2].



Fair enough. I am also aligned to use this solution with the support for
wildcard name service matching.

Thanks,
Beleswar



Shenwei proposed embedding the GPIO controller number in the
endpoint's source address [3], something I'm ambivalent about and
still have to look into.  I also have to read Tanmay's latest
comments.  I'm hoping to be done with all that by the end of the week.
With the above (1) and (2), a new patchset will be required to reset
this thread.

Thanks,
Mathieu

[1]. https://lwn.net/ml/all/afjyH5JT0JS2j0L5@p14s/
[2]. https://lwn.net/ml/all/afzIABSh1xtMEGbf%40p14s/
[3]. 
https://lwn.net/ml/all/paxpr04mb9185bfa6e7375fad0b15b02189...@paxpr04mb9185.eurprd04.prod.outlook.com/


 Andrew

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

[Mathieu Poirier]

On Thu, May 07, 2026 at 07:43:33PM +, Shenwei Wang wrote:
> 
> 
> > -Original Message-
> > From: Mathieu Poirier 
> > Sent: Thursday, May 7, 2026 12:13 PM
> > To: Arnaud POULIQUEN 
> > Cc: Beleswar Prasad Padhi ; Shenwei Wang
> > ; Andrew Lunn ; Linus Walleij
> > ; Bartosz Golaszewski ; Jonathan Corbet
> > ; Rob Herring ; Krzysztof Kozlowski
> > ; Conor Dooley ; Bjorn Andersson
> > ; Frank Li ; Sascha Hauer
> > ; Shuah Khan ; linux-
> > g...@vger.kernel.org; linux-...@vger.kernel.org; 
> > linux-kernel@vger.kernel.org;
> > Pengutronix Kernel Team ; Fabio Estevam
> > ; Peng Fan ;
> > devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org;
> > i...@lists.linux.dev; linux-arm-ker...@lists.infradead.org; dl-linux-imx 
> >  > i...@nxp.com>; Bartosz Golaszewski 
> > Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO 
> > driver
> > > > >  From my perspective, based on your proposal:
> > > > >   1) Linux should send a get_config message to the remote proc (0x405 
> > > > > ->
> > 0xD). 2) The remote processor would respond with the list of ports, 
> > associated
> > > > >  with an remote endpoint addresses.
> > > >
> > > >
> > > > Agreed, we can scale it for multiple remote endpoints like this.
> > > >
> > > > >   3) Linux would parse the response, compare it with the DT, enable 
> > > > > the
> > GPIO
> > > > >  ports accordingly, creating it local endpoint and associating it 
> > > > > with
> > > > >  the remote endpoint.
> > > > > Using name service to identify the ports should avoid step 1 & 2 ...
> > > >
> > > >
> > > > Yes, but won't that make a lot of hard-codings in the driver?
> > > >
> > > > +static struct rpmsg_device_id rpmsg_gpio_channel_id_table[] = {
> > > > +{ .name = "rpmsg-io-25" },
> > > > +{ .name = "rpmsg-io-32" },
> > > > +{ .name = "rpmsg-io-35" },
> > > > +{ },
> > > > +};
> > > >
> > > > What if tomorrow another vendor decides to add more remoteproc
> > > > controlled GPIO ports to Linux, they would have to update this
> > > > struct in the driver everytime. And the port indexes (25/32/35)
> > > > could also differ between vendors. We should make the driver dynamic
> > > > i.e. vendor agnostic.
> > > >
> > > > I think querying the remote firmware at runtime (step 1 & 2 above)
> > > > is a common design pattern and makes the driver vendor agnostic. But
> > > > feel free to correct me.
> > > >
> > >
> > > You are right. My proposal would require a patch in rpmsg-core. The
> > > idea of allowing a postfix in the compatible string has been discussed
> > > before, but, if I remember correctly, it was not concluded.
> > >
> > 
> > I also remember discussing this.  I even reviewed one of Arnaud's patch and
> > submitted one myself.  This must have been in 2020 and the reason why it 
> > wasn't
> > merged has escaped my memory.
> > 
> > > /* rpmsg devices and drivers are matched using the service name */
> > > static inline int rpmsg_id_match(const struct rpmsg_device *rpdev,
> > > const struct rpmsg_device_id *id) {
> > >   size_t len;
> > >
> > > + len = strnlen(id->name, RPMSG_NAME_SIZE);
> > > + if (len && id->name[len - 1] == '*')
> > > + return !strncmp(id->name, rpdev->id.name, len - 1);
> > >
> > >   return strncmp(id->name, rpdev->id.name, RPMSG_NAME_SIZE) == 0;
> > > }
> > >
> > > Then, in rpmsg-gpio, and possibly in other drivers such as rpmsg-tty
> > > and a future rpmsg-i2c, we could use:
> > > static struct rpmsg_device_id rpmsg_gpio_channel_id_table[] = {
> > > { .name = "rpmsg-io" },
> > > { .name = "rpmsg-io-*" },
> > > { },
> > > };
> > 
> > That was my initial approach.  We don't even need an additional 
> > "rpmsg-io-*" in
> > rpmsg_gpio_channel_id_table[].  All we need is:
> > 
> > /* rpmsg devices and drivers are matched using the service name */ static 
> > inline
> > int rpmsg_id_match(const struct rpmsg_device *rpdev,
&

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

[Shah, Tanmay]

On 5/13/2026 11:34 AM, Mathieu Poirier wrote:
> On Tue, 12 May 2026 at 11:20, Shah, Tanmay  wrote:
>>
>>
>>
>> On 5/12/2026 10:41 AM, Mathieu Poirier wrote:
>>> On Mon, May 11, 2026 at 04:35:46PM -0500, Shah, Tanmay wrote:
>>>>
>>>>
>>>> On 5/11/2026 12:58 PM, Mathieu Poirier wrote:
>>>>> On Mon, 11 May 2026 at 10:47, Shah, Tanmay  wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 5/5/2026 10:52 AM, Shah, Tanmay wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 5/5/2026 4:28 AM, Arnaud POULIQUEN wrote:
>>>>>>>> Hi Tanmay,
>>>>>>>>
>>>>>>>> On 5/4/26 21:19, Shah, Tanmay wrote:
>>>>>>>>>
>>>>>>>>> Hello all,
>>>>>>>>>
>>>>>>>>> I have started reviewing this work as well.
>>>>>>>>> Thanks Shenwei for this work.
>>>>>>>>>
>>>>>>>>> I have gone through only the current revision, and would like to 
>>>>>>>>> provide
>>>>>>>>> idea on how to achieve GPIO number multiplexing with the RPMsg 
>>>>>>>>> protocol.
>>>>>>>>> Also, have some bindings related question.
>>>>>>>>>
>>>>>>>>> Please see below:
>>>>>>>>>
>>>>>>>>> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>>>>>>>>>>> Hello Arnaud,
>>>>>>>>>>>
>>>>>>>>>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>>>>>>>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar  
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Mathieu,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>>>>>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -Original Message-
>>>>>>>>>>>>>>>>> From: Mathieu Poirier 
>>>>>>>>>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>>>>>>>>>>>> To: Shenwei Wang 
>>>>>>>>>>>>>>>>> Cc: Andrew Lunn ; Padhi, Beleswar >>>>>>>>>>>>>>>> pa...@ti.com>; Linus
>>>>>>>>>>>>>>>>> Walleij ; Bartosz Golaszewski
>>>>>>>>>>>>>>>>> ; Jonathan
>>>>>>>>>>>>>>>>> Corbet ; Rob Herring ;
>>>>>>>>>>>>>>>>> Krzysztof Kozlowski
>>>>>>>>>>>>>>>>> ; Conor Dooley ; 
>>>>>>>>>>>>>>>>> Bjorn
>>>>>>>>>>>>>>>>> Andersson
>>>>>>>>>>>>>>>>> ; Frank Li ; Sascha 
>>>>>>>>>>>>>>>>> Hauer
>>>>>>>>>>>>>>>>> ; Shuah Khan
>>>>>>>>>>>>>>>>> ; linux-
>>>>>>>>>>>>>>>>> g...@vger.kernel.org; linux-...@vger.kernel.org; linux-
>>>>>>>>>>>>>>>>> ker...@vger.kernel.org;
>>>>>>>>>>>>>>>>> Pengutronix Kernel Team ; Fabio Estevam
>>>>>>>>>>>&g

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

[Mathieu Poirier]

On Tue, 12 May 2026 at 11:20, Shah, Tanmay  wrote:
>
>
>
> On 5/12/2026 10:41 AM, Mathieu Poirier wrote:
> > On Mon, May 11, 2026 at 04:35:46PM -0500, Shah, Tanmay wrote:
> >>
> >>
> >> On 5/11/2026 12:58 PM, Mathieu Poirier wrote:
> >>> On Mon, 11 May 2026 at 10:47, Shah, Tanmay  wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 5/5/2026 10:52 AM, Shah, Tanmay wrote:
> >>>>>
> >>>>>
> >>>>> On 5/5/2026 4:28 AM, Arnaud POULIQUEN wrote:
> >>>>>> Hi Tanmay,
> >>>>>>
> >>>>>> On 5/4/26 21:19, Shah, Tanmay wrote:
> >>>>>>>
> >>>>>>> Hello all,
> >>>>>>>
> >>>>>>> I have started reviewing this work as well.
> >>>>>>> Thanks Shenwei for this work.
> >>>>>>>
> >>>>>>> I have gone through only the current revision, and would like to 
> >>>>>>> provide
> >>>>>>> idea on how to achieve GPIO number multiplexing with the RPMsg 
> >>>>>>> protocol.
> >>>>>>> Also, have some bindings related question.
> >>>>>>>
> >>>>>>> Please see below:
> >>>>>>>
> >>>>>>> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
> >>>>>>>>> Hello Arnaud,
> >>>>>>>>>
> >>>>>>>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
> >>>>>>>>>> Hello,
> >>>>>>>>>>
> >>>>>>>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
> >>>>>>>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar  
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi Mathieu,
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
> >>>>>>>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang 
> >>>>>>>>>>>>> 
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -Original Message-
> >>>>>>>>>>>>>>> From: Mathieu Poirier 
> >>>>>>>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
> >>>>>>>>>>>>>>> To: Shenwei Wang 
> >>>>>>>>>>>>>>> Cc: Andrew Lunn ; Padhi, Beleswar  >>>>>>>>>>>>>>> pa...@ti.com>; Linus
> >>>>>>>>>>>>>>> Walleij ; Bartosz Golaszewski
> >>>>>>>>>>>>>>> ; Jonathan
> >>>>>>>>>>>>>>> Corbet ; Rob Herring ;
> >>>>>>>>>>>>>>> Krzysztof Kozlowski
> >>>>>>>>>>>>>>> ; Conor Dooley ; 
> >>>>>>>>>>>>>>> Bjorn
> >>>>>>>>>>>>>>> Andersson
> >>>>>>>>>>>>>>> ; Frank Li ; Sascha 
> >>>>>>>>>>>>>>> Hauer
> >>>>>>>>>>>>>>> ; Shuah Khan
> >>>>>>>>>>>>>>> ; linux-
> >>>>>>>>>>>>>>> g...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> >>>>>>>>>>>>>>> ker...@vger.kernel.org;
> >>>>>>>>>>>>>>> Pengutronix Kernel Team ; Fabio Estevam
> >>>>>>>>>>>>>>> ; Peng Fan ;
> >>>>>>>>>>>>>>> devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org;
> >>>>>>>>>>>>>>> i...@lists.linux.de

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

[Shah, Tanmay]

On 5/12/2026 10:41 AM, Mathieu Poirier wrote:
> On Mon, May 11, 2026 at 04:35:46PM -0500, Shah, Tanmay wrote:
>>
>>
>> On 5/11/2026 12:58 PM, Mathieu Poirier wrote:
>>> On Mon, 11 May 2026 at 10:47, Shah, Tanmay  wrote:
>>>>
>>>>
>>>>
>>>> On 5/5/2026 10:52 AM, Shah, Tanmay wrote:
>>>>>
>>>>>
>>>>> On 5/5/2026 4:28 AM, Arnaud POULIQUEN wrote:
>>>>>> Hi Tanmay,
>>>>>>
>>>>>> On 5/4/26 21:19, Shah, Tanmay wrote:
>>>>>>>
>>>>>>> Hello all,
>>>>>>>
>>>>>>> I have started reviewing this work as well.
>>>>>>> Thanks Shenwei for this work.
>>>>>>>
>>>>>>> I have gone through only the current revision, and would like to provide
>>>>>>> idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
>>>>>>> Also, have some bindings related question.
>>>>>>>
>>>>>>> Please see below:
>>>>>>>
>>>>>>> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>>>>>>>>> Hello Arnaud,
>>>>>>>>>
>>>>>>>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>>>>>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar  
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Mathieu,
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>>>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang 
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -Original Message-
>>>>>>>>>>>>>>> From: Mathieu Poirier 
>>>>>>>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>>>>>>>>>> To: Shenwei Wang 
>>>>>>>>>>>>>>> Cc: Andrew Lunn ; Padhi, Beleswar >>>>>>>>>>>>>> pa...@ti.com>; Linus
>>>>>>>>>>>>>>> Walleij ; Bartosz Golaszewski
>>>>>>>>>>>>>>> ; Jonathan
>>>>>>>>>>>>>>> Corbet ; Rob Herring ;
>>>>>>>>>>>>>>> Krzysztof Kozlowski
>>>>>>>>>>>>>>> ; Conor Dooley ; Bjorn
>>>>>>>>>>>>>>> Andersson
>>>>>>>>>>>>>>> ; Frank Li ; Sascha 
>>>>>>>>>>>>>>> Hauer
>>>>>>>>>>>>>>> ; Shuah Khan
>>>>>>>>>>>>>>> ; linux-
>>>>>>>>>>>>>>> g...@vger.kernel.org; linux-...@vger.kernel.org; linux-
>>>>>>>>>>>>>>> ker...@vger.kernel.org;
>>>>>>>>>>>>>>> Pengutronix Kernel Team ; Fabio Estevam
>>>>>>>>>>>>>>> ; Peng Fan ;
>>>>>>>>>>>>>>> devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org;
>>>>>>>>>>>>>>> i...@lists.linux.dev; linux-arm-ker...@lists.infradead.org; dl-
>>>>>>>>>>>>>>> linux-imx >>>>>>>>>>>>>> i...@nxp.com>; Bartosz Golaszewski 
>>>>>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>>>>>>>> rpmsg GPIO driver
>>>>>>>>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +, Shenwei Wang wrote:
>>>>>>>>>>>>>>>>
>>&

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

[Mathieu Poirier]

On Mon, 11 May 2026 at 12:18, Andrew Lunn  wrote:
>
> > Arnaud, Beleswar, Andrew and I are all advocating for one endpoint per
> > GPIO controller.  The remaining issue it about the best way to work
> > out source and destination addresses between Linux and the remote
> > processor.  I'm running out of time for today but I'll return to this
> > thread with a final analysis by the end of the week.
>
> How many of the participants here will be in Minneapolis next week for
> the Embedded Linux Conference? There is even a talk about this:
>
> https://osselcna2026.sched.com/event/2JQpx/building-virtual-drivers-with-rpmsg-key-design-principles-challenges-trade-offs-beleswar-prasad-padhi-texas-instruments?iframe=yes&w=100%&sidebar=yes&bg=no
>
> Maybe we can get together and decide on the final design after the
> session.
>

I will not be in Minneapolis next week.  At this point I think things
are converging into 2 main takeaways:

1) A serious refactoring of the protocol to include only what is
available in the virtio-gpio specification [1].
2) The specification of GPIO controller number in an extension of the
namespace announcement [2].

Shenwei proposed embedding the GPIO controller number in the
endpoint's source address [3], something I'm ambivalent about and
still have to look into.  I also have to read Tanmay's latest
comments.  I'm hoping to be done with all that by the end of the week.
With the above (1) and (2), a new patchset will be required to reset
this thread.

Thanks,
Mathieu

[1]. https://lwn.net/ml/all/afjyH5JT0JS2j0L5@p14s/
[2]. https://lwn.net/ml/all/afzIABSh1xtMEGbf%40p14s/
[3]. 
https://lwn.net/ml/all/paxpr04mb9185bfa6e7375fad0b15b02189...@paxpr04mb9185.eurprd04.prod.outlook.com/

> Andrew

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

[Mathieu Poirier]

On Mon, May 11, 2026 at 04:35:46PM -0500, Shah, Tanmay wrote:
> 
> 
> On 5/11/2026 12:58 PM, Mathieu Poirier wrote:
> > On Mon, 11 May 2026 at 10:47, Shah, Tanmay  wrote:
> >>
> >>
> >>
> >> On 5/5/2026 10:52 AM, Shah, Tanmay wrote:
> >>>
> >>>
> >>> On 5/5/2026 4:28 AM, Arnaud POULIQUEN wrote:
> >>>> Hi Tanmay,
> >>>>
> >>>> On 5/4/26 21:19, Shah, Tanmay wrote:
> >>>>>
> >>>>> Hello all,
> >>>>>
> >>>>> I have started reviewing this work as well.
> >>>>> Thanks Shenwei for this work.
> >>>>>
> >>>>> I have gone through only the current revision, and would like to provide
> >>>>> idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
> >>>>> Also, have some bindings related question.
> >>>>>
> >>>>> Please see below:
> >>>>>
> >>>>> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
> >>>>>>
> >>>>>>
> >>>>>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
> >>>>>>> Hello Arnaud,
> >>>>>>>
> >>>>>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
> >>>>>>>> Hello,
> >>>>>>>>
> >>>>>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
> >>>>>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar  
> >>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Hi Mathieu,
> >>>>>>>>>>
> >>>>>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
> >>>>>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang 
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> -Original Message-
> >>>>>>>>>>>>> From: Mathieu Poirier 
> >>>>>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
> >>>>>>>>>>>>> To: Shenwei Wang 
> >>>>>>>>>>>>> Cc: Andrew Lunn ; Padhi, Beleswar  >>>>>>>>>>>>> pa...@ti.com>; Linus
> >>>>>>>>>>>>> Walleij ; Bartosz Golaszewski
> >>>>>>>>>>>>> ; Jonathan
> >>>>>>>>>>>>> Corbet ; Rob Herring ;
> >>>>>>>>>>>>> Krzysztof Kozlowski
> >>>>>>>>>>>>> ; Conor Dooley ; Bjorn
> >>>>>>>>>>>>> Andersson
> >>>>>>>>>>>>> ; Frank Li ; Sascha 
> >>>>>>>>>>>>> Hauer
> >>>>>>>>>>>>> ; Shuah Khan
> >>>>>>>>>>>>> ; linux-
> >>>>>>>>>>>>> g...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> >>>>>>>>>>>>> ker...@vger.kernel.org;
> >>>>>>>>>>>>> Pengutronix Kernel Team ; Fabio Estevam
> >>>>>>>>>>>>> ; Peng Fan ;
> >>>>>>>>>>>>> devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org;
> >>>>>>>>>>>>> i...@lists.linux.dev; linux-arm-ker...@lists.infradead.org; dl-
> >>>>>>>>>>>>> linux-imx  >>>>>>>>>>>>> i...@nxp.com>; Bartosz Golaszewski 
> >>>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
> >>>>>>>>>>>>> rpmsg GPIO driver
> >>>>>>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +, Shenwei Wang wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -Original Message-
> >>>>>>>>>>>>>>> From: Andrew Lunn 
> >>>>>>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
> >>>>>>>>>&

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

[Arnaud POULIQUEN]

Hello Andrew,

On 5/11/26 20:18, Andrew Lunn wrote:

Arnaud, Beleswar, Andrew and I are all advocating for one endpoint per
GPIO controller.  The remaining issue it about the best way to work
out source and destination addresses between Linux and the remote
processor.  I'm running out of time for today but I'll return to this
thread with a final analysis by the end of the week.


How many of the participants here will be in Minneapolis next week for
the Embedded Linux Conference? There is even a talk about this:

https://osselcna2026.sched.com/event/2JQpx/building-virtual-drivers-with-rpmsg-key-design-principles-challenges-trade-offs-beleswar-prasad-padhi-texas-instruments?iframe=yes&w=100%&sidebar=yes&bg=no

Maybe we can get together and decide on the final design after the
session.


I won’t be there, but I can join remotely if a call is scheduled,

Regards,
Arnaud



Andrew

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

[Shah, Tanmay]

On 5/11/2026 12:58 PM, Mathieu Poirier wrote:
> On Mon, 11 May 2026 at 10:47, Shah, Tanmay  wrote:
>>
>>
>>
>> On 5/5/2026 10:52 AM, Shah, Tanmay wrote:
>>>
>>>
>>> On 5/5/2026 4:28 AM, Arnaud POULIQUEN wrote:
>>>> Hi Tanmay,
>>>>
>>>> On 5/4/26 21:19, Shah, Tanmay wrote:
>>>>>
>>>>> Hello all,
>>>>>
>>>>> I have started reviewing this work as well.
>>>>> Thanks Shenwei for this work.
>>>>>
>>>>> I have gone through only the current revision, and would like to provide
>>>>> idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
>>>>> Also, have some bindings related question.
>>>>>
>>>>> Please see below:
>>>>>
>>>>> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
>>>>>>
>>>>>>
>>>>>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>>>>>>> Hello Arnaud,
>>>>>>>
>>>>>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>>>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar  wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Mathieu,
>>>>>>>>>>
>>>>>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang 
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> -Original Message-
>>>>>>>>>>>>> From: Mathieu Poirier 
>>>>>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>>>>>>>> To: Shenwei Wang 
>>>>>>>>>>>>> Cc: Andrew Lunn ; Padhi, Beleswar >>>>>>>>>>>> pa...@ti.com>; Linus
>>>>>>>>>>>>> Walleij ; Bartosz Golaszewski
>>>>>>>>>>>>> ; Jonathan
>>>>>>>>>>>>> Corbet ; Rob Herring ;
>>>>>>>>>>>>> Krzysztof Kozlowski
>>>>>>>>>>>>> ; Conor Dooley ; Bjorn
>>>>>>>>>>>>> Andersson
>>>>>>>>>>>>> ; Frank Li ; Sascha Hauer
>>>>>>>>>>>>> ; Shuah Khan
>>>>>>>>>>>>> ; linux-
>>>>>>>>>>>>> g...@vger.kernel.org; linux-...@vger.kernel.org; linux-
>>>>>>>>>>>>> ker...@vger.kernel.org;
>>>>>>>>>>>>> Pengutronix Kernel Team ; Fabio Estevam
>>>>>>>>>>>>> ; Peng Fan ;
>>>>>>>>>>>>> devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org;
>>>>>>>>>>>>> i...@lists.linux.dev; linux-arm-ker...@lists.infradead.org; dl-
>>>>>>>>>>>>> linux-imx >>>>>>>>>>>> i...@nxp.com>; Bartosz Golaszewski 
>>>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>>>>>> rpmsg GPIO driver
>>>>>>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +, Shenwei Wang wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -Original Message-
>>>>>>>>>>>>>>> From: Andrew Lunn 
>>>>>>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>>>>>>>>> To: Shenwei Wang 
>>>>>>>>>>>>>>> Cc: Padhi, Beleswar ; Linus Walleij
>>>>>>>>>>>>>>> ; Bartosz Golaszewski ;
>>>>>>>>>>>>>>> Jonathan
>>>>>>>>>>>>>>> Corbet ; Rob Herring ;
>>>>>>>>>>>>>>> Krzysztof
>>>>>>>>>>>>>>> Kozlowski ; Conor Dooley
>

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

[Andrew Lunn]

> Arnaud, Beleswar, Andrew and I are all advocating for one endpoint per
> GPIO controller.  The remaining issue it about the best way to work
> out source and destination addresses between Linux and the remote
> processor.  I'm running out of time for today but I'll return to this
> thread with a final analysis by the end of the week.

How many of the participants here will be in Minneapolis next week for
the Embedded Linux Conference? There is even a talk about this:

https://osselcna2026.sched.com/event/2JQpx/building-virtual-drivers-with-rpmsg-key-design-principles-challenges-trade-offs-beleswar-prasad-padhi-texas-instruments?iframe=yes&w=100%&sidebar=yes&bg=no

Maybe we can get together and decide on the final design after the
session.

Andrew

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

[Mathieu Poirier]

On Mon, 11 May 2026 at 10:47, Shah, Tanmay  wrote:
>
>
>
> On 5/5/2026 10:52 AM, Shah, Tanmay wrote:
> >
> >
> > On 5/5/2026 4:28 AM, Arnaud POULIQUEN wrote:
> >> Hi Tanmay,
> >>
> >> On 5/4/26 21:19, Shah, Tanmay wrote:
> >>>
> >>> Hello all,
> >>>
> >>> I have started reviewing this work as well.
> >>> Thanks Shenwei for this work.
> >>>
> >>> I have gone through only the current revision, and would like to provide
> >>> idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
> >>> Also, have some bindings related question.
> >>>
> >>> Please see below:
> >>>
> >>> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
> >>>>
> >>>>
> >>>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
> >>>>> Hello Arnaud,
> >>>>>
> >>>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
> >>>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar  wrote:
> >>>>>>>>
> >>>>>>>> Hi Mathieu,
> >>>>>>>>
> >>>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
> >>>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang 
> >>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> -Original Message-
> >>>>>>>>>>> From: Mathieu Poirier 
> >>>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
> >>>>>>>>>>> To: Shenwei Wang 
> >>>>>>>>>>> Cc: Andrew Lunn ; Padhi, Beleswar  >>>>>>>>>>> pa...@ti.com>; Linus
> >>>>>>>>>>> Walleij ; Bartosz Golaszewski
> >>>>>>>>>>> ; Jonathan
> >>>>>>>>>>> Corbet ; Rob Herring ;
> >>>>>>>>>>> Krzysztof Kozlowski
> >>>>>>>>>>> ; Conor Dooley ; Bjorn
> >>>>>>>>>>> Andersson
> >>>>>>>>>>> ; Frank Li ; Sascha Hauer
> >>>>>>>>>>> ; Shuah Khan
> >>>>>>>>>>> ; linux-
> >>>>>>>>>>> g...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> >>>>>>>>>>> ker...@vger.kernel.org;
> >>>>>>>>>>> Pengutronix Kernel Team ; Fabio Estevam
> >>>>>>>>>>> ; Peng Fan ;
> >>>>>>>>>>> devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org;
> >>>>>>>>>>> i...@lists.linux.dev; linux-arm-ker...@lists.infradead.org; dl-
> >>>>>>>>>>> linux-imx  >>>>>>>>>>> i...@nxp.com>; Bartosz Golaszewski 
> >>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
> >>>>>>>>>>> rpmsg GPIO driver
> >>>>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +, Shenwei Wang wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> -Original Message-
> >>>>>>>>>>>>> From: Andrew Lunn 
> >>>>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
> >>>>>>>>>>>>> To: Shenwei Wang 
> >>>>>>>>>>>>> Cc: Padhi, Beleswar ; Linus Walleij
> >>>>>>>>>>>>> ; Bartosz Golaszewski ;
> >>>>>>>>>>>>> Jonathan
> >>>>>>>>>>>>> Corbet ; Rob Herring ;
> >>>>>>>>>>>>> Krzysztof
> >>>>>>>>>>>>> Kozlowski ; Conor Dooley
> >>>>>>>>>>>>> ;
> >>>>>>>>>>>>> Bjorn Andersson ; Mathieu Poirier
> >>>>>>>>>>>>> ; Frank Li ;
> >>>>>>>>>>>>> Sascha
> >&g

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

[Shah, Tanmay]

On 5/5/2026 10:52 AM, Shah, Tanmay wrote:
> 
> 
> On 5/5/2026 4:28 AM, Arnaud POULIQUEN wrote:
>> Hi Tanmay,
>>
>> On 5/4/26 21:19, Shah, Tanmay wrote:
>>>
>>> Hello all,
>>>
>>> I have started reviewing this work as well.
>>> Thanks Shenwei for this work.
>>>
>>> I have gone through only the current revision, and would like to provide
>>> idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
>>> Also, have some bindings related question.
>>>
>>> Please see below:
>>>
>>> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
>>>>
>>>>
>>>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>>>>> Hello Arnaud,
>>>>>
>>>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>>>>> Hello,
>>>>>>
>>>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar  wrote:
>>>>>>>>
>>>>>>>> Hi Mathieu,
>>>>>>>>
>>>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang 
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -Original Message-
>>>>>>>>>>> From: Mathieu Poirier 
>>>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>>>>>> To: Shenwei Wang 
>>>>>>>>>>> Cc: Andrew Lunn ; Padhi, Beleswar >>>>>>>>>> pa...@ti.com>; Linus
>>>>>>>>>>> Walleij ; Bartosz Golaszewski
>>>>>>>>>>> ; Jonathan
>>>>>>>>>>> Corbet ; Rob Herring ;
>>>>>>>>>>> Krzysztof Kozlowski
>>>>>>>>>>> ; Conor Dooley ; Bjorn
>>>>>>>>>>> Andersson
>>>>>>>>>>> ; Frank Li ; Sascha Hauer
>>>>>>>>>>> ; Shuah Khan
>>>>>>>>>>> ; linux-
>>>>>>>>>>> g...@vger.kernel.org; linux-...@vger.kernel.org; linux-
>>>>>>>>>>> ker...@vger.kernel.org;
>>>>>>>>>>> Pengutronix Kernel Team ; Fabio Estevam
>>>>>>>>>>> ; Peng Fan ;
>>>>>>>>>>> devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org;
>>>>>>>>>>> i...@lists.linux.dev; linux-arm-ker...@lists.infradead.org; dl-
>>>>>>>>>>> linux-imx >>>>>>>>>> i...@nxp.com>; Bartosz Golaszewski 
>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>>>> rpmsg GPIO driver
>>>>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +, Shenwei Wang wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> -Original Message-
>>>>>>>>>>>>> From: Andrew Lunn 
>>>>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>>>>>>> To: Shenwei Wang 
>>>>>>>>>>>>> Cc: Padhi, Beleswar ; Linus Walleij
>>>>>>>>>>>>> ; Bartosz Golaszewski ;
>>>>>>>>>>>>> Jonathan
>>>>>>>>>>>>> Corbet ; Rob Herring ;
>>>>>>>>>>>>> Krzysztof
>>>>>>>>>>>>> Kozlowski ; Conor Dooley
>>>>>>>>>>>>> ;
>>>>>>>>>>>>> Bjorn Andersson ; Mathieu Poirier
>>>>>>>>>>>>> ; Frank Li ;
>>>>>>>>>>>>> Sascha
>>>>>>>>>>>>> Hauer ; Shuah Khan
>>>>>>>>>>>>> ; linux-g...@vger.kernel.org; linux-
>>>>>>>>>>>>> d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>>>>>>> Kernel Team ; Fabio Estevam
>>>>>>>>>>>>> ; Peng Fan ;
>>>>>>>>>>

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

[Arnaud POULIQUEN]

Hello Mathieu,

[...]


A third option would be a combination of both approaches: instantiate the
device using the same name service from the remote side, as done in
rpmsg-tty. In that case, a get_config message, or a similar mechanism, would
also be needed to retrieve the port information from the remote side.



I'm not overly fond of a get_config message because it is one more thing we
have to define and maintain.

Arnaud: is there a get_config message already defined for rpmsg_tty?


No there isn't.

Regards,
Arnaud



Beleswar: Can you provide a link to a virtio device that would use a get_config
message?
  

Tanmaya also proposed another alternative based on reserved addresses.

At this point, I suggest letting Mathieu review the discussion and recommend
the most suitable approach.

Thanks,
Arnaud



At the end, whatever solution is implemented, my main concern is that the
Linux driver design should, if possible, avoid adding unnecessary complexity
or limitations on the remote side (for instance in openAMP project).



Yes definitely, I want the same. Feel free to let me know if this does
not suit with the OpenAMP project.

Thanks,
Beleswar



Thanks,
Arnaud



So Linux does not need to send the port idx everytime while sending a
gpio message anymore.

Thanks,
Beleswar

[...]

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

[Padhi, Beleswar]

Hi Mathieu,

On 5/7/2026 10:42 PM, Mathieu Poirier wrote:

On Tue, May 05, 2026 at 10:46:11AM +0200, Arnaud POULIQUEN wrote:

Hi Beleswar

On 5/5/26 07:25, Beleswar Prasad Padhi wrote:

Hi Arnaud,

On 04/05/26 22:34, Arnaud POULIQUEN wrote:

Hi Beleswar,

On 5/4/26 10:17, Beleswar Prasad Padhi wrote:


[...]


I may have misunderstood your solution. Could you please help me
understand your proposal by explaining how you would handle three
GPIO ports defined in the DT, considering that the endpoint
addresses on the Linux side can be random?
If I assume there is a unique endpoint on the remote side,
I do not understand how you can match, on the firmware side,
the Linux endpoint address to the GPIO port.


Sure, let me take an example:
Assumptions: 3 GPIO ports in DT, 3 endpoints in Linux (one per port),
1 endpoint in remote (0xd) and 1 rpmsg channel (rpmsg-io)

          rpmsg {
            rpmsg-io {
              #address-cells = <1>;
              #size-cells = <0>;

              gpio@25 {
                compatible = "rpmsg-gpio";
                reg = <25>;
                gpio-controller;
                #gpio-cells = <2>;
                #interrupt-cells = <2>;
                interrupt-controller;
              };

              gpio@32 {
                compatible = "rpmsg-gpio";
                reg = <32>;
                gpio-controller;
                #gpio-cells = <2>;
                #interrupt-cells = <2>;
                interrupt-controller;
              };

              gpio@35 {
                compatible = "rpmsg-gpio";
                reg = <35>;
                gpio-controller;
                #gpio-cells = <2>;
                #interrupt-cells = <2>;
                interrupt-controller;
              };
            };
          };

Code Flow:
1. "rpmsg-io" channel is announced from remote firmware with unique dst
       ept = 0xd.

2. rpmsg_core.c creates the default dynamic local ept for the channel
       ept = 0x405.

3. rpmsg_core.c assigns the allocated addr to rpdev device:
       rpdev->src = 0x405 and rpdev->dst = 0xd.

4. rpmsg_gpio_channel_probe() is triggered. For *each* of the GPIO ports
       in DT, it will trigger rpmsg_gpiochip_register() which will now:
          a. Call port->ept = rpmsg_create_ept(rpdev,
                                                                      
rpmsg_gpio_channel_callback,
                                                                      port,
                                                                     
{rpdev.id.name,
                                                                      
RPMSG_ADDR_ANY,
                                                                      
RPMSG_ADDR_ANY});
              Ex- port->ept->addr = 0x408

          b. Prepare a 8-byte message having 2 fields:
              port->ept->addr (0x408) and port->idx (25)

          c. Send this message to remote firmware on default channel ept
              (0x405 -> 0xd) by:
              rpmsg_send(rpdev->ept, &message, sizeof(message));

          d. Remote side receives this message and creates a map of the
              linux_ept_addr to gpio_port. (0x408 <-> 25)

5. After this point, any gpio messages sent from Linux from gpio port
       endpoints (Ex- 0x408) can be decoded at remote side by looking up
       its map (Ex- map[0x408] = 25).

6. Any messages sent from remote to Linux for a particular gpio port can
       also be decoded at Linux by simply fetching the priv pointer to get
       the per-port device:
       struct rpmsg_gpio_port *port = priv;


Thanks for the details!

To sum up:
- the default endpoint acts as the GPIO controller (0x405),
- one extra Linux endpoint is created per port defined in DT.

This should work, but my concerns remain the same:

    1) This implementation forces the remote processor to handle a single
   endpoint instead of one endpoint per port. This may add complexity to
   the remote firmware if each port is managed in a separate thread.


A. Not really, I just chose 1 remote endpoint for this example as you
      suggested to. We can scale it for two-way communication via the
      get_config message like you suggested below.

B. Isn't it a bad design of the firmware if it is handling 10 gpio ports
      in 10 threads? The logic to handle all the ports is the same, only
      the parameters (e.g. line number, msg) is different.


    2) Linux, as a consumer, should not expose its capabilities to the remote
   side (in your proposal it enumerates the ports defined in the DT).     
In my view, the remote processor should expose its capabilities as the
   provider.


Agreed on this.


  From my perspective, based on your proposal:
   1) Linux should send a get_config message to the remote proc (0x405 -> 0xD). 
2) The remote processor would respond with the list of ports, associated
      with an remote endpoint addresses.


Agreed, we can scale it for multiple remote endpoints like this

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

[Shenwei Wang]

> -Original Message-
> From: Mathieu Poirier 
> Sent: Thursday, May 7, 2026 12:13 PM
> To: Arnaud POULIQUEN 
> Cc: Beleswar Prasad Padhi ; Shenwei Wang
> ; Andrew Lunn ; Linus Walleij
> ; Bartosz Golaszewski ; Jonathan Corbet
> ; Rob Herring ; Krzysztof Kozlowski
> ; Conor Dooley ; Bjorn Andersson
> ; Frank Li ; Sascha Hauer
> ; Shuah Khan ; linux-
> g...@vger.kernel.org; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Pengutronix Kernel Team ; Fabio Estevam
> ; Peng Fan ;
> devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org;
> i...@lists.linux.dev; linux-arm-ker...@lists.infradead.org; dl-linux-imx 
>  i...@nxp.com>; Bartosz Golaszewski 
> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> > > >  From my perspective, based on your proposal:
> > > >   1) Linux should send a get_config message to the remote proc (0x405 ->
> 0xD). 2) The remote processor would respond with the list of ports, associated
> > > >  with an remote endpoint addresses.
> > >
> > >
> > > Agreed, we can scale it for multiple remote endpoints like this.
> > >
> > > >   3) Linux would parse the response, compare it with the DT, enable the
> GPIO
> > > >  ports accordingly, creating it local endpoint and associating it 
> > > > with
> > > >  the remote endpoint.
> > > > Using name service to identify the ports should avoid step 1 & 2 ...
> > >
> > >
> > > Yes, but won't that make a lot of hard-codings in the driver?
> > >
> > > +static struct rpmsg_device_id rpmsg_gpio_channel_id_table[] = {
> > > +{ .name = "rpmsg-io-25" },
> > > +{ .name = "rpmsg-io-32" },
> > > +{ .name = "rpmsg-io-35" },
> > > +{ },
> > > +};
> > >
> > > What if tomorrow another vendor decides to add more remoteproc
> > > controlled GPIO ports to Linux, they would have to update this
> > > struct in the driver everytime. And the port indexes (25/32/35)
> > > could also differ between vendors. We should make the driver dynamic
> > > i.e. vendor agnostic.
> > >
> > > I think querying the remote firmware at runtime (step 1 & 2 above)
> > > is a common design pattern and makes the driver vendor agnostic. But
> > > feel free to correct me.
> > >
> >
> > You are right. My proposal would require a patch in rpmsg-core. The
> > idea of allowing a postfix in the compatible string has been discussed
> > before, but, if I remember correctly, it was not concluded.
> >
> 
> I also remember discussing this.  I even reviewed one of Arnaud's patch and
> submitted one myself.  This must have been in 2020 and the reason why it 
> wasn't
> merged has escaped my memory.
> 
> > /* rpmsg devices and drivers are matched using the service name */
> > static inline int rpmsg_id_match(const struct rpmsg_device *rpdev,
> > const struct rpmsg_device_id *id) {
> >   size_t len;
> >
> > + len = strnlen(id->name, RPMSG_NAME_SIZE);
> > + if (len && id->name[len - 1] == '*')
> > + return !strncmp(id->name, rpdev->id.name, len - 1);
> >
> >   return strncmp(id->name, rpdev->id.name, RPMSG_NAME_SIZE) == 0;
> > }
> >
> > Then, in rpmsg-gpio, and possibly in other drivers such as rpmsg-tty
> > and a future rpmsg-i2c, we could use:
> > static struct rpmsg_device_id rpmsg_gpio_channel_id_table[] = {
> > { .name = "rpmsg-io" },
> > { .name = "rpmsg-io-*" },
> > { },
> > };
> 
> That was my initial approach.  We don't even need an additional "rpmsg-io-*" 
> in
> rpmsg_gpio_channel_id_table[].  All we need is:
> 
> /* rpmsg devices and drivers are matched using the service name */ static 
> inline
> int rpmsg_id_match(const struct rpmsg_device *rpdev,
>  const struct rpmsg_device_id *id) {
>  + size_t len = strnlen(id->name, RPMSG_NAME_SIZE);
> 
>  - return strncmp(id->name, rpdev->id.name, RPMSG_NAME_SIZE) == 0;
>  + return strncmp(id->name, rpdev->id.name, len) == 0;
> }
> 

If we encode the port index directly into ept->src, for example:

ept->src = (baseaddr << 8) | port_index;

where baseaddr can be derived from the channel address, we can avoid the 
possible address conflict.

With this approach, the patch to rpmsg-core would no longer be necessary.

Thanks,
Shenwei

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

[Mathieu Poirier]

On Tue, May 05, 2026 at 10:46:11AM +0200, Arnaud POULIQUEN wrote:
> Hi Beleswar
> 
> On 5/5/26 07:25, Beleswar Prasad Padhi wrote:
> > Hi Arnaud,
> > 
> > On 04/05/26 22:34, Arnaud POULIQUEN wrote:
> > > Hi Beleswar,
> > > 
> > > On 5/4/26 10:17, Beleswar Prasad Padhi wrote:
> > > 
> > 
> > [...]
> > 
> > > > 
> > > > > 
> > > > > I may have misunderstood your solution. Could you please help me
> > > > > understand your proposal by explaining how you would handle three
> > > > > GPIO ports defined in the DT, considering that the endpoint
> > > > > addresses on the Linux side can be random?
> > > > > If I assume there is a unique endpoint on the remote side,
> > > > > I do not understand how you can match, on the firmware side,
> > > > > the Linux endpoint address to the GPIO port.
> > > > 
> > > > 
> > > > Sure, let me take an example:
> > > > Assumptions: 3 GPIO ports in DT, 3 endpoints in Linux (one per port),
> > > > 1 endpoint in remote (0xd) and 1 rpmsg channel (rpmsg-io)
> > > > 
> > > >          rpmsg {
> > > >            rpmsg-io {
> > > >              #address-cells = <1>;
> > > >              #size-cells = <0>;
> > > > 
> > > >              gpio@25 {
> > > >                compatible = "rpmsg-gpio";
> > > >                reg = <25>;
> > > >                gpio-controller;
> > > >                #gpio-cells = <2>;
> > > >                #interrupt-cells = <2>;
> > > >                interrupt-controller;
> > > >              };
> > > > 
> > > >              gpio@32 {
> > > >                compatible = "rpmsg-gpio";
> > > >                reg = <32>;
> > > >                gpio-controller;
> > > >                #gpio-cells = <2>;
> > > >                #interrupt-cells = <2>;
> > > >                interrupt-controller;
> > > >              };
> > > > 
> > > >              gpio@35 {
> > > >                compatible = "rpmsg-gpio";
> > > >                reg = <35>;
> > > >                gpio-controller;
> > > >                #gpio-cells = <2>;
> > > >                #interrupt-cells = <2>;
> > > >                interrupt-controller;
> > > >              };
> > > >            };
> > > >          };
> > > > 
> > > > Code Flow:
> > > > 1. "rpmsg-io" channel is announced from remote firmware with unique dst
> > > >       ept = 0xd.
> > > > 
> > > > 2. rpmsg_core.c creates the default dynamic local ept for the channel
> > > >       ept = 0x405.
> > > > 
> > > > 3. rpmsg_core.c assigns the allocated addr to rpdev device:
> > > >       rpdev->src = 0x405 and rpdev->dst = 0xd.
> > > > 
> > > > 4. rpmsg_gpio_channel_probe() is triggered. For *each* of the GPIO ports
> > > >       in DT, it will trigger rpmsg_gpiochip_register() which will now:
> > > >          a. Call port->ept = rpmsg_create_ept(rpdev,
> > > >                                                                      
> > > > rpmsg_gpio_channel_callback,
> > > >                                                                      
> > > > port,
> > > >                                                                     
> > > > {rpdev.id.name,
> > > >                                                                      
> > > > RPMSG_ADDR_ANY,
> > > >                                                                      
> > > > RPMSG_ADDR_ANY});
> > > >              Ex- port->ept->addr = 0x408
> > > > 
> > > >          b. Prepare a 8-byte message having 2 fields:
> > > >              port->ept->addr (0x408) and port->idx (25)
> > > > 
> > > >          c. Send this message to remote firmware on default channel ept
> > > >              (0x405 -> 0xd) by:
> > > >              rpmsg_send(rpdev->ept, &message, sizeof(message));
> > > > 
> > > >          d. Remote side receives this message and creates a map of the
> > > >              linux_ept_addr to gpio_port. (0x408 <-> 25)
> > > > 
> > > > 5. After this point, any gpio messages sent from Linux from gpio port
> > > >       endpoints (Ex- 0x408) can be decoded at remote side by looking up
> > > >       its map (Ex- map[0x408] = 25).
> > > > 
> > > > 6. Any messages sent from remote to Linux for a particular gpio port can
> > > >       also be decoded at Linux by simply fetching the priv pointer to 
> > > > get
> > > >       the per-port device:
> > > >       struct rpmsg_gpio_port *port = priv;
> > > > 
> > > 
> > > Thanks for the details!
> > > 
> > > To sum up:
> > > - the default endpoint acts as the GPIO controller (0x405),
> > > - one extra Linux endpoint is created per port defined in DT.
> > > 
> > > This should work, but my concerns remain the same:
> > > 
> > >    1) This implementation forces the remote processor to handle a single
> > >   endpoint instead of one endpoint per port. This may add complexity 
> > > to
> > >   the remote firmware if each port is managed in a separate thread.
> > 
> > 
> > A. Not really, I just chose 1 remote endpoint for this example as you
> >      suggested to. We can scale it for two-way communication via the
> >      get_config message lik

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

[Mathieu Poirier]

On Thu, Apr 30, 2026 at 09:35:09AM +0200, Arnaud POULIQUEN wrote:
> Hello,
> 
> On 4/29/26 21:20, Mathieu Poirier wrote:
> > On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar  wrote:
> > > 
> > > Hi Mathieu,
> > > 
> > > On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
> > > > On Wed, 29 Apr 2026 at 10:53, Shenwei Wang  wrote:
> > > > > 
> > > > > 
> > > > > > -Original Message-
> > > > > > From: Mathieu Poirier 
> > > > > > Sent: Wednesday, April 29, 2026 10:42 AM
> > > > > > To: Shenwei Wang 
> > > > > > Cc: Andrew Lunn ; Padhi, Beleswar ; 
> > > > > > Linus
> > > > > > Walleij ; Bartosz Golaszewski ; 
> > > > > > Jonathan
> > > > > > Corbet ; Rob Herring ; Krzysztof 
> > > > > > Kozlowski
> > > > > > ; Conor Dooley ; Bjorn 
> > > > > > Andersson
> > > > > > ; Frank Li ; Sascha Hauer
> > > > > > ; Shuah Khan ; 
> > > > > > linux-
> > > > > > g...@vger.kernel.org; linux-...@vger.kernel.org; 
> > > > > > linux-kernel@vger.kernel.org;
> > > > > > Pengutronix Kernel Team ; Fabio Estevam
> > > > > > ; Peng Fan ;
> > > > > > devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org;
> > > > > > i...@lists.linux.dev; linux-arm-ker...@lists.infradead.org; 
> > > > > > dl-linux-imx  > > > > > i...@nxp.com>; Bartosz Golaszewski 
> > > > > > Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg 
> > > > > > GPIO driver
> > > > > > On Tue, Apr 28, 2026 at 03:24:59PM +, Shenwei Wang wrote:
> > > > > > > 
> > > > > > > > -Original Message-
> > > > > > > > From: Andrew Lunn 
> > > > > > > > Sent: Monday, April 27, 2026 3:49 PM
> > > > > > > > To: Shenwei Wang 
> > > > > > > > Cc: Padhi, Beleswar ; Linus Walleij
> > > > > > > > ; Bartosz Golaszewski ; 
> > > > > > > > Jonathan
> > > > > > > > Corbet ; Rob Herring ; 
> > > > > > > > Krzysztof
> > > > > > > > Kozlowski ; Conor Dooley 
> > > > > > > > ;
> > > > > > > > Bjorn Andersson ; Mathieu Poirier
> > > > > > > > ; Frank Li ; 
> > > > > > > > Sascha
> > > > > > > > Hauer ; Shuah Khan
> > > > > > > > ; linux-g...@vger.kernel.org; linux-
> > > > > > > > d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
> > > > > > > > Kernel Team ; Fabio Estevam
> > > > > > > > ; Peng Fan ;
> > > > > > > > devicet...@vger.kernel.org; linux- remotep...@vger.kernel.org;
> > > > > > > > i...@lists.linux.dev; linux-arm- ker...@lists.infradead.org;
> > > > > > > > dl-linux-imx ; Bartosz Golaszewski
> > > > > > > > 
> > > > > > > > Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic 
> > > > > > > > rpmsg
> > > > > > > > GPIO driver
> > > > > > > > > > struct virtio_gpio_response {
> > > > > > > > > >   __u8 status;
> > > > > > > > > >   __u8 value;
> > > > > > > > > > };
> > > > > > > > > It is the same message format. Please see the message 
> > > > > > > > > definition
> > > > > > > > (GET_DIRECTION) below:
> > > > > > > > 
> > > > > > > > > +   +-+-+-+-+-++
> > > > > > > > > +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> > > > > > > > > +   | 1   | 2   |port |line | err | dir|
> > > > > > > > > +   +-+-+-+-+-++
> > > > > > > > Sorry, but i don't see how two u8 vs six u8 are the same 
> > > > > > > > message format.
> > > > > > > > 
> > > > > > > Some changes to the message format are necessary.
> > > > > > > 
> > > > > > > Virtio use

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

[Padhi, Beleswar]

On 5/5/2026 9:08 PM, Shah, Tanmay wrote:


[...]




  If there are
multiple or multiple instances of same controller, than we need separate
channel name for that controller just like we would have separate device
on the Linux.


Why so? I think there is some confusion in the terminology:

GPIO controller = GPIO port (gpio@xyz) defined in the
Device tree = struct rpmsg_gpio_port in code

GPIO line = Individual lines within each GPIO port (max =
GPIOS_PER_PORT_DEFAULT) = struct rpmsg_gpio_line in code


Okay, I understand now. So, same gpio controller has multiple instances.


1. namespace/channel#1 = rpmsg-io
   a. ept1 -> gpio-controller@1
   b. ept2 -> gpio-controller@2

So, In that case above mentioned approach doesn't work.

Because, this approach is mapping endpoint to the gpio-controller.



And what is the problem with that?


  From
linux's perspective, it needs to map rpmsg *channel* to the
gpio-controller not the endpoint.



Can you explain why it *needs* to?



To be more specific:

Linux:   remote:

ch1: rpmsg-gpio.-1.1024 -> gpio-controller@1024
 - gpio-line ept1
 - gpio-line ept2-> They all map to same callback_ept_1024.
 - gpio-line ept3



This is a weird mapping. I am not suggesting one ept per gpio-line,
rather one per gpio-controller. You can refer my detailed proposal
here:

https://lore.kernel.org/all/268f8e00-91bc-43ea-ba95-077cf859e...@ti.com/



ch2: rpmsg-gpio.-1.1025 -> gpio-controller@1025
 - gpio-line ept1
 - gpio-line ept2-> They all map to same callback_ept_1025.
 - gpio-line ept3



[...]



On the remote side, we have to hardcode Which rpmsg controller is mapped
to which endpoint.



Not necessarily, we can exchange this info at runtime.

Thanks,
Beleswar

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

[Shah, Tanmay]

On 5/5/2026 4:28 AM, Arnaud POULIQUEN wrote:
> Hi Tanmay,
> 
> On 5/4/26 21:19, Shah, Tanmay wrote:
>>
>> Hello all,
>>
>> I have started reviewing this work as well.
>> Thanks Shenwei for this work.
>>
>> I have gone through only the current revision, and would like to provide
>> idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
>> Also, have some bindings related question.
>>
>> Please see below:
>>
>> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
>>>
>>>
>>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>>>> Hello Arnaud,
>>>>
>>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>>>> Hello,
>>>>>
>>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar  wrote:
>>>>>>>
>>>>>>> Hi Mathieu,
>>>>>>>
>>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang 
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -Original Message-
>>>>>>>>>> From: Mathieu Poirier 
>>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>>>>> To: Shenwei Wang 
>>>>>>>>>> Cc: Andrew Lunn ; Padhi, Beleswar >>>>>>>>> pa...@ti.com>; Linus
>>>>>>>>>> Walleij ; Bartosz Golaszewski
>>>>>>>>>> ; Jonathan
>>>>>>>>>> Corbet ; Rob Herring ;
>>>>>>>>>> Krzysztof Kozlowski
>>>>>>>>>> ; Conor Dooley ; Bjorn
>>>>>>>>>> Andersson
>>>>>>>>>> ; Frank Li ; Sascha Hauer
>>>>>>>>>> ; Shuah Khan
>>>>>>>>>> ; linux-
>>>>>>>>>> g...@vger.kernel.org; linux-...@vger.kernel.org; linux-
>>>>>>>>>> ker...@vger.kernel.org;
>>>>>>>>>> Pengutronix Kernel Team ; Fabio Estevam
>>>>>>>>>> ; Peng Fan ;
>>>>>>>>>> devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org;
>>>>>>>>>> i...@lists.linux.dev; linux-arm-ker...@lists.infradead.org; dl-
>>>>>>>>>> linux-imx >>>>>>>>> i...@nxp.com>; Bartosz Golaszewski 
>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>>> rpmsg GPIO driver
>>>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +, Shenwei Wang wrote:
>>>>>>>>>>>
>>>>>>>>>>>> -Original Message-
>>>>>>>>>>>> From: Andrew Lunn 
>>>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>>>>>> To: Shenwei Wang 
>>>>>>>>>>>> Cc: Padhi, Beleswar ; Linus Walleij
>>>>>>>>>>>> ; Bartosz Golaszewski ;
>>>>>>>>>>>> Jonathan
>>>>>>>>>>>> Corbet ; Rob Herring ;
>>>>>>>>>>>> Krzysztof
>>>>>>>>>>>> Kozlowski ; Conor Dooley
>>>>>>>>>>>> ;
>>>>>>>>>>>> Bjorn Andersson ; Mathieu Poirier
>>>>>>>>>>>> ; Frank Li ;
>>>>>>>>>>>> Sascha
>>>>>>>>>>>> Hauer ; Shuah Khan
>>>>>>>>>>>> ; linux-g...@vger.kernel.org; linux-
>>>>>>>>>>>> d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>>>>>> Kernel Team ; Fabio Estevam
>>>>>>>>>>>> ; Peng Fan ;
>>>>>>>>>>>> devicet...@vger.kernel.org; linux- remotep...@vger.kernel.org;
>>>>>>>>>>>> i...@lists.linux.dev; linux-arm- ker...@lists.infradead.org;
>>>>>>>>>>>> dl-linux-imx ; Bartosz Golaszewski
>>>>>>>>>>>> 
>>>>>>>>>>>> Subject: [E

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

[Shah, Tanmay]

On 5/5/2026 6:16 AM, Beleswar Prasad Padhi wrote:
> Hi Tanmay,
> 
> On 05/05/26 00:49, Shah, Tanmay wrote:
>> Hello all,
>>
>> I have started reviewing this work as well.
>> Thanks Shenwei for this work.
>>
>> I have gone through only the current revision, and would like to provide
>> idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
>> Also, have some bindings related question.
>>
>> Please see below:
>>
>> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
>>>
>>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>>>> Hello Arnaud,
>>>>
>>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>>>> Hello,
>>>>>
>>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar  wrote:
>>>>>>> Hi Mathieu,
>>>>>>>
>>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang 
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> -Original Message-
>>>>>>>>>> From: Mathieu Poirier 
>>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>>>>> To: Shenwei Wang 
>>>>>>>>>> Cc: Andrew Lunn ; Padhi, Beleswar >>>>>>>>> pa...@ti.com>; Linus
>>>>>>>>>> Walleij ; Bartosz Golaszewski
>>>>>>>>>> ; Jonathan
>>>>>>>>>> Corbet ; Rob Herring ;
>>>>>>>>>> Krzysztof Kozlowski
>>>>>>>>>> ; Conor Dooley ; Bjorn
>>>>>>>>>> Andersson
>>>>>>>>>> ; Frank Li ; Sascha Hauer
>>>>>>>>>> ; Shuah Khan
>>>>>>>>>> ; linux-
>>>>>>>>>> g...@vger.kernel.org; linux-...@vger.kernel.org; linux-
>>>>>>>>>> ker...@vger.kernel.org;
>>>>>>>>>> Pengutronix Kernel Team ; Fabio Estevam
>>>>>>>>>> ; Peng Fan ;
>>>>>>>>>> devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org;
>>>>>>>>>> i...@lists.linux.dev; linux-arm-ker...@lists.infradead.org; dl-
>>>>>>>>>> linux-imx >>>>>>>>> i...@nxp.com>; Bartosz Golaszewski 
>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>>> rpmsg GPIO driver
>>>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +, Shenwei Wang wrote:
>>>>>>>>>>>> -Original Message-
>>>>>>>>>>>> From: Andrew Lunn 
>>>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>>>>>> To: Shenwei Wang 
>>>>>>>>>>>> Cc: Padhi, Beleswar ; Linus Walleij
>>>>>>>>>>>> ; Bartosz Golaszewski ;
>>>>>>>>>>>> Jonathan
>>>>>>>>>>>> Corbet ; Rob Herring ; Krzysztof
>>>>>>>>>>>> Kozlowski ; Conor Dooley
>>>>>>>>>>>> ;
>>>>>>>>>>>> Bjorn Andersson ; Mathieu Poirier
>>>>>>>>>>>> ; Frank Li ; Sascha
>>>>>>>>>>>> Hauer ; Shuah Khan
>>>>>>>>>>>> ; linux-g...@vger.kernel.org; linux-
>>>>>>>>>>>> d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>>>>>> Kernel Team ; Fabio Estevam
>>>>>>>>>>>> ; Peng Fan ;
>>>>>>>>>>>> devicet...@vger.kernel.org; linux- remotep...@vger.kernel.org;
>>>>>>>>>>>> i...@lists.linux.dev; linux-arm- ker...@lists.infradead.org;
>>>>>>>>>>>> dl-linux-imx ; Bartosz Golaszewski
>>>>>>>>>>>> 
>>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>>>>>>>>>> GPIO driver
>>>>>>>>>>>>>> struct virtio_gpio_response {
>>>>>>>

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

[Shenwei Wang]

> -Original Message-
> From: Beleswar Prasad Padhi 
> Sent: Monday, May 4, 2026 3:17 AM
> To: Arnaud POULIQUEN ; Mathieu Poirier
> 
> Cc: Shenwei Wang ; Andrew Lunn
> ; Linus Walleij ; Bartosz Golaszewski
> ; Jonathan Corbet ; Rob Herring
> ; Krzysztof Kozlowski ; Conor Dooley
> ; Bjorn Andersson ; Frank Li
> ; Sascha Hauer ; Shuah Khan
> ; linux-g...@vger.kernel.org; linux-
> d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> ; Fabio Estevam ; Peng Fan
> ; devicet...@vger.kernel.org; linux-
> remotep...@vger.kernel.org; i...@lists.linux.dev; linux-arm-
> ker...@lists.infradead.org; dl-linux-imx ; Bartosz
> Golaszewski 
> Subject: [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
> 
> 
> Hi Arnaud,
> 
> On 30/04/26 22:10, Arnaud POULIQUEN wrote:
> >
> >
> > On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
> >> Hello Arnaud,
> >>
> >> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
> >>> Hello,
> >>>
> >>> On 4/29/26 21:20, Mathieu Poirier wrote:
> >>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar  wrote:
> >>>>>
> >>>>> Hi Mathieu,
> >>>>>
> >>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
> >>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang
>  wrote:
> >>>>
> 
> [...]
> 
> >>>>> My mental model looks like this for the complete picture:
> >>>>>
> >>>>> 1. namespace/channel#1 = rpmsg-io
> >>>>>   a. ept1 -> gpio-controller@1
> >>>>>   b. ept2 -> gpio-controller@2
> >>>>>
> >>>>
> >>>> I've asked for one endpoint per GPIO controller since the very
> >>>> beginning.  I don't yet have a strong opinion on whether to use one
> >>>> namespace request per GPIO controller or a single request that
> >>>> spins off multiple endpoints.  I'll have to look at your link and
> >>>> reflect on that.  Regardless of how we proceed on that front,
> >>>> multiplexing needs to happen at the endpoint level rather than the
> >>>> packet level.  This is the only way this work can move forward.
> >>>>
> >>>
> >>> I would be more in favor of Mathieu’s proposal: “An endpoint is created 
> >>> with
> every namespace request.”
> >>>
> >>> If the endpoint is created only on the Linux side, how do we match the 
> >>> Linux
> endpoint address with the local port field on the remote side?
> >>
> >>
> >> Simply by sending a message to the remote containing the newly
> >> created endpoint and the port idx. Note that is this done just one
> >> time, after this Linux need not have the port field in the message
> >> everytime its sending a message.
> >>
> >>>
> >>> With a multi-namespace approach, the namespace could be rpmsg-io-[addr],
> where [addr] corresponds to the GPIO controller address in the DT. This would:
> >>
> >>
> >> You will face the same problem in this case also that you asked above:
> >> "how do we match the Linux endpoint address with the local port field
> >> on the remote side?"
> >
> > Sorry I probably introduced confusion here my sentence should be;
> > With a multi-namespace approach, the namespace could be
> > rpmsg-io-[port],  where [port] corresponds to the GPIO controller port in 
> > the
> DT.
> >
> >
> > For instance:
> >
> >   rpmsg {
> > rpmsg-io {
> >   #address-cells = <1>;
> >   #size-cells = <0>;
> >
> >   gpio@25 {
> > compatible = "rpmsg-gpio";
> > reg = <25>;
> > gpio-controller;
> > #gpio-cells = <2>;
> > #interrupt-cells = <2>;
> > interrupt-controller;
> >   };
> >
> >   gpio@32 {
> > compatible = "rpmsg-gpio";
> > reg = <32>;
> > gpio-controller;
> > #gpio-cells = <2>;
> > #interrupt-cells = <2>;
> > interrupt-controller;
> &

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

[Beleswar Prasad Padhi]

Hi Tanmay,

On 05/05/26 00:49, Shah, Tanmay wrote:
> Hello all,
>
> I have started reviewing this work as well.
> Thanks Shenwei for this work.
>
> I have gone through only the current revision, and would like to provide
> idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
> Also, have some bindings related question.
>
> Please see below:
>
> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
>>
>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>>> Hello Arnaud,
>>>
>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>>> Hello,
>>>>
>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar  wrote:
>>>>>> Hi Mathieu,
>>>>>>
>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang 
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> -Original Message-
>>>>>>>>> From: Mathieu Poirier 
>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>>>> To: Shenwei Wang 
>>>>>>>>> Cc: Andrew Lunn ; Padhi, Beleswar >>>>>>>> pa...@ti.com>; Linus
>>>>>>>>> Walleij ; Bartosz Golaszewski
>>>>>>>>> ; Jonathan
>>>>>>>>> Corbet ; Rob Herring ;
>>>>>>>>> Krzysztof Kozlowski
>>>>>>>>> ; Conor Dooley ; Bjorn
>>>>>>>>> Andersson
>>>>>>>>> ; Frank Li ; Sascha Hauer
>>>>>>>>> ; Shuah Khan
>>>>>>>>> ; linux-
>>>>>>>>> g...@vger.kernel.org; linux-...@vger.kernel.org; linux-
>>>>>>>>> ker...@vger.kernel.org;
>>>>>>>>> Pengutronix Kernel Team ; Fabio Estevam
>>>>>>>>> ; Peng Fan ;
>>>>>>>>> devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org;
>>>>>>>>> i...@lists.linux.dev; linux-arm-ker...@lists.infradead.org; dl-
>>>>>>>>> linux-imx >>>>>>>> i...@nxp.com>; Bartosz Golaszewski 
>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>> rpmsg GPIO driver
>>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +, Shenwei Wang wrote:
>>>>>>>>>>> -Original Message-
>>>>>>>>>>> From: Andrew Lunn 
>>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>>>>> To: Shenwei Wang 
>>>>>>>>>>> Cc: Padhi, Beleswar ; Linus Walleij
>>>>>>>>>>> ; Bartosz Golaszewski ;
>>>>>>>>>>> Jonathan
>>>>>>>>>>> Corbet ; Rob Herring ; Krzysztof
>>>>>>>>>>> Kozlowski ; Conor Dooley
>>>>>>>>>>> ;
>>>>>>>>>>> Bjorn Andersson ; Mathieu Poirier
>>>>>>>>>>> ; Frank Li ; Sascha
>>>>>>>>>>> Hauer ; Shuah Khan
>>>>>>>>>>> ; linux-g...@vger.kernel.org; linux-
>>>>>>>>>>> d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>>>>> Kernel Team ; Fabio Estevam
>>>>>>>>>>> ; Peng Fan ;
>>>>>>>>>>> devicet...@vger.kernel.org; linux- remotep...@vger.kernel.org;
>>>>>>>>>>> i...@lists.linux.dev; linux-arm- ker...@lists.infradead.org;
>>>>>>>>>>> dl-linux-imx ; Bartosz Golaszewski
>>>>>>>>>>> 
>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>>>>>>>>> GPIO driver
>>>>>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>>>>>    __u8 status;
>>>>>>>>>>>>>    __u8 value;
>>>>>>>>>>>>> };
>>>>>>>>>>>> It is the same message format. Please see the message definition
>>>>>>>>>>> (GET_DIRECTION) below:
>>

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

[Arnaud POULIQUEN]

Hi Tanmay,

On 5/4/26 21:19, Shah, Tanmay wrote:


Hello all,

I have started reviewing this work as well.
Thanks Shenwei for this work.

I have gone through only the current revision, and would like to provide
idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
Also, have some bindings related question.

Please see below:

On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:



On 4/30/26 14:56, Beleswar Prasad Padhi wrote:

Hello Arnaud,

On 30/04/26 13:05, Arnaud POULIQUEN wrote:

Hello,

On 4/29/26 21:20, Mathieu Poirier wrote:

On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar  wrote:


Hi Mathieu,

On 4/29/2026 11:03 PM, Mathieu Poirier wrote:

On Wed, 29 Apr 2026 at 10:53, Shenwei Wang 
wrote:




-Original Message-
From: Mathieu Poirier 
Sent: Wednesday, April 29, 2026 10:42 AM
To: Shenwei Wang 
Cc: Andrew Lunn ; Padhi, Beleswar ; Linus
Walleij ; Bartosz Golaszewski
; Jonathan
Corbet ; Rob Herring ;
Krzysztof Kozlowski
; Conor Dooley ; Bjorn
Andersson
; Frank Li ; Sascha Hauer
; Shuah Khan
; linux-
g...@vger.kernel.org; linux-...@vger.kernel.org; linux-
ker...@vger.kernel.org;
Pengutronix Kernel Team ; Fabio Estevam
; Peng Fan ;
devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org;
i...@lists.linux.dev; linux-arm-ker...@lists.infradead.org; dl-
linux-imx ; Bartosz Golaszewski 
Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
rpmsg GPIO driver
On Tue, Apr 28, 2026 at 03:24:59PM +, Shenwei Wang wrote:



-Original Message-
From: Andrew Lunn 
Sent: Monday, April 27, 2026 3:49 PM
To: Shenwei Wang 
Cc: Padhi, Beleswar ; Linus Walleij
; Bartosz Golaszewski ;
Jonathan
Corbet ; Rob Herring ; Krzysztof
Kozlowski ; Conor Dooley
;
Bjorn Andersson ; Mathieu Poirier
; Frank Li ; Sascha
Hauer ; Shuah Khan
; linux-g...@vger.kernel.org; linux-
d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
Kernel Team ; Fabio Estevam
; Peng Fan ;
devicet...@vger.kernel.org; linux- remotep...@vger.kernel.org;
i...@lists.linux.dev; linux-arm- ker...@lists.infradead.org;
dl-linux-imx ; Bartosz Golaszewski

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

struct virtio_gpio_response {
    __u8 status;
    __u8 value;
};

It is the same message format. Please see the message definition

(GET_DIRECTION) below:


+   +-+-+-+-+-++
+   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+   | 1   | 2   |port |line | err | dir|
+   +-+-+-+-+-++

Sorry, but i don't see how two u8 vs six u8 are the same
message format.


Some changes to the message format are necessary.

Virtio uses two communication channels (virtqueues): one for
requests and

replies, and a second one for events.

In contrast, rpmsg provides only a single communication
channel, so a
type field is required to distinguish between different kinds
of messages.

Since rpmsg replies and events share the same message format,
an additional

line is introduced to handle both cases.

Finally, rpmsg supports multiple GPIO controllers, so a port
field is added to

uniquely identify the target controller.

I have commented on this before - RPMSG is already providing
multiplexing
capability by way of endpoints.  There is no need for a port
field.  One endpoint,
one GPIO controller.


You still need a way to let the remote side know which port the
endpoint maps to, either
by embedding the port information in the message (the current
way), or by sending it
separately.


An endpoint is created with every namespace request.  There should be
one namespace request for every GPIO controller, which yields a
unique
endpoint for each controller and eliminates the need for an extra
field to identify them.



Right, but this can still be done by just having one namespace
request.
We can create new endpoints bound to an existing namespace/channel by
invoking rpmsg_create_ept(). This is what I suggested here too:
https://lore.kernel.org/all/29485742-6e49-482e-
b73d-228295daa...@ti.com/



I will look at your suggestion (i.e link above) later this week or
next week.


My mental model looks like this for the complete picture:

1. namespace/channel#1 = rpmsg-io
   a. ept1 -> gpio-controller@1
   b. ept2 -> gpio-controller@2



If my understanding of what gpio-controller is right, than this won't
work. We need one rpmsg channel per gpio-controller, and in most cases
there will be only one GPIO-controller on the remote side. If there are
multiple or multiple instances of same controller, than we need separate
channel name for that controller just like we would have separate device
on the Linux.


As done in ehe rpmsg_tty driver it could be instantiated several times with
the same channel/service name. This would imply a specific rpmsg to retreive
the gpio controller index from the remote side.




I've asked for one endpoint per GPIO controller since the very
beginning.  I don't yet have a strong opinion on whether to use one

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

[Arnaud POULIQUEN]

Hi Beleswar

On 5/5/26 07:25, Beleswar Prasad Padhi wrote:

Hi Arnaud,

On 04/05/26 22:34, Arnaud POULIQUEN wrote:

Hi Beleswar,

On 5/4/26 10:17, Beleswar Prasad Padhi wrote:



[...]





I may have misunderstood your solution. Could you please help me
understand your proposal by explaining how you would handle three
GPIO ports defined in the DT, considering that the endpoint
addresses on the Linux side can be random?
If I assume there is a unique endpoint on the remote side,
I do not understand how you can match, on the firmware side,
the Linux endpoint address to the GPIO port.



Sure, let me take an example:
Assumptions: 3 GPIO ports in DT, 3 endpoints in Linux (one per port),
1 endpoint in remote (0xd) and 1 rpmsg channel (rpmsg-io)

         rpmsg {
           rpmsg-io {
             #address-cells = <1>;
             #size-cells = <0>;

             gpio@25 {
               compatible = "rpmsg-gpio";
               reg = <25>;
               gpio-controller;
               #gpio-cells = <2>;
               #interrupt-cells = <2>;
               interrupt-controller;
             };

             gpio@32 {
               compatible = "rpmsg-gpio";
               reg = <32>;
               gpio-controller;
               #gpio-cells = <2>;
               #interrupt-cells = <2>;
               interrupt-controller;
             };

             gpio@35 {
               compatible = "rpmsg-gpio";
               reg = <35>;
               gpio-controller;
               #gpio-cells = <2>;
               #interrupt-cells = <2>;
               interrupt-controller;
             };
           };
         };

Code Flow:
1. "rpmsg-io" channel is announced from remote firmware with unique dst
      ept = 0xd.

2. rpmsg_core.c creates the default dynamic local ept for the channel
      ept = 0x405.

3. rpmsg_core.c assigns the allocated addr to rpdev device:
      rpdev->src = 0x405 and rpdev->dst = 0xd.

4. rpmsg_gpio_channel_probe() is triggered. For *each* of the GPIO ports
      in DT, it will trigger rpmsg_gpiochip_register() which will now:
         a. Call port->ept = rpmsg_create_ept(rpdev,
                                                                     
rpmsg_gpio_channel_callback,
                                                                     port,
                                                                    
{rpdev.id.name,
                                                                     
RPMSG_ADDR_ANY,
                                                                     
RPMSG_ADDR_ANY});
             Ex- port->ept->addr = 0x408

         b. Prepare a 8-byte message having 2 fields:
             port->ept->addr (0x408) and port->idx (25)

         c. Send this message to remote firmware on default channel ept
             (0x405 -> 0xd) by:
             rpmsg_send(rpdev->ept, &message, sizeof(message));

         d. Remote side receives this message and creates a map of the
             linux_ept_addr to gpio_port. (0x408 <-> 25)

5. After this point, any gpio messages sent from Linux from gpio port
      endpoints (Ex- 0x408) can be decoded at remote side by looking up
      its map (Ex- map[0x408] = 25).

6. Any messages sent from remote to Linux for a particular gpio port can
      also be decoded at Linux by simply fetching the priv pointer to get
      the per-port device:
      struct rpmsg_gpio_port *port = priv;



Thanks for the details!

To sum up:
- the default endpoint acts as the GPIO controller (0x405),
- one extra Linux endpoint is created per port defined in DT.

This should work, but my concerns remain the same:

   1) This implementation forces the remote processor to handle a single
  endpoint instead of one endpoint per port. This may add complexity to
  the remote firmware if each port is managed in a separate thread.



A. Not really, I just chose 1 remote endpoint for this example as you
     suggested to. We can scale it for two-way communication via the
     get_config message like you suggested below.

B. Isn't it a bad design of the firmware if it is handling 10 gpio ports
     in 10 threads? The logic to handle all the ports is the same, only
     the parameters (e.g. line number, msg) is different.



   2) Linux, as a consumer, should not expose its capabilities to the remote
  side (in your proposal it enumerates the ports defined in the DT).     In 
my view, the remote processor should expose its capabilities as the
  provider.



Agreed on this.



 From my perspective, based on your proposal:
  1) Linux should send a get_config message to the remote proc (0x405 -> 0xD). 
2) The remote processor would respond with the list of ports, associated
     with an remote endpoint addresses.



Agreed, we can scale it for multiple remote endpoints like this.


  3) Linux would parse the response, compare it with the DT, enable the GPIO
     ports accordingly, creating it local endpoint and associating it with
     the remote endpoint.

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

[Beleswar Prasad Padhi]

Hi Arnaud,

On 04/05/26 22:34, Arnaud POULIQUEN wrote:
> Hi Beleswar,
>
> On 5/4/26 10:17, Beleswar Prasad Padhi wrote: 
>

[...]

>>
>>>
>>> I may have misunderstood your solution. Could you please help me
>>> understand your proposal by explaining how you would handle three
>>> GPIO ports defined in the DT, considering that the endpoint
>>> addresses on the Linux side can be random?
>>> If I assume there is a unique endpoint on the remote side,
>>> I do not understand how you can match, on the firmware side,
>>> the Linux endpoint address to the GPIO port.
>>
>>
>> Sure, let me take an example:
>> Assumptions: 3 GPIO ports in DT, 3 endpoints in Linux (one per port),
>> 1 endpoint in remote (0xd) and 1 rpmsg channel (rpmsg-io)
>>
>>         rpmsg {
>>           rpmsg-io {
>>             #address-cells = <1>;
>>             #size-cells = <0>;
>>
>>             gpio@25 {
>>               compatible = "rpmsg-gpio";
>>               reg = <25>;
>>               gpio-controller;
>>               #gpio-cells = <2>;
>>               #interrupt-cells = <2>;
>>               interrupt-controller;
>>             };
>>
>>             gpio@32 {
>>               compatible = "rpmsg-gpio";
>>               reg = <32>;
>>               gpio-controller;
>>               #gpio-cells = <2>;
>>               #interrupt-cells = <2>;
>>               interrupt-controller;
>>             };
>>
>>             gpio@35 {
>>               compatible = "rpmsg-gpio";
>>               reg = <35>;
>>               gpio-controller;
>>               #gpio-cells = <2>;
>>               #interrupt-cells = <2>;
>>               interrupt-controller;
>>             };
>>           };
>>         };
>>
>> Code Flow:
>> 1. "rpmsg-io" channel is announced from remote firmware with unique dst
>>      ept = 0xd.
>>
>> 2. rpmsg_core.c creates the default dynamic local ept for the channel
>>      ept = 0x405.
>>
>> 3. rpmsg_core.c assigns the allocated addr to rpdev device:
>>      rpdev->src = 0x405 and rpdev->dst = 0xd.
>>
>> 4. rpmsg_gpio_channel_probe() is triggered. For *each* of the GPIO ports
>>      in DT, it will trigger rpmsg_gpiochip_register() which will now:
>>         a. Call port->ept = rpmsg_create_ept(rpdev,
>>                                                                     
>> rpmsg_gpio_channel_callback,
>>                                                                     port,
>>                                                                    
>> {rpdev.id.name,
>>                                                                     
>> RPMSG_ADDR_ANY,
>>                                                                     
>> RPMSG_ADDR_ANY});
>>             Ex- port->ept->addr = 0x408
>>
>>         b. Prepare a 8-byte message having 2 fields:
>>             port->ept->addr (0x408) and port->idx (25)
>>
>>         c. Send this message to remote firmware on default channel ept
>>             (0x405 -> 0xd) by:
>>             rpmsg_send(rpdev->ept, &message, sizeof(message));
>>
>>         d. Remote side receives this message and creates a map of the
>>             linux_ept_addr to gpio_port. (0x408 <-> 25)
>>
>> 5. After this point, any gpio messages sent from Linux from gpio port
>>      endpoints (Ex- 0x408) can be decoded at remote side by looking up
>>      its map (Ex- map[0x408] = 25).
>>
>> 6. Any messages sent from remote to Linux for a particular gpio port can
>>      also be decoded at Linux by simply fetching the priv pointer to get
>>      the per-port device:
>>      struct rpmsg_gpio_port *port = priv;
>>
>
> Thanks for the details!
>
> To sum up:
> - the default endpoint acts as the GPIO controller (0x405),
> - one extra Linux endpoint is created per port defined in DT.
>
> This should work, but my concerns remain the same:
>
>   1) This implementation forces the remote processor to handle a single
>  endpoint instead of one endpoint per port. This may add complexity to
>  the remote firmware if each port is managed in a separate thread. 


A. Not really, I just chose 1 remote endpoint for this example as you
    suggested to. We can scale it for two-way communication via the
    get_config message like you suggested below.

B. Isn't it a bad design of the firmware if it is handling 10 gpio ports
    in 10 threads? The logic to handle all the ports is the same, only
    the parameters (e.g. line number, msg) is different.

>
>   2) Linux, as a consumer, should not expose its capabilities to the remote
>  side (in your proposal it enumerates the ports defined in the DT).     
> In my view, the remote processor should expose its capabilities as the
>  provider. 


Agreed on this.

>
> From my perspective, based on your proposal:
>  1) Linux should send a get_config message to the remote proc (0x405 -> 0xD). 
> 2) The remote processor would respond with the list of ports, associated
>     with an remote endpoint addresses. 


Agreed, we can scale it for multiple remote endpoints like this.

> 

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

[Shah, Tanmay]

Hello all,

I have started reviewing this work as well.
Thanks Shenwei for this work.

I have gone through only the current revision, and would like to provide
idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
Also, have some bindings related question.

Please see below:

On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
> 
> 
> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>> Hello Arnaud,
>>
>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>> Hello,
>>>
>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar  wrote:
>>>>>
>>>>> Hi Mathieu,
>>>>>
>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang 
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> -Original Message-
>>>>>>>> From: Mathieu Poirier 
>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>>> To: Shenwei Wang 
>>>>>>>> Cc: Andrew Lunn ; Padhi, Beleswar >>>>>>> pa...@ti.com>; Linus
>>>>>>>> Walleij ; Bartosz Golaszewski
>>>>>>>> ; Jonathan
>>>>>>>> Corbet ; Rob Herring ;
>>>>>>>> Krzysztof Kozlowski
>>>>>>>> ; Conor Dooley ; Bjorn
>>>>>>>> Andersson
>>>>>>>> ; Frank Li ; Sascha Hauer
>>>>>>>> ; Shuah Khan
>>>>>>>> ; linux-
>>>>>>>> g...@vger.kernel.org; linux-...@vger.kernel.org; linux-
>>>>>>>> ker...@vger.kernel.org;
>>>>>>>> Pengutronix Kernel Team ; Fabio Estevam
>>>>>>>> ; Peng Fan ;
>>>>>>>> devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org;
>>>>>>>> i...@lists.linux.dev; linux-arm-ker...@lists.infradead.org; dl-
>>>>>>>> linux-imx >>>>>>> i...@nxp.com>; Bartosz Golaszewski 
>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>> rpmsg GPIO driver
>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +, Shenwei Wang wrote:
>>>>>>>>>
>>>>>>>>>> -----Original Message-
>>>>>>>>>> From: Andrew Lunn 
>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>>>> To: Shenwei Wang 
>>>>>>>>>> Cc: Padhi, Beleswar ; Linus Walleij
>>>>>>>>>> ; Bartosz Golaszewski ;
>>>>>>>>>> Jonathan
>>>>>>>>>> Corbet ; Rob Herring ; Krzysztof
>>>>>>>>>> Kozlowski ; Conor Dooley
>>>>>>>>>> ;
>>>>>>>>>> Bjorn Andersson ; Mathieu Poirier
>>>>>>>>>> ; Frank Li ; Sascha
>>>>>>>>>> Hauer ; Shuah Khan
>>>>>>>>>> ; linux-g...@vger.kernel.org; linux-
>>>>>>>>>> d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>>>> Kernel Team ; Fabio Estevam
>>>>>>>>>> ; Peng Fan ;
>>>>>>>>>> devicet...@vger.kernel.org; linux- remotep...@vger.kernel.org;
>>>>>>>>>> i...@lists.linux.dev; linux-arm- ker...@lists.infradead.org;
>>>>>>>>>> dl-linux-imx ; Bartosz Golaszewski
>>>>>>>>>> 
>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>>>>>>>> GPIO driver
>>>>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>>>>    __u8 status;
>>>>>>>>>>>>    __u8 value;
>>>>>>>>>>>> };
>>>>>>>>>>> It is the same message format. Please see the message definition
>>>>>>>>>> (GET_DIRECTION) below:
>>>>>>>>>>
>>>>>>>>>>> +   +-+-+-+-+-++
>>>>>>>>>>> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>>>>> +   | 1   | 2   |port |line | err | dir|
>

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

[Arnaud POULIQUEN]

Hi Beleswar,

On 5/4/26 10:17, Beleswar Prasad Padhi wrote:

Hi Arnaud,

On 30/04/26 22:10, Arnaud POULIQUEN wrote:



On 4/30/26 14:56, Beleswar Prasad Padhi wrote:

Hello Arnaud,

On 30/04/26 13:05, Arnaud POULIQUEN wrote:

Hello,

On 4/29/26 21:20, Mathieu Poirier wrote:

On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar  wrote:


Hi Mathieu,

On 4/29/2026 11:03 PM, Mathieu Poirier wrote:

On Wed, 29 Apr 2026 at 10:53, Shenwei Wang  wrote:




[...]


My mental model looks like this for the complete picture:

1. namespace/channel#1 = rpmsg-io
   a. ept1 -> gpio-controller@1
   b. ept2 -> gpio-controller@2



I've asked for one endpoint per GPIO controller since the very
beginning.  I don't yet have a strong opinion on whether to use one
namespace request per GPIO controller or a single request that spins
off multiple endpoints.  I'll have to look at your link and reflect on
that.  Regardless of how we proceed on that front, multiplexing needs
to happen at the endpoint level rather than the packet level.  This is
the only way this work can move forward.



I would be more in favor of Mathieu’s proposal: “An endpoint is created with 
every namespace request.”

If the endpoint is created only on the Linux side, how do we match the Linux 
endpoint address with the local port field on the remote side?



Simply by sending a message to the remote containing the newly created
endpoint and the port idx. Note that is this done just one time, after this
Linux need not have the port field in the message everytime its sending
a message.



With a multi-namespace approach, the namespace could be rpmsg-io-[addr], where 
[addr] corresponds to the GPIO controller address in the DT. This would:



You will face the same problem in this case also that you asked above:
"how do we match the Linux endpoint address with the local port field
on the remote side?"


Sorry I probably introduced confusion here
my sentence should be;
  With a multi-namespace approach, the namespace could be rpmsg-io-[port],
  where [port] corresponds to the GPIO controller port in the DT.


For instance:

   rpmsg {
     rpmsg-io {
   #address-cells = <1>;
   #size-cells = <0>;

   gpio@25 {
     compatible = "rpmsg-gpio";
     reg = <25>;
     gpio-controller;
     #gpio-cells = <2>;
     #interrupt-cells = <2>;
     interrupt-controller;
   };

   gpio@32 {
     compatible = "rpmsg-gpio";
     reg = <32>;
     gpio-controller;
     #gpio-cells = <2>;
     #interrupt-cells = <2>;
     interrupt-controller;
   };
     };
   };

  rpmsg-io-25  would match with gpio@25
  rpmsg-io-32  would match with gpio@32




Because the endpoint that is created on a namespace request is also
dynamic in nature. How will the remote know which endpoint addr
Linux allocated for a namespace that it announced?

As an example/PoC, I created a firmware example which announces
2 name services to Linux, one is the standard "rpmsg_chrdev" and
the other is a TI specific name service "ti.ipc4.ping-pong". You can
see it created 2 different addresses (0x400 and 0x401) for each of
the name service request from the same firmware:

root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
[    9.290275] virtio_rpmsg_bus virtio0: creating channel ti.ipc4.ping-pong 
addr 0xd
[    9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev addr 0xe
[    9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel formed 
from src = 0x400 to dst = 0xe
[    9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: new channel: 
0x401 -> 0xd!

So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
Back to same problem. Simple solution is to reply to remote with the
created ept addr and the index.


That why I would like to suggest to use the name service field to identify the 
port/controller, instead of the endpoint address.
  


- match the RPMsg probe with the DT,



We can probe from all controllers with a single name service
announcement too.


- provide a simple mapping between the port and the endpoint on both sides,



We are trying to get rid of this mapping from Linux side to adapt
the gpio-virtio design.


- allow multiple endpoints on the remote side,



We can support this as well with single nameservice model.
There is no limitation. Remote has to send a message with
its newly created ept that's all.


- provide a simple discovery mechanism for remote capabilities.



A single announcement: "rpmsg-io" is also discovery mechanism.

Feel free to let me know if you have concerns with any of the
suggestions!


My only concern, whatever the solution, is that we find a smart
solution to associate the correct endpoint with the correct GPIO
port/controller defined in the DT.



In my solution, there is no need to have this map of endpoint to
GPIO port at Linux side. This aligns more wi

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

[Beleswar Prasad Padhi]

Hi Arnaud,

On 30/04/26 22:10, Arnaud POULIQUEN wrote:
>
>
> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>> Hello Arnaud,
>>
>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>> Hello,
>>>
>>> On 4/29/26 21:20, Mathieu Poirier wrote:
 On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar  wrote:
>
> Hi Mathieu,
>
> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang  wrote:


[...]

> My mental model looks like this for the complete picture:
>
> 1. namespace/channel#1 = rpmsg-io
>   a. ept1 -> gpio-controller@1
>   b. ept2 -> gpio-controller@2
>

 I've asked for one endpoint per GPIO controller since the very
 beginning.  I don't yet have a strong opinion on whether to use one
 namespace request per GPIO controller or a single request that spins
 off multiple endpoints.  I'll have to look at your link and reflect on
 that.  Regardless of how we proceed on that front, multiplexing needs
 to happen at the endpoint level rather than the packet level.  This is
 the only way this work can move forward.

>>>
>>> I would be more in favor of Mathieu’s proposal: “An endpoint is created 
>>> with every namespace request.”
>>>
>>> If the endpoint is created only on the Linux side, how do we match the 
>>> Linux endpoint address with the local port field on the remote side?
>>
>>
>> Simply by sending a message to the remote containing the newly created
>> endpoint and the port idx. Note that is this done just one time, after this
>> Linux need not have the port field in the message everytime its sending
>> a message.
>>
>>>
>>> With a multi-namespace approach, the namespace could be rpmsg-io-[addr], 
>>> where [addr] corresponds to the GPIO controller address in the DT. This 
>>> would:
>>
>>
>> You will face the same problem in this case also that you asked above:
>> "how do we match the Linux endpoint address with the local port field
>> on the remote side?"
>
> Sorry I probably introduced confusion here
> my sentence should be;
>  With a multi-namespace approach, the namespace could be rpmsg-io-[port],
>  where [port] corresponds to the GPIO controller port in the DT.
>
>
> For instance:
>
>   rpmsg {
>     rpmsg-io {
>   #address-cells = <1>;
>   #size-cells = <0>;
>
>   gpio@25 {
>     compatible = "rpmsg-gpio";
>     reg = <25>;
>     gpio-controller;
>     #gpio-cells = <2>;
>     #interrupt-cells = <2>;
>     interrupt-controller;
>   };
>
>   gpio@32 {
>     compatible = "rpmsg-gpio";
>     reg = <32>;
>     gpio-controller;
>     #gpio-cells = <2>;
>     #interrupt-cells = <2>;
>     interrupt-controller;
>   };
>     };
>   };
>
>  rpmsg-io-25  would match with gpio@25
>  rpmsg-io-32  would match with gpio@32
>
>
>>
>> Because the endpoint that is created on a namespace request is also
>> dynamic in nature. How will the remote know which endpoint addr
>> Linux allocated for a namespace that it announced?
>>
>> As an example/PoC, I created a firmware example which announces
>> 2 name services to Linux, one is the standard "rpmsg_chrdev" and
>> the other is a TI specific name service "ti.ipc4.ping-pong". You can
>> see it created 2 different addresses (0x400 and 0x401) for each of
>> the name service request from the same firmware:
>>
>> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
>> [    9.290275] virtio_rpmsg_bus virtio0: creating channel ti.ipc4.ping-pong 
>> addr 0xd
>> [    9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev addr 
>> 0xe
>> [    9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel 
>> formed from src = 0x400 to dst = 0xe
>> [    9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: new 
>> channel: 0x401 -> 0xd!
>>
>> So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
>> Back to same problem. Simple solution is to reply to remote with the
>> created ept addr and the index.
>
> That why I would like to suggest to use the name service field to identify 
> the port/controller, instead of the endpoint address.
>>  
>>>
>>> - match the RPMsg probe with the DT,
>>
>>
>> We can probe from all controllers with a single name service
>> announcement too.
>>
>>> - provide a simple mapping between the port and the endpoint on both sides,
>>
>>
>> We are trying to get rid of this mapping from Linux side to adapt
>> the gpio-virtio design.
>>
>>> - allow multiple endpoints on the remote side,
>>
>>
>> We can support this as well with single nameservice model.
>> There is no limitation. Remote has to send a message with
>> its newly created ept that's all.
>>
>>> - provide a simple discovery mechanism for remote capabilities.
>>
>>
>> A single announcement: "rpmsg-io" is also discovery mechanism.
>>
>> Feel free to let me know if you have concerns wi

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

[Arnaud POULIQUEN]

On 4/30/26 14:56, Beleswar Prasad Padhi wrote:

Hello Arnaud,

On 30/04/26 13:05, Arnaud POULIQUEN wrote:

Hello,

On 4/29/26 21:20, Mathieu Poirier wrote:

On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar  wrote:


Hi Mathieu,

On 4/29/2026 11:03 PM, Mathieu Poirier wrote:

On Wed, 29 Apr 2026 at 10:53, Shenwei Wang  wrote:




-Original Message-
From: Mathieu Poirier 
Sent: Wednesday, April 29, 2026 10:42 AM
To: Shenwei Wang 
Cc: Andrew Lunn ; Padhi, Beleswar ; Linus
Walleij ; Bartosz Golaszewski ; Jonathan
Corbet ; Rob Herring ; Krzysztof Kozlowski
; Conor Dooley ; Bjorn Andersson
; Frank Li ; Sascha Hauer
; Shuah Khan ; linux-
g...@vger.kernel.org; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
Pengutronix Kernel Team ; Fabio Estevam
; Peng Fan ;
devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org;
i...@lists.linux.dev; linux-arm-ker...@lists.infradead.org; dl-linux-imx ; Bartosz Golaszewski 
Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
On Tue, Apr 28, 2026 at 03:24:59PM +, Shenwei Wang wrote:



-Original Message-
From: Andrew Lunn 
Sent: Monday, April 27, 2026 3:49 PM
To: Shenwei Wang 
Cc: Padhi, Beleswar ; Linus Walleij
; Bartosz Golaszewski ; Jonathan
Corbet ; Rob Herring ; Krzysztof
Kozlowski ; Conor Dooley ;
Bjorn Andersson ; Mathieu Poirier
; Frank Li ; Sascha
Hauer ; Shuah Khan
; linux-g...@vger.kernel.org; linux-
d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
Kernel Team ; Fabio Estevam
; Peng Fan ;
devicet...@vger.kernel.org; linux- remotep...@vger.kernel.org;
i...@lists.linux.dev; linux-arm- ker...@lists.infradead.org;
dl-linux-imx ; Bartosz Golaszewski

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

struct virtio_gpio_response {
   __u8 status;
   __u8 value;
};

It is the same message format. Please see the message definition

(GET_DIRECTION) below:


+   +-+-+-+-+-++
+   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+   | 1   | 2   |port |line | err | dir|
+   +-+-+-+-+-++

Sorry, but i don't see how two u8 vs six u8 are the same message format.


Some changes to the message format are necessary.

Virtio uses two communication channels (virtqueues): one for requests and

replies, and a second one for events.

In contrast, rpmsg provides only a single communication channel, so a
type field is required to distinguish between different kinds of messages.

Since rpmsg replies and events share the same message format, an additional

line is introduced to handle both cases.

Finally, rpmsg supports multiple GPIO controllers, so a port field is added to

uniquely identify the target controller.

I have commented on this before - RPMSG is already providing multiplexing
capability by way of endpoints.  There is no need for a port field.  One 
endpoint,
one GPIO controller.


You still need a way to let the remote side know which port the endpoint maps 
to, either
by embedding the port information in the message (the current way), or by 
sending it
separately.


An endpoint is created with every namespace request.  There should be
one namespace request for every GPIO controller, which yields a unique
endpoint for each controller and eliminates the need for an extra
field to identify them.



Right, but this can still be done by just having one namespace request.
We can create new endpoints bound to an existing namespace/channel by
invoking rpmsg_create_ept(). This is what I suggested here too:
https://lore.kernel.org/all/29485742-6e49-482e-b73d-228295daa...@ti.com/



I will look at your suggestion (i.e link above) later this week or next week.


My mental model looks like this for the complete picture:

1. namespace/channel#1 = rpmsg-io
  a. ept1 -> gpio-controller@1
  b. ept2 -> gpio-controller@2



I've asked for one endpoint per GPIO controller since the very
beginning.  I don't yet have a strong opinion on whether to use one
namespace request per GPIO controller or a single request that spins
off multiple endpoints.  I'll have to look at your link and reflect on
that.  Regardless of how we proceed on that front, multiplexing needs
to happen at the endpoint level rather than the packet level.  This is
the only way this work can move forward.



I would be more in favor of Mathieu’s proposal: “An endpoint is created with 
every namespace request.”

If the endpoint is created only on the Linux side, how do we match the Linux 
endpoint address with the local port field on the remote side?



Simply by sending a message to the remote containing the newly created
endpoint and the port idx. Note that is this done just one time, after this
Linux need not have the port field in the message everytime its sending
a message.



With a multi-namespace approach, the namespace could be rpmsg-io-[addr], where 
[addr] corresponds to the GPIO controller address in the DT. This would:



You will fac

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

[Beleswar Prasad Padhi]

Hello Arnaud,

On 30/04/26 13:05, Arnaud POULIQUEN wrote:
> Hello,
>
> On 4/29/26 21:20, Mathieu Poirier wrote:
>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar  wrote:
>>>
>>> Hi Mathieu,
>>>
>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang  wrote:
>>>>>
>>>>>
>>>>>> -Original Message-
>>>>>> From: Mathieu Poirier 
>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>> To: Shenwei Wang 
>>>>>> Cc: Andrew Lunn ; Padhi, Beleswar ; Linus
>>>>>> Walleij ; Bartosz Golaszewski ; 
>>>>>> Jonathan
>>>>>> Corbet ; Rob Herring ; Krzysztof 
>>>>>> Kozlowski
>>>>>> ; Conor Dooley ; Bjorn Andersson
>>>>>> ; Frank Li ; Sascha Hauer
>>>>>> ; Shuah Khan ; linux-
>>>>>> g...@vger.kernel.org; linux-...@vger.kernel.org; 
>>>>>> linux-kernel@vger.kernel.org;
>>>>>> Pengutronix Kernel Team ; Fabio Estevam
>>>>>> ; Peng Fan ;
>>>>>> devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org;
>>>>>> i...@lists.linux.dev; linux-arm-ker...@lists.infradead.org; dl-linux-imx 
>>>>>> >>>>> i...@nxp.com>; Bartosz Golaszewski 
>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO 
>>>>>> driver
>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +, Shenwei Wang wrote:
>>>>>>>
>>>>>>>> -Original Message-
>>>>>>>> From: Andrew Lunn 
>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>> To: Shenwei Wang 
>>>>>>>> Cc: Padhi, Beleswar ; Linus Walleij
>>>>>>>> ; Bartosz Golaszewski ; Jonathan
>>>>>>>> Corbet ; Rob Herring ; Krzysztof
>>>>>>>> Kozlowski ; Conor Dooley ;
>>>>>>>> Bjorn Andersson ; Mathieu Poirier
>>>>>>>> ; Frank Li ; Sascha
>>>>>>>> Hauer ; Shuah Khan
>>>>>>>> ; linux-g...@vger.kernel.org; linux-
>>>>>>>> d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>> Kernel Team ; Fabio Estevam
>>>>>>>> ; Peng Fan ;
>>>>>>>> devicet...@vger.kernel.org; linux- remotep...@vger.kernel.org;
>>>>>>>> i...@lists.linux.dev; linux-arm- ker...@lists.infradead.org;
>>>>>>>> dl-linux-imx ; Bartosz Golaszewski
>>>>>>>> 
>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>>>>>> GPIO driver
>>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>>   __u8 status;
>>>>>>>>>>   __u8 value;
>>>>>>>>>> };
>>>>>>>>> It is the same message format. Please see the message definition
>>>>>>>> (GET_DIRECTION) below:
>>>>>>>>
>>>>>>>>> +   +-+-+-+-+-++
>>>>>>>>> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>>> +   | 1   | 2   |port |line | err | dir|
>>>>>>>>> +   +-+-+-+-+-++
>>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same message 
>>>>>>>> format.
>>>>>>>>
>>>>>>> Some changes to the message format are necessary.
>>>>>>>
>>>>>>> Virtio uses two communication channels (virtqueues): one for requests 
>>>>>>> and
>>>>>> replies, and a second one for events.
>>>>>>> In contrast, rpmsg provides only a single communication channel, so a
>>>>>>> type field is required to distinguish between different kinds of 
>>>>>>> messages.
>>>>>>>
>>>>>>> Since rpmsg replies and events share the same message format, an 
>>>>>>> additional
>>>>>> line is introduced to handle both cases.
>>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port field is 
>>>>>>> added to
>>>>>&g

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

[Arnaud POULIQUEN]

Hello,

On 4/29/26 21:20, Mathieu Poirier wrote:

On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar  wrote:


Hi Mathieu,

On 4/29/2026 11:03 PM, Mathieu Poirier wrote:

On Wed, 29 Apr 2026 at 10:53, Shenwei Wang  wrote:




-Original Message-
From: Mathieu Poirier 
Sent: Wednesday, April 29, 2026 10:42 AM
To: Shenwei Wang 
Cc: Andrew Lunn ; Padhi, Beleswar ; Linus
Walleij ; Bartosz Golaszewski ; Jonathan
Corbet ; Rob Herring ; Krzysztof Kozlowski
; Conor Dooley ; Bjorn Andersson
; Frank Li ; Sascha Hauer
; Shuah Khan ; linux-
g...@vger.kernel.org; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
Pengutronix Kernel Team ; Fabio Estevam
; Peng Fan ;
devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org;
i...@lists.linux.dev; linux-arm-ker...@lists.infradead.org; dl-linux-imx ; Bartosz Golaszewski 
Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
On Tue, Apr 28, 2026 at 03:24:59PM +, Shenwei Wang wrote:



-Original Message-
From: Andrew Lunn 
Sent: Monday, April 27, 2026 3:49 PM
To: Shenwei Wang 
Cc: Padhi, Beleswar ; Linus Walleij
; Bartosz Golaszewski ; Jonathan
Corbet ; Rob Herring ; Krzysztof
Kozlowski ; Conor Dooley ;
Bjorn Andersson ; Mathieu Poirier
; Frank Li ; Sascha
Hauer ; Shuah Khan
; linux-g...@vger.kernel.org; linux-
d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
Kernel Team ; Fabio Estevam
; Peng Fan ;
devicet...@vger.kernel.org; linux- remotep...@vger.kernel.org;
i...@lists.linux.dev; linux-arm- ker...@lists.infradead.org;
dl-linux-imx ; Bartosz Golaszewski

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

struct virtio_gpio_response {
  __u8 status;
  __u8 value;
};

It is the same message format. Please see the message definition

(GET_DIRECTION) below:


+   +-+-+-+-+-++
+   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+   | 1   | 2   |port |line | err | dir|
+   +-+-+-+-+-++

Sorry, but i don't see how two u8 vs six u8 are the same message format.


Some changes to the message format are necessary.

Virtio uses two communication channels (virtqueues): one for requests and

replies, and a second one for events.

In contrast, rpmsg provides only a single communication channel, so a
type field is required to distinguish between different kinds of messages.

Since rpmsg replies and events share the same message format, an additional

line is introduced to handle both cases.

Finally, rpmsg supports multiple GPIO controllers, so a port field is added to

uniquely identify the target controller.

I have commented on this before - RPMSG is already providing multiplexing
capability by way of endpoints.  There is no need for a port field.  One 
endpoint,
one GPIO controller.


You still need a way to let the remote side know which port the endpoint maps 
to, either
by embedding the port information in the message (the current way), or by 
sending it
separately.


An endpoint is created with every namespace request.  There should be
one namespace request for every GPIO controller, which yields a unique
endpoint for each controller and eliminates the need for an extra
field to identify them.



Right, but this can still be done by just having one namespace request.
We can create new endpoints bound to an existing namespace/channel by
invoking rpmsg_create_ept(). This is what I suggested here too:
https://lore.kernel.org/all/29485742-6e49-482e-b73d-228295daa...@ti.com/



I will look at your suggestion (i.e link above) later this week or next week.


My mental model looks like this for the complete picture:

1. namespace/channel#1 = rpmsg-io
 a. ept1 -> gpio-controller@1
 b. ept2 -> gpio-controller@2



I've asked for one endpoint per GPIO controller since the very
beginning.  I don't yet have a strong opinion on whether to use one
namespace request per GPIO controller or a single request that spins
off multiple endpoints.  I'll have to look at your link and reflect on
that.  Regardless of how we proceed on that front, multiplexing needs
to happen at the endpoint level rather than the packet level.  This is
the only way this work can move forward.



I would be more in favor of Mathieu’s proposal: “An endpoint is created 
with every namespace request.”


If the endpoint is created only on the Linux side, how do we match the 
Linux endpoint address with the local port field on the remote side?


With a multi-namespace approach, the namespace could be rpmsg-io-[addr], 
where [addr] corresponds to the GPIO controller address in the DT. This 
would:


- match the RPMsg probe with the DT,
- provide a simple mapping between the port and the endpoint on both sides,
- allow multiple endpoints on the remote side,
- provide a simple discovery mechanism for remote capabilities.

Regards,
Arnaud


2. namespace/channel#2 = rpmsg-i2c
 a. ept1 -> i2c@1
 b. ept2 -> i2c@2
 c. ept3 -> i2c@3

etc...

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

[Shenwei Wang]

> -Original Message-
> From: Padhi, Beleswar 
> Sent: Wednesday, April 29, 2026 9:36 AM
> To: Shenwei Wang ; Linus Walleij
> ; Bartosz Golaszewski ; Jonathan Corbet
> ; Rob Herring ; Krzysztof Kozlowski
> ; Conor Dooley ; Bjorn Andersson
> ; Mathieu Poirier ; Frank Li
> ; Sascha Hauer 
> Cc: Shuah Khan ; linux-g...@vger.kernel.org; linux-
> d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> ; Fabio Estevam ; Peng Fan
> ; devicet...@vger.kernel.org; linux-
> remotep...@vger.kernel.org; i...@lists.linux.dev; linux-arm-
> ker...@lists.infradead.org; dl-linux-imx ; Bartosz
> Golaszewski ; Andrew Lunn 
> 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 
> >> Sent: Tuesday, April 28, 2026 10:53 AM
> >> To: Shenwei Wang ; Linus Walleij
> >> ; Bartosz Golaszewski ; Jonathan
> >> Corbet ; Rob Herring ; Krzysztof
> >> Kozlowski ; Conor Dooley ;
> >> Bjorn Andersson ; Mathieu Poirier
> >> ; Frank Li ; Sascha
> >> Hauer 
> >> Cc: Shuah Khan ;
> >> linux-g...@vger.kernel.org; linux- d...@vger.kernel.org;
> >> linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> >> ; Fabio Estevam ; Peng Fan
> >> ; devicet...@vger.kernel.org; linux-
> >> remotep...@vger.kernel.org; i...@lists.linux.dev; linux-arm-
> >> ker...@lists.infradead.org; dl-linux-imx ; Bartosz
> >> Golaszewski ; Andrew Lunn 
> >> 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.

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

[Mathieu Poirier]

On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar  wrote:
>
> Hi Mathieu,
>
> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
> > On Wed, 29 Apr 2026 at 10:53, Shenwei Wang  wrote:
> >>
> >>
> >>> -Original Message-
> >>> From: Mathieu Poirier 
> >>> Sent: Wednesday, April 29, 2026 10:42 AM
> >>> To: Shenwei Wang 
> >>> Cc: Andrew Lunn ; Padhi, Beleswar ; Linus
> >>> Walleij ; Bartosz Golaszewski ; 
> >>> Jonathan
> >>> Corbet ; Rob Herring ; Krzysztof 
> >>> Kozlowski
> >>> ; Conor Dooley ; Bjorn Andersson
> >>> ; Frank Li ; Sascha Hauer
> >>> ; Shuah Khan ; linux-
> >>> g...@vger.kernel.org; linux-...@vger.kernel.org; 
> >>> linux-kernel@vger.kernel.org;
> >>> Pengutronix Kernel Team ; Fabio Estevam
> >>> ; Peng Fan ;
> >>> devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org;
> >>> i...@lists.linux.dev; linux-arm-ker...@lists.infradead.org; dl-linux-imx 
> >>>  >>> i...@nxp.com>; Bartosz Golaszewski 
> >>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO 
> >>> driver
> >>> On Tue, Apr 28, 2026 at 03:24:59PM +, Shenwei Wang wrote:
> >>>>
> >>>>> -Original Message-
> >>>>> From: Andrew Lunn 
> >>>>> Sent: Monday, April 27, 2026 3:49 PM
> >>>>> To: Shenwei Wang 
> >>>>> Cc: Padhi, Beleswar ; Linus Walleij
> >>>>> ; Bartosz Golaszewski ; Jonathan
> >>>>> Corbet ; Rob Herring ; Krzysztof
> >>>>> Kozlowski ; Conor Dooley ;
> >>>>> Bjorn Andersson ; Mathieu Poirier
> >>>>> ; Frank Li ; Sascha
> >>>>> Hauer ; Shuah Khan
> >>>>> ; linux-g...@vger.kernel.org; linux-
> >>>>> d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
> >>>>> Kernel Team ; Fabio Estevam
> >>>>> ; Peng Fan ;
> >>>>> devicet...@vger.kernel.org; linux- remotep...@vger.kernel.org;
> >>>>> i...@lists.linux.dev; linux-arm- ker...@lists.infradead.org;
> >>>>> dl-linux-imx ; Bartosz Golaszewski
> >>>>> 
> >>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
> >>>>> GPIO driver
> >>>>>>> struct virtio_gpio_response {
> >>>>>>>  __u8 status;
> >>>>>>>  __u8 value;
> >>>>>>> };
> >>>>>> It is the same message format. Please see the message definition
> >>>>> (GET_DIRECTION) below:
> >>>>>
> >>>>>> +   +-+-+-+-+-++
> >>>>>> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> >>>>>> +   | 1   | 2   |port |line | err | dir|
> >>>>>> +   +-+-+-+-+-++
> >>>>> Sorry, but i don't see how two u8 vs six u8 are the same message format.
> >>>>>
> >>>> Some changes to the message format are necessary.
> >>>>
> >>>> Virtio uses two communication channels (virtqueues): one for requests and
> >>> replies, and a second one for events.
> >>>> In contrast, rpmsg provides only a single communication channel, so a
> >>>> type field is required to distinguish between different kinds of 
> >>>> messages.
> >>>>
> >>>> Since rpmsg replies and events share the same message format, an 
> >>>> additional
> >>> line is introduced to handle both cases.
> >>>> Finally, rpmsg supports multiple GPIO controllers, so a port field is 
> >>>> added to
> >>> uniquely identify the target controller.
> >>>
> >>> I have commented on this before - RPMSG is already providing multiplexing
> >>> capability by way of endpoints.  There is no need for a port field.  One 
> >>> endpoint,
> >>> one GPIO controller.
> >>>
> >> You still need a way to let the remote side know which port the endpoint 
> >> maps to, either
> >> by embedding the port information in the message (the current way), or by 
> >> sending it
> >> separately.
> >>
> > An endpoint is created with every namespace request.  There should be
> > one namespace request for every GPIO controller, which yie

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

[Padhi, Beleswar]

On 4/30/2026 12:05 AM, Shenwei Wang wrote:



-Original Message-
From: Padhi, Beleswar 
Sent: Wednesday, April 29, 2026 1:07 PM
To: Mathieu Poirier ; Shenwei Wang

Cc: Andrew Lunn ; Linus Walleij ; Bartosz
Golaszewski ; Jonathan Corbet ; Rob Herring
; Krzysztof Kozlowski ; Conor Dooley
; Bjorn Andersson ; Frank Li
; Sascha Hauer ; Shuah Khan
; linux-g...@vger.kernel.org; linux-
d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
; Fabio Estevam ; Peng Fan
; devicet...@vger.kernel.org; linux-
remotep...@vger.kernel.org; i...@lists.linux.dev; linux-arm-
ker...@lists.infradead.org; dl-linux-imx ; Bartosz
Golaszewski 
Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
Hi Mathieu,

On 4/29/2026 11:03 PM, Mathieu Poirier wrote:

On Wed, 29 Apr 2026 at 10:53, Shenwei Wang 

wrote:



-Original Message-
From: Mathieu Poirier 
Sent: Wednesday, April 29, 2026 10:42 AM
To: Shenwei Wang 
Cc: Andrew Lunn ; Padhi, Beleswar ;
Linus Walleij ; Bartosz Golaszewski
; Jonathan Corbet ; Rob Herring
; Krzysztof Kozlowski ; Conor
Dooley ; Bjorn Andersson
; Frank Li ; Sascha Hauer
; Shuah Khan ;
linux- g...@vger.kernel.org; linux-...@vger.kernel.org;
linux-kernel@vger.kernel.org; Pengutronix Kernel Team
; Fabio Estevam ; Peng
Fan ; devicet...@vger.kernel.org;
linux-remotep...@vger.kernel.org; i...@lists.linux.dev;
linux-arm-ker...@lists.infradead.org; dl-linux-imx ; Bartosz Golaszewski 
Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
GPIO driver On Tue, Apr 28, 2026 at 03:24:59PM +, Shenwei Wang

wrote:

-Original Message-
From: Andrew Lunn 
Sent: Monday, April 27, 2026 3:49 PM
To: Shenwei Wang 
Cc: Padhi, Beleswar ; Linus Walleij
; Bartosz Golaszewski ;
Jonathan Corbet ; Rob Herring ;
Krzysztof Kozlowski ; Conor Dooley
; Bjorn Andersson ;
Mathieu Poirier ; Frank Li
; Sascha Hauer ; Shuah
Khan ; linux-g...@vger.kernel.org;
linux- d...@vger.kernel.org; linux-kernel@vger.kernel.org;
Pengutronix Kernel Team ; Fabio Estevam
; Peng Fan ;
devicet...@vger.kernel.org; linux- remotep...@vger.kernel.org;
i...@lists.linux.dev; linux-arm- ker...@lists.infradead.org;
dl-linux-imx ; Bartosz Golaszewski

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

struct virtio_gpio_response {
  __u8 status;
  __u8 value;
};

It is the same message format. Please see the message definition

(GET_DIRECTION) below:


+   +-+-+-+-+-++
+   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+   | 1   | 2   |port |line | err | dir|
+   +-+-+-+-+-++

Sorry, but i don't see how two u8 vs six u8 are the same message format.


Some changes to the message format are necessary.

Virtio uses two communication channels (virtqueues): one for
requests and

replies, and a second one for events.

In contrast, rpmsg provides only a single communication channel, so
a type field is required to distinguish between different kinds of messages.

Since rpmsg replies and events share the same message format, an
additional

line is introduced to handle both cases.

Finally, rpmsg supports multiple GPIO controllers, so a port field
is added to

uniquely identify the target controller.

I have commented on this before - RPMSG is already providing
multiplexing capability by way of endpoints.  There is no need for a
port field.  One endpoint, one GPIO controller.


You still need a way to let the remote side know which port the
endpoint maps to, either by embedding the port information in the
message (the current way), or by sending it separately.


An endpoint is created with every namespace request.  There should be
one namespace request for every GPIO controller, which yields a unique
endpoint for each controller and eliminates the need for an extra
field to identify them.


Right, but this can still be done by just having one namespace request.
We can create new endpoints bound to an existing namespace/channel by
invoking rpmsg_create_ept(). This is what I suggested here too:
https://lore.kernel/
.org%2Fall%2F29485742-6e49-482e-b73d-
228295daaeec%40ti.com%2F&data=05%7C02%7Cshenwei.wang%40nxp.com%7
Caba62d7a899849fd57f708dea61a1d8b%7C686ea1d3bc2b4c6fa92cd99c5c3016
35%7C0%7C0%7C639130828278097401%7CUnknown%7CTWFpbGZsb3d8eyJFb
XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb
CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NLLYQ0NZCnYKLT%2F2OMDZE
SKgC%2Fme3FoUNqqEGBOIY2k%3D&reserved=0

My mental model looks like this for the complete picture:

1. namespace/channel#1 = rpmsg-io
 a. ept1 -> gpio-controller@1
 b. ept2 -> gpio-controller@2

2. namespace/channel#2 = rpmsg-i2c
 a. ept1 -> i2c@1
 b. ept2 -> i2c@2
 c. ept3 -> i2c@3


The GPIO nodes will act as providers.
Mapping the port index into the service name is a possible solution,



I am not suggesting this. Infact the opposite. Let there be a single
rpmsg service "rpmsg-io" for gpio.

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

[Shenwei Wang]

> -Original Message-
> From: Padhi, Beleswar 
> Sent: Wednesday, April 29, 2026 1:07 PM
> To: Mathieu Poirier ; Shenwei Wang
> 
> Cc: Andrew Lunn ; Linus Walleij ; Bartosz
> Golaszewski ; Jonathan Corbet ; Rob Herring
> ; Krzysztof Kozlowski ; Conor Dooley
> ; Bjorn Andersson ; Frank Li
> ; Sascha Hauer ; Shuah Khan
> ; linux-g...@vger.kernel.org; linux-
> d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> ; Fabio Estevam ; Peng Fan
> ; devicet...@vger.kernel.org; linux-
> remotep...@vger.kernel.org; i...@lists.linux.dev; linux-arm-
> ker...@lists.infradead.org; dl-linux-imx ; Bartosz
> Golaszewski 
> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> Hi Mathieu,
>
> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
> > On Wed, 29 Apr 2026 at 10:53, Shenwei Wang 
> wrote:
> >>
> >>
> >>> -Original Message-
> >>> From: Mathieu Poirier 
> >>> Sent: Wednesday, April 29, 2026 10:42 AM
> >>> To: Shenwei Wang 
> >>> Cc: Andrew Lunn ; Padhi, Beleswar ;
> >>> Linus Walleij ; Bartosz Golaszewski
> >>> ; Jonathan Corbet ; Rob Herring
> >>> ; Krzysztof Kozlowski ; Conor
> >>> Dooley ; Bjorn Andersson
> >>> ; Frank Li ; Sascha Hauer
> >>> ; Shuah Khan ;
> >>> linux- g...@vger.kernel.org; linux-...@vger.kernel.org;
> >>> linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> >>> ; Fabio Estevam ; Peng
> >>> Fan ; devicet...@vger.kernel.org;
> >>> linux-remotep...@vger.kernel.org; i...@lists.linux.dev;
> >>> linux-arm-ker...@lists.infradead.org; dl-linux-imx  >>> i...@nxp.com>; Bartosz Golaszewski 
> >>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
> >>> GPIO driver On Tue, Apr 28, 2026 at 03:24:59PM +, Shenwei Wang
> wrote:
> >>>>
> >>>>> -Original Message-
> >>>>> From: Andrew Lunn 
> >>>>> Sent: Monday, April 27, 2026 3:49 PM
> >>>>> To: Shenwei Wang 
> >>>>> Cc: Padhi, Beleswar ; Linus Walleij
> >>>>> ; Bartosz Golaszewski ;
> >>>>> Jonathan Corbet ; Rob Herring ;
> >>>>> Krzysztof Kozlowski ; Conor Dooley
> >>>>> ; Bjorn Andersson ;
> >>>>> Mathieu Poirier ; Frank Li
> >>>>> ; Sascha Hauer ; Shuah
> >>>>> Khan ; linux-g...@vger.kernel.org;
> >>>>> linux- d...@vger.kernel.org; linux-kernel@vger.kernel.org;
> >>>>> Pengutronix Kernel Team ; Fabio Estevam
> >>>>> ; Peng Fan ;
> >>>>> devicet...@vger.kernel.org; linux- remotep...@vger.kernel.org;
> >>>>> i...@lists.linux.dev; linux-arm- ker...@lists.infradead.org;
> >>>>> dl-linux-imx ; Bartosz Golaszewski
> >>>>> 
> >>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
> >>>>> GPIO driver
> >>>>>>> struct virtio_gpio_response {
> >>>>>>>  __u8 status;
> >>>>>>>  __u8 value;
> >>>>>>> };
> >>>>>> It is the same message format. Please see the message definition
> >>>>> (GET_DIRECTION) below:
> >>>>>
> >>>>>> +   +-+-+-+-+-++
> >>>>>> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> >>>>>> +   | 1   | 2   |port |line | err | dir|
> >>>>>> +   +-+-+-+-+-++
> >>>>> Sorry, but i don't see how two u8 vs six u8 are the same message format.
> >>>>>
> >>>> Some changes to the message format are necessary.
> >>>>
> >>>> Virtio uses two communication channels (virtqueues): one for
> >>>> requests and
> >>> replies, and a second one for events.
> >>>> In contrast, rpmsg provides only a single communication channel, so
> >>>> a type field is required to distinguish between different kinds of 
> >>>> messages.
> >>>>
> >>>> Since rpmsg replies and events share the same message format, an
> >>>> additional
> >>> line is introduced to handle both cases.
> >>>> Finally, rpmsg supports multiple GPIO controllers, so a port field
> >>>> is added to
> >>> uniquely identify the target controller.
> >>>
&

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

[Andrew Lunn]

> About this, we only need to do this because you are defining the gpio
> controller instances "statically" in the device tree. I understand gpio
> nodes can act as providers, but I do not see any device referencing the
> gpio nodes you are defining in the device tree.

They probably come later, and a board specific. The GPIO controllers
are probably SoC specific, so can be defined at the SoC .dtsi
level. The users are then in the board .dts files.

This is how GPIOs are typically used. Same will be true of I2C, the
SoC provides the I2C adaptor, the boards have devices on the bus,
again, described in DT.

   Andrew

 

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

[Padhi, Beleswar]

Hi Mathieu,

On 4/29/2026 11:03 PM, Mathieu Poirier wrote:

On Wed, 29 Apr 2026 at 10:53, Shenwei Wang  wrote:




-Original Message-
From: Mathieu Poirier 
Sent: Wednesday, April 29, 2026 10:42 AM
To: Shenwei Wang 
Cc: Andrew Lunn ; Padhi, Beleswar ; Linus
Walleij ; Bartosz Golaszewski ; Jonathan
Corbet ; Rob Herring ; Krzysztof Kozlowski
; Conor Dooley ; Bjorn Andersson
; Frank Li ; Sascha Hauer
; Shuah Khan ; linux-
g...@vger.kernel.org; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
Pengutronix Kernel Team ; Fabio Estevam
; Peng Fan ;
devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org;
i...@lists.linux.dev; linux-arm-ker...@lists.infradead.org; dl-linux-imx ; Bartosz Golaszewski 
Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
On Tue, Apr 28, 2026 at 03:24:59PM +, Shenwei Wang wrote:



-Original Message-
From: Andrew Lunn 
Sent: Monday, April 27, 2026 3:49 PM
To: Shenwei Wang 
Cc: Padhi, Beleswar ; Linus Walleij
; Bartosz Golaszewski ; Jonathan
Corbet ; Rob Herring ; Krzysztof
Kozlowski ; Conor Dooley ;
Bjorn Andersson ; Mathieu Poirier
; Frank Li ; Sascha
Hauer ; Shuah Khan
; linux-g...@vger.kernel.org; linux-
d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
Kernel Team ; Fabio Estevam
; Peng Fan ;
devicet...@vger.kernel.org; linux- remotep...@vger.kernel.org;
i...@lists.linux.dev; linux-arm- ker...@lists.infradead.org;
dl-linux-imx ; Bartosz Golaszewski

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

struct virtio_gpio_response {
 __u8 status;
 __u8 value;
};

It is the same message format. Please see the message definition

(GET_DIRECTION) below:


+   +-+-+-+-+-++
+   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+   | 1   | 2   |port |line | err | dir|
+   +-+-+-+-+-++

Sorry, but i don't see how two u8 vs six u8 are the same message format.


Some changes to the message format are necessary.

Virtio uses two communication channels (virtqueues): one for requests and

replies, and a second one for events.

In contrast, rpmsg provides only a single communication channel, so a
type field is required to distinguish between different kinds of messages.

Since rpmsg replies and events share the same message format, an additional

line is introduced to handle both cases.

Finally, rpmsg supports multiple GPIO controllers, so a port field is added to

uniquely identify the target controller.

I have commented on this before - RPMSG is already providing multiplexing
capability by way of endpoints.  There is no need for a port field.  One 
endpoint,
one GPIO controller.


You still need a way to let the remote side know which port the endpoint maps 
to, either
by embedding the port information in the message (the current way), or by 
sending it
separately.


An endpoint is created with every namespace request.  There should be
one namespace request for every GPIO controller, which yields a unique
endpoint for each controller and eliminates the need for an extra
field to identify them.



Right, but this can still be done by just having one namespace request.
We can create new endpoints bound to an existing namespace/channel by
invoking rpmsg_create_ept(). This is what I suggested here too:
https://lore.kernel.org/all/29485742-6e49-482e-b73d-228295daa...@ti.com/

My mental model looks like this for the complete picture:

1. namespace/channel#1 = rpmsg-io
   a. ept1 -> gpio-controller@1
   b. ept2 -> gpio-controller@2

2. namespace/channel#2 = rpmsg-i2c
   a. ept1 -> i2c@1
   b. ept2 -> i2c@2
   c. ept3 -> i2c@3

etc...

This way device groups are isolated with each channel/namespace, and
instances within each device groups are also respected with specific
endpoints.

Thanks,
Beleswar

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

[Padhi, Beleswar]

On 4/29/2026 10:23 PM, Shenwei Wang wrote:



-Original Message-
From: Mathieu Poirier 
Sent: Wednesday, April 29, 2026 10:42 AM
To: Shenwei Wang 
Cc: Andrew Lunn ; Padhi, Beleswar ; Linus
Walleij ; Bartosz Golaszewski ; Jonathan
Corbet ; Rob Herring ; Krzysztof Kozlowski
; Conor Dooley ; Bjorn Andersson
; Frank Li ; Sascha Hauer
; Shuah Khan ; linux-
g...@vger.kernel.org; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
Pengutronix Kernel Team ; Fabio Estevam
; Peng Fan ;
devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org;
i...@lists.linux.dev; linux-arm-ker...@lists.infradead.org; dl-linux-imx ; Bartosz Golaszewski 
Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
On Tue, Apr 28, 2026 at 03:24:59PM +, Shenwei Wang wrote:



-Original Message-
From: Andrew Lunn 
Sent: Monday, April 27, 2026 3:49 PM
To: Shenwei Wang 
Cc: Padhi, Beleswar ; Linus Walleij
; Bartosz Golaszewski ; Jonathan
Corbet ; Rob Herring ; Krzysztof
Kozlowski ; Conor Dooley ;
Bjorn Andersson ; Mathieu Poirier
; Frank Li ; Sascha
Hauer ; Shuah Khan
; linux-g...@vger.kernel.org; linux-
d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
Kernel Team ; Fabio Estevam
; Peng Fan ;
devicet...@vger.kernel.org; linux- remotep...@vger.kernel.org;
i...@lists.linux.dev; linux-arm- ker...@lists.infradead.org;
dl-linux-imx ; Bartosz Golaszewski

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

struct virtio_gpio_response {
 __u8 status;
 __u8 value;
};

It is the same message format. Please see the message definition

(GET_DIRECTION) below:


+   +-+-+-+-+-++
+   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+   | 1   | 2   |port |line | err | dir|
+   +-+-+-+-+-++

Sorry, but i don't see how two u8 vs six u8 are the same message format.


Some changes to the message format are necessary.

Virtio uses two communication channels (virtqueues): one for requests and

replies, and a second one for events.

In contrast, rpmsg provides only a single communication channel, so a
type field is required to distinguish between different kinds of messages.

Since rpmsg replies and events share the same message format, an additional

line is introduced to handle both cases.

Finally, rpmsg supports multiple GPIO controllers, so a port field is added to

uniquely identify the target controller.

I have commented on this before - RPMSG is already providing multiplexing
capability by way of endpoints.  There is no need for a port field.  One 
endpoint,
one GPIO controller.


You still need a way to let the remote side know which port the endpoint maps 
to,



About this, we only need to do this because you are defining the gpio
controller instances "statically" in the device tree. I understand gpio
nodes can act as providers, but I do not see any device referencing the
gpio nodes you are defining in the device tree. If that is the case, you
can completely remove the nodes from device tree, and "dynamically"
announce the existence of these nodes from the firmware itself
(similar to what is done for rpmsg-tty currently). In response to that
announce message, Linux could send the "ept" it allocated for the
controller. That way, Linux only cares about "ept" and there is no need
to maintain port 'idx' info anywhere in the Linux side anymore.

Thanks,
Beleswar

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

[Mathieu Poirier]

On Wed, 29 Apr 2026 at 10:53, Shenwei Wang  wrote:
>
>
>
> > -Original Message-
> > From: Mathieu Poirier 
> > Sent: Wednesday, April 29, 2026 10:42 AM
> > To: Shenwei Wang 
> > Cc: Andrew Lunn ; Padhi, Beleswar ; Linus
> > Walleij ; Bartosz Golaszewski ; Jonathan
> > Corbet ; Rob Herring ; Krzysztof Kozlowski
> > ; Conor Dooley ; Bjorn Andersson
> > ; Frank Li ; Sascha Hauer
> > ; Shuah Khan ; linux-
> > g...@vger.kernel.org; linux-...@vger.kernel.org; 
> > linux-kernel@vger.kernel.org;
> > Pengutronix Kernel Team ; Fabio Estevam
> > ; Peng Fan ;
> > devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org;
> > i...@lists.linux.dev; linux-arm-ker...@lists.infradead.org; dl-linux-imx 
> >  > i...@nxp.com>; Bartosz Golaszewski 
> > Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO 
> > driver
> > On Tue, Apr 28, 2026 at 03:24:59PM +, Shenwei Wang wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Andrew Lunn 
> > > > Sent: Monday, April 27, 2026 3:49 PM
> > > > To: Shenwei Wang 
> > > > Cc: Padhi, Beleswar ; Linus Walleij
> > > > ; Bartosz Golaszewski ; Jonathan
> > > > Corbet ; Rob Herring ; Krzysztof
> > > > Kozlowski ; Conor Dooley ;
> > > > Bjorn Andersson ; Mathieu Poirier
> > > > ; Frank Li ; Sascha
> > > > Hauer ; Shuah Khan
> > > > ; linux-g...@vger.kernel.org; linux-
> > > > d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
> > > > Kernel Team ; Fabio Estevam
> > > > ; Peng Fan ;
> > > > devicet...@vger.kernel.org; linux- remotep...@vger.kernel.org;
> > > > i...@lists.linux.dev; linux-arm- ker...@lists.infradead.org;
> > > > dl-linux-imx ; Bartosz Golaszewski
> > > > 
> > > > Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
> > > > GPIO driver
> > > > > > struct virtio_gpio_response {
> > > > > > __u8 status;
> > > > > > __u8 value;
> > > > > > };
> > > >
> > > > > It is the same message format. Please see the message definition
> > > > (GET_DIRECTION) below:
> > > >
> > > > > +   +-+-+-+-+-++
> > > > > +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> > > > > +   | 1   | 2   |port |line | err | dir|
> > > > > +   +-+-+-+-+-++
> > > >
> > > > Sorry, but i don't see how two u8 vs six u8 are the same message format.
> > > >
> > >
> > > Some changes to the message format are necessary.
> > >
> > > Virtio uses two communication channels (virtqueues): one for requests and
> > replies, and a second one for events.
> > > In contrast, rpmsg provides only a single communication channel, so a
> > > type field is required to distinguish between different kinds of messages.
> > >
> > > Since rpmsg replies and events share the same message format, an 
> > > additional
> > line is introduced to handle both cases.
> > >
> > > Finally, rpmsg supports multiple GPIO controllers, so a port field is 
> > > added to
> > uniquely identify the target controller.
> >
> > I have commented on this before - RPMSG is already providing multiplexing
> > capability by way of endpoints.  There is no need for a port field.  One 
> > endpoint,
> > one GPIO controller.
> >
>
> You still need a way to let the remote side know which port the endpoint maps 
> to, either
> by embedding the port information in the message (the current way), or by 
> sending it
> separately.
>

An endpoint is created with every namespace request.  There should be
one namespace request for every GPIO controller, which yields a unique
endpoint for each controller and eliminates the need for an extra
field to identify them.

> Shenwei
>
> > >
> > > Shenwei
> > >
> > > >Andrew

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

[Shenwei Wang]

> -Original Message-
> From: Mathieu Poirier 
> Sent: Wednesday, April 29, 2026 10:42 AM
> To: Shenwei Wang 
> Cc: Andrew Lunn ; Padhi, Beleswar ; Linus
> Walleij ; Bartosz Golaszewski ; Jonathan
> Corbet ; Rob Herring ; Krzysztof Kozlowski
> ; Conor Dooley ; Bjorn Andersson
> ; Frank Li ; Sascha Hauer
> ; Shuah Khan ; linux-
> g...@vger.kernel.org; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Pengutronix Kernel Team ; Fabio Estevam
> ; Peng Fan ;
> devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org;
> i...@lists.linux.dev; linux-arm-ker...@lists.infradead.org; dl-linux-imx 
>  i...@nxp.com>; Bartosz Golaszewski 
> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> On Tue, Apr 28, 2026 at 03:24:59PM +, Shenwei Wang wrote:
> >
> >
> > > -Original Message-
> > > From: Andrew Lunn 
> > > Sent: Monday, April 27, 2026 3:49 PM
> > > To: Shenwei Wang 
> > > Cc: Padhi, Beleswar ; Linus Walleij
> > > ; Bartosz Golaszewski ; Jonathan
> > > Corbet ; Rob Herring ; Krzysztof
> > > Kozlowski ; Conor Dooley ;
> > > Bjorn Andersson ; Mathieu Poirier
> > > ; Frank Li ; Sascha
> > > Hauer ; Shuah Khan
> > > ; linux-g...@vger.kernel.org; linux-
> > > d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
> > > Kernel Team ; Fabio Estevam
> > > ; Peng Fan ;
> > > devicet...@vger.kernel.org; linux- remotep...@vger.kernel.org;
> > > i...@lists.linux.dev; linux-arm- ker...@lists.infradead.org;
> > > dl-linux-imx ; Bartosz Golaszewski
> > > 
> > > Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
> > > GPIO driver
> > > > > struct virtio_gpio_response {
> > > > > __u8 status;
> > > > > __u8 value;
> > > > > };
> > >
> > > > It is the same message format. Please see the message definition
> > > (GET_DIRECTION) below:
> > >
> > > > +   +-+-+-+-+-++
> > > > +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> > > > +   | 1   | 2   |port |line | err | dir|
> > > > +   +-+-+-+-+-++
> > >
> > > Sorry, but i don't see how two u8 vs six u8 are the same message format.
> > >
> >
> > Some changes to the message format are necessary.
> >
> > Virtio uses two communication channels (virtqueues): one for requests and
> replies, and a second one for events.
> > In contrast, rpmsg provides only a single communication channel, so a
> > type field is required to distinguish between different kinds of messages.
> >
> > Since rpmsg replies and events share the same message format, an additional
> line is introduced to handle both cases.
> >
> > Finally, rpmsg supports multiple GPIO controllers, so a port field is added 
> > to
> uniquely identify the target controller.
> 
> I have commented on this before - RPMSG is already providing multiplexing
> capability by way of endpoints.  There is no need for a port field.  One 
> endpoint,
> one GPIO controller.
> 

You still need a way to let the remote side know which port the endpoint maps 
to, either 
by embedding the port information in the message (the current way), or by 
sending it 
separately.

Shenwei

> >
> > Shenwei
> >
> > >Andrew

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

[Mathieu Poirier]

On Tue, Apr 28, 2026 at 03:24:59PM +, Shenwei Wang wrote:
> 
> 
> > -Original Message-
> > From: Andrew Lunn 
> > Sent: Monday, April 27, 2026 3:49 PM
> > To: Shenwei Wang 
> > Cc: Padhi, Beleswar ; Linus Walleij ;
> > Bartosz Golaszewski ; Jonathan Corbet ;
> > Rob Herring ; Krzysztof Kozlowski ;
> > Conor Dooley ; Bjorn Andersson
> > ; Mathieu Poirier ; Frank 
> > Li
> > ; Sascha Hauer ; Shuah Khan
> > ; linux-g...@vger.kernel.org; linux-
> > d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> > ; Fabio Estevam ; Peng Fan
> > ; devicet...@vger.kernel.org; linux-
> > remotep...@vger.kernel.org; i...@lists.linux.dev; linux-arm-
> > ker...@lists.infradead.org; dl-linux-imx ; Bartosz
> > Golaszewski 
> > Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO 
> > driver
> > > > struct virtio_gpio_response {
> > > > __u8 status;
> > > > __u8 value;
> > > > };
> > 
> > > It is the same message format. Please see the message definition
> > (GET_DIRECTION) below:
> > 
> > > +   +-+-+-+-+-++
> > > +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> > > +   | 1   | 2   |port |line | err | dir|
> > > +   +-+-+-+-+-++
> > 
> > Sorry, but i don't see how two u8 vs six u8 are the same message format.
> > 
> 
> Some changes to the message format are necessary.
> 
> Virtio uses two communication channels (virtqueues): one for requests and 
> replies, and a second one for events. 
> In contrast, rpmsg provides only a single communication channel, so a type 
> field is required to distinguish between 
> different kinds of messages.
> 
> Since rpmsg replies and events share the same message format, an additional 
> line is introduced to handle both cases.
> 
> Finally, rpmsg supports multiple GPIO controllers, so a port field is added 
> to uniquely identify the target controller.

I have commented on this before - RPMSG is already providing multiplexing
capability by way of endpoints.  There is no need for a port field.  One
endpoint, one GPIO controller. 

> 
> Shenwei
> 
> >Andrew

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

[Padhi, Beleswar]

On 4/28/2026 11:35 PM, Andrew Lunn wrote:

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:

I've never used rpmsg, so this might be a FAQ. How does the remote
side know what the endpoint is to be used for? Here we are talking
about GPIO. But the same hardware implements I2C, and a few other
things. How do we indicate this endpoint is for GPIO?



That's where the channel level isolation helps. GPIO ports are announced
over "rpmsg-io" channel (parent of endpoint), i2c devices would be
announced over "rpmsg-i2c" channel. The default epts in those channels
would have separate addresses (e.g. 0xd for rpmsg-io and 0xe for
rpmsg-i2c). The remote side would have bound a gpio_handling callback
on addr 0xd and a i2c_handling callback on addr 0xe while doing the
channel announcement. So while sending a GPIO msg from Linux, we
should direct it to 0xd dst endpoint, and for sending a i2c message, we
should direct it to 0xe dst endpoint (src ept can be anything). And without
any extra effort, messages sent from dynamic epts at Linux land in the
appropriate handler at remote even for separate device types.



Maybe also related, this hardware also supports a number of GPIO
controllers. There has been some argument about if one endpoint should
support multiple GPIO controllers.



IMO no...


  Or, like gpio-virtio, one endpoint
represents one GPIO controller, and you instantiate multiple
endpoints, one per controller.



Yes, this is what I am suggesting in the review of this version.
Basically there should be one rpmsg channel per device type
(e.g. gpio/i2c), and multiple rpmsg endpoints in one channel
representing each instance of the device (e.g. gpio1, gpio2 etc.)


  How can you tell the different
instances of GPIO endpoints apart when they are dynamically created?



Well by 2 ways:
1. We can maintain a map of the dynamically created ept and its
    corresponding instance number.This is useful while sending a message
    for a particular instance.
2. rpmsg_create_ept() takes a private data argument, so we just bind the
    per-instance data (struct rpmsg_gpio_port * in this case) to the ept.
    This is useful while receiving a message for a particular instance.

I have suggested an implementation for the same here:
https://lore.kernel.org/all/29485742-6e49-482e-b73d-228295daa...@ti.com/

Thanks,
Beleswar

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

[Padhi, Beleswar]

On 4/28/2026 10:06 PM, Shenwei Wang wrote:



-Original Message-
From: Padhi, Beleswar 
Sent: Tuesday, April 28, 2026 10:53 AM
To: Shenwei Wang ; Linus Walleij
; Bartosz Golaszewski ; Jonathan Corbet
; Rob Herring ; Krzysztof Kozlowski
; Conor Dooley ; Bjorn Andersson
; Mathieu Poirier ; Frank Li
; Sascha Hauer 
Cc: Shuah Khan ; linux-g...@vger.kernel.org; linux-
d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
; Fabio Estevam ; Peng Fan
; devicet...@vger.kernel.org; linux-
remotep...@vger.kernel.org; i...@lists.linux.dev; linux-arm-
ker...@lists.infradead.org; dl-linux-imx ; Bartosz
Golaszewski ; Andrew Lunn 
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

[...]

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

[Andrew Lunn]

> 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:

I've never used rpmsg, so this might be a FAQ. How does the remote
side know what the endpoint is to be used for? Here we are talking
about GPIO. But the same hardware implements I2C, and a few other
things. How do we indicate this endpoint is for GPIO?

Maybe also related, this hardware also supports a number of GPIO
controllers. There has been some argument about if one endpoint should
support multiple GPIO controllers. Or, like gpio-virtio, one endpoint
represents one GPIO controller, and you instantiate multiple
endpoints, one per controller. How can you tell the different
instances of GPIO endpoints apart when they are dynamically created?

   Andrew

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

[Shenwei Wang]

> -Original Message-
> From: Padhi, Beleswar 
> Sent: Tuesday, April 28, 2026 10:53 AM
> To: Shenwei Wang ; Linus Walleij
> ; Bartosz Golaszewski ; Jonathan Corbet
> ; Rob Herring ; Krzysztof Kozlowski
> ; Conor Dooley ; Bjorn Andersson
> ; Mathieu Poirier ; Frank Li
> ; Sascha Hauer 
> Cc: Shuah Khan ; linux-g...@vger.kernel.org; linux-
> d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> ; Fabio Estevam ; Peng Fan
> ; devicet...@vger.kernel.org; linux-
> remotep...@vger.kernel.org; i...@lists.linux.dev; linux-arm-
> ker...@lists.infradead.org; dl-linux-imx ; Bartosz
> Golaszewski ; Andrew Lunn 
> 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=OUmjqOdWqiXSTjPDv1TUvrjKP1YTx9ji44SdGl

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

[Shenwei Wang]

> -Original Message-
> From: Andrew Lunn 
> Sent: Monday, April 27, 2026 3:49 PM
> To: Shenwei Wang 
> Cc: Padhi, Beleswar ; Linus Walleij ;
> Bartosz Golaszewski ; Jonathan Corbet ;
> Rob Herring ; Krzysztof Kozlowski ;
> Conor Dooley ; Bjorn Andersson
> ; Mathieu Poirier ; Frank Li
> ; Sascha Hauer ; Shuah Khan
> ; linux-g...@vger.kernel.org; linux-
> d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> ; Fabio Estevam ; Peng Fan
> ; devicet...@vger.kernel.org; linux-
> remotep...@vger.kernel.org; i...@lists.linux.dev; linux-arm-
> ker...@lists.infradead.org; dl-linux-imx ; Bartosz
> Golaszewski 
> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> > > struct virtio_gpio_response {
> > > __u8 status;
> > > __u8 value;
> > > };
> 
> > It is the same message format. Please see the message definition
> (GET_DIRECTION) below:
> 
> > +   +-+-+-+-+-++
> > +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> > +   | 1   | 2   |port |line | err | dir|
> > +   +-+-+-+-+-++
> 
> Sorry, but i don't see how two u8 vs six u8 are the same message format.
> 

Some changes to the message format are necessary.

Virtio uses two communication channels (virtqueues): one for requests and 
replies, and a second one for events. 
In contrast, rpmsg provides only a single communication channel, so a type 
field is required to distinguish between 
different kinds of messages.

Since rpmsg replies and events share the same message format, an additional 
line is introduced to handle both cases.

Finally, rpmsg supports multiple GPIO controllers, so a port field is added to 
uniquely identify the target controller.

Shenwei

>Andrew

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

[Shenwei Wang]

> -Original Message-
> From: Beleswar Prasad Padhi 
> Sent: Tuesday, April 28, 2026 2:25 AM
> To: Shenwei Wang ; Linus Walleij
> ; Bartosz Golaszewski ; Jonathan Corbet
> ; Rob Herring ; Krzysztof Kozlowski
> ; Conor Dooley ; Bjorn Andersson
> ; Mathieu Poirier ; Frank Li
> ; Sascha Hauer 
> Cc: Shuah Khan ; linux-g...@vger.kernel.org; linux-
> d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> ; Fabio Estevam ; Peng Fan
> ; devicet...@vger.kernel.org; linux-
> remotep...@vger.kernel.org; i...@lists.linux.dev; linux-arm-
> ker...@lists.infradead.org; dl-linux-imx ; Bartosz
> Golaszewski ; Andrew Lunn 
> 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?
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().
> 

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

[Padhi, Beleswar]

On 4/28/2026 9:01 PM, Shenwei Wang wrote:



-Original Message-
From: Padhi, Beleswar 
Sent: Tuesday, April 28, 2026 10:11 AM
To: Shenwei Wang ; Linus Walleij
; Bartosz Golaszewski ; Jonathan Corbet
; Rob Herring ; Krzysztof Kozlowski
; Conor Dooley ; Bjorn Andersson
; Mathieu Poirier ; Frank Li
; Sascha Hauer 
Cc: Shuah Khan ; linux-g...@vger.kernel.org; linux-
d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
; Fabio Estevam ; Peng Fan
; devicet...@vger.kernel.org; linux-
remotep...@vger.kernel.org; i...@lists.linux.dev; linux-arm-
ker...@lists.infradead.org; dl-linux-imx ; Bartosz
Golaszewski ; Andrew Lunn 
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 
Sent: Tuesday, April 28, 2026 2:25 AM
To: Shenwei Wang ; Linus Walleij
; Bartosz Golaszewski ; Jonathan
Corbet ; Rob Herring ; Krzysztof
Kozlowski ; Conor Dooley ;
Bjorn Andersson ; Mathieu Poirier
; Frank Li ; Sascha
Hauer 
Cc: Shuah Khan ;
linux-g...@vger.kernel.org; linux- d...@vger.kernel.org;
linux-kernel@vger.kernel.org; Pengutronix Kernel Team
; Fabio Estevam ; Peng Fan
; devicet...@vger.kernel.org; linux-
remotep...@vger.kernel.org; i...@lists.linux.dev; linux-arm-
ker...@lists.infradead.org; dl-linux-imx ; Bartosz
Golaszewski ; Andrew Lunn 
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?

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

[Shenwei Wang]

> -Original Message-
> From: Padhi, Beleswar 
> Sent: Tuesday, April 28, 2026 10:11 AM
> To: Shenwei Wang ; Linus Walleij
> ; Bartosz Golaszewski ; Jonathan Corbet
> ; Rob Herring ; Krzysztof Kozlowski
> ; Conor Dooley ; Bjorn Andersson
> ; Mathieu Poirier ; Frank Li
> ; Sascha Hauer 
> Cc: Shuah Khan ; linux-g...@vger.kernel.org; linux-
> d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> ; Fabio Estevam ; Peng Fan
> ; devicet...@vger.kernel.org; linux-
> remotep...@vger.kernel.org; i...@lists.linux.dev; linux-arm-
> ker...@lists.infradead.org; dl-linux-imx ; Bartosz
> Golaszewski ; Andrew Lunn 
> 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 
> >> Sent: Tuesday, April 28, 2026 2:25 AM
> >> To: Shenwei Wang ; Linus Walleij
> >> ; Bartosz Golaszewski ; Jonathan
> >> Corbet ; Rob Herring ; Krzysztof
> >> Kozlowski ; Conor Dooley ;
> >> Bjorn Andersson ; Mathieu Poirier
> >> ; Frank Li ; Sascha
> >> Hauer 
> >> Cc: Shuah Khan ;
> >> linux-g...@vger.kernel.org; linux- d...@vger.kernel.org;
> >> linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> >> ; Fabio Estevam ; Peng Fan
> >> ; devicet...@vger.kernel.org; linux-
> >> remotep...@vger.kernel.org; i...@lists.linux.dev; linux-arm-
> >> ker...@lists.infradead.org; dl-linux-imx ; Bartosz
> >> Golaszewski ; Andrew Lunn 
> >> 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%

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

[Padhi, Beleswar]

On 4/28/2026 8:13 PM, Shenwei Wang wrote:



-Original Message-
From: Beleswar Prasad Padhi 
Sent: Tuesday, April 28, 2026 2:25 AM
To: Shenwei Wang ; Linus Walleij
; Bartosz Golaszewski ; Jonathan Corbet
; Rob Herring ; Krzysztof Kozlowski
; Conor Dooley ; Bjorn Andersson
; Mathieu Poirier ; Frank Li
; Sascha Hauer 
Cc: Shuah Khan ; linux-g...@vger.kernel.org; linux-
d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
; Fabio Estevam ; Peng Fan
; devicet...@vger.kernel.org; linux-
remotep...@vger.kernel.org; i...@lists.linux.dev; linux-arm-
ker...@lists.infradead.org; dl-linux-imx ; Bartosz
Golaszewski ; Andrew Lunn 
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 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.com/torvalds/linux/blob/master/drivers/rpmsg/rpmsg_core.c#L480

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

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

[Beleswar Prasad Padhi]

On 28/04/26 00:53, Shenwei Wang wrote:
[...]
>>> +
>>> +struct rpmsg_gpio_packet {
>>> + u8 type;/* Message type */
>>> + u8 cmd; /* Command code */
>>> + u8 port_idx;
>>> + u8 line;
>>> + u8 val1;
>>> + u8 val2;
>>> +};
>>
>> Could you please document the fields in these structs (and the below ones 
>> too)?
>> From the code, it looks like while sending a message from Linux to Firmware; 
>> val1
>> and val2 are used to describe the values to set. Whereas while receiving a
>> response, val1 represents a possible error code, and val2 represents the 
>> actual
>> message of get type queries. If that is so, you might want to change the 
>> variable
>> names to be more descriptive and also use a union.
>>
> The fields in the two structs are fairly self-explanatory. Do we really need 
> the additional comments?


val1 and val2 sounded arbitrary, that's all. If we are moving away from
that, then there is no need :)

[...]

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

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


>
>> This also allows for dynamic creation and deletion of ports too! (if/when the
>> firmware supports it)
>>
>> Which means at port init time, we should make a call to
>> rpmsg_create_ept() for each port tying the same callback
>> rpmsg_gpio_channel_callback(). And based on the 'u32 src', we could identify 
>> the
>> appropriate gpio port in the callback.
>>

[...]
>>
>>> +
>>> + girq = &gc->irq;
>>> + gpio_irq_chip_set_chip(girq, &gpio_rpmsg_irq_chip);
>>> + girq->parent_handler = NULL;
>>> + girq->num_parents = 0;
>>> + girq->parents = NULL;
>>> + girq->chip->name = devm_kasprintf(&rpdev->dev, GFP_KERNEL, "%s-
>> gpio%d",
>>> +   drvdata->rproc_name,
>>> + port->idx);
>>
>> We could just re-use gc->label here...
> We also want to include the remoteproc name (for example, 
> remoteproc-cm33-gpio0), rather than just gpio0.


Isn't it also included in the gc->label field?

gc->label = devm_kasprintf(&rpdev->dev, GFP_KERNEL, "%s-gpio%d",
+                   drvdata->rproc_name, port->idx);

[...]

>>> +}
>>> +
>>> +static int rpmsg_gpio_channel_probe(struct rpmsg_device *rpdev) {
>>> + struct device *dev = &rpdev->dev;
>>> + struct rpdev_drvdata *drvdata;
>>> + struct device_node *np;
>>> + int ret = -ENODEV;
>>> +
>>> + if (!dev->of_node) {
>>> + np = rpmsg_get_channel_ofnode(rpdev, rpdev->id.name);
>>> + if (np) {
>>> + dev->of_node = np;
>>> + set_primary_fwnode(dev, of_fwnode_handle(np));
>>> + }
>>> + return -EPROBE_DEFER;
>>
>> I know this was asked in the v10 version also. But I don't think the answer 
>> is
>> sufficient. Should we not continue the intialization of drvdata etc if np != 
>> 0? Why
>> return a deferred probe, and let the kernel come back to it again to do the 
>> same
>> stuff with extra latency?
>>
>> We could just do:
>> if (!np) return -EPROBE_DEFER;
>> else {everything_else};
>>
> After configuring dev->of_node, it would be better to restart the driver 
> probe process. 
> This ensures that all required resources, such as pinctrl, clocks, and power 
> domains, are 
> properly set up if they are specified in the device node, before the probe 
> function is invoked.


Hmm that makes sense to me... Thanks!

Thanks,
Beleswar

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

[Andrew Lunn]

> > struct virtio_gpio_response {
> > __u8 status;
> > __u8 value;
> > };

> It is the same message format. Please see the message definition 
> (GET_DIRECTION) below:

> +   +-+-+-+-+-++
> +   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
> +   | 1   | 2   |port |line | err | dir|
> +   +-+-+-+-+-++

Sorry, but i don't see how two u8 vs six u8 are the same message
format.

   Andrew

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

[Shenwei Wang]

> -Original Message-
> From: Andrew Lunn 
> Sent: Monday, April 27, 2026 3:28 PM
> To: Shenwei Wang 
> Cc: Padhi, Beleswar ; Linus Walleij ;
> Bartosz Golaszewski ; Jonathan Corbet ;
> Rob Herring ; Krzysztof Kozlowski ;
> Conor Dooley ; Bjorn Andersson
> ; Mathieu Poirier ; Frank Li
> ; Sascha Hauer ; Shuah Khan
> ; linux-g...@vger.kernel.org; linux-
> d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> ; Fabio Estevam ; Peng Fan
> ; devicet...@vger.kernel.org; linux-
> remotep...@vger.kernel.org; i...@lists.linux.dev; linux-arm-
> ker...@lists.infradead.org; dl-linux-imx ; Bartosz
> Golaszewski 
> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> > > > +struct rpmsg_gpio_packet {
> > > > + u8 type;/* Message type */
> > > > + u8 cmd; /* Command code */
> > > > + u8 port_idx;
> > > > + u8 line;
> > > > + u8 val1;
> > > > + u8 val2;
> > > > +};
> > >
> > >
> > > Could you please document the fields in these structs (and the below ones
> too)?
> > > From the code, it looks like while sending a message from Linux to
> > > Firmware; val1 and val2 are used to describe the values to set.
> > > Whereas while receiving a response, val1 represents a possible error
> > > code, and val2 represents the actual message of get type queries. If
> > > that is so, you might want to change the variable names to be more
> descriptive and also use a union.
> > >
> >
> > The fields in the two structs are fairly self-explanatory. Do we really 
> > need the
> additional comments?
> > The previous version of the patch used a union, which was updated to support
> the fixed_up hooks.
> > Now that the fixed_up hooks have been removed, I can revert this back to the
> union-based implementation.
> 
> I thought you had already adopted the virtio message format?
> 
> 
> /* Possible values of the status field */
> #define VIRTIO_GPIO_STATUS_OK   0x0
> #define VIRTIO_GPIO_STATUS_ERR  0x1
> 
> struct virtio_gpio_response {
> __u8 status;
> __u8 value;
> };
> 
> Seems pretty obvious what status means. value depends on the request,
> get_direction actually uses it, and it can be one of
> 
> #define VIRTIO_GPIO_DIRECTION_NONE  0x00
> #define VIRTIO_GPIO_DIRECTION_OUT   0x01
> #define VIRTIO_GPIO_DIRECTION_IN0x02
> 
> and gpio_get uses it as a bool for the state of the GPIO.
> 
> Why do we need all the complexity for val1, val2, etc?
> 

It is the same message format. Please see the message definition 
(GET_DIRECTION) below:

+GET_DIRECTION (Cmd=2)
+~
+
+**Request:**
+
+.. code-block:: none
+
+   +-+-+-+-+-++
+   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+   | 0   | 2   |port |line | 0   | 0  |
+   +-+-+-+-+-++
+
+**Reply:**
+
+.. code-block:: none
+
+   +-+-+-+-+-++
+   |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
+   | 1   | 2   |port |line | err | dir|
+   +-+-+-+-+-++
+
+- **err**: See above for definitions.
+
+- **dir**: Direction.
+
+  - 0: None
+  - 1: Output
+  - 2: Input
+

Shenwei

>   Andrew

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

[Andrew Lunn]

> > > +struct rpmsg_gpio_packet {
> > > + u8 type;/* Message type */
> > > + u8 cmd; /* Command code */
> > > + u8 port_idx;
> > > + u8 line;
> > > + u8 val1;
> > > + u8 val2;
> > > +};
> > 
> > 
> > Could you please document the fields in these structs (and the below ones 
> > too)?
> > From the code, it looks like while sending a message from Linux to 
> > Firmware; val1
> > and val2 are used to describe the values to set. Whereas while receiving a
> > response, val1 represents a possible error code, and val2 represents the 
> > actual
> > message of get type queries. If that is so, you might want to change the 
> > variable
> > names to be more descriptive and also use a union.
> > 
> 
> The fields in the two structs are fairly self-explanatory. Do we really need 
> the additional comments?
> The previous version of the patch used a union, which was updated to support 
> the fixed_up hooks. 
> Now that the fixed_up hooks have been removed, I can revert this back to the 
> union-based implementation.

I thought you had already adopted the virtio message format?


/* Possible values of the status field */
#define VIRTIO_GPIO_STATUS_OK   0x0
#define VIRTIO_GPIO_STATUS_ERR  0x1

struct virtio_gpio_response {
__u8 status;
__u8 value;
};

Seems pretty obvious what status means. value depends on the request,
get_direction actually uses it, and it can be one of

#define VIRTIO_GPIO_DIRECTION_NONE  0x00
#define VIRTIO_GPIO_DIRECTION_OUT   0x01
#define VIRTIO_GPIO_DIRECTION_IN0x02

and gpio_get uses it as a bool for the state of the GPIO.

Why do we need all the complexity for val1, val2, etc?

  Andrew

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

[Shenwei Wang]

> -Original Message-
> From: Padhi, Beleswar 
> Sent: Sunday, April 26, 2026 7:44 AM
> To: Shenwei Wang ; Linus Walleij
> ; Bartosz Golaszewski ; Jonathan Corbet
> ; Rob Herring ; Krzysztof Kozlowski
> ; Conor Dooley ; Bjorn Andersson
> ; Mathieu Poirier ; Frank Li
> ; Sascha Hauer 
> Cc: Shuah Khan ; linux-g...@vger.kernel.org; linux-
> d...@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix Kernel Team
> ; Fabio Estevam ; Peng Fan
> ; devicet...@vger.kernel.org; linux-
> remotep...@vger.kernel.org; i...@lists.linux.dev; linux-arm-
> ker...@lists.infradead.org; dl-linux-imx ; Bartosz
> Golaszewski ; Andrew Lunn 
> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
> Hello Shenwei, Greetings,
> 
> On 4/23/2026 2:58 AM, Shenwei Wang wrote:
> > On an AMP platform, the system may include two processors:
> 
> 
> s/two/multiple
> 
> >   - An MCU running an RTOS
> 
> 
> s/An MCU/MCUs
> 
> >   - An MPU running Linux
> >
> > These processors communicate via the RPMSG protocol.
> > The driver implements the standard GPIO interface, allowing the Linux
> > side to control GPIO controllers which reside in the remote processor
> > via RPMSG protocol.
> >
> > Cc: Bartosz Golaszewski 
> > Cc: Andrew Lunn 
> > Signed-off-by: Shenwei Wang 
> > ---
> >   drivers/gpio/Kconfig  |  17 ++
> >   drivers/gpio/Makefile |   1 +
> >   drivers/gpio/gpio-rpmsg.c | 573
> ++
> >   3 files changed, 591 insertions(+)
> >   create mode 100644 drivers/gpio/gpio-rpmsg.c
> >
> > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index
> > 020e51e30317..4ad299fe3c6f 100644
> > --- a/drivers/gpio/Kconfig
> > +++ b/drivers/gpio/Kconfig
> > @@ -1917,6 +1917,23 @@ config GPIO_SODAVILLE
> >
> >   endmenu
> >
> > +menu "RPMSG GPIO drivers"
> > + depends on RPMSG
> > +
> > +config GPIO_RPMSG
> > + tristate "Generic RPMSG GPIO support"
> > + depends on OF && REMOTEPROC
> > + select GPIOLIB_IRQCHIP
> > + default REMOTEPROC
> > + help
> > +   Say yes here to support the generic GPIO functions over the RPMSG
> > +   bus. Currently supported devices: i.MX7ULP, i.MX8ULP, i.MX8x, and
> > +   i.MX9x.
> > +
> > +   If unsure, say N.
> > +
> > +endmenu
> > +
> >   menu "SPI GPIO expanders"
> >   depends on SPI_MASTER
> >
> > diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile index
> > b267598b517d..ee75c0e65b8b 100644
> > --- a/drivers/gpio/Makefile
> > +++ b/drivers/gpio/Makefile
> > @@ -157,6 +157,7 @@ obj-$(CONFIG_GPIO_RDC321X)+= gpio-
> rdc321x.o
> >   obj-$(CONFIG_GPIO_REALTEK_OTTO) += gpio-realtek-otto.o
> >   obj-$(CONFIG_GPIO_REG)  += gpio-reg.o
> >   obj-$(CONFIG_GPIO_ROCKCHIP) += gpio-rockchip.o
> > +obj-$(CONFIG_GPIO_RPMSG) += gpio-rpmsg.o
> >   obj-$(CONFIG_GPIO_RTD)  += gpio-rtd.o
> >   obj-$(CONFIG_ARCH_SA1100)   += gpio-sa1100.o
> >   obj-$(CONFIG_GPIO_SAMA5D2_PIOBU)+= gpio-sama5d2-piobu.o
> > diff --git a/drivers/gpio/gpio-rpmsg.c b/drivers/gpio/gpio-rpmsg.c new
> > file mode 100644 index ..993cde7af2fa
> > --- /dev/null
> > +++ b/drivers/gpio/gpio-rpmsg.c
> > @@ -0,0 +1,573 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright 2026 NXP
> > + *
> > + * The driver exports a standard gpiochip interface to control
> > + * the GPIO controllers via RPMSG on a remote processor.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define MAX_PORT_PER_CHANNEL10
> > +#define GPIOS_PER_PORT_DEFAULT   32
> > +#define RPMSG_TIMEOUT1000
> > +
> > +/* GPIO RPMSG Type */
> > +#define GPIO_RPMSG_SEND  0
> > +#define GPIO_RPMSG_REPLY 1
> > +#define GPIO_RPMSG_NOTIFY2
> > +
> > +struct rpmsg_gpio_packet {
> > + u8 type;/* Message type */
> > + u8 cmd; /* Command code */
> > + u8 port_idx;
> > + u8 line;
> > + u8 val1;
> > + u8 val2;
> > +};
> 

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

[Padhi, Beleswar]

Hello Shenwei, Greetings,

On 4/23/2026 2:58 AM, Shenwei Wang wrote:

On an AMP platform, the system may include two processors:



s/two/multiple


- An MCU running an RTOS



s/An MCU/MCUs


- An MPU running Linux

These processors communicate via the RPMSG protocol.
The driver implements the standard GPIO interface, allowing
the Linux side to control GPIO controllers which reside in
the remote processor via RPMSG protocol.

Cc: Bartosz Golaszewski 
Cc: Andrew Lunn 
Signed-off-by: Shenwei Wang 
---
  drivers/gpio/Kconfig  |  17 ++
  drivers/gpio/Makefile |   1 +
  drivers/gpio/gpio-rpmsg.c | 573 ++
  3 files changed, 591 insertions(+)
  create mode 100644 drivers/gpio/gpio-rpmsg.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 020e51e30317..4ad299fe3c6f 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1917,6 +1917,23 @@ config GPIO_SODAVILLE
  
  endmenu
  
+menu "RPMSG GPIO drivers"

+   depends on RPMSG
+
+config GPIO_RPMSG
+   tristate "Generic RPMSG GPIO support"
+   depends on OF && REMOTEPROC
+   select GPIOLIB_IRQCHIP
+   default REMOTEPROC
+   help
+ Say yes here to support the generic GPIO functions over the RPMSG
+ bus. Currently supported devices: i.MX7ULP, i.MX8ULP, i.MX8x, and
+ i.MX9x.
+
+ If unsure, say N.
+
+endmenu
+
  menu "SPI GPIO expanders"
depends on SPI_MASTER
  
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile

index b267598b517d..ee75c0e65b8b 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -157,6 +157,7 @@ obj-$(CONFIG_GPIO_RDC321X)  += gpio-rdc321x.o
  obj-$(CONFIG_GPIO_REALTEK_OTTO)   += gpio-realtek-otto.o
  obj-$(CONFIG_GPIO_REG)+= gpio-reg.o
  obj-$(CONFIG_GPIO_ROCKCHIP)   += gpio-rockchip.o
+obj-$(CONFIG_GPIO_RPMSG)   += gpio-rpmsg.o
  obj-$(CONFIG_GPIO_RTD)+= gpio-rtd.o
  obj-$(CONFIG_ARCH_SA1100) += gpio-sa1100.o
  obj-$(CONFIG_GPIO_SAMA5D2_PIOBU)  += gpio-sama5d2-piobu.o
diff --git a/drivers/gpio/gpio-rpmsg.c b/drivers/gpio/gpio-rpmsg.c
new file mode 100644
index ..993cde7af2fa
--- /dev/null
+++ b/drivers/gpio/gpio-rpmsg.c
@@ -0,0 +1,573 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2026 NXP
+ *
+ * The driver exports a standard gpiochip interface to control
+ * the GPIO controllers via RPMSG on a remote processor.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAX_PORT_PER_CHANNEL10
+#define GPIOS_PER_PORT_DEFAULT 32
+#define RPMSG_TIMEOUT  1000
+
+/* GPIO RPMSG Type */
+#define GPIO_RPMSG_SEND0
+#define GPIO_RPMSG_REPLY   1
+#define GPIO_RPMSG_NOTIFY  2
+
+struct rpmsg_gpio_packet {
+   u8 type;/* Message type */
+   u8 cmd; /* Command code */
+   u8 port_idx;
+   u8 line;
+   u8 val1;
+   u8 val2;
+};



Could you please document the fields in these structs (and the below
ones too)? From the code, it looks like while sending a message from
Linux to Firmware; val1 and val2 are used to describe the values to
set. Whereas while receiving a response, val1 represents a possible
error code, and val2 represents the actual message of get type
queries. If that is so, you might want to change the variable names to
be more descriptive and also use a union.


+
+struct rpmsg_gpio_line {
+   u8 irq_shutdown;
+   u8 irq_unmask;
+   u8 irq_mask;
+   u32 irq_wake_enable;
+   u32 irq_type;
+   struct rpmsg_gpio_packet msg;



We don't need to have this field. More info at [0].


+};
+
+struct rpmsg_gpio_info {
+   struct rpmsg_device *rpdev;
+   struct rpmsg_gpio_packet *reply_msg;
+   struct completion cmd_complete;
+   struct mutex lock;
+   void **port_store;
+};
+
+struct rpmsg_gpio_port {
+   struct gpio_chip gc;
+   struct rpmsg_gpio_line lines[GPIOS_PER_PORT_DEFAULT];
+   struct rpmsg_gpio_info info;
+   u32 ngpios;
+   u32 idx;
+};
+
+/**
+ * struct rpmsg_drvdata - driver data per channel.
+ * @rproc_name: the name of the remote proc.
+ * @recv_pkt: a pointer to the received packet for protocol fix up.
+ * @channel_devices: an array of the devices related to the rpdev.
+ */
+struct rpdev_drvdata {
+   const char *rproc_name;
+   void *recv_pkt;



I don't see any use of this field in the code?


+   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.

This also allows for dynamic creation and deletion of ports too! (