linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>,
	"Enrico Weigelt, metux IT consult" <info@metux.net>,
	linux-kernel@vger.kernel.org, corbet@lwn.net,
	linus.walleij@linaro.org, bgolaszewski@baylibre.com,
	linux-doc@vger.kernel.org, linux-gpio@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	linux-riscv@lists.infradead.org, stefanha@redhat.com,
	msuchanek@suse.de
Subject: Re: [PATCH v2 2/2] drivers: gpio: add virtio-gpio guest driver
Date: Sat, 5 Dec 2020 21:05:16 +0100	[thread overview]
Message-ID: <e69569b5-0c45-e072-5de4-81a4acecdae3@metux.net> (raw)
In-Reply-To: <20201205142218-mutt-send-email-mst@kernel.org>

On 05.12.20 20:32, Michael S. Tsirkin wrote:

Hi,

> It seems a bit of a mess, at this point I'm not entirely sure when
> should drivers select VIRTIO and when depend on it.

if VIRTIO just enables something that could be seen as library
functions, then select should be right, IMHO.

> The text near it says:
> 
> # SPDX-License-Identifier: GPL-2.0-only
> config VIRTIO
>         tristate

oh, wait, doesn't have an menu text, so we can't even explicitly enable
it (not shown in menu) - only implicitly. Which means that some other
option must select it, in order to become availe at all, and in order
to make others depending on it becoming available.

IMHO, therefore select is the correct approach.


>         help
>           This option is selected by any driver which implements the virtio
>           bus, such as CONFIG_VIRTIO_PCI, CONFIG_VIRTIO_MMIO, CONFIG_RPMSG
>           or CONFIG_S390_GUEST.
> 
> Which seems clear enough and would indicate drivers for devices *behind*
> the bus should not select VIRTIO and thus presumably should "depend on" it.
> This is violated in virtio console and virtio fs drivers.

See above: NAK. because it can't even be enabled directly (by the user).
If it wasn't meant otherwise, we'd have to add an menu text.

> For console it says:
> 
> commit 9f30eb29c514589e16f2999ea070598583d1f6ec
> Author: Michal Suchanek <msuchanek@suse.de>
> Date:   Mon Aug 31 18:58:50 2020 +0200
> 
>     char: virtio: Select VIRTIO from VIRTIO_CONSOLE.
>     
>     Make it possible to have virtio console built-in when
>     other virtio drivers are modular.
>     
>     Signed-off-by: Michal Suchanek <msuchanek@suse.de>
>     Reviewed-by: Amit Shah <amit@kernel.org>
>     Link: https://lore.kernel.org/r/20200831165850.26163-1-msuchanek@suse.de
>     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> which seems kind of bogus - why do we care about allowing a builtin
> virtio console driver if the pci virtio bus driver is a module?
> There won't be any devices on the bus to attach to ...

When using other transports ?
In my current project, eg. I'm using mmio - my kernel has pci completely
disabled.

> I am inclined to fix console and virtio fs to depend on VIRTIO:
> select is harder to use correctly ...

I don't thinkt that would be good - instead everybody should just select
VIRTIO, never depend on it (maybe depend on VIRTIO_MENU instead)


--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

  reply	other threads:[~2020-12-05 20:08 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-03 19:11 [PATCH v2 1/2] drivers: gpio: put virtual gpio device into their own submenu Enrico Weigelt, metux IT consult
2020-12-03 19:11 ` [PATCH v2 2/2] drivers: gpio: add virtio-gpio guest driver Enrico Weigelt, metux IT consult
2020-12-04  3:35   ` Jason Wang
2020-12-04  9:36     ` Enrico Weigelt, metux IT consult
2020-12-07  3:48       ` Jason Wang
2020-12-07  9:33         ` Enrico Weigelt, metux IT consult
2020-12-08  2:49           ` Jason Wang
2021-04-13 11:07       ` Alex Bennée
2020-12-05  7:59     ` Enrico Weigelt, metux IT consult
2020-12-05 19:32       ` Michael S. Tsirkin
2020-12-05 20:05         ` Enrico Weigelt, metux IT consult [this message]
2020-12-07  3:16           ` Jason Wang
2020-12-07 13:52           ` Michael S. Tsirkin
2020-12-07 20:34             ` Enrico Weigelt, metux IT consult
2020-12-07  3:12         ` Jason Wang
2020-12-07 13:53           ` Michael S. Tsirkin
2020-12-08  2:36             ` Jason Wang
2020-12-08  7:02               ` Enrico Weigelt, metux IT consult
2020-12-09  9:31                 ` Jason Wang
2020-12-09 10:33                   ` Enrico Weigelt, metux IT consult
2020-12-08 10:10         ` Michal Suchánek
2020-12-08 12:33           ` Enrico Weigelt, metux IT consult
2020-12-09 10:34             ` Michal Suchánek
2020-12-05 20:15   ` Howto listen to/handle gpio state changes ? " Enrico Weigelt, metux IT consult
2020-12-08  9:38     ` Linus Walleij
2020-12-08 14:04       ` Enrico Weigelt, metux IT consult
2020-12-08 16:15         ` Grygorii Strashko
2020-12-09  8:51         ` Linus Walleij
2020-12-09 11:19           ` Arnd Bergmann
2020-12-09 12:53             ` Linus Walleij
2020-12-09 20:22               ` Grygorii Strashko
2020-12-09 20:38                 ` Arnd Bergmann
2020-12-10 13:32                   ` Grygorii Strashko
2021-05-24 11:27   ` Viresh Kumar
2021-05-25 12:59     ` Enrico Weigelt, metux IT consult
2021-05-26  3:32       ` Viresh Kumar
2021-07-03  8:05         ` Michael S. Tsirkin
2021-07-05  3:51           ` Viresh Kumar
2020-12-07  9:55 ` [PATCH v2 1/2] drivers: gpio: put virtual gpio device into their own submenu Andy Shevchenko
2020-12-07 10:31 ` Bartosz Golaszewski
2020-12-07 11:22   ` Enrico Weigelt, metux IT consult

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e69569b5-0c45-e072-5de4-81a4acecdae3@metux.net \
    --to=lkml@metux.net \
    --cc=bgolaszewski@baylibre.com \
    --cc=corbet@lwn.net \
    --cc=info@metux.net \
    --cc=jasowang@redhat.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mst@redhat.com \
    --cc=msuchanek@suse.de \
    --cc=stefanha@redhat.com \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).