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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 15 Aug 2022 10:15:22 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Florian Fainelli <f.fainelli@...il.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Arnd Bergmann <arnd@...db.de>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        SoC Team <soc@...nel.org>,
        bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>,
        william.zhang@...adcom.com, anand.gore@...adcom.com,
        Olof Johansson <olof@...om.net>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        open list <linux-kernel@...r.kernel.org>,
        Shawn Guo <shawnguo@...nel.org>, Li Yang <leoyang.li@....com>,
        Wei Xu <xuwei5@...ilicon.com>, Andrew Lunn <andrew@...n.ch>,
        Gregory Clement <gregory.clement@...tlin.com>,
        "moderated list:ARM/Mediatek SoC..." 
        <linux-mediatek@...ts.infradead.org>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
        Matthias Brugger <mbrugger@...e.com>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        "moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES" 
        <linux-samsung-soc@...r.kernel.org>,
        Dinh Nguyen <dinguyen@...nel.org>
Subject: Re: [PATCH] arm64: Kconfig.platforms: Re-organized Broadcom menu

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