| Message ID | 20220829173830.3567047-3-f.fainelli@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64: Kconfig.platforms: Group vendors together | expand |
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?
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
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
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(-)