All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: "Rob Herring" <robh+dt@kernel.org>,
	"Viresh Kumar" <viresh.kumar@linaro.org>,
	"Jason Wang" <jasowang@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Vincent Guittot" <vincent.guittot@linaro.org>,
	"Bill Mills" <bill.mills@linaro.org>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Enrico Weigelt, metux IT consult" <info@metux.net>,
	"Jie Deng" <jie.deng@intel.com>,
	DTML <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"open list:DRM DRIVER FOR QEMU'S CIRRUS DEVICE"
	<virtualization@lists.linux-foundation.org>
Subject: Re: [PATCH 1/5] dt-bindings: virtio: mmio: Add support for device subnode
Date: Wed, 14 Jul 2021 10:20:21 +0200	[thread overview]
Message-ID: <YO6eRXz/J1tPOi0P@myrica> (raw)
In-Reply-To: <CAK8P3a3Gve=M9GF-E+2OJED1Hd1qngxOkVSO15wB0jVWK8D0_Q@mail.gmail.com>

On Tue, Jul 13, 2021 at 10:34:03PM +0200, Arnd Bergmann wrote:
> > > Is it going to be a problem if two devices in kernel use the same
> > > of_node ?
> >
> > There shouldn't be. We have nodes be multiple providers (e.g clocks
> > and resets) already.
> 
> I think this would be a little different, but it can still work. There is in
> fact already some precedent of doing this, with Jean-Philippe's virtio-iommu
> binding, which is documented in both
> 
> Documentation/devicetree/bindings/virtio/iommu.txt
> Documentation/devicetree/bindings/virtio/mmio.txt
> 
> Unfortunately, those are still slightly different from where I think we should
> be going here, but it's probably close enough to fit into the general
> system.
> 
> What we have with virtio-iommu is two special hacks:
>  - on virtio-mmio, a node with 'compatible="virtio,mmio"' may optionally
>    have an '#iommu-cells=<1>', in which case we assume it's an iommu.
>  - for virtio-pci, the node has the standard PCI 'reg' property but a special
>    'compatible="virtio,pci-iommu"' property that I think is different from any
>    other PCI node.

Yes in retrospect I don't think the compatible property on the PCI
endpoint node is necessary nor useful, we could deprecate it. The OS gets
the IOMMU topology information early from 'iommus', 'iommu-map' and
'#iommu-cells' properties, which is the only reason we need this PCI
endpoint explicitly described in DT. The rest is discovered while probing
just like virtio-mmio.

Thanks,
Jean

WARNING: multiple messages have this Message-ID (diff)
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: "Enrico Weigelt, metux IT consult" <info@metux.net>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"open list:DRM DRIVER FOR QEMU'S CIRRUS DEVICE"
	<virtualization@lists.linux-foundation.org>,
	DTML <devicetree@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Bill Mills <bill.mills@linaro.org>
Subject: Re: [PATCH 1/5] dt-bindings: virtio: mmio: Add support for device subnode
Date: Wed, 14 Jul 2021 10:20:21 +0200	[thread overview]
Message-ID: <YO6eRXz/J1tPOi0P@myrica> (raw)
In-Reply-To: <CAK8P3a3Gve=M9GF-E+2OJED1Hd1qngxOkVSO15wB0jVWK8D0_Q@mail.gmail.com>

On Tue, Jul 13, 2021 at 10:34:03PM +0200, Arnd Bergmann wrote:
> > > Is it going to be a problem if two devices in kernel use the same
> > > of_node ?
> >
> > There shouldn't be. We have nodes be multiple providers (e.g clocks
> > and resets) already.
> 
> I think this would be a little different, but it can still work. There is in
> fact already some precedent of doing this, with Jean-Philippe's virtio-iommu
> binding, which is documented in both
> 
> Documentation/devicetree/bindings/virtio/iommu.txt
> Documentation/devicetree/bindings/virtio/mmio.txt
> 
> Unfortunately, those are still slightly different from where I think we should
> be going here, but it's probably close enough to fit into the general
> system.
> 
> What we have with virtio-iommu is two special hacks:
>  - on virtio-mmio, a node with 'compatible="virtio,mmio"' may optionally
>    have an '#iommu-cells=<1>', in which case we assume it's an iommu.
>  - for virtio-pci, the node has the standard PCI 'reg' property but a special
>    'compatible="virtio,pci-iommu"' property that I think is different from any
>    other PCI node.

Yes in retrospect I don't think the compatible property on the PCI
endpoint node is necessary nor useful, we could deprecate it. The OS gets
the IOMMU topology information early from 'iommus', 'iommu-map' and
'#iommu-cells' properties, which is the only reason we need this PCI
endpoint explicitly described in DT. The rest is discovered while probing
just like virtio-mmio.

Thanks,
Jean
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  parent reply	other threads:[~2021-07-14  8:20 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-13 10:50 [PATCH 0/5] virtio: Parse virtio-device nodes from DT Viresh Kumar
2021-07-13 10:50 ` Viresh Kumar
2021-07-13 10:50 ` [PATCH 1/5] dt-bindings: virtio: mmio: Add support for device subnode Viresh Kumar
2021-07-13 10:50   ` Viresh Kumar
2021-07-13 12:32   ` Arnd Bergmann
2021-07-14  2:28     ` Viresh Kumar
2021-07-14  2:28       ` Viresh Kumar
2021-07-13 14:43   ` Rob Herring
2021-07-13 15:19     ` Viresh Kumar
2021-07-13 15:19       ` Viresh Kumar
2021-07-13 19:34       ` Rob Herring
2021-07-13 20:34         ` Arnd Bergmann
2021-07-14  2:26           ` Viresh Kumar
2021-07-14  2:26             ` Viresh Kumar
2021-07-14 11:40             ` Viresh Kumar
2021-07-14 11:40               ` Viresh Kumar
2021-07-14  8:20           ` Jean-Philippe Brucker [this message]
2021-07-14  8:20             ` Jean-Philippe Brucker
2021-07-14 15:43           ` Rob Herring
2021-07-14 21:07             ` Arnd Bergmann
2021-07-19 10:33               ` Viresh Kumar
2021-07-19 10:33                 ` Viresh Kumar
2021-07-19 12:04                 ` Arnd Bergmann
2021-07-14  2:19         ` Viresh Kumar
2021-07-14  2:19           ` Viresh Kumar
2021-07-13 10:50 ` [PATCH 2/5] virtio_mmio: Bind virtio device to device-tree node Viresh Kumar
2021-07-13 10:50   ` Viresh Kumar
2021-07-13 12:26   ` Arnd Bergmann
2021-07-14  3:11     ` Viresh Kumar
2021-07-14  3:11       ` Viresh Kumar
2021-07-13 10:50 ` [PATCH 3/5] dt-bindings: i2c: Add bindings for i2c-virtio Viresh Kumar
2021-07-13 10:50   ` Viresh Kumar
2021-07-13 14:03   ` Rob Herring
2021-07-13 14:03     ` Rob Herring
2021-07-13 10:50 ` [PATCH 4/5] i2c: virtio: Update i2c-adapter's of_node Viresh Kumar
2021-07-13 10:50   ` Viresh Kumar
2021-07-13 10:50 ` [PATCH 5/5] dt-bindings: gpio: Add bindings for gpio-virtio Viresh Kumar
2021-07-13 10:50   ` Viresh Kumar
2021-07-13 14:03   ` Rob Herring
2021-07-13 14:03     ` Rob Herring
2021-07-13 14:46   ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YO6eRXz/J1tPOi0P@myrica \
    --to=jean-philippe@linaro.org \
    --cc=alex.bennee@linaro.org \
    --cc=arnd@kernel.org \
    --cc=bill.mills@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=info@metux.net \
    --cc=jasowang@redhat.com \
    --cc=jie.deng@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=robh+dt@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.