NXP Public
> -----Original Message-----
> From: Mathieu Poirier <[email protected]>
> Sent: Thursday, September 3, 2026 12:30 PM
> To: [email protected]; [email protected]
> Cc: Linus Walleij <[email protected]>; Bartosz Golaszewski <[email protected]>;
> Jonathan Corbet <[email protected]>; Conor Dooley <[email protected]>; Bjorn
> Andersson <[email protected]>; Frank Li <[email protected]>; Sascha Hauer
> <[email protected]>; Shuah Khan <[email protected]>; linux-
> [email protected]; [email protected]; [email protected];
> Pengutronix Kernel Team <[email protected]>; Fabio Estevam
> <[email protected]>; Shenwei Wang <[email protected]>; Peng Fan
> <[email protected]>; [email protected]; linux-
> [email protected]; [email protected]; linux-arm-
> [email protected]; dl-linux-imx <[email protected]>; Arnaud
> POULIQUEN <[email protected]>; [email protected]; Andrew Lunn
> <[email protected]>; [email protected]
> Subject: Re: [PATCH v15 2/5] dt-bindings: remoteproc: imx_rproc: Add "rpmsg"
> subnode support
>
> Krzysztof and Rob - I'm seeking your advice on the best way to define
> bindings for
> this use case.
>
> Here is some background:
>
> The transport mechanic between the kernel and remote processors can take
> different forms. As of this writing we have 'glink' and 'virtio'. The
> protocol that
> runs on top of the transport mechanic is RPMSG. All this is already
> implemented
> and stable.
>
> In this use case, we have GPIO controllers connected to the remote processor
> and we want to make them available to the kernel. We also want to use the
> existing virtio-gpio protocol on top of RPMSG, allowing the kernel to
> interface
> with the GPIO controllers as if they were virtio-gpios. This patchset is
> about
> providing a driver that will enact the virtio-gpio procotol on top of the
> mechanic
> used between the kernel and remote processor.
>
> Shenwei has proposed some bindings (below). I think they can be improved to
> take into account the transport mechanic and be closer to what virtio-gpio
> currently does. I'm proposing something like this:
>
> $(transport) {
> compatible = "$(transport),rpmsg";
> #address-cells = <1>;
> #size-cells = <0>;
>
> gpio {
> compatible = "virtio,device29";
> reg = <3>
> gpio-controller;
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> };
> gpio {
> compatible = "virtio,device29";
> reg = <4>
> gpio-controller;
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> };
> }
>
> A complete example with a virtio transport mechanic would look like:
>
I'd like to point out a conceptual difference here.
RPMSG is effectively a messaging bus that operates on top of the Virtio
transport.
Virtio itself is not a bus.
In the current implementation, the GPIO devices are exposed over the RPMSG bus,
not
directly over a Virtio interace. As a result, modeling the GPIO nodes as
children of a Virtio
device may not accurately reflect the software architecture or device discovery
path.
From the GPIO client's perspective, the communication path is:
GPIO consumer
-> RPMsg
-> Virtio transport
-> remote endpoint
Therefore, I think the binding should primarily describe the RPMSG-based
hierarchy that exists
today, while keeping the underlying Virtio transport as an implementation
detail unless there
is a specific need to expose it in the DT representation.
Shenwei
> m4_rproc: m4@10000000 {
> compatible = "st,stm32mp1-m4";
> reg = <0x10000000 0x40000>,
> <0x30000000 0x40000>,
> <0x38000000 0x10000>;
> resets = <&rcc MCU_R>;
> reset-names = "mcu_rst";
> st,syscfg-holdboot = <&rcc 0x10C 0x1>;
> st,syscfg-pdds = <&pwr_mcu 0x0 0x1>;
> st,syscfg-rsc-tbl = <&tamp 0x144 0xFFFFFFFF>;
> st,syscfg-m4-state = <&tamp 0x148 0xFFFFFFFF>;
> status = "disabled";
>
> virtio {
> compatible = "virtio,rpmsg";
> #address-cells = <1>;
> #size-cells = <0>;
>
> gpio {
> compatible = "virtio,device29";
> reg = <3>
> gpio-controller;
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> };
> gpio {
> compatible = "virtio,device29";
> reg = <4>
> gpio-controller;
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> };
> }
> };
> };
>
> Let me know what you think.
>
> Thanks,
> Mathieu
>
>
> On Tue, Jul 21, 2026 at 03:46:45PM -0500, Shenwei Wang wrote:
> > From: Shenwei Wang <[email protected]>
> >
> > Remote processors may announce multiple GPIO controllers over an RPMSG
> > channel. These GPIO controllers may require corresponding device tree
> > nodes, especially when acting as providers, to supply phandles for
> > their consumers.
> >
> > Define an RPMSG node to work as a container for a group of RPMSG
> > channels under the imx_rproc node. Each subnode within "rpmsg"
> > represents an individual RPMSG channel. The name of each subnode
> > corresponds to the channel name as defined by the remote processor.
> >
> > All remote devices associated with a given channel are defined as
> > child nodes under the corresponding channel node.
> >
> > Signed-off-by: Shenwei Wang <[email protected]>
> > ---
> > .../devicetree/bindings/gpio/gpio-rpmsg.yaml | 55 +++++++++++++++++++
> > .../bindings/remoteproc/fsl,imx-rproc.yaml | 53 ++++++++++++++++++
> > 2 files changed, 108 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/gpio/gpio-rpmsg.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/gpio/gpio-rpmsg.yaml
> > b/Documentation/devicetree/bindings/gpio/gpio-rpmsg.yaml
> > new file mode 100644
> > index 000000000000..41eb2e149942
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/gpio/gpio-rpmsg.yaml
> > @@ -0,0 +1,55 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/gpio/gpio-rpmsg.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Generic RPMSG GPIO Controller
> > +
> > +maintainers:
> > + - Shenwei Wang <[email protected]>
> > +
> > +description:
> > + On an AMP platform, some GPIO controllers are exposed by the remote
> > +processor
> > + through the RPMSG bus. The RPMSG GPIO transport protocol defines
> > +the packet
> > + structure and communication flow between Linux and the remote
> > +firmware. Those
> > + controllers are managed via this transport protocol. For more
> > +details of the
> > + protocol, check the document below.
> > + Documentation/driver-api/gpio/gpio-rpmsg.rst
> > +
> > +properties:
> > + compatible:
> > + oneOf:
> > + - items:
> > + - enum:
> > + - fsl,rpmsg-gpio
> > + - const: rpmsg-gpio
> > + - const: rpmsg-gpio
> > +
> > + reg:
> > + description:
> > + The reg property represents the index of the GPIO controllers. Since
> > + the driver manages controllers on a remote system, this index tells
> > + the remote system which controller to operate.
> > + maxItems: 1
> > +
> > + "#gpio-cells":
> > + const: 2
> > +
> > + gpio-controller: true
> > +
> > + interrupt-controller: true
> > +
> > + "#interrupt-cells":
> > + const: 2
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - "#gpio-cells"
> > + - gpio-controller
> > +
> > +allOf:
> > + - $ref: /schemas/gpio/gpio.yaml#
> > +
> > +unevaluatedProperties: false
> > diff --git
> > a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> > b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> > index c18f71b64889..b9b559b186af 100644
> > --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> > +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> > @@ -88,6 +88,34 @@ properties:
> > This property is to specify the resource id of the remote processor
> > in SoC
> > which supports SCFW
> >
> > + rpmsg:
> > + type: object
> > + additionalProperties: false
> > + description:
> > + Represents the RPMSG bus between Linux and the remote system.
> Contains
> > + a group of RPMSG channel devices running on the bus.
> > +
> > + properties:
> > + rpmsg-io:
> > + type: object
> > + additionalProperties: false
> > + properties:
> > + '#address-cells':
> > + const: 1
> > +
> > + '#size-cells':
> > + const: 0
> > +
> > + patternProperties:
> > + "^gpio@[0-9a-f]+$":
> > + type: object
> > + $ref: /schemas/gpio/gpio-rpmsg.yaml#
> > + unevaluatedProperties: false
> > +
> > + required:
> > + - '#address-cells'
> > + - '#size-cells'
> > +
> > required:
> > - compatible
> >
> > @@ -150,5 +178,30 @@ examples:
> > &mu 3 1>;
> > memory-region = <&vdev0buffer>, <&vdev0vring0>, <&vdev0vring1>,
> <&rsc_table>;
> > syscon = <&src>;
> > +
> > + rpmsg {
> > + rpmsg-io {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + gpio@0 {
> > + compatible = "rpmsg-gpio";
> > + reg = <0>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + #interrupt-cells = <2>;
> > + interrupt-controller;
> > + };
> > +
> > + gpio@1 {
> > + compatible = "rpmsg-gpio";
> > + reg = <1>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + #interrupt-cells = <2>;
> > + interrupt-controller;
> > + };
> > + };
> > + };
> > };
> > ...
> > --
> > 2.43.0
> >
