linux-kernel - Re: [PATCH 1/5] dt-bindings: virtio: mmio: Add support for device subnode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a2mS3GoW9MXdDNK7-EbnRH-9Kn4_k_TgnGSCycSez8Xow@mail.gmail.com>
Date:   Wed, 14 Jul 2021 23:07:28 +0200
From:   Arnd Bergmann <arnd@...nel.org>
To:     Rob Herring <robh+dt@...nel.org>
Cc:     Viresh Kumar <viresh.kumar@...aro.org>,
        Jason Wang <jasowang@...hat.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Jean-Philippe Brucker <jean-philippe@...aro.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Bill Mills <bill.mills@...aro.org>,
        Alex Bennée <alex.bennee@...aro.org>,
        "Enrico Weigelt, metux IT consult" <info@...ux.net>,
        Jie Deng <jie.deng@...el.com>,
        DTML <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "open list:DRM DRIVER FOR QEMU'S CIRRUS DEVICE" 
        <virtualization@...ts.linux-foundation.org>
Subject: Re: [PATCH 1/5] dt-bindings: virtio: mmio: Add support for device subnode

On Wed, Jul 14, 2021 at 5:43 PM Rob Herring <robh+dt@...nel.org> wrote:
> On Tue, Jul 13, 2021 at 2:34 PM Arnd Bergmann <arnd@...nel.org> wrote:
> > On Tue, Jul 13, 2021 at 9:35 PM Rob Herring <robh+dt@...nel.org> 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