Re: [PATCH] memory: OMAP_GPMC should depend on ARCH_OMAP2PLUS || ARCH_K3

From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>,
	Roger Quadros <rogerq@kernel.org>
Cc: Tony Lindgren <tony@atomide.com>,
	"open list:TI ETHERNET SWITCH DRIVER (CPSW)" 
	<linux-omap@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] memory: OMAP_GPMC should depend on ARCH_OMAP2PLUS || ARCH_K3
Date: Tue, 10 May 2022 09:36:57 +0200	[thread overview]
Message-ID: <b8983ff3-7dca-0556-1bcc-05897aef212c@linaro.org> (raw)
In-Reply-To: <CAMuHMdVXHSnOOnn3jchezQc+bsPYTnSPuw_rOe+pyskAVaQGnQ@mail.gmail.com>

On 10/05/2022 09:30, Geert Uytterhoeven wrote:
> Hi Roger,
> 
> On Tue, May 10, 2022 at 9:22 AM Roger Quadros <rogerq@kernel.org> wrote:
>> On 09/05/2022 16:48, Geert Uytterhoeven wrote:
>>> The Texas Instruments OMAP General Purpose Memory Controller (GPMC) is
>>> only present on TI OMAP2/3/4/5, AM33xx, AM43x, DRA7xx, TI81xx, and K3
>>> SoCs.  Hence add a dependency on ARCH_OMAP2PLUS || ARCH_K3, to prevent
>>> asking the user about this driver when configuring a kernel without
>>> OMAP2+ or K3 SoC family support.
>>>
>>> Fixes: be34f45f0d4aa91c ("memory: omap-gpmc: Make OMAP_GPMC config visible and selectable")
>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> 
>>> --- a/drivers/memory/Kconfig
>>> +++ b/drivers/memory/Kconfig
>>> @@ -105,6 +105,7 @@ config TI_EMIF
>>>  config OMAP_GPMC
>>>       tristate "Texas Instruments OMAP SoC GPMC driver"
>>>       depends on OF_ADDRESS
>>> +     depends on ARCH_OMAP2PLUS || ARCH_K3 || COMPILE_TEST
>>>       select GPIOLIB
>>>       help
>>>         This driver is for the General Purpose Memory Controller (GPMC)
>>
>> Is there any possibility that CONFIG_IRQ_DOMAIN is not set while both
>> OF_ADDRESS and COMPILE_TEST are set?
>>
>> That particular case will lead to build failures.
>>
>> e.g.
>> https://krzk.eu/#/builders/63/builds/162
> 
> So it needs an additional dependency on IRQ_DOMAIN.
> That is a pre-existing problem, not caused by my patch (which adds
> more dependencies, and doesn't remove any).

Is this really a case here? The failure reported above was for earlier
version of Roger's patch which was changing to:
	depends on OF_ADDRESS || COMPILE_TEST

Here, OF_ADDRESS will be always a dependency. If it builds in current
configuration (having only OF_ADDRESS), then adding dependencies should
not cause more issues.... It only restricts the config, not widens it.

Therefore the patch looks actually correct, but some testing would be
nice that we don't hit the same issues as before.

Best regards,
Krzysztof