linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
	Naresh Kamboju <naresh.kamboju@linaro.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	open list <linux-kernel@vger.kernel.org>,
	Linux-Next Mailing List <linux-next@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Andrey Konovalov <andreyknvl@gmail.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Arnd Bergmann <arnd@arndb.de>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Linus Walleij <linus.walleij@linaro.org>
Subject: Re: gpu: drm_fb_cma_helper.c:46: undefined reference to `drm_gem_fb_get_obj'
Date: Wed, 27 Oct 2021 08:19:49 +0200	[thread overview]
Message-ID: <CAK8P3a0wG8dKnuQMOL=bKmBHuSkWcu6OfvhTP-86rpLdr7_5CA@mail.gmail.com> (raw)
In-Reply-To: <6862b109-ea12-6ffa-c82b-b23ee26aa5b2@infradead.org>

On Wed, Oct 27, 2021 at 2:58 AM Randy Dunlap <rdunlap@infradead.org> wrote:

> >
> > Looking at this config, there is:
> >
> > CONFIG_DRM=y
> > # CONFIG_DRM_DP_AUX_CHARDEV is not set
> > # CONFIG_DRM_DEBUG_MM is not set
> > # CONFIG_DRM_DEBUG_SELFTEST is not set
> > CONFIG_DRM_KMS_HELPER=m
> > # CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
> > # CONFIG_DRM_DP_CEC is not set
> > CONFIG_DRM_GEM_CMA_HELPER=y
> > CONFIG_DRM_KMS_CMA_HELPER=y
> >
> > GEM_CMA_HELPER depends on KMS_HELPER, but the latter is a module. That's probably the cause of the problem. Is it intentionally set this way?
> >
>
> The only drivers that select DRM_KMS_HELPER are both =m, so that's how
> DRM_KMS_HELPER is set also.
>
> Symbol: DRM_KMS_HELPER [=m]
> Type : tristate
> Defined at drivers/gpu/drm/Kconfig:82
> Depends on: HAS_IOMEM [=y] && DRM [=y]
> Selected by [m]:
> - DRM_ATMEL_HLCDC [=m] && HAS_IOMEM [=y] && DRM [=y] && OF [=y] && COMMON_CLK [=y] && MFD_ATMEL_HLCDC [=y] && ARM [=y]
> - DRM_ASPEED_GFX [=m] && HAS_IOMEM [=y] && DRM [=y] && OF [=y] && (COMPILE_TEST [=n] || ARCH_ASPEED [=y]) && MMU [=y]
>
>
> I did the ARM cross-build and also see the linker error.
> I didn't understand why -- and still don't, but here is a little
> speculation:
>
> In the past (e.g. 10 years ago), we have to move some .o files
> in lib/ from lib-y to obj-y so that they would always be included
> in the final object file and not cause their user/caller object
> files to suffer from undefined references.
> These happened because unused functions(?) in lib-y files are
> stripped out of the final object files.
> The same thing could be happening here (still just guessing).
>
> Does that help any?  I dunno.
>
> Adding Arnd to Cc: to see if he has any ideas...

From all I can tell, the problem is that DRM_KMS_CMA_HELPER is a 'bool'
symbol, so if it gets selected by a '=m' driver, it turns into '=y', which
then selects DRM_GEM_CMA_HELPER=y, but that one cannot link
against DRM_KMS_HELPER=m code.

This trivial change makes it all build:

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index c08860db2520..699f434ce813 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -218,7 +218,7 @@ config DRM_GEM_CMA_HELPER
          Choose this if you need the GEM CMA helper functions

 config DRM_KMS_CMA_HELPER
-       bool
+       tristate
        depends on DRM
        select DRM_GEM_CMA_HELPER
        help

but this needs some more testing to make sure it doesn't add
any other regressions.

Interestingly, I never hit the problem in randconfig testing since
there is always some '=y' driver that selects DRM_KMS_HELPER.

        Arnd

  reply	other threads:[~2021-10-27  6:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-25 12:13 gpu: drm_fb_cma_helper.c:46: undefined reference to `drm_gem_fb_get_obj' Naresh Kamboju
2021-10-25 14:01 ` Naresh Kamboju
2021-10-26 17:59   ` Thomas Zimmermann
2021-10-27  2:56     ` Naresh Kamboju
2021-10-25 18:25 ` Thomas Zimmermann
2021-10-26 18:21 ` Thomas Zimmermann
2021-10-27  0:58   ` Randy Dunlap
2021-10-27  6:19     ` Arnd Bergmann [this message]
2021-10-27  6:26       ` Randy Dunlap
2021-10-27  6:50         ` Arnd Bergmann
2021-10-27  8:08           ` Thomas Zimmermann

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='CAK8P3a0wG8dKnuQMOL=bKmBHuSkWcu6OfvhTP-86rpLdr7_5CA@mail.gmail.com' \
    --to=arnd@arndb.de \
    --cc=airlied@linux.ie \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andreyknvl@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=naresh.kamboju@linaro.org \
    --cc=rdunlap@infradead.org \
    --cc=sfr@canb.auug.org.au \
    --cc=tzimmermann@suse.de \
    /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).