On 19/08/2022 08:35, Geert Uytterhoeven wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> Hi Conor,
>
> On Thu, Aug 18, 2022 at 8:54 PM <Conor.Dooley@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> wrote:
>>>> On Mon, Aug 15, 2022 at 5:16 PM Lad Prabhakar
>>>> <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx>
>>>>
>>>> Thanks for your patch!
>>>>
>>>> The technical part LGTM, so
>>>> Reviewed-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
>>>>
>>>>> --- 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?
Yeah.. gets unmaintainable fast!
>
> 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).
tbf, the reason it was done was fairly obvious, but since it wasn't
mentioned just wanted to double check it wasn't an accident ;)
I like the approach you suggested approach a lot tbh, makes a lot
of sense & doesn't involve having to merge the symbol for a core
driver through arch/riscv if something changes.
> 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@xxxxxxxxxxxxxx
>
> 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
