On Tue, Oct 06, 2026 at 06:51:52PM -0600, Mathieu Poirier wrote: > On Tue, 6 Oct 2026 at 12:39, Rob Herring <[email protected]> wrote: > > > > On Tue, Sep 22, 2026 at 09:44:20PM +0200, Francesco Valla wrote: > > > On Tue, Sep 22, 2026 at 09:40:31AM -0600, Mathieu Poirier wrote: > > > > On Wed, Sep 16, 2026 at 11:10:53PM +0200, Francesco Valla wrote: > > > > > Add a new binding to describe remoteproc-provided virtio devices; > > > > > while > > > > > these are discovered through a resource table parsed by the remoteproc > > > > > infrastructure at runtime, their description can be needed to probe > > > > > non-discoverable buses (such as I2C) or to link consumers and > > > > > suppliers. > > > > > > > > > > Each vdev is described by a dedicated "group" node, which then > > > > > includes > > > > > a virtio-device node, which binding is already existent and used by > > > > > virtio-mmio. Each vdev shall be stattically linked to a "group" node > > > > > using its index inside the resource table as the reg property of the > > > > > node; this permits to have multiple instances of the same type of > > > > > device. > > > > > > > > > > The binding is intended to be generic and adopted by any remoteproc > > > > > provider. > > > > > > > > > > Signed-off-by: Francesco Valla <[email protected]> > > > > > --- > > > > > .../bindings/remoteproc/remoteproc-virtio.yaml | 89 > > > > > ++++++++++++++++++++++ > > > > > 1 file changed, 89 insertions(+) > > > > > > > > > > diff --git > > > > > a/Documentation/devicetree/bindings/remoteproc/remoteproc-virtio.yaml > > > > > b/Documentation/devicetree/bindings/remoteproc/remoteproc-virtio.yaml > > > > > new file mode 100644 > > > > > index 000000000000..c4a0d84b1460 > > > > > --- /dev/null > > > > > +++ > > > > > b/Documentation/devicetree/bindings/remoteproc/remoteproc-virtio.yaml > > > > > @@ -0,0 +1,89 @@ > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > > > > +%YAML 1.2 > > > > > +--- > > > > > +$id: http://devicetree.org/schemas/remoteproc/remoteproc-virtio.yaml# > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > + > > > > > +title: Virtio devices over remoteproc > > > > > + > > > > > +description: | > > > > > + Virtio devices ("vdevs") can be exposed using the remoteproc > > > > > infrastructure > > > > > + and its resource table. For some of them, a device tree node might > > > > > be needed > > > > > + to describe remote undiscoverable hardware and/or connect > > > > > consumers and > > > > > + providers. > > > > > + > > > > > +maintainers: > > > > > + - Francesco Valla <[email protected]> > > > > > + > > > > > +properties: > > > > > + virtio: > > > > > + description: Contains a group of Virtio devices exposed by the > > > > > remoteproc. > > > > > + > > > > > + properties: > > > > > + '#address-cells': > > > > > + const: 1 > > > > > + > > > > > + '#size-cells': > > > > > + const: 0 > > > > > + > > > > > + patternProperties: > > > > > + "^vdev@[0-9a-f]+$": > > > > > + type: object > > > > > + > > > > > + properties: > > > > > + reg: > > > > > + description: Virtio device index inside the resource > > > > > table. > > > > There are 2 configurations we need to account for: (1) each device > located behind the remote processor gets its own set of virtqueues and > adheres to the virtio specifications. This is the configuration > targeted by this thread. The other configuration (2), discussed in > the other thread, involves virtio piggy-backed over RPMSG. The hope > is to represent both configurations using the same bindings. For (1), > virtio devices will be advertised in the resource table and for (2), > virtio devices will be announced via the existing remoteproc namespace > service. > > > Who/what defines the resource table? > > The resource table is part of the firmware image and is parsed by the > remoteproc core. For (1), as presented in this set, "reg" links the > entry in the resource table with the device definition in the DT. For > (2), the definition is also a device index, but said index is > communicated to the remoteproc core using a namespace announcement > rather than the resource table. > > I hope to establish bindings for configuration (1) and merge that work > first. Once that is done we can extend it to cover (2).
"Defined by firmware" is all I needed. Please make sure the binding patches include this information or I'll forget and just ask again. Rob
