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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux SoC Development]     [Linux Rockchip Development]     [Linux for Synopsys ARC Processors]    
  • [Linux on Unisoc (RDA Micro) SoCs]     [Linux Actions SoC]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Linux SCSI]     [Yosemite News]

  •   Powered by Linux