From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 43675CA5FED for ; Tue, 6 Oct 2026 18:39:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=YnuOeuo/LodeBx6Sgln5fFHIlb9TcaUTmkgxnYAmmVo=; b=E0XXKuhvpWGVMBtWyRTfJKqISn iWWkJTiLtD4e4FdFlw1eSu0/2Gk+bmosEUG3YypCmdYnah1/C1EHF8UOwfGvV96yZd3l1h7macLht sXGCXZT2u7MZPoaGZGFyKZ19NTgpnVD8G3+Yu3ygREpMwXIl/PZJpRp8edWSK7qMrt02yYk9XOnqV 0+m11+Xjc1feu/43aLmCX9XKaWvj8AzD4PORT0dbLSGrwRYvR47Pc+T4kQYW/XI62HxP8Mnuxq1aJ CnRtlSH783RHP4hnVesN1PgTOeNbWkQsR6VhkJhvXrVXJ7CssaGk9dZUlG55IBjmabmoMg/YPtC8X T37+xqGA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1xEA4H-00000001HPE-1FfZ; Tue, 06 Oct 2026 18:39:13 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1xEA4G-00000001HP7-29S8 for linux-arm-kernel@lists.infradead.org; Tue, 06 Oct 2026 18:39:12 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id E0A9C4065C; Tue, 6 Oct 2026 18:39:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9CC881F0089B; Tue, 6 Oct 2026 18:39:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791311951; bh=YnuOeuo/LodeBx6Sgln5fFHIlb9TcaUTmkgxnYAmmVo=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=gk6GjwcCcwF0BnSp+fwOsMz0okjMzU7Y/H0nrSZLiq3H85mI/+8VFmvi3VKF6fyoY xBCKO+AfsNCIyiZrJyvKwJ2Xjgg//Vo+gDM/ZiDDjDJqpcPoq5IHk5OQPGy4s+9HBE NYdVEAvQ0bTbspMPorb+92ddphVavQaAi2RaT4cduu2n+oGoZVnQu/ChThV8JbTPYm ZG5v6xaNhUuSefo2vtOiUTyzvwW+IxWn6UyyGeX+JzvBf2YKiQdy92Qk/Acb3A0Snw 3qRPnljHIzJY07gIvWLxtyPGT2KUMim+rkeVEqIVSZYrb0QPORNVZE8dM6HaBYnwbD aLxOhdzU0sFRA== Date: Tue, 6 Oct 2026 13:39:10 -0500 From: Rob Herring To: Francesco Valla Cc: Mathieu Poirier , Bjorn Andersson , Kees Cook , "Gustavo A. R. Silva" , Marek Szyprowski , Robin Murphy , Mark Brown , Krzysztof Kozlowski , Conor Dooley , Frank Li , Peng Fan , Sascha Hauer , linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, virtualization@lists.linux.dev, imx@lists.linux.dev, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH RFC 08/12] dt-bindings: remoteproc: add remoteproc-virtio Message-ID: <20261006183910.GA2890477-robh@kernel.org> References: <20260916-remoteproc_virtio_map-v1-0-dac8c5eb4aa9@valla.it> <20260916-remoteproc_virtio_map-v1-8-dac8c5eb4aa9@valla.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 > > > --- > > > .../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 > > > + > > > +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. Who/what defines the resource table? > > > + maxItems: 1 > > > + > > > + additionalProperties: > > > + type: object > > > + $ref: /schemas/virtio/virtio-device.yaml > > > + maxItems: 1 > > > + > > > + required: > > > + - reg > > > + > > > + additionalProperties: false Preferred to put this before 'properties' in the indented cases. Easier to see what level it belongs to. > > > + > > > + required: > > > + - '#address-cells' > > > + - '#size-cells' > > > + > > > +additionalProperties: true > > > + > > > +examples: > > > + - | > > > + remoteproc-cm33 { > > > + virtio { > > > + #address-cells = <1>; > > > + #size-cells = <0>; > > > + > > > + vdev@0 { > > > + reg = <0>; > > > + > > > > Do we need the 'reg' since we already have vdev@X? I'll let the DT people > > provide their input on this. > > > > AFAIK yes, because the rproc_get_vdev_fwnode() helpers search for indexed > child nodes using the 'reg' property, not the node name. This I believe > is the preferred way of doing things. It is either both unit-address and reg or neither. It's preferred to have them unless you are just making up numbers. Rob