| Message ID | 20220815151451.23293-5-prabhakar.mahadev-lad.rj@bp.renesas.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Geert Uytterhoeven |
| Headers | show |
| Series | Add support for Renesas RZ/Five SoC | expand |
On 15/08/2022 16:14, Lad Prabhakar wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > 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. Hey Lad, I think I said something similar on v1, but I said it again to Samuel today so I may as well repost here too: "I think this and patch 12/12 with the defconfig changes should be deferred until post LPC (which still leaves plenty of time for making the 6.1 merge window). We already have like 4 different approaches between the existing SOC_FOO symbols & two more when D1 stuff and the Renesas stuff is considered. Plan is to decide at LPC on one approach for what to do with Kconfig.socs & to me it seems like a good idea to do what's being done here - it's likely that further arm vendors will move and keeping the common symbols makes a lot of sense to me..." Also, for the sake of my OCD could you pick either riscv or RISC-V and use it for the whole series? Pedantic I guess, but /shrug Thanks, Conor. > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > --- > v1->v2 > * No Change > --- > arch/riscv/Kconfig.socs | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs > index 69774bb362d6..91b7f38b77a8 100644 > --- 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 > + bool > + select GPIOLIB > + select PINCTRL > + select SOC_BUS > + > +config SOC_RENESAS_RZFIVE > + bool "Renesas RZ/Five SoC" > + select ARCH_R9A07G043 > + select ARCH_RENESAS > + select RESET_CONTROLLER > + help > + This enables support for Renesas RZ/Five SoC. > + > endmenu # "SoC selection" > -- > 2.25.1 >
Hi Conor, Thank you for the review. On Mon, Aug 15, 2022 at 8:10 PM <Conor.Dooley@microchip.com> wrote: > > On 15/08/2022 16:14, Lad Prabhakar wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > > > 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. > > Hey Lad, > > I think I said something similar on v1, but I said it again > to Samuel today so I may as well repost here too: > "I think this and patch 12/12 with the defconfig changes should be patch 8/8. > deferred until post LPC (which still leaves plenty of time for > making the 6.1 merge window). We already have like 4 different > approaches between the existing SOC_FOO symbols & two more when > D1 stuff and the Renesas stuff is considered. > > Plan is to decide at LPC on one approach for what to do with > Kconfig.socs & to me it seems like a good idea to do what's being > done here - it's likely that further arm vendors will move and > keeping the common symbols makes a lot of sense to me..." > Sure not a problem. But delaying patch 4 and 8 will make RZ/Five SoC not buildable. Is that OK? > Also, for the sake of my OCD could you pick either riscv or > RISC-V and use it for the whole series? Pedantic I guess, but > /shrug > Sorry did you mean I add riscv/RISC-V in the subject? Cheers, Prabhakar > Thanks, > Conor. > > > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > > --- > > v1->v2 > > * No Change > > --- > > arch/riscv/Kconfig.socs | 14 ++++++++++++++ > > 1 file changed, 14 insertions(+) > > > > diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs > > index 69774bb362d6..91b7f38b77a8 100644 > > --- 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 > > + bool > > + select GPIOLIB > > + select PINCTRL > > + select SOC_BUS > > + > > +config SOC_RENESAS_RZFIVE > > + bool "Renesas RZ/Five SoC" > > + select ARCH_R9A07G043 > > + select ARCH_RENESAS > > + select RESET_CONTROLLER > > + help > > + This enables support for Renesas RZ/Five SoC. > > + > > endmenu # "SoC selection" > > -- > > 2.25.1 > > >
On 15/08/2022 20:57, Lad, Prabhakar wrote: > Hi Conor, > > Thank you for the review. > > On Mon, Aug 15, 2022 at 8:10 PM <Conor.Dooley@microchip.com> wrote: >> >> On 15/08/2022 16:14, Lad Prabhakar wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>> >>> 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. >> >> Hey Lad, >> >> I think I said something similar on v1, but I said it again >> to Samuel today so I may as well repost here too: >> "I think this and patch 12/12 with the defconfig changes should be > patch 8/8. It was a direct copy paste, hence the quotes ;) Your patch 8/8 lines up with the current symbols while Samuel's doesn't. > > >> deferred until post LPC (which still leaves plenty of time for >> making the 6.1 merge window). We already have like 4 different >> approaches between the existing SOC_FOO symbols & two more when >> D1 stuff and the Renesas stuff is considered. >> >> Plan is to decide at LPC on one approach for what to do with >> Kconfig.socs & to me it seems like a good idea to do what's being >> done here - it's likely that further arm vendors will move and >> keeping the common symbols makes a lot of sense to me..." >> > Sure not a problem. But delaying patch 4 and 8 will make RZ/Five SoC > not buildable. Is that OK? No no, I prob just did a bad job of explaining. I meant more along the lines of "I don't think this is the right approach but I will defer reviewing until after LPC, when we have picked one approach to use for everyone". I'm sorry, poor choice of words maybe. I didn't mean drop these patches so that it does not build, keeping it buildable until then so that we can all test/review is the way to go. Not your fault we've done 4 different things so far! Hopefully that makes a bit more sense? > >> Also, for the sake of my OCD could you pick either riscv or >> RISC-V and use it for the whole series? Pedantic I guess, but >> /shrug >> > Sorry did you mean I add riscv/RISC-V in the subject? You have some patches with RISC-V and some with riscv. What I meant was use one of the two for the whole series. Thanks, Conor. > > Cheers, > Prabhakar > > >> Thanks, >> Conor. >> >>> >>> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> >>> --- >>> v1->v2 >>> * No Change >>> --- >>> arch/riscv/Kconfig.socs | 14 ++++++++++++++ >>> 1 file changed, 14 insertions(+) >>> >>> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs >>> index 69774bb362d6..91b7f38b77a8 100644 >>> --- 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 >>> + bool >>> + select GPIOLIB >>> + select PINCTRL >>> + select SOC_BUS >>> + >>> +config SOC_RENESAS_RZFIVE >>> + bool "Renesas RZ/Five SoC" >>> + select ARCH_R9A07G043 >>> + select ARCH_RENESAS >>> + select RESET_CONTROLLER >>> + help >>> + This enables support for Renesas RZ/Five SoC. >>> + >>> endmenu # "SoC selection" >>> -- >>> 2.25.1 >>> >> > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
Hi Conor, On Mon, Aug 15, 2022 at 9:05 PM <Conor.Dooley@microchip.com> wrote: > > On 15/08/2022 20:57, Lad, Prabhakar wrote: > > Hi Conor, > > > > Thank you for the review. > > > > On Mon, Aug 15, 2022 at 8:10 PM <Conor.Dooley@microchip.com> wrote: > >> > >> On 15/08/2022 16:14, Lad Prabhakar wrote: > >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > >>> > >>> 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. > >> > >> Hey Lad, > >> > >> I think I said something similar on v1, but I said it again > >> to Samuel today so I may as well repost here too: > >> "I think this and patch 12/12 with the defconfig changes should be > > patch 8/8. > > It was a direct copy paste, hence the quotes ;) :) > Your patch 8/8 lines up with the current symbols while Samuel's > doesn't. > > > > > > >> deferred until post LPC (which still leaves plenty of time for > >> making the 6.1 merge window). We already have like 4 different > >> approaches between the existing SOC_FOO symbols & two more when > >> D1 stuff and the Renesas stuff is considered. > >> > >> Plan is to decide at LPC on one approach for what to do with > >> Kconfig.socs & to me it seems like a good idea to do what's being > >> done here - it's likely that further arm vendors will move and > >> keeping the common symbols makes a lot of sense to me..." > >> > > Sure not a problem. But delaying patch 4 and 8 will make RZ/Five SoC > > not buildable. Is that OK? > > No no, I prob just did a bad job of explaining. I meant more > along the lines of "I don't think this is the right approach > but I will defer reviewing until after LPC, when we have picked > one approach to use for everyone". I'm sorry, poor choice of > words maybe. I didn't mean drop these patches so that it does > not build, keeping it buildable until then so that we can all > test/review is the way to go. Not your fault we've done 4 different > things so far! > > Hopefully that makes a bit more sense? > Yep, that makes sense. > > > >> Also, for the sake of my OCD could you pick either riscv or > >> RISC-V and use it for the whole series? Pedantic I guess, but > >> /shrug > >> > > Sorry did you mean I add riscv/RISC-V in the subject? > > You have some patches with RISC-V and some with riscv. > What I meant was use one of the two for the whole series. I followed the previous subjects for that file which were previously accepted. But not a problem I'll change them to riscv instead. Cheers, Prabhakar
Hi Prabhakar, On Mon, Aug 15, 2022 at 5:16 PM Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.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@bp.renesas.com> Thanks for your patch! The technical part LGTM, so Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.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. > + 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 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. > + bool "Renesas RZ/Five SoC" > + select ARCH_R9A07G043 > + select ARCH_RENESAS > + select RESET_CONTROLLER > + help > + This enables support for Renesas RZ/Five SoC. > + > endmenu # "SoC selection" [1] https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git/commit/?h=renesas-drivers-for-v6.1&id=ebd0e06f3063cc2e3a689112904b29720579c6d2 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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
Hi Geert, Thank you for the review. On Thu, Aug 18, 2022 at 4:16 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Prabhakar, > > On Mon, Aug 15, 2022 at 5:16 PM Lad Prabhakar > <prabhakar.mahadev-lad.rj@bp.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@bp.renesas.com> > > Thanks for your patch! > > The technical part LGTM, so > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.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? Cheers, Prabhakar
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 > > Hi Geert, > > Thank you for the review. > > On Thu, Aug 18, 2022 at 4:16 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: >> >> Hi Prabhakar, >> >> On Mon, Aug 15, 2022 at 5:16 PM Lad Prabhakar >> <prabhakar.mahadev-lad.rj@bp.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@bp.renesas.com> >> >> Thanks for your patch! >> >> The technical part LGTM, so >> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.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> 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
Hi Conor, On Thu, Aug 18, 2022 at 8:54 PM <Conor.Dooley@microchip.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@linux-m68k.org> wrote: > >> On Mon, Aug 15, 2022 at 5:16 PM Lad Prabhakar > >> <prabhakar.mahadev-lad.rj@bp.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@bp.renesas.com> > >> > >> Thanks for your patch! > >> > >> The technical part LGTM, so > >> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.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
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@microchip.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@linux-m68k.org> wrote: >>>> On Mon, Aug 15, 2022 at 5:16 PM Lad Prabhakar >>>> <prabhakar.mahadev-lad.rj@bp.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@bp.renesas.com> >>>> >>>> Thanks for your patch! >>>> >>>> The technical part LGTM, so >>>> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.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? 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
diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs index 69774bb362d6..91b7f38b77a8 100644 --- 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 + bool + select GPIOLIB + select PINCTRL + select SOC_BUS + +config SOC_RENESAS_RZFIVE + bool "Renesas RZ/Five SoC" + select ARCH_R9A07G043 + select ARCH_RENESAS + select RESET_CONTROLLER + help + This enables support for Renesas RZ/Five SoC. + endmenu # "SoC selection"
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@bp.renesas.com> --- v1->v2 * No Change --- arch/riscv/Kconfig.socs | 14 ++++++++++++++ 1 file changed, 14 insertions(+)