From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
Cc: stefanha@redhat.com, corbet@lwn.net,
Jason Wang <jasowang@redhat.com>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
bgolaszewski@baylibre.com, linux-gpio@vger.kernel.org,
linux-riscv@lists.infradead.org, msuchanek@suse.de,
"Enrico Weigelt, metux IT consult" <info@metux.net>,
linus.walleij@linaro.org
Subject: Re: [PATCH v2 2/2] drivers: gpio: add virtio-gpio guest driver
Date: Mon, 7 Dec 2020 08:52:20 -0500 [thread overview]
Message-ID: <20201206075131-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <e69569b5-0c45-e072-5de4-81a4acecdae3@metux.net>
On Sat, Dec 05, 2020 at 09:05:16PM +0100, Enrico Weigelt, metux IT consult wrote:
> 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.
The point is that user enables one of the bindings.
That in turn enables drivers. If we merely select VIRTIO
there's a chance user won't remember to select any bindings
and will be surprised not to see any devices.
> > 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 ?
Any transport selects VIRTIO so if you enable that, you get
VIRTIO and thus it's enough to depend on it.
> 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)
GPU depends on VIRTIO and on VIRTIO_MENU ... which seems even messier
...
>
> --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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2020-12-07 13:52 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
2020-12-07 3:16 ` Jason Wang
2020-12-07 13:52 ` Michael S. Tsirkin [this message]
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=20201206075131-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--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=lkml@metux.net \
--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).