Group the three NXP platforms under an ARCH_NXP menuconfig symbol to
make make selection of similar vendor SoCs visually nicer.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 arch/arm64/Kconfig.platforms | 29 ++++++++++++++++++-----------
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 748f9ac4d775..61d946e092d3 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -143,12 +143,6 @@ config ARCH_K3
 	  This enables support for Texas Instruments' K3 multicore SoC
 	  architecture.
 
-config ARCH_LAYERSCAPE
-	bool "ARMv8 based Freescale Layerscape SoC family"
-	select EDAC_SUPPORT
-	help
-	  This enables support for the Freescale Layerscape SoC family.
-
 config ARCH_LG1K
 	bool "LG Electronics LG1K SoC Family"
 	help
@@ -207,6 +201,17 @@ config ARCH_MVEBU
 	   - Armada 8K SoC Family
 	   - 98DX2530 SoC Family
 
+menuconfig ARCH_NXP
+	bool "NXP SoC support"
+
+if ARCH_NXP
+
+config ARCH_LAYERSCAPE
+	bool "ARMv8 based Freescale Layerscape SoC family"
+	select EDAC_SUPPORT
+	help
+	  This enables support for the Freescale Layerscape SoC family.
+
 config ARCH_MXC
 	bool "ARMv8 based NXP i.MX SoC family"
 	select ARM64_ERRATUM_843419
@@ -221,6 +226,13 @@ config ARCH_MXC
 	  This enables support for the ARMv8 based SoCs in the
 	  NXP i.MX family.
 
+config ARCH_S32
+	bool "NXP S32 SoC Family"
+	help
+	  This enables support for the NXP S32 family of processors.
+
+endif
+
 config ARCH_NPCM
 	bool "Nuvoton NPCM Architecture"
 	select PINCTRL
@@ -264,11 +276,6 @@ config ARCH_ROCKCHIP
 	  This enables support for the ARMv8 based Rockchip chipsets,
 	  like the RK3368.
 
-config ARCH_S32
-	bool "NXP S32 SoC Family"
-	help
-	  This enables support for the NXP S32 family of processors.
-
 config ARCH_SEATTLE
 	bool "AMD Seattle SoC Family"
 	help
-- 
2.25.1

On Mon, Aug 29, 2022 at 10:38:29AM -0700, Florian Fainelli wrote:
> Group the three NXP platforms under an ARCH_NXP menuconfig symbol to
> make make selection of similar vendor SoCs visually nicer.
> 
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>

Hi,

While these are convenient if they're done right from the beginning, the result
of adding a new dependency like this is that old defconfigs stop working if you
just go with the default.

Was there a reason to group these now and cause this config churn for
downstream users?


-Olof

On 9/15/22 09:08, Olof Johansson wrote:
> On Mon, Aug 29, 2022 at 10:38:29AM -0700, Florian Fainelli wrote:
>> Group the three NXP platforms under an ARCH_NXP menuconfig symbol to
>> make make selection of similar vendor SoCs visually nicer.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> 
> Hi,
> 
> While these are convenient if they're done right from the beginning, the result
> of adding a new dependency like this is that old defconfigs stop working if you
> just go with the default.
> 
> Was there a reason to group these now and cause this config churn for
> downstream users?

No reason to cause churn, and no specific reason other than visually and 
logically group options from the same vendors. I had clearly not 
anticipated the defconfig breakage, too bad that Kconfig does not allow 
menuconfig items to be enabled by default, or does it?
-- 
Florian

On Thu, Sep 15, 2022 at 1:52 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> On 9/15/22 09:08, Olof Johansson wrote:
> > On Mon, Aug 29, 2022 at 10:38:29AM -0700, Florian Fainelli wrote:
> >> Group the three NXP platforms under an ARCH_NXP menuconfig symbol to
> >> make make selection of similar vendor SoCs visually nicer.
> >>
> >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> >
> > Hi,
> >
> > While these are convenient if they're done right from the beginning, the result
> > of adding a new dependency like this is that old defconfigs stop working if you
> > just go with the default.
> >
> > Was there a reason to group these now and cause this config churn for
> > downstream users?
>
> No reason to cause churn, and no specific reason other than visually and
> logically group options from the same vendors. I had clearly not
> anticipated the defconfig breakage, too bad that Kconfig does not allow
> menuconfig items to be enabled by default, or does it?

My local workflow is normally that I update my trees, then run a "make
oldconfig" and go with the defaults on new options. When I do that,
the layerscape arch option drops off, which turned out to be
unfortunate since it was the machine I was running on.

It's less of an issue if you use an in-tree defconfig (presuming they
get updated). I worry that distros will have similar issues if they
supply their own config.

Again, this is a one-time thing but it's easier for everybody if we
find ways to avoid them. Giving these new groups a "default y" might
not help either, since that would need to come off at some point, and
at that time the same issue will arise.


-Olof