linux-kernel - Re: [Stratos-dev] [PATCH V3 1/3] gpio: Add virtio-gpio driver

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-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a0-cVF=n1OxURZM8yXLKCPAAgBnZNXZVUzxA8m2ZzjP1A@mail.gmail.com>
Date:   Mon, 14 Jun 2021 14:58:16 +0200
From:   Arnd Bergmann <arnd@...nel.org>
To:     Vincent Guittot <vincent.guittot@...aro.org>
Cc:     Stefan Hajnoczi <stefanha@...hat.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        virtualization@...ts.linux-foundation.org,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        "Stefano Garzarella --cc virtualization @ lists . linux-foundation . org" 
        <sgarzare@...hat.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Viresh Kumar <vireshk@...nel.org>,
        Stratos Mailing List <stratos-dev@...lists.linaro.org>,
        "Enrico Weigelt, metux IT consult" <info@...ux.net>,
        Jason Wang <jasowang@...hat.com>
Subject: Re: [Stratos-dev] [PATCH V3 1/3] gpio: Add virtio-gpio driver

On Mon, Jun 14, 2021 at 2:50 PM Vincent Guittot via Stratos-dev
<stratos-dev@...lists.linaro.org> wrote:>
> On Mon, 14 Jun 2021 at 14:33, Arnd Bergmann <arnd@...nel.org> wrote:
> > On Mon, Jun 14, 2021 at 12:23 PM Viresh Kumar <viresh.kumar@...aro.org> wrote:
> >
> > I think most importantly we need a DT binding to describe what device
> > nodes are supposed to look like underneath a virtio-mmio or
> > virtio-pci device in order for a hypervisor to pass down the
> > information to a guest OS in a generic way. We can probably borrow
> > the USB naming, and replace compatible="usbVID,PID" with
> > compatible="virtioDID", with the device ID in hexadecimal digits,
> > such as "virtio22" for I2C (virtio device ID 34 == 0x22) if we decide
> > to have a sub-node under the device, or we just point dev->of_node
> > of the virtio device to the platform/pci device that is its parent
> > in Linux.
> >
> > Adding the Linux guest code to the virtio layer should be fairly
> > straightforward, and I suppose it could be mostly copied from the
> > corresponding code that added this for mmc in commit 25185f3f31c9
> > ("mmc: Add SDIO function devicetree subnode parsing") and for USB
> > in commit 69bec7259853 ("USB: core: let USB device know device
> > node") and 1a7e3948cb9f ("USB: add device-tree support for
> > interfaces").
>
> And something similar is also done with SCMI protocols which are
> defined in a SCMI node. A  typical example:
>
>     cpu@0 {
>         ...
>         clocks = <&scmi_dvfs 0>;
>         ...
>     };
>
>     deviceX: deviceX@...YYYY {
>         ...
>         clocks = <&scmi_clk 0>;
>         ...
>     };
>
>     scmi: scmi {
>         compatible = "arm,scmi-virtio";
>         #address-cells = <1>;
>         #size-cells = <0>;
>
>         scmi_devpd: protocol@11 {
>             reg = <0x11>;
>             #power-domain-cells = <1>;
>         };
>
>         scmi_clk: protocol@14 {
>             reg = <0x14>;
>             #clock-cells = <1>;
>         };
>
>         scmi_sensors: protocol@15 {
>             reg = <0x15>;
>             #thermal-sensor-cells = <1>;
>         };
>
>         scmi_dvfs: protocol@13 {
>             reg = <0x13>;
>             #clock-cells = <1>;
>         };
>     };

But this example seem to be completely different from the ones I mentioned:
The scmi node that you have here looks like it shows up under the root of the
device tree, not below the virtio device that implements the scmi transport.

         Arnd