> 
> On Thu, May 07, 2026 at 07:43:33PM +0000, 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.
>