Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <0131e1d6-09c0-31a4-5b9d-0e2fc49d61ac@linaro.org>
Date:   Wed, 13 Jul 2022 10:40:05 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH] arm64: Kconfig.platforms: Re-organized Broadcom menu
Content-Language: en-US
To:     Arnd Bergmann <arnd@arndb.de>,
        Florian Fainelli <f.fainelli@gmail.com>
Cc:     Linux ARM <linux-arm-kernel@lists.infradead.org>,
        SoC Team <soc@kernel.org>,
        bcm-kernel-feedback-list <bcm-kernel-feedback-list@broadcom.com>,
        william.zhang@broadcom.com, anand.gore@broadcom.com,
        Olof Johansson <olof@lixom.net>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will@kernel.org>,
        open list <linux-kernel@vger.kernel.org>,
        Shawn Guo <shawnguo@kernel.org>, Li Yang <leoyang.li@nxp.com>,
        Wei Xu <xuwei5@hisilicon.com>, Andrew Lunn <andrew@lunn.ch>,
        Gregory Clement <gregory.clement@bootlin.com>,
        "moderated list:ARM/Mediatek SoC..." 
        <linux-mediatek@lists.infradead.org>,
        Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>,
        Matthias Brugger <mbrugger@suse.com>,
        linux-arm-msm <linux-arm-msm@vger.kernel.org>,
        Geert Uytterhoeven <geert+renesas@glider.be>,
        "moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES" 
        <linux-samsung-soc@vger.kernel.org>,
        Dinh Nguyen <dinguyen@kernel.org>
References: <20220712164235.40293-1-f.fainelli@gmail.com>
 <CAK8P3a2QrYbWOqV+CG-W0ZkzW6ORgw8R6Dv-L3o2ZAtJs-B3Kw@mail.gmail.com>
From:   Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
In-Reply-To: <CAK8P3a2QrYbWOqV+CG-W0ZkzW6ORgw8R6Dv-L3o2ZAtJs-B3Kw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 13/07/2022 10:25, Arnd Bergmann wrote:
> On Tue, Jul 12, 2022 at 6:42 PM Florian Fainelli <f.fainelli@gmail.com> 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@gmail.com>
>> ---
>>
>> 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