Messages in this thread | | | Subject | Re: [PATCH v2 2/2] drivers: gpio: add virtio-gpio guest driver | From | Jason Wang <> | Date | Tue, 8 Dec 2020 10:36:00 +0800 |
| |
On 2020/12/7 下午9:53, Michael S. Tsirkin wrote: > 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?
E.g testing
modprobe -r virtio_mmio modprobe virtio_pci
?
> >>> 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.
So we endup with two solutions (without a prompt):
1) using select, user may end up with driver without transport 2) using depends, user need to enable at least one transport
2) looks a little bit better I admit.
Thanks
> >>> >>>> -- >>>> --- >>>> 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
| |