| Message ID | 20160829123428.3260105-1-arnd@arndb.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Aug 29, 2016 at 02:34:07PM +0200, Arnd Bergmann wrote: > When CONFIG_DRM_KMS_FB_HELPER is disabled, we can have a configuration > in which some DRM drivers are built-in, but the framebuffer core is a > loadable module. This results in a link error, such as: > > drivers/gpu/drm/radeon/radeon.o: In function `radeon_pci_probe': > radeon_kfd.c:(.text.radeon_pci_probe+0xbc): undefined reference to `remove_conflicting_framebuffers' > drivers/gpu/drm/amd/amdgpu/amdgpu.o: In function `amdgpu_pci_probe': > amdgpu_mn.c:(.text.amdgpu_pci_probe+0xa8): undefined reference to `remove_conflicting_framebuffers' > drivers/gpu/drm/mgag200/mgag200.o: In function `mga_vram_init': > mgag200_ttm.c:(.text.mga_vram_init+0xa8): undefined reference to `remove_conflicting_framebuffers' > drivers/gpu/drm/mgag200/mgag200.o: In function `mga_pci_probe': > mgag200_ttm.c:(.text.mga_pci_probe+0x88): undefined reference to `remove_conflicting_framebuffers' > Makefile:969: recipe for target 'vmlinux' failed > > This changes the compile-time check to IS_REACHABLE, which means we end up > not calling remove_conflicting_framebuffers() in the configuration, which > seems good enough, as we know that no framebuffer driver is loaded by the > time that the built-in DRM driver calls remove_conflicting_framebuffers. > > We could alternatively avoid the link error by forcing CONFIG_FB to not > be a module in this case, but that wouldn't change anything at runtime, > and just make the already convoluted set of dependencies worse here. > > I could not find out what happens if the fbdev driver gets loaded as > a module after the DRM driver is already initialized, but that is a case > that can happen with or without this patch. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > Fixes: 0a3bfe29f816 ("drm/fb-helper: Fix the dummy remove_conflicting_framebuffers") Applied to drm-misc, thanks. -Daniel > --- > include/drm/drm_fb_helper.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h > index edc6cfd3aa34..797fb5f80c45 100644 > --- a/include/drm/drm_fb_helper.h > +++ b/include/drm/drm_fb_helper.h > @@ -491,7 +491,7 @@ static inline int > drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a, > const char *name, bool primary) > { > -#if IS_ENABLED(CONFIG_FB) > +#if IS_REACHABLE(CONFIG_FB) > return remove_conflicting_framebuffers(a, name, primary); > #else > return 0; > -- > 2.9.0 >
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h index edc6cfd3aa34..797fb5f80c45 100644 --- a/include/drm/drm_fb_helper.h +++ b/include/drm/drm_fb_helper.h @@ -491,7 +491,7 @@ static inline int drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a, const char *name, bool primary) { -#if IS_ENABLED(CONFIG_FB) +#if IS_REACHABLE(CONFIG_FB) return remove_conflicting_framebuffers(a, name, primary); #else return 0;
When CONFIG_DRM_KMS_FB_HELPER is disabled, we can have a configuration in which some DRM drivers are built-in, but the framebuffer core is a loadable module. This results in a link error, such as: drivers/gpu/drm/radeon/radeon.o: In function `radeon_pci_probe': radeon_kfd.c:(.text.radeon_pci_probe+0xbc): undefined reference to `remove_conflicting_framebuffers' drivers/gpu/drm/amd/amdgpu/amdgpu.o: In function `amdgpu_pci_probe': amdgpu_mn.c:(.text.amdgpu_pci_probe+0xa8): undefined reference to `remove_conflicting_framebuffers' drivers/gpu/drm/mgag200/mgag200.o: In function `mga_vram_init': mgag200_ttm.c:(.text.mga_vram_init+0xa8): undefined reference to `remove_conflicting_framebuffers' drivers/gpu/drm/mgag200/mgag200.o: In function `mga_pci_probe': mgag200_ttm.c:(.text.mga_pci_probe+0x88): undefined reference to `remove_conflicting_framebuffers' Makefile:969: recipe for target 'vmlinux' failed This changes the compile-time check to IS_REACHABLE, which means we end up not calling remove_conflicting_framebuffers() in the configuration, which seems good enough, as we know that no framebuffer driver is loaded by the time that the built-in DRM driver calls remove_conflicting_framebuffers. We could alternatively avoid the link error by forcing CONFIG_FB to not be a module in this case, but that wouldn't change anything at runtime, and just make the already convoluted set of dependencies worse here. I could not find out what happens if the fbdev driver gets loaded as a module after the DRM driver is already initialized, but that is a case that can happen with or without this patch. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 0a3bfe29f816 ("drm/fb-helper: Fix the dummy remove_conflicting_framebuffers") --- include/drm/drm_fb_helper.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)