Currently, PINCTRL_S32CC selects PINCTRL_S32CC which needs GPIOLIB, without
selecting or depending on GPIOLIB.

However, other similar options in this subsystem actually select GPIOLIB
instead of depending, so I think we can do the same here.

This unmet dependency was found by kconfirm, a static analysis tool for
Kconfig.

Fixes: 94cb9e8f2707 ("pinctrl: s32cc: implement GPIO functionality")
Signed-off-by: Julian Braha <julianbraha@gmail.com>
---
 drivers/pinctrl/nxp/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/nxp/Kconfig b/drivers/pinctrl/nxp/Kconfig
index 711c0fe11565..fab725f250ab 100644
--- a/drivers/pinctrl/nxp/Kconfig
+++ b/drivers/pinctrl/nxp/Kconfig
@@ -1,10 +1,11 @@
 # SPDX-License-Identifier: GPL-2.0-only
 config PINCTRL_S32CC
 	bool
-	depends on ARCH_S32 && OF && GPIOLIB
+	depends on ARCH_S32 && OF
 	select GENERIC_PINCTRL_GROUPS
 	select GENERIC_PINMUX_FUNCTIONS
 	select GENERIC_PINCONF
+	select GPIOLIB
 	select GPIO_REGMAP
 	select REGMAP_MMIO
 
-- 
2.54.0

On Wed, Jul 22, 2026, at 22:26, Julian Braha wrote:
> Currently, PINCTRL_S32CC selects PINCTRL_S32CC which needs GPIOLIB, without
> selecting or depending on GPIOLIB.
>
> However, other similar options in this subsystem actually select GPIOLIB
> instead of depending, so I think we can do the same here.
>
> This unmet dependency was found by kconfirm, a static analysis tool for
> Kconfig.
>
> Fixes: 94cb9e8f2707 ("pinctrl: s32cc: implement GPIO functionality")
> Signed-off-by: Julian Braha <julianbraha@gmail.com>

Acked-by: Arnd Bergmann <arnd@arndb.de>

The patch looks fine, but I'm curious about what type of rule found
the mistake. Is this a heuristic that found that drivers/pinctrl/*
overwhelmingly uses select instead of depends, or did kconfirm
find a circular dependency that was caused by inconsistent
rules?

    Arnd

On 7/22/26 21:39, Arnd Bergmann wrote:
> The patch looks fine, but I'm curious about what type of rule found
> the mistake. Is this a heuristic that found that drivers/pinctrl/*
> overwhelmingly uses select instead of depends, or did kconfirm
> find a circular dependency that was caused by inconsistent
> rules?

Not a heuristic, kconfirm-smt is the first complete SMT solver for
Kconfig (as in, all semantics of the Kconfig language are used to
automatically encode all Kconfig files as SMT constraints).

There have been many previous SAT solvers for Kconfig, and there was one
that attempted to detect unmet dependencies (Kismet) but that one has
both false positives and false negatives because it approximates
everything as boolean logic.

In contrast, kconfirm-smt uses SMT integers and strings to model Kconfig
int/hex and strings (unsurprisingly). I believe I am the first to do
this.

So, to detect unmet dependencies, kconfirm-smt runs a check on every
single selector-selectee pair using this routine:
1. Add the constraints to the model that the option is enabled, and its
selector is enabled, and its dependencies aren't met.
2. If Z3 finds a solution (as in, the constraints are still satisfiable)
then we know that there is an unmet dependency.
3. Reset the constraints back to the original model, and loop ^^^

You can also use kconfirm-smt to do better random config generation than
randconfig ;)

Also, you can give it a partial .config file, and it will randomize the
rest of the options that are not in it.

Give it a try, I would love some feedback:
https://github.com/julianbraha/kconfirm/tree/smt#usage-examples

- Julian Braha

On Wed, Jul 22, 2026, at 23:14, Julian Braha wrote:
> On 7/22/26 21:39, Arnd Bergmann wrote:
>> The patch looks fine, but I'm curious about what type of rule found
>> the mistake. Is this a heuristic that found that drivers/pinctrl/*
>> overwhelmingly uses select instead of depends, or did kconfirm
>> find a circular dependency that was caused by inconsistent
>> rules?
>
> Not a heuristic, kconfirm-smt is the first complete SMT solver for
> Kconfig (as in, all semantics of the Kconfig language are used to
> automatically encode all Kconfig files as SMT constraints).

Ok, thanks for your detailed explanation. It turns out that there
is a typo in your patch description, and I further misread it:

| Currently, PINCTRL_S32CC selects PINCTRL_S32CC which needs GPIOLIB,
| without selecting or depending on GPIOLIB.

Clearly, this should have said

| ... PINCTRL_S32G2 selects PINCTRL_S32CC ...

to explain the actual bug. ;-)

      Arnd