| Message ID | 5213510.IMdSbsXdoQ@wuerfel |
|---|---|
| State | New |
| Headers | show |
| Series | None | expand |
On Fri, Jan 01, 2016 at 11:04:07PM +0100, Arnd Bergmann wrote: > CONFIG_DRM_HDLCD is a tristate option that depends on the boolean > CONFIG_DRM_ARM, which in turn depends on the tristate CONFIG_DRM. > The effect of this is that a configuration with CONFIG_DRM=m > and CONFIG_DRM_HDLCD=y can be chosen, but won't link because the > DRM core symbols are not reachable from builtin code: > > drivers/built-in.o: In function `hdlcd_drm_unbind': > drivers/gpu/drm/arm/hdlcd_drv.c:445: undefined reference to `drm_fbdev_cma_fini' > drivers/gpu/drm/arm/hdlcd_drv.c:448: undefined reference to `drm_kms_helper_poll_fini' > drivers/gpu/drm/arm/hdlcd_drv.c:450: undefined reference to `drm_vblank_cleanup' > drivers/gpu/drm/arm/hdlcd_drv.c:452: undefined reference to `drm_irq_uninstall' > drivers/gpu/drm/arm/hdlcd_drv.c:460: undefined reference to `drm_mode_config_cleanup' > drivers/gpu/drm/arm/hdlcd_drv.c:461: undefined reference to `drm_dev_unregister' > drivers/gpu/drm/arm/hdlcd_drv.c:462: undefined reference to `drm_dev_unref' > ... > > This adds another dependency on CONFIG_DRM to enforce that DRM_HDLCD > cannot be builtin if DRM is not. Ugh... wouldn't it be much simpler to get rid of DRM_ARM? It seems like a completely superfluous option to me. I don't think we've ever had the equivalent of "vendor" Kconfig options in DRM, and I don't see why we'd need to start now. If ARM was going to add another driver it can simply have a separate Kconfig entry. There should be no need to select the vendor option first. Thierry
On Mon, Jan 04, 2016 at 09:39:46AM +0100, Arnd Bergmann wrote: > On Monday 04 January 2016 09:24:16 Thierry Reding wrote: > > > > Ugh... wouldn't it be much simpler to get rid of DRM_ARM? It seems like > > a completely superfluous option to me. I don't think we've ever had the > > equivalent of "vendor" Kconfig options in DRM, and I don't see why we'd > > need to start now. If ARM was going to add another driver it can simply > > have a separate Kconfig entry. There should be no need to select the > > vendor option first. > > Fine with me too. I vaguely remembered having seen some discussion about > this, so I decided to do a minimal fix, but I agree that would be more > in line with the other drivers. > > Arnd > Arnd, I'm OK with the whole series of Kconfig clean-up/fixes and I offer my appologies for adding noise with my patchset. Please let me know how do you prefer to handle them. I'm OK with merging your changes into my series before sending the pull request to David Airlie. Best regards, Liviu -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯
On Monday 11 January 2016 11:12:56 Liviu Dudau wrote: > On Mon, Jan 04, 2016 at 09:39:46AM +0100, Arnd Bergmann wrote: > > On Monday 04 January 2016 09:24:16 Thierry Reding wrote: > > > > > > Ugh... wouldn't it be much simpler to get rid of DRM_ARM? It seems like > > > a completely superfluous option to me. I don't think we've ever had the > > > equivalent of "vendor" Kconfig options in DRM, and I don't see why we'd > > > need to start now. If ARM was going to add another driver it can simply > > > have a separate Kconfig entry. There should be no need to select the > > > vendor option first. > > > > Fine with me too. I vaguely remembered having seen some discussion about > > this, so I decided to do a minimal fix, but I agree that would be more > > in line with the other drivers. > > > > Arnd > > > > Arnd, > > I'm OK with the whole series of Kconfig clean-up/fixes and I offer my appologies > for adding noise with my patchset. Please let me know how do you prefer to handle > them. I'm OK with merging your changes into my series before sending the pull > request to David Airlie. Please merge them into your tree if you have some other changes to send to him. I just realized that these are in your own git tree at the moment, not in drm-next. I guess that means you will rebase the whole series after -rc1 and submit it into linux-4.6, right? If so, just fold my fixes into your patches when you rebase. Arnd
diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig index 81ea7802ca50..487fb1f0c979 100644 --- a/drivers/gpu/drm/arm/Kconfig +++ b/drivers/gpu/drm/arm/Kconfig @@ -7,7 +7,7 @@ config DRM_ARM config DRM_HDLCD tristate "ARM HDLCD" - depends on DRM_ARM + depends on DRM_ARM && DRM depends on COMMON_CLK select DRM_KMS_CMA_HELPER select DRM_GEM_CMA_HELPER
CONFIG_DRM_HDLCD is a tristate option that depends on the boolean CONFIG_DRM_ARM, which in turn depends on the tristate CONFIG_DRM. The effect of this is that a configuration with CONFIG_DRM=m and CONFIG_DRM_HDLCD=y can be chosen, but won't link because the DRM core symbols are not reachable from builtin code: drivers/built-in.o: In function `hdlcd_drm_unbind': drivers/gpu/drm/arm/hdlcd_drv.c:445: undefined reference to `drm_fbdev_cma_fini' drivers/gpu/drm/arm/hdlcd_drv.c:448: undefined reference to `drm_kms_helper_poll_fini' drivers/gpu/drm/arm/hdlcd_drv.c:450: undefined reference to `drm_vblank_cleanup' drivers/gpu/drm/arm/hdlcd_drv.c:452: undefined reference to `drm_irq_uninstall' drivers/gpu/drm/arm/hdlcd_drv.c:460: undefined reference to `drm_mode_config_cleanup' drivers/gpu/drm/arm/hdlcd_drv.c:461: undefined reference to `drm_dev_unregister' drivers/gpu/drm/arm/hdlcd_drv.c:462: undefined reference to `drm_dev_unref' ... This adds another dependency on CONFIG_DRM to enforce that DRM_HDLCD cannot be builtin if DRM is not. Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- Ok, I found yet another one after a few hundred extra randconfig builds on today's next. Let me know if you'd rather have the three Kconfig changes combined into a single patch, it's starting to get ridiculous. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/