On Fri, Feb 20, 2026 at 10:16:42AM +0100, Arnaud POULIQUEN wrote:
>
>
> On 2/19/26 14:42, Andrew Lunn wrote:
> > > > + u8 id; /* Message ID Code */
> > > > + u8 vendor; /* Vendor ID number */
> > >
> > > Does this fields above are mandatory, seems that it is just some constant
> > > values that are useless.
> > >
> > > > + u8 version; /* Vendor-specific version number */
> > >
> > > Why it is vendor specific? the version should represent the rpmsg-tty
> > > protocol version.
> > >
> > > > + u8 type; /* Message type */
> > > > + u8 cmd; /* Command code */
> > > > + u8 reserved[5];
> > >
> > > What is the purpose of this reserved field?
> >
> > They have an implementation of the other end running on there systems,
> > and it sounds like it is widely deployed, and they are trying to keep
> > backwards compatibility. The protocol also implements more than
> > GPIO. There is also I2C, maybe watchdog, i don't remember, but early
> > versions of this patchset had a list. Some of these fields are used
> > for some of these other devices.
> >
> > I've been arguing it should be a clean design, with the protocol
> > focusing on GPIO. And that the rpmsg channel makes it clear this is a
> > GPIO device, the protocol itself does not need to include fields to
> > differentiate between GPIO, I2C etc.
> >
> > When they start submitting I2C over rpmsg, i expect the same sort of
> > discussion will start again, so the likelihood of keeping backwards
> > compatible with there firmware seems low to me.
>
> Agree with you.
Hi Shenwei
We now have two Maintainers who think you should make a clean
design...
You should go talk with your Management and decide what they want to
do. Drop this patch series and only support the out of tree driver? Or
rework this driver and the firmware to the liking of the mainline
Maintainers.
Andrew
