Several drivers express optional Kconfig dependency with FOO || !FOO, but for many choices this is neither suitable (lack of stubs for !FOO like in HWMON) nor really needed and driver can be built in even if FOO is the module. This is achieved with IS_REACHABLE, so provide cross reference to it. Cc: Masahiro Yamada <masahiroy@xxxxxxxxxx> Cc: Arnd Bergmann <arnd@xxxxxxxx> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> --- Documentation/kbuild/kconfig-language.rst | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst index 2619fdf56e68..66248294a552 100644 --- a/Documentation/kbuild/kconfig-language.rst +++ b/Documentation/kbuild/kconfig-language.rst @@ -194,6 +194,8 @@ applicable everywhere (see syntax). ability to hook into a secondary subsystem while allowing the user to configure that subsystem out without also having to unset these drivers. +.. _is_reachable: + Note: If the combination of FOO=y and BAZ=m causes a link error, you can guard the function call with IS_REACHABLE():: @@ -580,10 +582,15 @@ 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:: +There are two ways to express this optional dependency: - config FOO +1. If pre-processor can discard entire optional code or module FOO does not + provide !FOO stubs then in the C code :ref:`IS_REACHABLE<is_reachable>` + +2. Otherwise (and module FOO must provide all !FOO stubs) use the slightly + counterintuitive Kconfig syntax:: + + config FOO tristate "Support for foo hardware" depends on BAR || !BAR -- 2.43.0
