From: Jani Nikula <jani.nikula@linux.intel.com>
To: Gerd Hoffmann <kraxel@redhat.com>,
dri-devel@lists.freedesktop.org, virtio-dev@lists.oasis-open.org
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
mst@redhat.com, open list <linux-kernel@vger.kernel.org>,
airlied@redhat.com,
"open list:MEDIA INPUT INFRA..." <linux-media@vger.kernel.org>
Subject: Re: [PATCH v2 1/4] break kconfig dependency loop
Date: Wed, 01 Apr 2015 16:47:12 +0300 [thread overview]
Message-ID: <87wq1wot9b.fsf@intel.com> (raw)
In-Reply-To: <1427894130-14228-2-git-send-email-kraxel@redhat.com>
On Wed, 01 Apr 2015, Gerd Hoffmann <kraxel@redhat.com> wrote:
> After adding virtio-gpu I get this funky kconfig dependency loop.
>
> scripts/kconfig/conf --oldconfig Kconfig
> drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
> drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
> drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER is selected by DRM_VIRTIO_GPU
> drivers/gpu/drm/virtio/Kconfig:1: symbol DRM_VIRTIO_GPU depends on VIRTIO
> drivers/virtio/Kconfig:1: symbol VIRTIO is selected by REMOTEPROC
> drivers/remoteproc/Kconfig:4: symbol REMOTEPROC is selected by OMAP_REMOTEPROC
> drivers/remoteproc/Kconfig:12: symbol OMAP_REMOTEPROC depends on OMAP_IOMMU
> drivers/iommu/Kconfig:141: symbol OMAP_IOMMU is selected by VIDEO_OMAP3
> drivers/media/platform/Kconfig:96: symbol VIDEO_OMAP3 depends on VIDEO_V4L2
> drivers/media/v4l2-core/Kconfig:6: symbol VIDEO_V4L2 depends on I2C
> drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC
> drivers/video/fbdev/Kconfig:59: symbol FB_DDC is selected by FB_CYBER2000_DDC
> drivers/video/fbdev/Kconfig:374: symbol FB_CYBER2000_DDC depends on FB_CYBER2000
> drivers/video/fbdev/Kconfig:362: symbol FB_CYBER2000 depends on FB
>
> Making VIDEO_OMAP3 depend on OMAP_IOMMU instead of selecting it breaks the
> loop, which looks like the best way to handle it to me. I'm open to better
> suggestions though.
I think part of the problem is that "select" is often used not as
documented [1] but rather as "show my config in menuconfig for
convenience even if my dependency is not met, and select the dependency
even though I know it can screw up the dependency chain".
In light of the documentation, your patch seems to DTRT. (Disclaimer: I
don't work with the drivers in question, hence no Reviewed-by.)
In the big picture, it feels like menuconfig needs a way to display
items whose dependencies are not met, and a way to recursively enable
said items and all their dependencies when told. This would reduce the
resistance to sticking with "select" when clearly "depends" is what's
meant.
BR,
Jani.
[1] Documentation/kbuild/kconfig-language.txt: "In general use select
only for non-visible symbols (no prompts anywhere) and for symbols with
no dependencies. That will limit the usefulness but on the other hand
avoid the illegal configurations all over."
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
> drivers/media/platform/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index d9b872b..fc21734 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -87,8 +87,8 @@ config VIDEO_OMAP3
> tristate "OMAP 3 Camera support"
> depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
> depends on HAS_DMA
> + depends on OMAP_IOMMU
> select ARM_DMA_USE_IOMMU
> - select OMAP_IOMMU
> select VIDEOBUF2_DMA_CONTIG
> ---help---
> Driver for an OMAP 3 camera controller.
> --
> 1.8.3.1
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Gerd Hoffmann <kraxel@redhat.com>,
dri-devel@lists.freedesktop.org, virtio-dev@lists.oasis-open.org
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
mst@redhat.com, open list <linux-kernel@vger.kernel.org>,
airlied@redhat.com,
"open list\:MEDIA INPUT INFRA..." <linux-media@vger.kernel.org>
Subject: Re: [PATCH v2 1/4] break kconfig dependency loop
Date: Wed, 01 Apr 2015 16:47:12 +0300 [thread overview]
Message-ID: <87wq1wot9b.fsf@intel.com> (raw)
In-Reply-To: <1427894130-14228-2-git-send-email-kraxel@redhat.com>
On Wed, 01 Apr 2015, Gerd Hoffmann <kraxel@redhat.com> wrote:
> After adding virtio-gpu I get this funky kconfig dependency loop.
>
> scripts/kconfig/conf --oldconfig Kconfig
> drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
> drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
> drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER is selected by DRM_VIRTIO_GPU
> drivers/gpu/drm/virtio/Kconfig:1: symbol DRM_VIRTIO_GPU depends on VIRTIO
> drivers/virtio/Kconfig:1: symbol VIRTIO is selected by REMOTEPROC
> drivers/remoteproc/Kconfig:4: symbol REMOTEPROC is selected by OMAP_REMOTEPROC
> drivers/remoteproc/Kconfig:12: symbol OMAP_REMOTEPROC depends on OMAP_IOMMU
> drivers/iommu/Kconfig:141: symbol OMAP_IOMMU is selected by VIDEO_OMAP3
> drivers/media/platform/Kconfig:96: symbol VIDEO_OMAP3 depends on VIDEO_V4L2
> drivers/media/v4l2-core/Kconfig:6: symbol VIDEO_V4L2 depends on I2C
> drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC
> drivers/video/fbdev/Kconfig:59: symbol FB_DDC is selected by FB_CYBER2000_DDC
> drivers/video/fbdev/Kconfig:374: symbol FB_CYBER2000_DDC depends on FB_CYBER2000
> drivers/video/fbdev/Kconfig:362: symbol FB_CYBER2000 depends on FB
>
> Making VIDEO_OMAP3 depend on OMAP_IOMMU instead of selecting it breaks the
> loop, which looks like the best way to handle it to me. I'm open to better
> suggestions though.
I think part of the problem is that "select" is often used not as
documented [1] but rather as "show my config in menuconfig for
convenience even if my dependency is not met, and select the dependency
even though I know it can screw up the dependency chain".
In light of the documentation, your patch seems to DTRT. (Disclaimer: I
don't work with the drivers in question, hence no Reviewed-by.)
In the big picture, it feels like menuconfig needs a way to display
items whose dependencies are not met, and a way to recursively enable
said items and all their dependencies when told. This would reduce the
resistance to sticking with "select" when clearly "depends" is what's
meant.
BR,
Jani.
[1] Documentation/kbuild/kconfig-language.txt: "In general use select
only for non-visible symbols (no prompts anywhere) and for symbols with
no dependencies. That will limit the usefulness but on the other hand
avoid the illegal configurations all over."
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
> drivers/media/platform/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index d9b872b..fc21734 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -87,8 +87,8 @@ config VIDEO_OMAP3
> tristate "OMAP 3 Camera support"
> depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
> depends on HAS_DMA
> + depends on OMAP_IOMMU
> select ARM_DMA_USE_IOMMU
> - select OMAP_IOMMU
> select VIDEOBUF2_DMA_CONTIG
> ---help---
> Driver for an OMAP 3 camera controller.
> --
> 1.8.3.1
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
next prev parent reply other threads:[~2015-04-01 13:47 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-01 13:15 [PATCH v2 0/4] Add virtio gpu driver Gerd Hoffmann
2015-04-01 13:15 ` [PATCH v2 1/4] break kconfig dependency loop Gerd Hoffmann
2015-04-01 13:15 ` Gerd Hoffmann
2015-04-01 13:47 ` Jani Nikula [this message]
2015-04-01 13:47 ` Jani Nikula
2015-04-06 9:50 ` Paul Bolle
2015-04-06 9:50 ` Paul Bolle
2015-04-06 14:27 ` Mauro Carvalho Chehab
2015-04-01 14:55 ` John Hunter
2015-04-01 15:08 ` Michael S. Tsirkin
2015-04-01 15:08 ` Michael S. Tsirkin
2015-04-01 15:38 ` Gerd Hoffmann
2015-04-01 15:38 ` Gerd Hoffmann
2015-05-14 18:23 ` Mauro Carvalho Chehab
2015-05-14 18:23 ` Mauro Carvalho Chehab
2015-04-01 13:15 ` [PATCH v2 2/4] drm_vblank_get: don't WARN_ON in case vblanks are not initialized Gerd Hoffmann
2015-04-01 13:15 ` Gerd Hoffmann
2015-04-02 13:37 ` Alex Deucher
2015-04-01 13:15 ` [PATCH v2 3/4] Add virtio gpu driver Gerd Hoffmann
2015-04-01 13:15 ` Gerd Hoffmann
2015-04-01 13:31 ` Michael S. Tsirkin
2015-04-01 13:31 ` Michael S. Tsirkin
2015-04-02 15:52 ` Marc-André Lureau
2015-04-02 15:52 ` Marc-André Lureau
2015-04-07 9:41 ` Gerd Hoffmann
2015-04-07 9:41 ` Gerd Hoffmann
2015-04-07 9:41 ` Gerd Hoffmann
2015-04-01 13:15 ` Gerd Hoffmann
2015-04-01 13:15 ` [PATCH v2 4/4] Add virtio-vga bits Gerd Hoffmann
2015-04-01 13:15 ` Gerd Hoffmann
2015-04-01 13:15 ` Gerd Hoffmann
2015-04-01 13:26 ` Michael S. Tsirkin
2015-04-01 13:26 ` Michael S. Tsirkin
2015-04-01 13:26 ` Michael S. Tsirkin
2015-04-01 13:42 ` Gerd Hoffmann
2015-04-01 13:42 ` Gerd Hoffmann
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=87wq1wot9b.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=airlied@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kraxel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@osg.samsung.com \
--cc=mst@redhat.com \
--cc=virtio-dev@lists.oasis-open.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.