Re: [PATCH] arm64: Kconfig.platforms: Re-organized Broadcom menu

[Florian Fainelli]

On 7/13/22 15:05, Florian Fainelli wrote:
> On 7/13/22 02:17, Geert Uytterhoeven wrote:
> > Hi Krzysztof,
> >
> > On Wed, Jul 13, 2022 at 10:40 AM Krzysztof Kozlowski
> > <krzysztof.kozlowski@xxxxxxxxxx> wrote:
> > > On 13/07/2022 10:25, Arnd Bergmann wrote:
> > > > On Tue, Jul 12, 2022 at 6:42 PM Florian Fainelli 
> > > > <f.fainelli@xxxxxxxxx> wrote:
> > > > > There are now multiple Broadcom SoCs supported so group them under 
> > > > > their
> > > > > own menu such that the selection is visually more appealing and we can
> > > > > easily add new platforms there in the future. This allows us to move
> > > > > ARCH_BRCMSTB back to its siblings.
> > > > >
> > > > > No functional changes introduced.
> > > > >
> > > > > Signed-off-by: Florian Fainelli <f.fainelli@xxxxxxxxx>
> > > > > ---
> > > > >
> > > > > Note this is based on "arm64: bcmbca: add arch bcmbca machine entry"
> > > >
> > > > Hi Florian,
> > > >
> > > > So far, we have tried to keep the Kconfig.platforms file rather 
> > > > coarse-grained,
> > > > mainly limiting it to company names and high-level families, but 
> > > > avoiding
> > > > sub-menus or adding too many sub-families.
> > > >
> > > > If we add per-vendor submenus, we should probably first decide how we
> > > > want to structure this across vendors. I've added maintainers and 
> > > > lists to
> > > > Cc for a couple of the ones that are in a similar situation.
> > > >
> > > > I can see a couple of ways we can do this:
> > > >
> > > > a) keep the list of platforms as short as possible, combining related
> > > >    SoC families from a single vendor wherever possible, but no 
> > > > sub-menus
> > > >    (same as today)
> > > >
> > > > b) Always use sub-menus when there is more than one family, but
> > > >     keep relatively coarse platform selection.
> > > >
> > > > c) Use sub-menus and also move to a more fine-grained SoC
> > > >      selection, similar to what we have on 32-bit arm.
> > > >
> > > > I would not really want to go to c), but a) and b) both make sense to
> > > > me as long as do it consistently across all platforms.
> > > >
> > > > Any other ideas or opinions?
> > >
> > > Whatever we decide here, the SoC can override in drivers/soc, just like
> > > Renesas did. I think Renesas chose option c), but made it in
> > > drivers/soc. I would vote to have consistent policy, so if arch/arm64 is
> > > a) or b), sub-archs should not redefine it in drivers/soc.
> >
> > We did so because of the "only a single symbol in
> > arch/arm64/Kconfig.platforms"-policy.
>
> I was not aware of that rule.
>
> It is a bit of a mixed situation with Broadcom SoCs but in essence, each 
> Kconfig entry denotes a deeply different SoC architecture at the memory 
> subsystem, bus, security or product space that you might not want to 
> enable in your kernel. There is definitively sharing of drivers between 
> all of the platforms and a lot of cross pollination too but usually 
> these are deeply different that different kernel images do make sense.
>
> The itch that I wanted to calm was that ARCH_BRCMSTB was after the other 
> Broadcom platforms separated by ARCH_BERLIN. if you prefer a pair of 
> KConfig comments to delineate them and flatten the platform selection, 
> that works for me, too.

There are 2 Marvell-based platforms (Berlin and mvebu) as well as two 
NXP-based platforms (MXC and S32), would it be better to also group them 
under an ARCH_MARVELL and ARCH_NXP menuconfig symbol the same way this 
patch does it for Broadcom-based SoCs?
--
Florian