On Wed, Jul 14, 2021 at 5:43 PM Rob Herring [off-list ref] wrote:

On Tue, Jul 13, 2021 at 2:34 PM Arnd Bergmann [off-list ref] wrote:

quoted

On Tue, Jul 13, 2021 at 9:35 PM Rob Herring [off-list ref] 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

quoted

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.

quoted

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".

quoted

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