linux-kernel - Re: [PATCH v2 4/8] RISC-V: Kconfig.socs: Add Renesas RZ/Five SoC kconfig option

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:   Fri, 19 Aug 2022 09:35:40 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Conor Dooley <Conor.Dooley@...rochip.com>
Cc:     Prabhakar Lad <prabhakar.csengg@...il.com>,
        "Lad, Prabhakar" <prabhakar.mahadev-lad.rj@...renesas.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Anup Patel <anup@...infault.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Biju Das <biju.das.jz@...renesas.com>,
        Samuel Holland <samuel@...lland.org>
Subject: Re: [PATCH v2 4/8] RISC-V: Kconfig.socs: Add Renesas RZ/Five SoC
 kconfig option

Hi Conor,

On Thu, Aug 18, 2022 at 8:54 PM <Conor.Dooley@...rochip.com> wrote:
> On 18/08/2022 19:19, Lad, Prabhakar wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > On Thu, Aug 18, 2022 at 4:16 PM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> >> On Mon, Aug 15, 2022 at 5:16 PM Lad Prabhakar
> >> <prabhakar.mahadev-lad.rj@...renesas.com> wrote:
> >>> Introduce SOC_RENESAS_RZFIVE config option to enable Renesas RZ/Five
> >>> (R9A07G043) SoC, along side also add ARCH_RENESAS config option as most
> >>> of the Renesas drivers depend on this config option.
> >>>
> >>> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> >>
> >> Thanks for your patch!
> >>
> >> The technical part LGTM, so
> >> Reviewed-by: Geert Uytterhoeven <geert+renesas@...der.be>
> >>
> >>> --- a/arch/riscv/Kconfig.socs
> >>> +++ b/arch/riscv/Kconfig.socs
> >>> @@ -80,4 +80,18 @@ config SOC_CANAAN_K210_DTB_SOURCE
> >>>
> >>>  endif # SOC_CANAAN
> >>>
> >>> +config ARCH_RENESAS
> >>
> >> We definitely want ARCH_RENESAS, as it serves as a gatekeeper for
> >> Kconfig options for IP cores found on Renesas ARM and RISC-V SoCs.
> >>
> > Agreed, or else we will end up touching too many Kconfig files.
> >
> >>> +       bool
> >>> +       select GPIOLIB
> >>> +       select PINCTRL
> >>> +       select SOC_BUS
> >>> +
> >>> +config SOC_RENESAS_RZFIVE
> >>
> >> Do we need this symbol? You could as well make ARCH_RENESAS above
> >> visible, and defer the actual SoC selection to ARCH_R9A07G043 in
> >> drivers/soc/renesas/Kconfig[1].
> >>
> > I think we could drop it and just defer the actual SoC selection to
> > ARCH_R9A07G043 as you said.
> >
> >> I don't know what is the policy on RISC-V. ARM64 has a "single-symbol
> >> in arch/arm64/Kconfig.platforms"-policy, so we handle SoC selection
> >> in drivers/soc/renesas/Kconfig, and that is fine, as it avoids merge
> >> conflicts.
> >>
> > Agreed.
> >
> > @Conor - Does the above sound OK?
>
> It's not my decision to be honest - Palmer's the boss :)
>
> I would rather have a single symbol & a single approach so that we are
> all doing the same thing here. As of now, we have all basically done
> different things for each SOC that was added - there's SOC_SIFIVE &
> SOC_MICROCHIP_POLARFIRE which are obviously not doing the same thing
> for starters & then how the symbol is used: selects vs depends + default
> all varies between the symbols.
>
> I tried to make some changes to the PolarFire one a few months ago to
> add some peripherals but Palmer was not too keen on the changes. We had
> a conversation on IRC, the upshot of which was deciding to talk about it
> at Plumbers (which is in 3 weeks) as none of them follow his original
> intent:
> <quote>
> the original idea behind Kconfig.socs was to provide an easy place for
> users to say "I want all the support for SOC X", and then just have one
> Kconfig to turn that on
> <\quote>

For whatever definition of "all"? Does this include e.g. all
multi-media stuff?

For Renesas ARM SoCs, we make sure to select the critical core parts,
cfr. the selects above, and in drivers/soc/renesas/Kconfig.
These selects do not include optional drivers, including the serial
port (cfr. your confusion about adding CONFIG_SERIAL_SH_SCI=y
to the defconfig).
All the rest is handled by the defconfigs (shmobile_defconfig on
arm32, single defconfig on arm64, and out-of-tree renesas_defconfig
in my renesas-devel tree).

> In theory, that's lovely but not really maintainable & none of us were
> doing it anyway. Hopefully we can come up with a plan at Plumbers - so
> feel free to chime in (or maybe it gets sorted out here and I don't
> have to do any public speaking 😍).

Ah, there is my good reason for registering for LPC ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds