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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9bcd63d2-f75f-4cb6-a81f-eefc983a99bb@lunn.ch>
Date: Wed, 12 Nov 2025 14:41:30 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Shenwei Wang <shenwei.wang@....com>
Cc: Linus Walleij <linus.walleij@...aro.org>,
	Bjorn Andersson <andersson@...nel.org>,
	Mathieu Poirier <mathieu.poirier@...aro.org>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Jonathan Corbet <corbet@....net>,
	Bartosz Golaszewski <brgl@...ev.pl>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>, Peng Fan <peng.fan@....com>,
	"linux-remoteproc@...r.kernel.org" <linux-remoteproc@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"imx@...ts.linux.dev" <imx@...ts.linux.dev>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	dl-linux-imx <linux-imx@....com>
Subject: Re: [PATCH v5 3/5] docs: staging: gpio-rpmsg: gpio over rpmsg bus

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

Since this has not been merged yet, there are no existing systems.

It is well known that what gets merged into mainline is often
different to the initial out of tree version. You just need to deal
with it. One option you have is to set the vendor byte to 1, so
indicating NXP. If Linux uses vendor 0, it might be your out of tree
vendor driver, not the in kernel driver. Just document in the
specification vendor 0 is reserved.

You are going to have to modify your firmware anyway, level interrupts
are broken. And this is an example of why quirks are needed.

	Andrew