[PATCH] Support conditional deps using "depends on X if Y"

[PATCH] Support conditional deps using "depends on X if Y"

[Graham Roff]

From: Nicolas Pitre <nico@fluxnic.net>

Extend the "depends on" syntax to support conditional dependencies
using "depends on X if Y". While functionally equivalent to "depends
on X || (Y == n)", "depends on X if Y" is much more readable and
makes the kconfig language uniform in supporting the "if <expr>"
suffix.

The change is implemented by converting the "X if Y" syntax into the
"X || (Y == n)" syntax during "depends on" token processing.

Signed-off-by: Nicolas Pitre <nico@fluxnic.net>

[Graham Roff: Rewrote commit message and redid patch for latest kernel]

Signed-off-by: Graham Roff <grahamr@qti.qualcomm.com>
---
This patch updates an earlier one that was not merged to work on 
the latest kernel release.

Link: https://lwn.net/ml/linux-kernel/nycvar.YSQ.7.76.2004231102480.2671@knanqh.ubzr/#t

Support for this change has been expressed by a number of developers
since the original patch was proposed back in 2020, and has recently
also been raised as a patch to the Zephyr kconfig system.
One specific use is when mapping the Bluetooth specification to Kconfig,
as it explicitly provides dependencies between features as conditional
on other features. Many other cases exist where the "slightly
counterintuitive" (quoted from the Kconfig specification) expression 
"depends on BAR || !BAR" has been used when a proper "if" condition 
would be more readable.

The earlier patch discussion ended without a real conclusion and should
be revisited now.
---
 Documentation/kbuild/kconfig-language.rst | 12 +++++++++++-
 scripts/kconfig/lkc.h                     |  2 +-
 scripts/kconfig/menu.c                    | 12 +++++++++++-
 scripts/kconfig/parser.y                  |  6 +++---
 4 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst
index abce88f15d7c..61848f999db8 100644
--- a/Documentation/kbuild/kconfig-language.rst
+++ b/Documentation/kbuild/kconfig-language.rst
@@ -118,7 +118,7 @@ applicable everywhere (see syntax).
   This is a shorthand notation for a type definition plus a value.
   Optionally dependencies for this default value can be added with "if".
 
-- dependencies: "depends on" <expr>
+- dependencies: "depends on" <expr> ["if" <expr>]
 
   This defines a dependency for this menu entry. If multiple
   dependencies are defined, they are connected with '&&'. Dependencies
@@ -134,6 +134,16 @@ applicable everywhere (see syntax).
 	bool "foo"
 	default y
 
+  The dependency definition itself may be conditional by appending "if"
+  followed by an expression. If such expression is false (n) then this
+  dependency is ignored. One possible use case is:
+
+    config FOO
+	tristate
+	depends on BAZ if BAZ != n
+
+  meaning that FOO is constrained by the value of BAZ only when it is set.
+
 - reverse dependencies: "select" <symbol> ["if" <expr>]
 
   While normal dependencies reduce the upper limit of a symbol (see
diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h
index 56548efc14d7..798985961215 100644
--- a/scripts/kconfig/lkc.h
+++ b/scripts/kconfig/lkc.h
@@ -82,7 +82,7 @@ void menu_warn(const struct menu *menu, const char *fmt, ...);
 struct menu *menu_add_menu(void);
 void menu_end_menu(void);
 void menu_add_entry(struct symbol *sym, enum menu_type type);
-void menu_add_dep(struct expr *dep);
+void menu_add_dep(struct expr *dep, struct expr *cond);
 void menu_add_visibility(struct expr *dep);
 struct property *menu_add_prompt(enum prop_type type, const char *prompt,
 				 struct expr *dep);
diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index 0f1a6513987c..b2d8d4e11e07 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -127,8 +127,18 @@ static struct expr *rewrite_m(struct expr *e)
 	return e;
 }
 
-void menu_add_dep(struct expr *dep)
+void menu_add_dep(struct expr *dep, struct expr *cond)
 {
+	if (cond) {
+		/*
+		 * We have "depends on X if Y" and we want:
+		 *	Y != n --> X
+		 *	Y == n --> y
+		 * That simplifies to: (X || (Y == n))
+		 */
+		dep = expr_alloc_or(dep,
+				expr_trans_compare(cond, E_EQUAL, &symbol_no));
+	}
 	current_entry->dep = expr_alloc_and(current_entry->dep, dep);
 }
 
diff --git a/scripts/kconfig/parser.y b/scripts/kconfig/parser.y
index 49b79dde1725..6d1bbee38f5d 100644
--- a/scripts/kconfig/parser.y
+++ b/scripts/kconfig/parser.y
@@ -323,7 +323,7 @@ if_entry: T_IF expr T_EOL
 {
 	printd(DEBUG_PARSE, "%s:%d:if\n", cur_filename, cur_lineno);
 	menu_add_entry(NULL, M_IF);
-	menu_add_dep($2);
+	menu_add_dep($2, NULL);
 	$$ = menu_add_menu();
 };
 
@@ -422,9 +422,9 @@ help: help_start T_HELPTEXT
 
 /* depends option */
 
-depends: T_DEPENDS T_ON expr T_EOL
+depends: T_DEPENDS T_ON expr if_expr T_EOL
 {
-	menu_add_dep($3);
+	menu_add_dep($3, $4);
 	printd(DEBUG_PARSE, "%s:%d:depends on\n", cur_filename, cur_lineno);
 };
 

---
base-commit: a1388fcb52fcad3e0b06e2cdd0ed757a82a5be30
change-id: 20251106-kconfig_conditional_deps-51f1c903f863

Best regards,
-- 
Graham Roff <grahamr@qti.qualcomm.com>

Re: [PATCH] Support conditional deps using "depends on X if Y"

[Nathan Chancellor]

Hi Graham,

On Fri, Nov 07, 2025 at 05:16:34PM -0800, Graham Roff wrote:
> From: Nicolas Pitre <nico@fluxnic.net>
> 
> Extend the "depends on" syntax to support conditional dependencies
> using "depends on X if Y". While functionally equivalent to "depends
> on X || (Y == n)", "depends on X if Y" is much more readable and
> makes the kconfig language uniform in supporting the "if <expr>"
> suffix.
> 
> The change is implemented by converting the "X if Y" syntax into the
> "X || (Y == n)" syntax during "depends on" token processing.
> 
> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
> 
> [Graham Roff: Rewrote commit message and redid patch for latest kernel]
> 
> Signed-off-by: Graham Roff <grahamr@qti.qualcomm.com>
> ---
> This patch updates an earlier one that was not merged to work on 
> the latest kernel release.
> 
> Link: https://lwn.net/ml/linux-kernel/nycvar.YSQ.7.76.2004231102480.2671@knanqh.ubzr/#t
> 
> Support for this change has been expressed by a number of developers
> since the original patch was proposed back in 2020, and has recently
> also been raised as a patch to the Zephyr kconfig system.

Do you have a link to this Zephyr Kconfig change?

> One specific use is when mapping the Bluetooth specification to Kconfig,
> as it explicitly provides dependencies between features as conditional
> on other features. Many other cases exist where the "slightly
> counterintuitive" (quoted from the Kconfig specification) expression 
> "depends on BAR || !BAR" has been used when a proper "if" condition 
> would be more readable.
> 
> The earlier patch discussion ended without a real conclusion and should
> be revisited now.

I think it would be useful to have a slightly more concrete example in
the documentation of where this could be useful because even with the
"if" syntax, it still feels a little confusing to me at least with the
current example. Since this is just internally converting "depends on A
if B" to "depends on A || !B", this seems like a low risk addition to
the Kconfig language but it would be good to have some tests under
scripts/kconfig/tests like the ones recently added by commit
f9afce4f32e9 ("kconfig: Add transitional symbol attribute for migration
support") upstream.

> ---
>  Documentation/kbuild/kconfig-language.rst | 12 +++++++++++-
>  scripts/kconfig/lkc.h                     |  2 +-
>  scripts/kconfig/menu.c                    | 12 +++++++++++-
>  scripts/kconfig/parser.y                  |  6 +++---
>  4 files changed, 26 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst
> index abce88f15d7c..61848f999db8 100644
> --- a/Documentation/kbuild/kconfig-language.rst
> +++ b/Documentation/kbuild/kconfig-language.rst
> @@ -118,7 +118,7 @@ applicable everywhere (see syntax).
>    This is a shorthand notation for a type definition plus a value.
>    Optionally dependencies for this default value can be added with "if".
>  
> -- dependencies: "depends on" <expr>
> +- dependencies: "depends on" <expr> ["if" <expr>]
>  
>    This defines a dependency for this menu entry. If multiple
>    dependencies are defined, they are connected with '&&'. Dependencies
> @@ -134,6 +134,16 @@ applicable everywhere (see syntax).
>  	bool "foo"
>  	default y
>  
> +  The dependency definition itself may be conditional by appending "if"
> +  followed by an expression. If such expression is false (n) then this
> +  dependency is ignored. One possible use case is:
> +
> +    config FOO
> +	tristate
> +	depends on BAZ if BAZ != n
> +
> +  meaning that FOO is constrained by the value of BAZ only when it is set.
> +
>  - reverse dependencies: "select" <symbol> ["if" <expr>]
>  
>    While normal dependencies reduce the upper limit of a symbol (see
> diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h
> index 56548efc14d7..798985961215 100644
> --- a/scripts/kconfig/lkc.h
> +++ b/scripts/kconfig/lkc.h
> @@ -82,7 +82,7 @@ void menu_warn(const struct menu *menu, const char *fmt, ...);
>  struct menu *menu_add_menu(void);
>  void menu_end_menu(void);
>  void menu_add_entry(struct symbol *sym, enum menu_type type);
> -void menu_add_dep(struct expr *dep);
> +void menu_add_dep(struct expr *dep, struct expr *cond);
>  void menu_add_visibility(struct expr *dep);
>  struct property *menu_add_prompt(enum prop_type type, const char *prompt,
>  				 struct expr *dep);
> diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
> index 0f1a6513987c..b2d8d4e11e07 100644
> --- a/scripts/kconfig/menu.c
> +++ b/scripts/kconfig/menu.c
> @@ -127,8 +127,18 @@ static struct expr *rewrite_m(struct expr *e)
>  	return e;
>  }
>  
> -void menu_add_dep(struct expr *dep)
> +void menu_add_dep(struct expr *dep, struct expr *cond)
>  {
> +	if (cond) {
> +		/*
> +		 * We have "depends on X if Y" and we want:
> +		 *	Y != n --> X
> +		 *	Y == n --> y
> +		 * That simplifies to: (X || (Y == n))
> +		 */
> +		dep = expr_alloc_or(dep,
> +				expr_trans_compare(cond, E_EQUAL, &symbol_no));
> +	}
>  	current_entry->dep = expr_alloc_and(current_entry->dep, dep);
>  }
>  
> diff --git a/scripts/kconfig/parser.y b/scripts/kconfig/parser.y
> index 49b79dde1725..6d1bbee38f5d 100644
> --- a/scripts/kconfig/parser.y
> +++ b/scripts/kconfig/parser.y
> @@ -323,7 +323,7 @@ if_entry: T_IF expr T_EOL
>  {
>  	printd(DEBUG_PARSE, "%s:%d:if\n", cur_filename, cur_lineno);
>  	menu_add_entry(NULL, M_IF);
> -	menu_add_dep($2);
> +	menu_add_dep($2, NULL);
>  	$$ = menu_add_menu();
>  };
>  
> @@ -422,9 +422,9 @@ help: help_start T_HELPTEXT
>  
>  /* depends option */
>  
> -depends: T_DEPENDS T_ON expr T_EOL
> +depends: T_DEPENDS T_ON expr if_expr T_EOL
>  {
> -	menu_add_dep($3);
> +	menu_add_dep($3, $4);
>  	printd(DEBUG_PARSE, "%s:%d:depends on\n", cur_filename, cur_lineno);
>  };
>  
> 
> ---
> base-commit: a1388fcb52fcad3e0b06e2cdd0ed757a82a5be30
> change-id: 20251106-kconfig_conditional_deps-51f1c903f863
> 
> Best regards,
> -- 
> Graham Roff <grahamr@qti.qualcomm.com>
> 

Re: [PATCH] Support conditional deps using "depends on X if Y"

[Jani Nikula]

On Sun, 09 Nov 2025, Nathan Chancellor <nathan@kernel.org> wrote:
> I think it would be useful to have a slightly more concrete example in
> the documentation of where this could be useful because even with the
> "if" syntax, it still feels a little confusing to me at least with the
> current example. Since this is just internally converting "depends on A
> if B" to "depends on A || !B", this seems like a low risk addition to
> the Kconfig language but it would be good to have some tests under
> scripts/kconfig/tests like the ones recently added by commit
> f9afce4f32e9 ("kconfig: Add transitional symbol attribute for migration
> support") upstream.

"depends on A || !A" (or A=n) is the most common pattern in Kconfig,
which literally means "depends on A if A".

BR,
Jani.


-- 
Jani Nikula, Intel

Re: [PATCH] Support conditional deps using "depends on X if Y"

[Nathan Chancellor]

On Mon, Nov 10, 2025 at 10:48:59AM +0200, Jani Nikula wrote:
> "depends on A || !A" (or A=n) is the most common pattern in Kconfig,
> which literally means "depends on A if A".

That is totally fair, I did not try to actually search for the idiom. I
will say I do not find that either expression in Kconfig easily
translates in my head to "this dependency must be built in if the symbol
is built in, modular if the symbol is modular, or disabled" but I guess
that is just lack of familiarity with these idioms. I just want it to be
obvious to folks writing Kconfig when something like this is appropriate
to use but I guess with that being the most common usage in the tree, it
is fine as is.

I think my point about tests still stands, at least something very
basic.

Cheers,
Nathan

Re: [PATCH] Support conditional deps using "depends on X if Y"

[Randy Dunlap]

On 11/10/25 1:15 PM, Nathan Chancellor wrote:
> On Mon, Nov 10, 2025 at 10:48:59AM +0200, Jani Nikula wrote:
>> "depends on A || !A" (or A=n) is the most common pattern in Kconfig,
>> which literally means "depends on A if A".
> 
> That is totally fair, I did not try to actually search for the idiom. I
> will say I do not find that either expression in Kconfig easily
> translates in my head to "this dependency must be built in if the symbol
> is built in, modular if the symbol is modular, or disabled" but I guess
> that is just lack of familiarity with these idioms. I just want it to be
> obvious to folks writing Kconfig when something like this is appropriate
> to use but I guess with that being the most common usage in the tree, it
> is fine as is.

I haven't tested it but it looks reasonable to me.

> I think my point about tests still stands, at least something very
> basic.

Ack.

-- 
~Randy

Re: [PATCH] Support conditional deps using "depends on X if Y"

[Graham Roff]

> On 11/10/25 1:15 PM, Nathan Chancellor wrote:
> > Support for this change has been expressed by a number of developers 
> > since the original patch was proposed back in 2020, and has recently 
> > also been raised as a patch to the Zephyr kconfig system.
> 
> Do you have a link to this Zephyr Kconfig change?

Link: https://github.com/zephyrproject-rtos/Kconfiglib/pull/21

> > On Mon, Nov 10, 2025 at 10:48:59AM +0200, Jani Nikula wrote:
> >> "depends on A || !A" (or A=n) is the most common pattern in Kconfig,
> >> which literally means "depends on A if A".
> > 
> > That is totally fair, I did not try to actually search for the idiom. I
> > will say I do not find that either expression in Kconfig easily
> > translates in my head to "this dependency must be built in if the symbol
> > is built in, modular if the symbol is modular, or disabled" but I guess
> > that is just lack of familiarity with these idioms. I just want it to be
> > obvious to folks writing Kconfig when something like this is appropriate
> > to use but I guess with that being the most common usage in the tree, it
> > is fine as is.
> 
> I haven't tested it but it looks reasonable to me.

I will update the documentation to make the initial example
more understandable ("depends on A if B" is actually easier to follow 
than the more strange "depends on A if A"). Then also add a note in the
section on Optional Dependencies about using the new "A if A" form.

> 
> > I think my point about tests still stands, at least something very
> > basic.
> 
> Ack.

Agree, will include tests in the updated patch.

Graham 

Re: [PATCH] Support conditional deps using "depends on X if Y"

[Jani Nikula]

On Mon, 10 Nov 2025, Nathan Chancellor <nathan@kernel.org> wrote:
> On Mon, Nov 10, 2025 at 10:48:59AM +0200, Jani Nikula wrote:
>> "depends on A || !A" (or A=n) is the most common pattern in Kconfig,
>> which literally means "depends on A if A".
>
> That is totally fair, I did not try to actually search for the idiom. I
> will say I do not find that either expression in Kconfig easily
> translates in my head to "this dependency must be built in if the symbol
> is built in, modular if the symbol is modular, or disabled" but I guess
> that is just lack of familiarity with these idioms. I just want it to be
> obvious to folks writing Kconfig when something like this is appropriate
> to use but I guess with that being the most common usage in the tree, it
> is fine as is.

Right. I guess it takes a while to get used to the idiom A || !A. But
then is it counter-productive to add an alternative that is apparently
not much more helpful? And then we have two ways to express the same
thing.

So the follow-up questions:

- Can we come up with a more obvious alternative to the specific case of
  "A || !A"?

- Can we have examples of conversions from "A || !B" to "A if B" in
  kernel Kconfigs? As in, don't add features without users.

My point is, there are like 10x more "A || !A" than there are "A || !B".
Feels weird to advertize and document the thing for the latter, when the
former is the more prevalent case.

$ git grep -E "depends on .*\b([A-Z0-9_]+) \|\| (\!\1\b|\1=n)"

I'm not at all opposed to the change per se.


BR,
Jani.


-- 
Jani Nikula, Intel

Re: [PATCH] Support conditional deps using "depends on X if Y"

[Graham Roff]

Jani,

> Right. I guess it takes a while to get used to the idiom A || !A. But
> then is it counter-productive to add an alternative that is apparently
> not much more helpful? And then we have two ways to express the same
> thing.

I think that expressing an optional dependency using "depends on
A if A" is easier to read and understand than "depends on A || !A". And
it is certainly easier to follow "depends on A if B" rather than
"depends on A || !B" - even realizing those are equivalent takes a
class in boolean logic ;)

Also, most other Kconfig attributes support the trailing "if <expr>"
so this makes the language more consistent.

> So the follow-up questions:
> 
> - Can we come up with a more obvious alternative to the specific case of
>   "A || !A"?

Meaning an entirely different syntax rather than "A if A"? Something
like "optional_depends on A" (just a made-up example to make the 
question clear)? That seems to be adding unnecessary syntax when the
conditional dependency covers both cases ("A if B" and "A if A"). If
there are any suggestions for a clearer way to express the purely
optional dependency case then that is worth looking at - but honestly
the entire concept seems a bit weird (even if widely used). It may 
just naturally be hard to express the concept in a simple manner.

> - Can we have examples of conversions from "A || !B" to "A if B" in
>   kernel Kconfigs? As in, don't add features without users.

(In the Zephyr pull-request I listed a number of examples from that 
project as well.)
You are correct that most commonly conditional dependencies are used
for *optional* dependencies, but there are a lot of other conditional
ones as well. Note when grepping for examples look for both "!A || B"
and "!B || A" - both forms are present in many places. A few examples:

arch/arm64/Kconfig:
  depends on ARM64_64K_PAGES || !ARM64_VA_BITS_52 -->
  depends on ARM64_64K_PAGES if ARM64_VA_BITS_52
arch/mips/Kconfig:
  depends on SYS_SUPPORTS_HOTPLUG_CPU || !SMP -->
  depends on SYS_SUPPORTS_HOTPLUG_CPU if SMP
arch/riscv/Kconfig:
  depends on CC_HAS_MIN_FUNCTION_ALIGNMENT || !RISCV_ISA_C -->
  depends on CC_HAS_MIN_FUNCTION_ALIGNMENT if RISCV_ISA_C
arch/x86/Kconfig:
  depends on X86_64 || !SPARSEMEM -->
  depends on X86_64 if SPARSEMEM
drivers/acpi/Kconfig:
  depends on ACPI_WMI || !X86 -->
  depends on ACPI_WMI if X86
drivers/bluetooth/Kconfig:
  depends on USB || !BT_HCIBTUSB_MTK
  depends on USB if BT_HCIBTUSB_MTK
mm/Kconfig:
  depends on !ARM || CPU_CACHE_VIPT -->
  depends on CPU_CACHE_VIPT if ARM
kernel/Kconfig.locks:
  depends on !PREEMPTION || ARCH_INLINE_READ_UNLOCK -->
  depends on ARCH_INLINE_READ_UNLOCK if PREEMPTION

Are you suggesting an update to the commit text to call out the 
optional dependency use-case explicitly?

> My point is, there are like 10x more "A || !A" than there are "A || !B".
> Feels weird to advertize and document the thing for the latter, when the
> former is the more prevalent case.
> 
> $ git grep -E "depends on .*\b([A-Z0-9_]+) \|\| (\!\1\b|\1=n)"
> 
> I'm not at all opposed to the change per se.

The Kconfig documentation will cover both cases (in next patch). The
"A || !A" case is covered already in a special "Optional dependencies"
section which I will update to use "A if A" as a preferred syntax. I 
still suggest having the definition section for "depends on" using the 
easier to understand example of "depends on A if B".

Thanks, 

Graham