From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: "Enrico Weigelt, metux IT consult" <lkml@metux.net>,
"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: Mon, 7 Dec 2020 08:53:49 -0500 [thread overview]
Message-ID: <20201207085247-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <842519cc-94ca-3c11-ddd6-543e5a89c998@redhat.com>
On Mon, Dec 07, 2020 at 11:12:50AM +0800, Jason Wang wrote:
>
> On 2020/12/6 上午3:32, Michael S. Tsirkin wrote:
> > On Sat, Dec 05, 2020 at 08:59:55AM +0100, Enrico Weigelt, metux IT consult wrote:
> > > On 04.12.20 04:35, Jason Wang wrote:
> > >
> > > > > --- a/drivers/gpio/Kconfig
> > > > > +++ b/drivers/gpio/Kconfig
> > > > > @@ -1615,6 +1615,15 @@ config GPIO_MOCKUP
> > > > > Â Â Â Â Â Â Â tools/testing/selftests/gpio/gpio-mockup.sh. Reference the
> > > > > usage in
> > > > > Â Â Â Â Â Â Â it.
> > > > > Â +config GPIO_VIRTIO
> > > > > +Â Â Â tristate "VirtIO GPIO support"
> > > > > +Â Â Â depends on VIRTIO
> > > >
> > > > Let's use select, since there's no prompt for VIRTIO and it doesn't have
> > > > any dependencies.
> > > whoops, it's not that simple:
> > >
> > > make: Entering directory '/home/nekrad/src/apu2-dev/pkg/kernel.apu2.git'
> > > make[1]: Entering directory
> > > '/home/nekrad/src/dk/DistroKit/platform-x86_64/build-target/linux-5.8.9-build'
> > > GEN Makefile
> > > drivers/gpu/drm/Kconfig:74:error: recursive dependency detected!
> > > drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by
> > > DRM_VIRTIO_GPU
> > > drivers/gpu/drm/virtio/Kconfig:2: symbol DRM_VIRTIO_GPU depends on VIRTIO
> > > drivers/virtio/Kconfig:2: symbol VIRTIO is selected by GPIO_VIRTIO
> > > drivers/gpio/Kconfig:1618: symbol GPIO_VIRTIO depends on GPIOLIB
> > > drivers/gpio/Kconfig:14: symbol GPIOLIB is selected by I2C_MUX_LTC4306
> > > drivers/i2c/muxes/Kconfig:47: symbol I2C_MUX_LTC4306 depends on I2C
> > > drivers/i2c/Kconfig:8: symbol I2C is selected by FB_DDC
> > > drivers/video/fbdev/Kconfig:63: symbol FB_DDC depends on FB
> > > drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER
> > > drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on
> > > DRM_KMS_HELPER
> > >
> > > Seems that we can only depend on or select some symbol - we run into
> > > huge trouble if thats mixed. Just changed DRM_VIRTIO_GPU to just select
> > > VIRIO instead of depending on it, and now it works.
> > >
> > > I've posted another patch for fixing drivers/gpu/drm/virtio/Kconfig
> > > to use 'select' instead of 'depends on'.
> > 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.
> >
> > The text near it says:
> >
> > # SPDX-License-Identifier: GPL-2.0-only
> > config VIRTIO
> > tristate
> > 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.
> >
> > 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 ...
>
>
> For testing like switching bus from pci to MMIO?
Not sure I understand ... can you give an example?
>
> > And for virtio fs it was like this from the beginning.
> >
> > I am inclined to fix console and virtio fs to depend on VIRTIO:
> > select is harder to use correctly ...
> >
> > Jason?
>
>
> I think it works, but we need a prompt for VIRTIO otherwise there's no way
> to enable it.
>
> Thanks
That's even messier. No one needs VIRTIO core by itself - it's only used
by transports and drivers.
>
> >
> >
> > > --
> > > ---
> > > 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
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: stefanha@redhat.com, corbet@lwn.net, linus.walleij@linaro.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
bgolaszewski@baylibre.com, "Enrico Weigelt,
metux IT consult" <lkml@metux.net>,
linux-gpio@vger.kernel.org, linux-riscv@lists.infradead.org,
msuchanek@suse.de, "Enrico Weigelt,
metux IT consult" <info@metux.net>
Subject: Re: [PATCH v2 2/2] drivers: gpio: add virtio-gpio guest driver
Date: Mon, 7 Dec 2020 08:53:49 -0500 [thread overview]
Message-ID: <20201207085247-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <842519cc-94ca-3c11-ddd6-543e5a89c998@redhat.com>
On Mon, Dec 07, 2020 at 11:12:50AM +0800, Jason Wang wrote:
>
> On 2020/12/6 上午3:32, Michael S. Tsirkin wrote:
> > On Sat, Dec 05, 2020 at 08:59:55AM +0100, Enrico Weigelt, metux IT consult wrote:
> > > On 04.12.20 04:35, Jason Wang wrote:
> > >
> > > > > --- a/drivers/gpio/Kconfig
> > > > > +++ b/drivers/gpio/Kconfig
> > > > > @@ -1615,6 +1615,15 @@ config GPIO_MOCKUP
> > > > > Â Â Â Â Â Â Â tools/testing/selftests/gpio/gpio-mockup.sh. Reference the
> > > > > usage in
> > > > > Â Â Â Â Â Â Â it.
> > > > > Â +config GPIO_VIRTIO
> > > > > +Â Â Â tristate "VirtIO GPIO support"
> > > > > +Â Â Â depends on VIRTIO
> > > >
> > > > Let's use select, since there's no prompt for VIRTIO and it doesn't have
> > > > any dependencies.
> > > whoops, it's not that simple:
> > >
> > > make: Entering directory '/home/nekrad/src/apu2-dev/pkg/kernel.apu2.git'
> > > make[1]: Entering directory
> > > '/home/nekrad/src/dk/DistroKit/platform-x86_64/build-target/linux-5.8.9-build'
> > > GEN Makefile
> > > drivers/gpu/drm/Kconfig:74:error: recursive dependency detected!
> > > drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by
> > > DRM_VIRTIO_GPU
> > > drivers/gpu/drm/virtio/Kconfig:2: symbol DRM_VIRTIO_GPU depends on VIRTIO
> > > drivers/virtio/Kconfig:2: symbol VIRTIO is selected by GPIO_VIRTIO
> > > drivers/gpio/Kconfig:1618: symbol GPIO_VIRTIO depends on GPIOLIB
> > > drivers/gpio/Kconfig:14: symbol GPIOLIB is selected by I2C_MUX_LTC4306
> > > drivers/i2c/muxes/Kconfig:47: symbol I2C_MUX_LTC4306 depends on I2C
> > > drivers/i2c/Kconfig:8: symbol I2C is selected by FB_DDC
> > > drivers/video/fbdev/Kconfig:63: symbol FB_DDC depends on FB
> > > drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER
> > > drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on
> > > DRM_KMS_HELPER
> > >
> > > Seems that we can only depend on or select some symbol - we run into
> > > huge trouble if thats mixed. Just changed DRM_VIRTIO_GPU to just select
> > > VIRIO instead of depending on it, and now it works.
> > >
> > > I've posted another patch for fixing drivers/gpu/drm/virtio/Kconfig
> > > to use 'select' instead of 'depends on'.
> > 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.
> >
> > The text near it says:
> >
> > # SPDX-License-Identifier: GPL-2.0-only
> > config VIRTIO
> > tristate
> > 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.
> >
> > 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 ...
>
>
> For testing like switching bus from pci to MMIO?
Not sure I understand ... can you give an example?
>
> > And for virtio fs it was like this from the beginning.
> >
> > I am inclined to fix console and virtio fs to depend on VIRTIO:
> > select is harder to use correctly ...
> >
> > Jason?
>
>
> I think it works, but we need a prompt for VIRTIO otherwise there's no way
> to enable it.
>
> Thanks
That's even messier. No one needs VIRTIO core by itself - it's only used
by transports and drivers.
>
> >
> >
> > > --
> > > ---
> > > 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
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: stefanha@redhat.com, corbet@lwn.net, linus.walleij@linaro.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
bgolaszewski@baylibre.com, "Enrico Weigelt,
metux IT consult" <lkml@metux.net>,
linux-gpio@vger.kernel.org, linux-riscv@lists.infradead.org,
msuchanek@suse.de, "Enrico Weigelt,
metux IT consult" <info@metux.net>
Subject: Re: [PATCH v2 2/2] drivers: gpio: add virtio-gpio guest driver
Date: Mon, 7 Dec 2020 08:53:49 -0500 [thread overview]
Message-ID: <20201207085247-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <842519cc-94ca-3c11-ddd6-543e5a89c998@redhat.com>
On Mon, Dec 07, 2020 at 11:12:50AM +0800, Jason Wang wrote:
>
> On 2020/12/6 上午3:32, Michael S. Tsirkin wrote:
> > On Sat, Dec 05, 2020 at 08:59:55AM +0100, Enrico Weigelt, metux IT consult wrote:
> > > On 04.12.20 04:35, Jason Wang wrote:
> > >
> > > > > --- a/drivers/gpio/Kconfig
> > > > > +++ b/drivers/gpio/Kconfig
> > > > > @@ -1615,6 +1615,15 @@ config GPIO_MOCKUP
> > > > > Â Â Â Â Â Â Â tools/testing/selftests/gpio/gpio-mockup.sh. Reference the
> > > > > usage in
> > > > > Â Â Â Â Â Â Â it.
> > > > > Â +config GPIO_VIRTIO
> > > > > +Â Â Â tristate "VirtIO GPIO support"
> > > > > +Â Â Â depends on VIRTIO
> > > >
> > > > Let's use select, since there's no prompt for VIRTIO and it doesn't have
> > > > any dependencies.
> > > whoops, it's not that simple:
> > >
> > > make: Entering directory '/home/nekrad/src/apu2-dev/pkg/kernel.apu2.git'
> > > make[1]: Entering directory
> > > '/home/nekrad/src/dk/DistroKit/platform-x86_64/build-target/linux-5.8.9-build'
> > > GEN Makefile
> > > drivers/gpu/drm/Kconfig:74:error: recursive dependency detected!
> > > drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by
> > > DRM_VIRTIO_GPU
> > > drivers/gpu/drm/virtio/Kconfig:2: symbol DRM_VIRTIO_GPU depends on VIRTIO
> > > drivers/virtio/Kconfig:2: symbol VIRTIO is selected by GPIO_VIRTIO
> > > drivers/gpio/Kconfig:1618: symbol GPIO_VIRTIO depends on GPIOLIB
> > > drivers/gpio/Kconfig:14: symbol GPIOLIB is selected by I2C_MUX_LTC4306
> > > drivers/i2c/muxes/Kconfig:47: symbol I2C_MUX_LTC4306 depends on I2C
> > > drivers/i2c/Kconfig:8: symbol I2C is selected by FB_DDC
> > > drivers/video/fbdev/Kconfig:63: symbol FB_DDC depends on FB
> > > drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER
> > > drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on
> > > DRM_KMS_HELPER
> > >
> > > Seems that we can only depend on or select some symbol - we run into
> > > huge trouble if thats mixed. Just changed DRM_VIRTIO_GPU to just select
> > > VIRIO instead of depending on it, and now it works.
> > >
> > > I've posted another patch for fixing drivers/gpu/drm/virtio/Kconfig
> > > to use 'select' instead of 'depends on'.
> > 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.
> >
> > The text near it says:
> >
> > # SPDX-License-Identifier: GPL-2.0-only
> > config VIRTIO
> > tristate
> > 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.
> >
> > 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 ...
>
>
> For testing like switching bus from pci to MMIO?
Not sure I understand ... can you give an example?
>
> > And for virtio fs it was like this from the beginning.
> >
> > I am inclined to fix console and virtio fs to depend on VIRTIO:
> > select is harder to use correctly ...
> >
> > Jason?
>
>
> I think it works, but we need a prompt for VIRTIO otherwise there's no way
> to enable it.
>
> Thanks
That's even messier. No one needs VIRTIO core by itself - it's only used
by transports and drivers.
>
> >
> >
> > > --
> > > ---
> > > 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
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2020-12-07 13:55 UTC|newest]
Thread overview: 99+ 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 ` 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-03 19:11 ` Enrico Weigelt, metux IT consult
2020-12-04 3:35 ` Jason Wang
2020-12-04 3:35 ` Jason Wang
2020-12-04 3:35 ` Jason Wang
2020-12-04 9:36 ` Enrico Weigelt, metux IT consult
2020-12-04 9:36 ` Enrico Weigelt, metux IT consult
2020-12-07 3:48 ` Jason Wang
2020-12-07 3:48 ` Jason Wang
2020-12-07 3:48 ` Jason Wang
2020-12-07 9:33 ` Enrico Weigelt, metux IT consult
2020-12-07 9:33 ` Enrico Weigelt, metux IT consult
2020-12-08 2:49 ` Jason Wang
2020-12-08 2:49 ` Jason Wang
2020-12-08 2:49 ` Jason Wang
2021-04-13 11:07 ` Alex Bennée
2021-04-13 11:07 ` Alex Bennée
2021-04-13 11:07 ` Alex Bennée
2020-12-05 7:59 ` Enrico Weigelt, metux IT consult
2020-12-05 7:59 ` Enrico Weigelt, metux IT consult
2020-12-05 19:32 ` Michael S. Tsirkin
2020-12-05 19:32 ` Michael S. Tsirkin
2020-12-05 19:32 ` Michael S. Tsirkin
2020-12-05 20:05 ` Enrico Weigelt, metux IT consult
2020-12-05 20:05 ` Enrico Weigelt, metux IT consult
2020-12-07 3:16 ` Jason Wang
2020-12-07 3:16 ` Jason Wang
2020-12-07 3:16 ` Jason Wang
2020-12-07 13:52 ` Michael S. Tsirkin
2020-12-07 13:52 ` Michael S. Tsirkin
2020-12-07 13:52 ` Michael S. Tsirkin
2020-12-07 20:34 ` Enrico Weigelt, metux IT consult
2020-12-07 20:34 ` Enrico Weigelt, metux IT consult
2020-12-07 3:12 ` Jason Wang
2020-12-07 3:12 ` Jason Wang
2020-12-07 3:12 ` Jason Wang
2020-12-07 13:53 ` Michael S. Tsirkin [this message]
2020-12-07 13:53 ` Michael S. Tsirkin
2020-12-07 13:53 ` Michael S. Tsirkin
2020-12-08 2:36 ` Jason Wang
2020-12-08 2:36 ` Jason Wang
2020-12-08 2:36 ` Jason Wang
2020-12-08 7:02 ` Enrico Weigelt, metux IT consult
2020-12-08 7:02 ` Enrico Weigelt, metux IT consult
2020-12-09 9:31 ` Jason Wang
2020-12-09 9:31 ` Jason Wang
2020-12-09 9:31 ` Jason Wang
2020-12-09 10:33 ` Enrico Weigelt, metux IT consult
2020-12-09 10:33 ` Enrico Weigelt, metux IT consult
2020-12-08 10:10 ` Michal Suchánek
2020-12-08 10:10 ` Michal Suchánek
2020-12-08 12:33 ` Enrico Weigelt, metux IT consult
2020-12-08 12:33 ` Enrico Weigelt, metux IT consult
2020-12-09 10:34 ` Michal Suchánek
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-05 20:15 ` Enrico Weigelt, metux IT consult
2020-12-08 9:38 ` Linus Walleij
2020-12-08 9:38 ` Linus Walleij
2020-12-08 9:38 ` Linus Walleij
2020-12-08 14:04 ` Enrico Weigelt, metux IT consult
2020-12-08 14:04 ` Enrico Weigelt, metux IT consult
2020-12-08 16:15 ` Grygorii Strashko
2020-12-08 16:15 ` Grygorii Strashko
2020-12-09 8:51 ` Linus Walleij
2020-12-09 8:51 ` Linus Walleij
2020-12-09 8:51 ` Linus Walleij
2020-12-09 11:19 ` Arnd Bergmann
2020-12-09 11:19 ` Arnd Bergmann
2020-12-09 12:53 ` Linus Walleij
2020-12-09 12:53 ` Linus Walleij
2020-12-09 12:53 ` Linus Walleij
2020-12-09 20:22 ` Grygorii Strashko
2020-12-09 20:22 ` Grygorii Strashko
2020-12-09 20:38 ` Arnd Bergmann
2020-12-09 20:38 ` Arnd Bergmann
2020-12-10 13:32 ` Grygorii Strashko
2020-12-10 13:32 ` Grygorii Strashko
2021-05-24 11:27 ` Viresh Kumar
2021-05-24 11:27 ` Viresh Kumar
2021-05-25 12:59 ` Enrico Weigelt, metux IT consult
2021-05-25 12:59 ` Enrico Weigelt, metux IT consult
2021-05-26 3:32 ` Viresh Kumar
2021-05-26 3:32 ` Viresh Kumar
2021-07-03 8:05 ` Michael S. Tsirkin
2021-07-03 8:05 ` Michael S. Tsirkin
2021-07-03 8:05 ` Michael S. Tsirkin
2021-07-05 3:51 ` Viresh Kumar
2021-07-05 3:51 ` Viresh Kumar
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 9:55 ` Andy Shevchenko
2020-12-07 9:55 ` Andy Shevchenko
2020-12-07 10:31 ` Bartosz Golaszewski
2020-12-07 10:31 ` Bartosz Golaszewski
2020-12-07 11:22 ` Enrico Weigelt, metux IT consult
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=20201207085247-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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.