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