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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,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 976C4C48BDF for ; Thu, 10 Jun 2021 20:47:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7F44E61404 for ; Thu, 10 Jun 2021 20:47:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230212AbhFJUtW (ORCPT ); Thu, 10 Jun 2021 16:49:22 -0400 Received: from mail-lj1-f169.google.com ([209.85.208.169]:35677 "EHLO mail-lj1-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229941AbhFJUtW (ORCPT ); Thu, 10 Jun 2021 16:49:22 -0400 Received: by mail-lj1-f169.google.com with SMTP id n17so6750595ljg.2 for ; Thu, 10 Jun 2021 13:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P3feXPo8hgD2FD68i8SPgVY8I4kuiJLBZN2g8qdSekM=; b=yY+WLokJziltoHJ9f3XgfvwE/LSudYOXHFaEMxWzIlSAyHQ4l4493Euz5Bx9wQPb7a jpyTB8qdbkY1dJd4TqfOgK+VuvohCE29cXAbv6BGujgKABmWag8PeU0649zqKmpPK+d3 L3YeQfMXlzWmcQPkHTiWmDTr2Ly+swbU10hGAGB5DlKfZSPjiUa/medL+veah9aYlzKz HWakmG2quynID1DJ+/m3r5Vq1EEnUjoQA2Ht+5jxdI5W6AowYsdQm9TP/2CtP0evZfaU 1pJBZ9tM9E79EbjLcTa47JCMa41g7dXjg6ykRGszpx/NJB5cC9Ep31xpV808Li2sJr9h U89g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=P3feXPo8hgD2FD68i8SPgVY8I4kuiJLBZN2g8qdSekM=; b=nr6XB9+s7FfnbqbjoImabwOVRcXM/iu1kEgVMxn5cC41rOPV2qjmtuR58vTe4WrWgB apRsu7aPXm7o7X/L40YcSOYZgRu9ZId7p/qa0wXSW6jpD0BDqPCO82lIHF6n0xN71caZ kLuBAeBmP7ZfaHKdw/r1XnrxmSe/nqla8nNyBnaXzxzvTUNIqVP1wji2qKFIwxyBCSC/ 3IcicCulGQuG2TS3pMkSFmkZReEiRPvfdmMmWC9zvFPzLQccykjopN++n7+5rhdOba/6 pMy4PqOuE9eRYqCrVmZ4C1PhnwPbSewKhwjYwBaNczslUm8KlJKOdfaaw9nkcR07IY+x vpyA== X-Gm-Message-State: AOAM533KM8TmJEALWa2jBEIxeNWdRXYqWJxoUCZ1jJK20jrBtXvskCgH RGg+P1aZJdCdPIElJOMBi8lZ1r+6LuA76O18DZzKBQ== X-Google-Smtp-Source: ABdhPJxNKGpZ/jjSlWl2zoMMOz8tNxjDSR41dSYXKzHTgV7+ERxWWp9zJMl7Q6uw/IGcGvfEK0j0qWyEO2QHKxTxfVQ= X-Received: by 2002:a05:651c:1411:: with SMTP id u17mr327855lje.438.1623357976125; Thu, 10 Jun 2021 13:46:16 -0700 (PDT) MIME-Version: 1.0 References: <10442926ae8a65f716bfc23f32339a6b35e51d5a.1623326176.git.viresh.kumar@linaro.org> In-Reply-To: <10442926ae8a65f716bfc23f32339a6b35e51d5a.1623326176.git.viresh.kumar@linaro.org> From: Linus Walleij Date: Thu, 10 Jun 2021 22:46:04 +0200 Message-ID: Subject: Re: [PATCH V3 1/3] gpio: Add virtio-gpio driver To: Viresh Kumar , Geert Uytterhoeven , Bjorn Andersson Cc: Bartosz Golaszewski , "Enrico Weigelt, metux IT consult" , Viresh Kumar , "Michael S. Tsirkin" , Jason Wang , Vincent Guittot , Bill Mills , =?UTF-8?B?QWxleCBCZW5uw6ll?= , stratos-dev@op-lists.linaro.org, "open list:GPIO SUBSYSTEM" , linux-kernel , Stefan Hajnoczi , "Stefano Garzarella --cc virtualization @ lists . linux-foundation . org" , virtualization@lists.linux-foundation.org, Alistair Strachan Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org Hi Viresh! thanks for working on this, it's a really interesting driver. My first question is conceptual: We previously have Geerts driver for virtualization: drivers/gpio/gpio-aggregator.c The idea with the aggregator is that a host script sets up a unique gpiochip for the virtualized instance using some poking in sysfs and pass that to the virtual machine. So this is Linux acting as virtualization host by definition. I think virtio is more abstract and intended for the usecase where the hypervisor is not Linux, so this should be mentioned in the commit, possibly also in Kconfig so users immediately know what usecases the two different drivers are for. Possibly both could be used: aggregator to pick out the GPIOs you want into a synthetic GPIO chip, and the actual talk between the hypervisor/host and the guest using virtio, even with linux-on-linux. Yet another usecase would be to jit this with remoteproc/rpmsg and let a specific signal processor or real-time executive on another CPU with a few GPIOs around present these to Linux using this mechanism. Well that would certainly interest Bjorn and other rpmsg stakeholders, so they should have a look so that this provides what they need they day they need it. (CCed Bjorn and also Google who may want this for their Android emulators.) On Thu, Jun 10, 2021 at 2:16 PM Viresh Kumar wrote: > +static const char **parse_gpio_names(struct virtio_device *vdev, > + struct virtio_gpio_config *config) I really like this end-to-end plug-and-play that even provides the names over virtio. I think my patch to the gpiolib to make it mandatory for names to be unique per-chip made it in, but please make that part of the spec so that we don't get the problem with non-unique names here. I suppose the spec can be augmented later to also accept config settings like open drain pull up/down etc but no need to specify more than the basic for now. But to be able to add more in the future, the client needs some kind of query mechanism or version number so the driver can adapt and not announce something the underlying virtio device cannot do. Do we have this? A bitmask for features, a version number that increase monotonically for new features to be presented or similar? Because otherwise we have to bump this: +#define VIRTIO_ID_GPIO 41 /* virtio GPIO */ every time we add something new (and we will). Yours, Linus Walleij 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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,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 B16F6C48BDF for ; Thu, 10 Jun 2021 20:46:29 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4941C613FF for ; Thu, 10 Jun 2021 20:46:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4941C613FF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=virtualization-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 0A9F583D48; Thu, 10 Jun 2021 20:46:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcfXKRA7j8xD; Thu, 10 Jun 2021 20:46:24 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp1.osuosl.org (Postfix) with ESMTPS id 1B3AA83D47; Thu, 10 Jun 2021 20:46:24 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id F246BC000E; Thu, 10 Jun 2021 20:46:23 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id BCEECC000B for ; Thu, 10 Jun 2021 20:46:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id AB136401F4 for ; Thu, 10 Jun 2021 20:46:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=linaro.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3VK_bEQkVTP for ; Thu, 10 Jun 2021 20:46:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) by smtp2.osuosl.org (Postfix) with ESMTPS id 5ED96400C8 for ; Thu, 10 Jun 2021 20:46:18 +0000 (UTC) Received: by mail-lj1-x236.google.com with SMTP id r16so6820876ljc.0 for ; Thu, 10 Jun 2021 13:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P3feXPo8hgD2FD68i8SPgVY8I4kuiJLBZN2g8qdSekM=; b=yY+WLokJziltoHJ9f3XgfvwE/LSudYOXHFaEMxWzIlSAyHQ4l4493Euz5Bx9wQPb7a jpyTB8qdbkY1dJd4TqfOgK+VuvohCE29cXAbv6BGujgKABmWag8PeU0649zqKmpPK+d3 L3YeQfMXlzWmcQPkHTiWmDTr2Ly+swbU10hGAGB5DlKfZSPjiUa/medL+veah9aYlzKz HWakmG2quynID1DJ+/m3r5Vq1EEnUjoQA2Ht+5jxdI5W6AowYsdQm9TP/2CtP0evZfaU 1pJBZ9tM9E79EbjLcTa47JCMa41g7dXjg6ykRGszpx/NJB5cC9Ep31xpV808Li2sJr9h U89g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=P3feXPo8hgD2FD68i8SPgVY8I4kuiJLBZN2g8qdSekM=; b=tisKCJpg8cIZYZ2FiOXph/6x/g85/68AHRIc0p9O6/Iv6f2NlT5Mvy1l7IQ/c5z/Ch PKENxZ/WQcQNN7jMq3KCJ5IkAlT5s8JVlHbXVYuNiyg//AyMDxLKK66d/I60879OM7E5 FSeTmIMtqAzj9mCMB2SKgPnVxW4Xqd/G2xsQWiBJtfs1I2cbg1XJQ04RvNs3c4Z6bo8p dWUNpQRC2Vbq+aRZpsCk8LGWswbPVE/MaN6Cd0qaqL0Tp633VRrym8468QlofZ8PmPR3 O3O40wVNHO4J82IIcKC3W4GGR2wLFl8tG5radUJOdMzrUjcu3TzD40Z/QJTHnZ8tG2f6 Fwkg== X-Gm-Message-State: AOAM530qpCZjlXHJF10OlhIioJwTS1O+zuGsxFbih6wj81T/5Jly1ngy tKgn1Zz9cacsesfPUdZQaL5tKLNM9o9x8+Pawm/d0g== X-Google-Smtp-Source: ABdhPJxNKGpZ/jjSlWl2zoMMOz8tNxjDSR41dSYXKzHTgV7+ERxWWp9zJMl7Q6uw/IGcGvfEK0j0qWyEO2QHKxTxfVQ= X-Received: by 2002:a05:651c:1411:: with SMTP id u17mr327855lje.438.1623357976125; Thu, 10 Jun 2021 13:46:16 -0700 (PDT) MIME-Version: 1.0 References: <10442926ae8a65f716bfc23f32339a6b35e51d5a.1623326176.git.viresh.kumar@linaro.org> In-Reply-To: <10442926ae8a65f716bfc23f32339a6b35e51d5a.1623326176.git.viresh.kumar@linaro.org> From: Linus Walleij Date: Thu, 10 Jun 2021 22:46:04 +0200 Message-ID: Subject: Re: [PATCH V3 1/3] gpio: Add virtio-gpio driver To: Viresh Kumar , Geert Uytterhoeven , Bjorn Andersson Cc: Alistair Strachan , Vincent Guittot , Stefan Hajnoczi , "Michael S. Tsirkin" , Viresh Kumar , linux-kernel , virtualization@lists.linux-foundation.org, Bartosz Golaszewski , "open list:GPIO SUBSYSTEM" , "Enrico Weigelt, metux IT consult" , Bill Mills , stratos-dev@op-lists.linaro.org X-BeenThere: virtualization@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux virtualization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: virtualization-bounces@lists.linux-foundation.org Sender: "Virtualization" Hi Viresh! thanks for working on this, it's a really interesting driver. My first question is conceptual: We previously have Geerts driver for virtualization: drivers/gpio/gpio-aggregator.c The idea with the aggregator is that a host script sets up a unique gpiochip for the virtualized instance using some poking in sysfs and pass that to the virtual machine. So this is Linux acting as virtualization host by definition. I think virtio is more abstract and intended for the usecase where the hypervisor is not Linux, so this should be mentioned in the commit, possibly also in Kconfig so users immediately know what usecases the two different drivers are for. Possibly both could be used: aggregator to pick out the GPIOs you want into a synthetic GPIO chip, and the actual talk between the hypervisor/host and the guest using virtio, even with linux-on-linux. Yet another usecase would be to jit this with remoteproc/rpmsg and let a specific signal processor or real-time executive on another CPU with a few GPIOs around present these to Linux using this mechanism. Well that would certainly interest Bjorn and other rpmsg stakeholders, so they should have a look so that this provides what they need they day they need it. (CCed Bjorn and also Google who may want this for their Android emulators.) On Thu, Jun 10, 2021 at 2:16 PM Viresh Kumar wrote: > +static const char **parse_gpio_names(struct virtio_device *vdev, > + struct virtio_gpio_config *config) I really like this end-to-end plug-and-play that even provides the names over virtio. I think my patch to the gpiolib to make it mandatory for names to be unique per-chip made it in, but please make that part of the spec so that we don't get the problem with non-unique names here. I suppose the spec can be augmented later to also accept config settings like open drain pull up/down etc but no need to specify more than the basic for now. But to be able to add more in the future, the client needs some kind of query mechanism or version number so the driver can adapt and not announce something the underlying virtio device cannot do. Do we have this? A bitmask for features, a version number that increase monotonically for new features to be presented or similar? Because otherwise we have to bump this: +#define VIRTIO_ID_GPIO 41 /* virtio GPIO */ every time we add something new (and we will). Yours, Linus Walleij _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization