[linux-next:master 520/6567] warning: (DRM_STM && ..) selects DRM_PANEL_BRIDGE which has unmet direct dependencies (HAS_IOMEM && ..)

Linus Walleij linus.walleij at linaro.org
Thu Oct 19 09:25:53 UTC 2017


Paging in Arnd on this one, as he builds a lot of next kernels
and randconfigs.

On Wed, Oct 18, 2017 at 12:55 PM, kbuild test robot
<fengguang.wu at intel.com> wrote:

> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> head:   a7dd40274d75326ca868479c62090b1198a357ad
> commit: 001485d5255cb17e99aa9e3712e43865b92d6adc [520/6567] drm/pl111: Replace custom connector with panel bridge
> config: x86_64-randconfig-ws0-10181652 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
>         git checkout 001485d5255cb17e99aa9e3712e43865b92d6adc
>         # save the attached .config to linux build tree
>         make ARCH=x86_64
>
> All warnings (new ones prefixed by >>):
>
> warning: (DRM_STM && DRM_VC4 && DRM_PL111 && DRM_TVE200 && DRM_LVDS_ENCODER && DRM_DW_MIPI_DSI)
> selects DRM_PANEL_BRIDGE which has unmet direct dependencies (HAS_IOMEM && DRM_BRIDGE && DRM_KMS_HELPER)

I have a real hard time deciphering this Kconfig problem.

Can someone help?

What I see it that DTM_STM, DRM_VC4, DRM_PL111, DRM_TVE200 and
DRM_DW_MIPI_DSI all select DRM_PANEL_BRIDGE and
DRM_KMS_HELPER.

DRM_LVDS_ENCODER select DRM_PANEL_BRIDGE

So they seem to select what they need.

HAS_IOMEM must be the real culprit, and it is not set in the .config
attached.

So is the real problem that the bot is compiling a config without
HAS_IOMEM and we should put a depends on HAS_IOMEM
somewhere?

This HAS_IOMEM business keep annoying me, UML has this
problem a lot since it doesn't have iomem for sure, but this
randconfig wants to build an x86_64 without iomem and is not
pestering us about it.

Is building for x86_64 without iomem really a problem we should
be addressing?

I think there are tons of problems in the kernel related to the
depends on HAS_IOMEM being missing, we can go fixing that
forever I think.

Yours,
Linus Walleij


More information about the dri-devel mailing list