On Wed, Jul 14, 2021 at 5:43 PM Rob Herring <robh+dt@xxxxxxxxxx> wrote:
> On Tue, Jul 13, 2021 at 2:34 PM Arnd Bergmann <arnd@xxxxxxxxxx> wrote:
> > On Tue, Jul 13, 2021 at 9:35 PM Rob Herring <robh+dt@xxxxxxxxxx> wrote:
> >
> > 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.
>
> How is that different? PCI device can be a VID/PID compatible or
> omitted, but can also be a "typical" compatible string.
Ok, my mistake then, I though the VID/PID compatible was mandated
> > I think for other virtio devices, we should come up with a way to define a
> > binding per device (i2c, gpio, ...) without needing to cram this into the
> > "virtio,mmio" binding or coming up with special compatible strings for
> > PCI devices.
> >
> > Having a child device for the virtio device type gives a better separation
> > here, since it lets you have two nodes with 'compatible' strings that each
> > make sense for their respective parent buses: The parent is either a PCI
> > device or a plain mmio based device, and the child is a virtio device with
> > its own namespace for compatible values. As you say, the downside is
> > that this requires an extra node that is redundant because there is always
> > a 1:1 relation with its parent.
> >
> > Having a combined node gets rid of the redundancy but if we want to
> > identify the device for the purpose of defining a custom binding, it would have
> > to have two compatible strings, something like
> >
> > compatible="virtio,mmio", "virtio,device34";
>
> The order seems backwards here. 'virtio,device34' is more specific.
> Though I guess the meanings are orthogonal.
Right, one defines the transport and the other defines the device behind
the transport.
> > for a virtio-mmio device of device-id 34 (i2c), or a PCI device with
> >
> > compatible="pci1af4,1041", "virtio,device34";
>
> But this seems the right order. Though does '1041' have any specific
> meaning or device IDs are just dynamically assigned? It seems to be
> the latter from my brief scan of the code.
It's the assigned PCI vendor/device pair for virtio, all virtio-pci devices
have to be "pci1af4,1041", just like all virtio-mmio devices are
"virtio,mmio".
> > which also does not quite feel right.
>
> I guess it comes down to is 'virtio,mmio' providing a bus or is it
> just a device? I guess a bus (so 2 nodes) does make sense here.
> 'virtio,mmio' defines how you access/discover the virtio queues (the
> bus) and the functional device (i2c, gpio, iommu, etc.) is accessed
> via the virtio queues.
It's not really a bus since there is only ever one device behind it.
A better analogy would be your 'serdev' framework: You could
have a 8250 or a pl011 uart, and behind that have a mouse, GPS
receiver or bluetooth dongle.
In Documentation/devicetree/bindings/serial/serial.yaml, you also
have two nodes for a single device, so we could follow that
example.
Arnd
