[PATCH v5 3/5] docs: staging: gpio-rpmsg: gpio over rpmsg bus

[Shenwei Wang]

> -----Original Message-----
> From: Linus Walleij <linus.walleij at linaro.org>
> Sent: Tuesday, November 11, 2025 4:36 AM
> To: Shenwei Wang <shenwei.wang at nxp.com>; Bjorn Andersson
> <andersson at kernel.org>
> Cc: Mathieu Poirier <mathieu.poirier at linaro.org>; Rob Herring
> <robh at kernel.org>; Krzysztof Kozlowski <krzk+dt at kernel.org>; Conor Dooley
> <conor+dt at kernel.org>; Shawn Guo <shawnguo at kernel.org>; Sascha Hauer
> <s.hauer at pengutronix.de>; Jonathan Corbet <corbet at lwn.net>; Bartosz
> Golaszewski <brgl at bgdev.pl>; Pengutronix Kernel Team
> <kernel at pengutronix.de>; Fabio Estevam <festevam at gmail.com>; Peng Fan
> <peng.fan at nxp.com>; linux-remoteproc at vger.kernel.org;
> devicetree at vger.kernel.org; imx at lists.linux.dev; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org; linux-
> doc at vger.kernel.org; dl-linux-imx <linux-imx at nxp.com>
> Subject: [EXT] Re: [PATCH v5 3/5] docs: staging: gpio-rpmsg: gpio over rpmsg bus
> Hi Shenwei,
> 
> thanks for your patch!
> 
> Also, a big thanks for working on improving the standardization of rpmsg so we
> can get some order here. This is very important work.
> 
> On Tue, Nov 4, 2025 at 9:34 PM Shenwei Wang <shenwei.wang at nxp.com>
> wrote:
> 
> > +- **Major**: Major version number.
> > +
> > +- **Minor**: Minor version number.
> 
> I'm not contesting these if they come from similar fields in other rpmsg devices.
> 
> What I'm thinking is that the driver will eventually have to quirk around bugs in
> the responding rpmsg CPU, and there will be bugs. This can end up with this
> situation:
> 
> major,minor = (1,2) NXP implementation, no bug major,minor = (1,2) Sharp
> implementation, no bug major,minor = (1,2) Sony implementation, ooops this has
> a bug
> 
> What is the driver going to do here to work around that bug?
> 
> The scheme kind of suppose that all vendors use the same codebase and they
> don't.
> 
> I would rather have:
> 
> **Vendor**: Vendor ID number (such as the PCI or USB ID)
> 
> **Version**: Vendor-specific version number (such as SW release)
> 
> This will make it possible to identify buggy firmware and apply quirks.
> 
> My apologies if the rpmsg community has already thought about this.
> 
> Bjorns input would be appreciated!
> 

Hi Linus,

Thank you very much for the review and suggestions.

Would it be feasible to use the reserved field for this purpose? This approach would maintain 
compatibility with the existing system.

+-----+------+------+-----+-----+------------+-----+-----+--------+
|0x00 |0x01  |0x02  |0x03 |0x04 |0x05..0x09  |0x0A |0x0B |0x0C~0x0D|
|cate |major |minor |type |cmd  |reserved[5] |line |port |  data  |
+-----+------+------+-----+-----+------------+-----+-----+--------+

We could allocate four bytes from the reserved field to store the VID:PID combinations.

Thanks,
Shenwei

> Yours,
> Linus Walleij