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: <f4adf05b-d3da-a692-3bd8-0b4d705e0dc2@gmail.com>
Date:   Mon, 15 Aug 2022 10:15:22 -0700
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:     Florian Fainelli <f.fainelli@gmail.com>,
        Geert Uytterhoeven <geert@linux-m68k.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc:     Arnd Bergmann <arnd@arndb.de>,
        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>
 <0131e1d6-09c0-31a4-5b9d-0e2fc49d61ac@linaro.org>
 <CAMuHMdWDDY_72y3WYt401hG122xg1s7_VRCG9Vyhhkzco-nBYw@mail.gmail.com>
 <fb4f4444-20c2-0e35-bb83-79a419ec87a7@gmail.com>
From:   Florian Fainelli <f.fainelli@gmail.com>
In-Reply-To: <fb4f4444-20c2-0e35-bb83-79a419ec87a7@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

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@linaro.org> wrote:
>>> 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.
>>
>> 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