From: Arnd Bergmann Date: Sun, 17 Sep 2023 19:19:59 +0000 (+0200) Subject: Documentation: kbuild: explain handling optional dependencies X-Git-Tag: v6.6.7~1800^2~4 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=28d49e171676afb7df7f47798391364af9abed7f;p=platform%2Fkernel%2Flinux-starfive.git Documentation: kbuild: explain handling optional dependencies This problem frequently comes up in randconfig testing, with drivers failing to link because of a dependency on an optional feature. The Kconfig language for this is very confusing, so try to document it in "Kconfig hints" section. Reviewed-by: Javier Martinez Canillas Reviewed-by: Sakari Ailus Reviewed-by: Nicolas Schier Signed-off-by: Arnd Bergmann Signed-off-by: Masahiro Yamada --- diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst index 858ed5d..0135905 100644 --- a/Documentation/kbuild/kconfig-language.rst +++ b/Documentation/kbuild/kconfig-language.rst @@ -573,6 +573,32 @@ above, leading to: bool "Support for foo hardware" depends on ARCH_FOO_VENDOR || COMPILE_TEST +Optional dependencies +~~~~~~~~~~~~~~~~~~~~~ + +Some drivers are able to optionally use a feature from another module +or build cleanly with that module disabled, but cause a link failure +when trying to use that loadable module from a built-in driver. + +The most common way to express this optional dependency in Kconfig logic +uses the slightly counterintuitive:: + + config FOO + tristate "Support for foo hardware" + depends on BAR || !BAR + +This means that there is either a dependency on BAR that disallows +the combination of FOO=y with BAR=m, or BAR is completely disabled. +For a more formalized approach if there are multiple drivers that have +the same dependency, a helper symbol can be used, like:: + + config FOO + tristate "Support for foo hardware" + depends on BAR_OPTIONAL + + config BAR_OPTIONAL + def_tristate BAR || !BAR + Kconfig recursive dependency limitations ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~