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. Or we could choose d) d) keep arch/arm64 list of platforms as short as possible, but sub-archs can do whatever they like on drivers/soc. Personally, I find fine-grained SoC selection a bit ridiculous optimization, like compiling kernel, Glibc and userspace with -O3, -funroll-loops and many other flags. One gets smaller size but looses multi-platform and ability to test one kernel on different boards. Therefore I would vote for b) with disallowing drivers/soc defining more ARCH_ and more SOC_. Best regards, Krzysztof
