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

Padhi, Beleswar b-padhi at ti.com
Tue May 5 09:13:09 PDT 2026


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 at 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 at 1
>>>>>>>>        b. ept2 -> gpio-controller at 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 at 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-077cf859e7f3@ti.com/

>
> ch2: rpmsg-gpio.-1.1025 ->     gpio-controller at 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




More information about the linux-arm-kernel mailing list