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

On Mon, Jun 14, 2021 at 12:23 PM Viresh Kumar <viresh.kumar@...aro.org> wrote:
> On 10-06-21, 15:22, Arnd Bergmann wrote:
> > Can you give an example of how this would be hooked up to other drivers
> > using those gpios. Can you give an example of how using the "gpio-keys" or
> > "gpio-leds" drivers in combination with virtio-gpio looks like in the DT?
> >
> > Would qemu simply add the required DT properties to the device node that
> > corresponds to the virtio device in this case?
> >
> > From what I can tell, both the mmio and pci variants of virtio can have their
> > dev->of_node populated, but I don't see the logic in register_virtio_device()
> > that looks up the of_node of the virtio_device that the of_gpio code then
> > tries to refer to.
>
> To be honest, I haven't tried this yet and I was expecting it to be
> already taken care of. I was relying on the DTB automatically
> generated by Qemu to get the driver probed and didn't have a look at
> it as well.
>
> I now understand that it won't be that straight forward. The same must
> be true for adding an i2c device to an i2c bus over virtio (The way I
> tested that earlier was by using the sysfs file to add a device to a
> bus).

Yes, correct, we had the same discussion about i2c.  Again, this is
relatively straightforward when the controller and the device attached
to it (i2c controller/client or gpio controller/function) are both emulated
by qemu, but a lot harder when the controller and device are
implemented in different programs.

> This may be something lacking generally for virtio-pci thing, not
> sure though.

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

        Arnd

Powered by blists - more mailing lists