The GPIO reset controller uses gpiolib but there is no Kconfig
dependency reflecting this fact, add one.

With the addition of the controller to the arm64 defconfig this is
causing build breaks for arm64 virtconfig in -next:

aarch64-linux-gnu-ld: drivers/reset/core.o: in function `__reset_add_reset_gpio_lookup':
/build/stage/linux/drivers/reset/core.c:861:(.text+0xccc): undefined reference to `gpio_device_find_by_fwnode'

Fixes: cee544a40e44 ("reset: gpio: Add GPIO-based reset controller")
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 drivers/reset/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 85b27c42cf65..f426b4c39179 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -68,6 +68,7 @@ config RESET_BRCMSTB_RESCAL
 
 config RESET_GPIO
 	tristate "GPIO reset controller"
+	depends on GPIOLIB
 	help
 	  This enables a generic reset controller for resets attached via
 	  GPIOs.  Typically for OF platforms this driver expects "reset-gpios"

---
base-commit: 72fb52fb0ac44b6a1edd9bc390e44bce3acccd26
change-id: 20240320-reset-gpiolib-deps-f76269197fc0

Best regards,
-- 
Mark Brown <broonie@kernel.org>

On 20/03/2024 20:59, Mark Brown wrote:
> The GPIO reset controller uses gpiolib but there is no Kconfig
> dependency reflecting this fact, add one.
> 
> With the addition of the controller to the arm64 defconfig this is
> causing build breaks for arm64 virtconfig in -next:
> 
> aarch64-linux-gnu-ld: drivers/reset/core.o: in function `__reset_add_reset_gpio_lookup':
> /build/stage/linux/drivers/reset/core.c:861:(.text+0xccc): undefined reference to `gpio_device_find_by_fwnode'
> 

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof

On 20/03/2024 20:59, Mark Brown wrote:
> The GPIO reset controller uses gpiolib but there is no Kconfig
> dependency reflecting this fact, add one.
> 
> With the addition of the controller to the arm64 defconfig this is
> causing build breaks for arm64 virtconfig in -next:
> 
> aarch64-linux-gnu-ld: drivers/reset/core.o: in function `__reset_add_reset_gpio_lookup':
> /build/stage/linux/drivers/reset/core.c:861:(.text+0xccc): undefined reference to `gpio_device_find_by_fwnode'
> 

Lack of dependency was intentional: because there is no dependency.
GPIOLIB is optional. Because of that I added few stubs for missing
GPIOLIB functions, but I missed this stub here.

I propose to add gpio_device_find_by_fwnode() stub for !GPIOLIB case,
instead of adding dependency.

Best regards,
Krzysztof

On Thu, Mar 21, 2024 at 08:18:36AM +0100, Krzysztof Kozlowski wrote:
> On 20/03/2024 20:59, Mark Brown wrote:

> > The GPIO reset controller uses gpiolib but there is no Kconfig
> > dependency reflecting this fact, add one.

> Lack of dependency was intentional: because there is no dependency.
> GPIOLIB is optional. Because of that I added few stubs for missing
> GPIOLIB functions, but I missed this stub here.

> I propose to add gpio_device_find_by_fwnode() stub for !GPIOLIB case,
> instead of adding dependency.

In general the stubs do make sense however in this specific case given
that the driver is specifically to control a GPIO rather than using a
GPIO along with controlling some other thing a dependency does seem like
it makes sense.

On 21/03/2024 11:59, Mark Brown wrote:
> On Thu, Mar 21, 2024 at 08:18:36AM +0100, Krzysztof Kozlowski wrote:
>> On 20/03/2024 20:59, Mark Brown wrote:
> 
>>> The GPIO reset controller uses gpiolib but there is no Kconfig
>>> dependency reflecting this fact, add one.
> 
>> Lack of dependency was intentional: because there is no dependency.
>> GPIOLIB is optional. Because of that I added few stubs for missing
>> GPIOLIB functions, but I missed this stub here.
> 
>> I propose to add gpio_device_find_by_fwnode() stub for !GPIOLIB case,
>> instead of adding dependency.
> 
> In general the stubs do make sense however in this specific case given
> that the driver is specifically to control a GPIO rather than using a
> GPIO along with controlling some other thing a dependency does seem like
> it makes sense.

Then you add dependency in wrong place. The warning you have is in:
drivers/reset/core.o

But the dependency you add is in RESET_GPIO, which is a separate driver.
While the driver indeed wants GPIO, this won't solve the original
problem. You still can have RESET_GPIO disabled and core still has the
gpiolib call to missing stub.

Best regards,
Krzysztof

On Thu, Mar 21, 2024 at 12:38:16PM +0100, Krzysztof Kozlowski wrote:
> On 21/03/2024 11:59, Mark Brown wrote:

> > In general the stubs do make sense however in this specific case given
> > that the driver is specifically to control a GPIO rather than using a
> > GPIO along with controlling some other thing a dependency does seem like
> > it makes sense.

> Then you add dependency in wrong place. The warning you have is in:
> drivers/reset/core.o

Note that this isn't a warning but rather a link failure.

> But the dependency you add is in RESET_GPIO, which is a separate driver.
> While the driver indeed wants GPIO, this won't solve the original
> problem. You still can have RESET_GPIO disabled and core still has the
> gpiolib call to missing stub.

That's true, though it does happen to fix the immediate issue and seems
to make sense anyway given that the driver does actually rely on gpiolib
for functionality - it seems clear that there should be a dependency
there independently of the build failure.  Like I say I do agree that a
stub is sensible and you're right that it will fix the underlying issue
behind the build failure.