Message ID | 8737xvc87a.fsf@intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On 2015-10-01 10:19, Jani Nikula wrote: > On Thu, 01 Oct 2015, Daniel Vetter <daniel.vetter@ffwll.ch> wrote: >> Surprisingly kbuild can't cope with tristates in the >> <module>-$(CONFIG_FOO) pattern. This patch hacks up a solution. > > Given that it's two distinct Makefile variables (foo-y and foo-m) being > assigned to, I don't really find this surprising. Maybe this could be > made to work as a convenience, but there might be other, more surpising > consequences. I actually think that kbuild should be able to handle this. The likely reason why it is not doing it right now is that in an ideal world, modules are modules can be built out of tree against just the kernel and their static dependencies. In real world, we sometimes have features in modules that are enabled if other modules are enabled. I'll post a patch later. We also have lots of tests fo CONFIG_FOO || CONFIG_FOO_MODULE in built-in code, which is a similar case. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 01, 2015 at 11:58:32AM +0200, Michal Marek wrote: > On 2015-10-01 10:19, Jani Nikula wrote: > > On Thu, 01 Oct 2015, Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > >> Surprisingly kbuild can't cope with tristates in the > >> <module>-$(CONFIG_FOO) pattern. This patch hacks up a solution. > > > > Given that it's two distinct Makefile variables (foo-y and foo-m) being > > assigned to, I don't really find this surprising. Maybe this could be > > made to work as a convenience, but there might be other, more surpising > > consequences. > > I actually think that kbuild should be able to handle this. The likely > reason why it is not doing it right now is that in an ideal world, > modules are modules can be built out of tree against just the kernel and > their static dependencies. In real world, we sometimes have features in > modules that are enabled if other modules are enabled. I'll post a patch > later. We also have lots of tests fo CONFIG_FOO || CONFIG_FOO_MODULE in > built-in code, which is a similar case. Cool. I'll keep this hack in drm-misc then. Please cc me on the proper solution so I know when I can revert it again. -Daniel
On 2015-10-01 12:17, Daniel Vetter wrote: > On Thu, Oct 01, 2015 at 11:58:32AM +0200, Michal Marek wrote: >> On 2015-10-01 10:19, Jani Nikula wrote: >>> On Thu, 01 Oct 2015, Daniel Vetter <daniel.vetter@ffwll.ch> wrote: >>>> Surprisingly kbuild can't cope with tristates in the >>>> <module>-$(CONFIG_FOO) pattern. This patch hacks up a solution. >>> >>> Given that it's two distinct Makefile variables (foo-y and foo-m) being >>> assigned to, I don't really find this surprising. Maybe this could be >>> made to work as a convenience, but there might be other, more surpising >>> consequences. >> >> I actually think that kbuild should be able to handle this. The likely >> reason why it is not doing it right now is that in an ideal world, >> modules are modules can be built out of tree against just the kernel and >> their static dependencies. In real world, we sometimes have features in >> modules that are enabled if other modules are enabled. I'll post a patch >> later. We also have lots of tests fo CONFIG_FOO || CONFIG_FOO_MODULE in >> built-in code, which is a similar case. > > Cool. I'll keep this hack in drm-misc then. Please cc me on the proper > solution so I know when I can revert it again. It's not as trivial as it seemed, because there are at least three Makefiles that rely on the current behavior: init/Makefile drivers/misc/ibmasm/Makefile fs/logfs/Makefile While ibmasm and logfs can and probably should be fixed to work with modular 8250 and mtd, respectively, init/Makefile would need a workaround to only pick up do_mounts_rd.o and do_mounts_md.o if the respective block drivers are built-in. So we would be trading one hack for another. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2015-10-01 16:50, Michal Marek wrote: > On 2015-10-01 12:17, Daniel Vetter wrote: >> On Thu, Oct 01, 2015 at 11:58:32AM +0200, Michal Marek wrote: >>> On 2015-10-01 10:19, Jani Nikula wrote: >>>> On Thu, 01 Oct 2015, Daniel Vetter <daniel.vetter@ffwll.ch> wrote: >>>>> Surprisingly kbuild can't cope with tristates in the >>>>> <module>-$(CONFIG_FOO) pattern. This patch hacks up a solution. >>>> >>>> Given that it's two distinct Makefile variables (foo-y and foo-m) being >>>> assigned to, I don't really find this surprising. Maybe this could be >>>> made to work as a convenience, but there might be other, more surpising >>>> consequences. >>> >>> I actually think that kbuild should be able to handle this. The likely >>> reason why it is not doing it right now is that in an ideal world, >>> modules are modules can be built out of tree against just the kernel and >>> their static dependencies. In real world, we sometimes have features in >>> modules that are enabled if other modules are enabled. I'll post a patch >>> later. We also have lots of tests fo CONFIG_FOO || CONFIG_FOO_MODULE in >>> built-in code, which is a similar case. >> >> Cool. I'll keep this hack in drm-misc then. Please cc me on the proper >> solution so I know when I can revert it again. > > It's not as trivial as it seemed, because there are at least three > Makefiles that rely on the current behavior: > > init/Makefile > drivers/misc/ibmasm/Makefile > fs/logfs/Makefile drivers/usb/chipidea is also on the list. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 1a0a8df2eed8..aecbec030aa4 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -7,6 +7,7 @@ menuconfig DRM tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)" depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU && HAS_DMA + select DRM_AGP if AGP select HDMI select FB_CMDLINE select I2C @@ -21,6 +22,9 @@ menuconfig DRM details. You should also select and configure AGP (/dev/agpgart) support if it is available for your platform. +config DRM_AGP + bool + config DRM_MIPI_DSI bool depends on DRM diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index f458d6e33655..c04d5a33fcac 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -19,7 +19,7 @@ drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o drm-$(CONFIG_PCI) += ati_pcigart.o drm-$(CONFIG_DRM_PANEL) += drm_panel.o drm-$(CONFIG_OF) += drm_of.o -drm-$(CONFIG_AGP) += drm_agpsupport.o +drm-$(CONFIG_DRM_AGP) += drm_agpsupport.o drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \ drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o