From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F02B3C2B9F4 for ; Mon, 14 Jun 2021 12:33:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CAE786120E for ; Mon, 14 Jun 2021 12:33:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232966AbhFNMfv (ORCPT ); Mon, 14 Jun 2021 08:35:51 -0400 Received: from mail.kernel.org ([198.145.29.99]:36482 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232775AbhFNMfv (ORCPT ); Mon, 14 Jun 2021 08:35:51 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 6646961244; Mon, 14 Jun 2021 12:33:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623674028; bh=dmo8qs/MKATYA1IZ7AKaDdhtV6InuuZs1/xAmbBoelg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=tNeM8rM+lhmlbM045WN+IcMEQHT9GEmw3lCv0Hj8oSEfiazU1Jp8srjGbVwOIpBvL tQIQT5ZF6vI55B69SdF2qkC9alHY6RjyX/SAHRSHRiQC3PoRS0L9zFDDAQQLRRnsq3 4EnydgJEtvF94ROI4jAv+sGkYNONW3PEGkeG8Sh7M3WH00XYHAWrw0KmnEIfi6m7hJ jctPDMS7+g480SSRQDBg5k/kaWE3l5N4nEP0ovrCqUSUJPVwHGWKTbMJzRh8eLJydc bj37EfY6qtAWhzEIYFNIAsxhbOnj5oKYk6gy8lG/kyTN//eM0+9RuB9ppcGDBmA7IM 6TqIG6S7wk/Xw== Received: by mail-wr1-f44.google.com with SMTP id f2so14361667wri.11; Mon, 14 Jun 2021 05:33:48 -0700 (PDT) X-Gm-Message-State: AOAM533wJu2rLHDO/Igt86o9ewA0ORhIUa1M2zbihJxgrxYcNjMPDG0A fHiZMV2+imQuymR4LPXpxxcthI29AhN6tRYPmhs= X-Google-Smtp-Source: ABdhPJzEzwMZ9lAEzL6goASqbV9BzfrcmBrbAr/mXOU1vhDrwPLQ4Gu51NELxrrSobNInTElCWXuBlr/adgJDGZiRs0= X-Received: by 2002:a5d:4e12:: with SMTP id p18mr17397922wrt.105.1623674026992; Mon, 14 Jun 2021 05:33:46 -0700 (PDT) MIME-Version: 1.0 References: <10442926ae8a65f716bfc23f32339a6b35e51d5a.1623326176.git.viresh.kumar@linaro.org> <20210614102119.qifm5sj7fpg54iqo@vireshk-i7> In-Reply-To: <20210614102119.qifm5sj7fpg54iqo@vireshk-i7> From: Arnd Bergmann Date: Mon, 14 Jun 2021 14:31:43 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH V3 1/3] gpio: Add virtio-gpio driver To: Viresh Kumar Cc: Bartosz Golaszewski , Linus Walleij , "Enrico Weigelt, metux IT consult" , Viresh Kumar , "Michael S. Tsirkin" , Jason Wang , Vincent Guittot , Bill Mills , =?UTF-8?B?QWxleCBCZW5uw6ll?= , Stratos Mailing List , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List , Stefan Hajnoczi , "Stefano Garzarella --cc virtualization @ lists . linux-foundation . org" , virtualization@lists.linux-foundation.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Mon, Jun 14, 2021 at 12:23 PM Viresh Kumar 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