* Should we merge arch/riscv/boot/dts via the SOC tree? @ 2022-11-07 16:46 ` Palmer Dabbelt 0 siblings, 0 replies; 15+ messages in thread From: Palmer Dabbelt @ 2022-11-07 16:46 UTC (permalink / raw) To: Arnd Bergmann, Conor Dooley, kernel Cc: krzk, masahiroy, mkl, davem, linux-riscv, soc This has come up a bunch of times, but I don't think we've ever really made a decision. Historically that's not been such a big deal because the RISC-V device trees were pretty inactive, but that's changed -- both because Conor has been cleaning everything up, and also because there's a bunch of SOCs showing up with RISC-V cores in them. We talked about this again at plumbers a few times, but Arnd wasn't around it person so I figured it's best to just start an email thread and see how people feel. A lot of these new SOCs are based on Arm designs and the device trees very much reflect that, so it makes sense to me to just keep the device tree merges via as similar a path as possible. IIUC that happens via the SOC tree these days, so it makes sense to me that we start handling the RISC-V device trees that way as well. That would make things easier for contributors, as they'll have one workflow for all their SOCs, but also easier for me as a lot of this SOC stuff touches bits I really don't understand and thus get kind of lost trying to review. Arnd: looks like you're handling most of the merges these days so this would be increasing your workload. I feel kind of bad just dumping a bunch of stuff on you, but I think at least now the RISC-V DTS are in reasonable shape so hopefully it's not that bad. It'd certainly help things on my end, and I'm happy to try and re-direct some of that saved time to helping out in SOC land but I'm not sure how well that'd work out in practice as I'm pretty buried. On a somewhat related note, Conor has offered to pick up the otherwise unmaintained RISC-V SOCs. That's sort of its own discussion, but if we change over to the SOC tree we might as well just do everything at the same time. Presumably we'd want to adjust the MAINTAINERS file in a handful of ways to make sure patches end up in the right place. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Should we merge arch/riscv/boot/dts via the SOC tree? @ 2022-11-07 16:46 ` Palmer Dabbelt 0 siblings, 0 replies; 15+ messages in thread From: Palmer Dabbelt @ 2022-11-07 16:46 UTC (permalink / raw) To: Arnd Bergmann, Conor Dooley, kernel Cc: krzk, masahiroy, mkl, davem, linux-riscv, soc This has come up a bunch of times, but I don't think we've ever really made a decision. Historically that's not been such a big deal because the RISC-V device trees were pretty inactive, but that's changed -- both because Conor has been cleaning everything up, and also because there's a bunch of SOCs showing up with RISC-V cores in them. We talked about this again at plumbers a few times, but Arnd wasn't around it person so I figured it's best to just start an email thread and see how people feel. A lot of these new SOCs are based on Arm designs and the device trees very much reflect that, so it makes sense to me to just keep the device tree merges via as similar a path as possible. IIUC that happens via the SOC tree these days, so it makes sense to me that we start handling the RISC-V device trees that way as well. That would make things easier for contributors, as they'll have one workflow for all their SOCs, but also easier for me as a lot of this SOC stuff touches bits I really don't understand and thus get kind of lost trying to review. Arnd: looks like you're handling most of the merges these days so this would be increasing your workload. I feel kind of bad just dumping a bunch of stuff on you, but I think at least now the RISC-V DTS are in reasonable shape so hopefully it's not that bad. It'd certainly help things on my end, and I'm happy to try and re-direct some of that saved time to helping out in SOC land but I'm not sure how well that'd work out in practice as I'm pretty buried. On a somewhat related note, Conor has offered to pick up the otherwise unmaintained RISC-V SOCs. That's sort of its own discussion, but if we change over to the SOC tree we might as well just do everything at the same time. Presumably we'd want to adjust the MAINTAINERS file in a handful of ways to make sure patches end up in the right place. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should we merge arch/riscv/boot/dts via the SOC tree? 2022-11-07 16:46 ` Palmer Dabbelt @ 2022-11-07 17:51 ` Krzysztof Kozlowski -1 siblings, 0 replies; 15+ messages in thread From: Krzysztof Kozlowski @ 2022-11-07 17:51 UTC (permalink / raw) To: Palmer Dabbelt, Arnd Bergmann, Conor Dooley, kernel Cc: masahiroy, mkl, davem, linux-riscv, soc On 07/11/2022 17:46, Palmer Dabbelt wrote: > This has come up a bunch of times, but I don't think we've ever really > made a decision. Historically that's not been such a big deal because > the RISC-V device trees were pretty inactive, but that's changed -- both > because Conor has been cleaning everything up, and also because there's > a bunch of SOCs showing up with RISC-V cores in them. We talked about > this again at plumbers a few times, but Arnd wasn't around it person so > I figured it's best to just start an email thread and see how people > feel. > > A lot of these new SOCs are based on Arm designs and the device trees > very much reflect that, so it makes sense to me to just keep the device > tree merges via as similar a path as possible. Recent Renesas r9a07g043 (sharing between arm64 and riscv) is example of that. If changes to them start coming via different trees, we might have a lot of conflicts. > IIUC that happens via > the SOC tree these days, so it makes sense to me that we start handling > the RISC-V device trees that way as well. That would make things easier > for contributors, as they'll have one workflow for all their SOCs, but > also easier for me as a lot of this SOC stuff touches bits I really > don't understand and thus get kind of lost trying to review. > > Arnd: looks like you're handling most of the merges these days so this > would be increasing your workload. I feel kind of bad just dumping a > bunch of stuff on you, but I think at least now the RISC-V DTS are in > reasonable shape so hopefully it's not that bad. It'd certainly help > things on my end, and I'm happy to try and re-direct some of that saved > time to helping out in SOC land but I'm not sure how well that'd work > out in practice as I'm pretty buried. > > On a somewhat related note, Conor has offered to pick up the otherwise > unmaintained RISC-V SOCs. That's sort of its own discussion, but if we > change over to the SOC tree we might as well just do everything at the > same time. > On the other hand MIPS DTS is not coming via SoC tree, so there is no yet such wide approach. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should we merge arch/riscv/boot/dts via the SOC tree? @ 2022-11-07 17:51 ` Krzysztof Kozlowski 0 siblings, 0 replies; 15+ messages in thread From: Krzysztof Kozlowski @ 2022-11-07 17:51 UTC (permalink / raw) To: Palmer Dabbelt, Arnd Bergmann, Conor Dooley, kernel Cc: masahiroy, mkl, davem, linux-riscv, soc On 07/11/2022 17:46, Palmer Dabbelt wrote: > This has come up a bunch of times, but I don't think we've ever really > made a decision. Historically that's not been such a big deal because > the RISC-V device trees were pretty inactive, but that's changed -- both > because Conor has been cleaning everything up, and also because there's > a bunch of SOCs showing up with RISC-V cores in them. We talked about > this again at plumbers a few times, but Arnd wasn't around it person so > I figured it's best to just start an email thread and see how people > feel. > > A lot of these new SOCs are based on Arm designs and the device trees > very much reflect that, so it makes sense to me to just keep the device > tree merges via as similar a path as possible. Recent Renesas r9a07g043 (sharing between arm64 and riscv) is example of that. If changes to them start coming via different trees, we might have a lot of conflicts. > IIUC that happens via > the SOC tree these days, so it makes sense to me that we start handling > the RISC-V device trees that way as well. That would make things easier > for contributors, as they'll have one workflow for all their SOCs, but > also easier for me as a lot of this SOC stuff touches bits I really > don't understand and thus get kind of lost trying to review. > > Arnd: looks like you're handling most of the merges these days so this > would be increasing your workload. I feel kind of bad just dumping a > bunch of stuff on you, but I think at least now the RISC-V DTS are in > reasonable shape so hopefully it's not that bad. It'd certainly help > things on my end, and I'm happy to try and re-direct some of that saved > time to helping out in SOC land but I'm not sure how well that'd work > out in practice as I'm pretty buried. > > On a somewhat related note, Conor has offered to pick up the otherwise > unmaintained RISC-V SOCs. That's sort of its own discussion, but if we > change over to the SOC tree we might as well just do everything at the > same time. > On the other hand MIPS DTS is not coming via SoC tree, so there is no yet such wide approach. Best regards, Krzysztof _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should we merge arch/riscv/boot/dts via the SOC tree? 2022-11-07 17:51 ` Krzysztof Kozlowski @ 2022-11-13 15:52 ` Icenowy Zheng -1 siblings, 0 replies; 15+ messages in thread From: Icenowy Zheng @ 2022-11-13 15:52 UTC (permalink / raw) To: Krzysztof Kozlowski, Palmer Dabbelt, Arnd Bergmann, Conor Dooley, kernel Cc: masahiroy, mkl, davem, linux-riscv, soc 在 2022-11-07星期一的 18:51 +0100，Krzysztof Kozlowski写道： > On 07/11/2022 17:46, Palmer Dabbelt wrote: > > This has come up a bunch of times, but I don't think we've ever > > really > > made a decision. Historically that's not been such a big deal > > because > > the RISC-V device trees were pretty inactive, but that's changed -- > > both > > because Conor has been cleaning everything up, and also because > > there's > > a bunch of SOCs showing up with RISC-V cores in them. We talked > > about > > this again at plumbers a few times, but Arnd wasn't around it > > person so > > I figured it's best to just start an email thread and see how > > people > > feel. > > > > A lot of these new SOCs are based on Arm designs and the device > > trees > > very much reflect that, so it makes sense to me to just keep the > > device > > tree merges via as similar a path as possible. > > Recent Renesas r9a07g043 (sharing between arm64 and riscv) is example > of > that. If changes to them start coming via different trees, we might > have > a lot of conflicts. > > > IIUC that happens via > > the SOC tree these days, so it makes sense to me that we start > > handling > > the RISC-V device trees that way as well. That would make things > > easier > > for contributors, as they'll have one workflow for all their SOCs, > > but > > also easier for me as a lot of this SOC stuff touches bits I really > > don't understand and thus get kind of lost trying to review. > > > > Arnd: looks like you're handling most of the merges these days so > > this > > would be increasing your workload. I feel kind of bad just dumping > > a > > bunch of stuff on you, but I think at least now the RISC-V DTS are > > in > > reasonable shape so hopefully it's not that bad. It'd certainly > > help > > things on my end, and I'm happy to try and re-direct some of that > > saved > > time to helping out in SOC land but I'm not sure how well that'd > > work > > out in practice as I'm pretty buried. > > > > On a somewhat related note, Conor has offered to pick up the > > otherwise > > unmaintained RISC-V SOCs. That's sort of its own discussion, but > > if we > > change over to the SOC tree we might as well just do everything at > > the > > same time. > > > > On the other hand MIPS DTS is not coming via SoC tree, so there is no > yet such wide approach. Fewer SoC vendors share the most of their SoC designs between ARM and RISC-V ones. > > Best regards, > Krzysztof > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should we merge arch/riscv/boot/dts via the SOC tree? @ 2022-11-13 15:52 ` Icenowy Zheng 0 siblings, 0 replies; 15+ messages in thread From: Icenowy Zheng @ 2022-11-13 15:52 UTC (permalink / raw) To: Krzysztof Kozlowski, Palmer Dabbelt, Arnd Bergmann, Conor Dooley, kernel Cc: masahiroy, mkl, davem, linux-riscv, soc 在 2022-11-07星期一的 18:51 +0100，Krzysztof Kozlowski写道： > On 07/11/2022 17:46, Palmer Dabbelt wrote: > > This has come up a bunch of times, but I don't think we've ever > > really > > made a decision. Historically that's not been such a big deal > > because > > the RISC-V device trees were pretty inactive, but that's changed -- > > both > > because Conor has been cleaning everything up, and also because > > there's > > a bunch of SOCs showing up with RISC-V cores in them. We talked > > about > > this again at plumbers a few times, but Arnd wasn't around it > > person so > > I figured it's best to just start an email thread and see how > > people > > feel. > > > > A lot of these new SOCs are based on Arm designs and the device > > trees > > very much reflect that, so it makes sense to me to just keep the > > device > > tree merges via as similar a path as possible. > > Recent Renesas r9a07g043 (sharing between arm64 and riscv) is example > of > that. If changes to them start coming via different trees, we might > have > a lot of conflicts. > > > IIUC that happens via > > the SOC tree these days, so it makes sense to me that we start > > handling > > the RISC-V device trees that way as well. That would make things > > easier > > for contributors, as they'll have one workflow for all their SOCs, > > but > > also easier for me as a lot of this SOC stuff touches bits I really > > don't understand and thus get kind of lost trying to review. > > > > Arnd: looks like you're handling most of the merges these days so > > this > > would be increasing your workload. I feel kind of bad just dumping > > a > > bunch of stuff on you, but I think at least now the RISC-V DTS are > > in > > reasonable shape so hopefully it's not that bad. It'd certainly > > help > > things on my end, and I'm happy to try and re-direct some of that > > saved > > time to helping out in SOC land but I'm not sure how well that'd > > work > > out in practice as I'm pretty buried. > > > > On a somewhat related note, Conor has offered to pick up the > > otherwise > > unmaintained RISC-V SOCs. That's sort of its own discussion, but > > if we > > change over to the SOC tree we might as well just do everything at > > the > > same time. > > > > On the other hand MIPS DTS is not coming via SoC tree, so there is no > yet such wide approach. Fewer SoC vendors share the most of their SoC designs between ARM and RISC-V ones. > > Best regards, > Krzysztof > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should we merge arch/riscv/boot/dts via the SOC tree? 2022-11-07 16:46 ` Palmer Dabbelt @ 2022-11-07 18:31 ` Conor Dooley -1 siblings, 0 replies; 15+ messages in thread From: Conor Dooley @ 2022-11-07 18:31 UTC (permalink / raw) To: Palmer Dabbelt Cc: Arnd Bergmann, kernel, krzk, masahiroy, mkl, davem, linux-riscv, soc On Mon, Nov 07, 2022 at 08:46:00AM -0800, Palmer Dabbelt wrote: > This has come up a bunch of times, but I don't think we've ever really > made a decision. Historically that's not been such a big deal because > the RISC-V device trees were pretty inactive, but that's changed -- both > because Conor has been cleaning everything up, and also because there's > a bunch of SOCs showing up with RISC-V cores in them. We talked about > this again at plumbers a few times, but Arnd wasn't around it person so > I figured it's best to just start an email thread and see how people > feel. > > A lot of these new SOCs are based on Arm designs and the device trees > very much reflect that, so it makes sense to me to just keep the device > tree merges via as similar a path as possible. IIUC that happens via > the SOC tree these days, so it makes sense to me that we start handling > the RISC-V device trees that way as well. That would make things easier > for contributors, as they'll have one workflow for all their SOCs, but > also easier for me as a lot of this SOC stuff touches bits I really > don't understand and thus get kind of lost trying to review. Reviewing the Renesas/Allwinner stuff, it's p apparent to me that they need to go via the same tree for RISC-V and ARM. > Arnd: looks like you're handling most of the merges these days so this > would be increasing your workload. I feel kind of bad just dumping a > bunch of stuff on you, but I think at least now the RISC-V DTS are in > reasonable shape so hopefully it's not that bad. Warning free at least... :) > It'd certainly help > things on my end, and I'm happy to try and re-direct some of that saved > time to helping out in SOC land but I'm not sure how well that'd work > out in practice as I'm pretty buried. As things stand, I'm the only one sending PRs from the RISC-V side for dt & I am down to send things whatever way. Since he expressed willingness off list, I'm happy to route things via the soc tree going forwards. > On a somewhat related note, Conor has offered to pick up the otherwise > unmaintained RISC-V SOCs. That's sort of its own discussion, but if we > change over to the SOC tree we might as well just do everything at the > same time. > > Presumably we'd want to adjust the MAINTAINERS file in a handful of ways > to make sure patches end up in the right place. Arnd mentioned that that should cover stuff in drivers/{soc,firmware} as well as the dt, so with the assumption that that MAINTAINERS entry looks something like: diff --git a/MAINTAINERS b/MAINTAINERS index cf0f18502372..03e78d2e5cc6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -17709,6 +17709,16 @@ F: arch/riscv/ N: riscv K: riscv +RISC-V/MISC SOC SUPPORT +M: Conor Dooley <conor@kernel.org> +L: linux-riscv@lists.infradead.org +S: Maintained +Q: https://patchwork.kernel.org/project/linux-riscv/list/ +T: git https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/ +F: arch/riscv/boot/dts/ +F: drivers/soc/microchip/ +F: drivers/soc/sifive/ + RISC-V/MICROCHIP POLARFIRE SOC SUPPORT M: Conor Dooley <conor.dooley@microchip.com> M: Daire McNamara <daire.mcnamara@microchip.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Thanks Palmer/Arnd, Conor. ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: Should we merge arch/riscv/boot/dts via the SOC tree? @ 2022-11-07 18:31 ` Conor Dooley 0 siblings, 0 replies; 15+ messages in thread From: Conor Dooley @ 2022-11-07 18:31 UTC (permalink / raw) To: Palmer Dabbelt Cc: Arnd Bergmann, kernel, krzk, masahiroy, mkl, davem, linux-riscv, soc On Mon, Nov 07, 2022 at 08:46:00AM -0800, Palmer Dabbelt wrote: > This has come up a bunch of times, but I don't think we've ever really > made a decision. Historically that's not been such a big deal because > the RISC-V device trees were pretty inactive, but that's changed -- both > because Conor has been cleaning everything up, and also because there's > a bunch of SOCs showing up with RISC-V cores in them. We talked about > this again at plumbers a few times, but Arnd wasn't around it person so > I figured it's best to just start an email thread and see how people > feel. > > A lot of these new SOCs are based on Arm designs and the device trees > very much reflect that, so it makes sense to me to just keep the device > tree merges via as similar a path as possible. IIUC that happens via > the SOC tree these days, so it makes sense to me that we start handling > the RISC-V device trees that way as well. That would make things easier > for contributors, as they'll have one workflow for all their SOCs, but > also easier for me as a lot of this SOC stuff touches bits I really > don't understand and thus get kind of lost trying to review. Reviewing the Renesas/Allwinner stuff, it's p apparent to me that they need to go via the same tree for RISC-V and ARM. > Arnd: looks like you're handling most of the merges these days so this > would be increasing your workload. I feel kind of bad just dumping a > bunch of stuff on you, but I think at least now the RISC-V DTS are in > reasonable shape so hopefully it's not that bad. Warning free at least... :) > It'd certainly help > things on my end, and I'm happy to try and re-direct some of that saved > time to helping out in SOC land but I'm not sure how well that'd work > out in practice as I'm pretty buried. As things stand, I'm the only one sending PRs from the RISC-V side for dt & I am down to send things whatever way. Since he expressed willingness off list, I'm happy to route things via the soc tree going forwards. > On a somewhat related note, Conor has offered to pick up the otherwise > unmaintained RISC-V SOCs. That's sort of its own discussion, but if we > change over to the SOC tree we might as well just do everything at the > same time. > > Presumably we'd want to adjust the MAINTAINERS file in a handful of ways > to make sure patches end up in the right place. Arnd mentioned that that should cover stuff in drivers/{soc,firmware} as well as the dt, so with the assumption that that MAINTAINERS entry looks something like: diff --git a/MAINTAINERS b/MAINTAINERS index cf0f18502372..03e78d2e5cc6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -17709,6 +17709,16 @@ F: arch/riscv/ N: riscv K: riscv +RISC-V/MISC SOC SUPPORT +M: Conor Dooley <conor@kernel.org> +L: linux-riscv@lists.infradead.org +S: Maintained +Q: https://patchwork.kernel.org/project/linux-riscv/list/ +T: git https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/ +F: arch/riscv/boot/dts/ +F: drivers/soc/microchip/ +F: drivers/soc/sifive/ + RISC-V/MICROCHIP POLARFIRE SOC SUPPORT M: Conor Dooley <conor.dooley@microchip.com> M: Daire McNamara <daire.mcnamara@microchip.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Thanks Palmer/Arnd, Conor. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: Should we merge arch/riscv/boot/dts via the SOC tree? 2022-11-07 18:31 ` Conor Dooley @ 2022-11-08 12:51 ` Arnd Bergmann -1 siblings, 0 replies; 15+ messages in thread From: Arnd Bergmann @ 2022-11-08 12:51 UTC (permalink / raw) To: Conor Dooley, Palmer Dabbelt Cc: kernel, Krzysztof Kozlowski, Masahiro Yamada, Marc Kleine-Budde, David S . Miller, linux-riscv, soc On Mon, Nov 7, 2022, at 19:31, Conor Dooley wrote: > On Mon, Nov 07, 2022 at 08:46:00AM -0800, Palmer Dabbelt wrote: >> This has come up a bunch of times, but I don't think we've ever really >> made a decision. Historically that's not been such a big deal because >> the RISC-V device trees were pretty inactive, but that's changed -- both >> because Conor has been cleaning everything up, and also because there's >> a bunch of SOCs showing up with RISC-V cores in them. We talked about >> this again at plumbers a few times, but Arnd wasn't around it person so >> I figured it's best to just start an email thread and see how people >> feel. >> >> A lot of these new SOCs are based on Arm designs and the device trees >> very much reflect that, so it makes sense to me to just keep the device >> tree merges via as similar a path as possible. IIUC that happens via >> the SOC tree these days, so it makes sense to me that we start handling >> the RISC-V device trees that way as well. That would make things easier >> for contributors, as they'll have one workflow for all their SOCs, but >> also easier for me as a lot of this SOC stuff touches bits I really >> don't understand and thus get kind of lost trying to review. > > Reviewing the Renesas/Allwinner stuff, it's p apparent to me that they > need to go via the same tree for RISC-V and ARM. > >> Arnd: looks like you're handling most of the merges these days so this >> would be increasing your workload. I feel kind of bad just dumping a >> bunch of stuff on you, but I think at least now the RISC-V DTS are in >> reasonable shape so hopefully it's not that bad. > > Warning free at least... :) I don't see a problem with merging this through the SoC tree, it was always the plan to pick up related changes across architectures where needed. The MIPS and PowerPC maintainers have so far preferred to handle the changes through their respective trees, everything else has been in the noise. Looking at the number of DT changesets since linux-5.0 per architecture, I see 7748 arch/arm64/boot/dts 6654 arch/arm/boot/dts 197 arch/mips/boot/dts 155 arch/riscv/boot/dts 67 arch/powerpc/boot/dts 35 arch/arc/boot/dts 6 arch/openrisc/boot/dts 5 arch/xtensa/boot/dts 5 arch/nios2/boot/dts 5 arch/microblaze/boot/dts 2 arch/csky/boot/dts 1 arch/loongarch/boot/dts >> On a somewhat related note, Conor has offered to pick up the otherwise >> unmaintained RISC-V SOCs. That's sort of its own discussion, but if we >> change over to the SOC tree we might as well just do everything at the >> same time. >> >> Presumably we'd want to adjust the MAINTAINERS file in a handful of ways >> to make sure patches end up in the right place. > > Arnd mentioned that that should cover stuff in drivers/{soc,firmware} as > well as the dt, so with the assumption that that MAINTAINERS entry looks > something like: > > diff --git a/MAINTAINERS b/MAINTAINERS > index cf0f18502372..03e78d2e5cc6 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -17709,6 +17709,16 @@ F: arch/riscv/ > N: riscv > K: riscv > > +RISC-V/MISC SOC SUPPORT > +M: Conor Dooley <conor@kernel.org> > +L: linux-riscv@lists.infradead.org > +S: Maintained > +Q: https://patchwork.kernel.org/project/linux-riscv/list/ > +T: git https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/ > +F: arch/riscv/boot/dts/ > +F: drivers/soc/microchip/ > +F: drivers/soc/sifive/ I'd probably make separate entries here, at least for the drivers/soc/microchip directory, I can see that being shared with architectures other than RISC-V in the future, and the sifive directory should probably have at least a reviewer from sifive.com even if you plan to route the patches my way for them. Ard ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should we merge arch/riscv/boot/dts via the SOC tree? @ 2022-11-08 12:51 ` Arnd Bergmann 0 siblings, 0 replies; 15+ messages in thread From: Arnd Bergmann @ 2022-11-08 12:51 UTC (permalink / raw) To: Conor Dooley, Palmer Dabbelt Cc: kernel, Krzysztof Kozlowski, Masahiro Yamada, Marc Kleine-Budde, David S . Miller, linux-riscv, soc On Mon, Nov 7, 2022, at 19:31, Conor Dooley wrote: > On Mon, Nov 07, 2022 at 08:46:00AM -0800, Palmer Dabbelt wrote: >> This has come up a bunch of times, but I don't think we've ever really >> made a decision. Historically that's not been such a big deal because >> the RISC-V device trees were pretty inactive, but that's changed -- both >> because Conor has been cleaning everything up, and also because there's >> a bunch of SOCs showing up with RISC-V cores in them. We talked about >> this again at plumbers a few times, but Arnd wasn't around it person so >> I figured it's best to just start an email thread and see how people >> feel. >> >> A lot of these new SOCs are based on Arm designs and the device trees >> very much reflect that, so it makes sense to me to just keep the device >> tree merges via as similar a path as possible. IIUC that happens via >> the SOC tree these days, so it makes sense to me that we start handling >> the RISC-V device trees that way as well. That would make things easier >> for contributors, as they'll have one workflow for all their SOCs, but >> also easier for me as a lot of this SOC stuff touches bits I really >> don't understand and thus get kind of lost trying to review. > > Reviewing the Renesas/Allwinner stuff, it's p apparent to me that they > need to go via the same tree for RISC-V and ARM. > >> Arnd: looks like you're handling most of the merges these days so this >> would be increasing your workload. I feel kind of bad just dumping a >> bunch of stuff on you, but I think at least now the RISC-V DTS are in >> reasonable shape so hopefully it's not that bad. > > Warning free at least... :) I don't see a problem with merging this through the SoC tree, it was always the plan to pick up related changes across architectures where needed. The MIPS and PowerPC maintainers have so far preferred to handle the changes through their respective trees, everything else has been in the noise. Looking at the number of DT changesets since linux-5.0 per architecture, I see 7748 arch/arm64/boot/dts 6654 arch/arm/boot/dts 197 arch/mips/boot/dts 155 arch/riscv/boot/dts 67 arch/powerpc/boot/dts 35 arch/arc/boot/dts 6 arch/openrisc/boot/dts 5 arch/xtensa/boot/dts 5 arch/nios2/boot/dts 5 arch/microblaze/boot/dts 2 arch/csky/boot/dts 1 arch/loongarch/boot/dts >> On a somewhat related note, Conor has offered to pick up the otherwise >> unmaintained RISC-V SOCs. That's sort of its own discussion, but if we >> change over to the SOC tree we might as well just do everything at the >> same time. >> >> Presumably we'd want to adjust the MAINTAINERS file in a handful of ways >> to make sure patches end up in the right place. > > Arnd mentioned that that should cover stuff in drivers/{soc,firmware} as > well as the dt, so with the assumption that that MAINTAINERS entry looks > something like: > > diff --git a/MAINTAINERS b/MAINTAINERS > index cf0f18502372..03e78d2e5cc6 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -17709,6 +17709,16 @@ F: arch/riscv/ > N: riscv > K: riscv > > +RISC-V/MISC SOC SUPPORT > +M: Conor Dooley <conor@kernel.org> > +L: linux-riscv@lists.infradead.org > +S: Maintained > +Q: https://patchwork.kernel.org/project/linux-riscv/list/ > +T: git https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/ > +F: arch/riscv/boot/dts/ > +F: drivers/soc/microchip/ > +F: drivers/soc/sifive/ I'd probably make separate entries here, at least for the drivers/soc/microchip directory, I can see that being shared with architectures other than RISC-V in the future, and the sifive directory should probably have at least a reviewer from sifive.com even if you plan to route the patches my way for them. Ard _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should we merge arch/riscv/boot/dts via the SOC tree? 2022-11-08 12:51 ` Arnd Bergmann @ 2022-11-08 13:32 ` Conor Dooley -1 siblings, 0 replies; 15+ messages in thread From: Conor Dooley @ 2022-11-08 13:32 UTC (permalink / raw) To: Arnd Bergmann, palmer, nicolas.ferre Cc: Conor Dooley, Palmer Dabbelt, kernel, Krzysztof Kozlowski, Masahiro Yamada, Marc Kleine-Budde, David S . Miller, linux-riscv, soc +CC Nicolas On Tue, Nov 08, 2022 at 01:51:37PM +0100, Arnd Bergmann wrote: > On Mon, Nov 7, 2022, at 19:31, Conor Dooley wrote: > > On Mon, Nov 07, 2022 at 08:46:00AM -0800, Palmer Dabbelt wrote: > >> This has come up a bunch of times, but I don't think we've ever really > >> made a decision. Historically that's not been such a big deal because > >> the RISC-V device trees were pretty inactive, but that's changed -- both > >> because Conor has been cleaning everything up, and also because there's > >> a bunch of SOCs showing up with RISC-V cores in them. We talked about > >> this again at plumbers a few times, but Arnd wasn't around it person so > >> I figured it's best to just start an email thread and see how people > >> feel. > >> > >> A lot of these new SOCs are based on Arm designs and the device trees > >> very much reflect that, so it makes sense to me to just keep the device > >> tree merges via as similar a path as possible. IIUC that happens via > >> the SOC tree these days, so it makes sense to me that we start handling > >> the RISC-V device trees that way as well. That would make things easier > >> for contributors, as they'll have one workflow for all their SOCs, but > >> also easier for me as a lot of this SOC stuff touches bits I really > >> don't understand and thus get kind of lost trying to review. > > > > Reviewing the Renesas/Allwinner stuff, it's p apparent to me that they > > need to go via the same tree for RISC-V and ARM. > > > >> Arnd: looks like you're handling most of the merges these days so this > >> would be increasing your workload. I feel kind of bad just dumping a > >> bunch of stuff on you, but I think at least now the RISC-V DTS are in > >> reasonable shape so hopefully it's not that bad. > > > > Warning free at least... :) > > I don't see a problem with merging this through the SoC tree, it > was always the plan to pick up related changes across architectures > where needed. > > The MIPS and PowerPC maintainers have so far preferred to handle > the changes through their respective trees, everything else > has been in the noise. Looking at the number of DT changesets since > linux-5.0 per architecture, I see > > 7748 arch/arm64/boot/dts > 6654 arch/arm/boot/dts > 197 arch/mips/boot/dts > 155 arch/riscv/boot/dts > 67 arch/powerpc/boot/dts > 35 arch/arc/boot/dts > 6 arch/openrisc/boot/dts > 5 arch/xtensa/boot/dts > 5 arch/nios2/boot/dts > 5 arch/microblaze/boot/dts > 2 arch/csky/boot/dts > 1 arch/loongarch/boot/dts > > >> On a somewhat related note, Conor has offered to pick up the otherwise > >> unmaintained RISC-V SOCs. That's sort of its own discussion, but if we > >> change over to the SOC tree we might as well just do everything at the > >> same time. > >> > >> Presumably we'd want to adjust the MAINTAINERS file in a handful of ways > >> to make sure patches end up in the right place. > > > > Arnd mentioned that that should cover stuff in drivers/{soc,firmware} as > > well as the dt, so with the assumption that that MAINTAINERS entry looks > > something like: > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index cf0f18502372..03e78d2e5cc6 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -17709,6 +17709,16 @@ F: arch/riscv/ > > N: riscv > > K: riscv > > > > +RISC-V/MISC SOC SUPPORT > > +M: Conor Dooley <conor@kernel.org> > > +L: linux-riscv@lists.infradead.org > > +S: Maintained > > +Q: https://patchwork.kernel.org/project/linux-riscv/list/ > > +T: git https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/ > > +F: arch/riscv/boot/dts/ > > +F: drivers/soc/microchip/ > > +F: drivers/soc/sifive/ > > I'd probably make separate entries here, at least for the > drivers/soc/microchip directory, I can see that being shared with > architectures other than RISC-V in the future (Added Nicolas to CC so that he's in the loop) Uh sure. It'd crossed my mind, but I filed it away in the "may happen some day" category. The arm stuff is going via the atmel directory at the moment so I was operating on the basis of "do it this way until something changes". Splitting is fine by me. As things stand, anything drivers/soc/microchip already CCs the linux-riscv list so maybe that can change alongside this. > and the sifive > directory should probably have at least a reviewer from > sifive.com even if you plan to route the patches my way for > them. Anything sifive should already be covered by: SIFIVE DRIVERS M: Palmer Dabbelt <palmer@dabbelt.com> M: Paul Walmsley <paul.walmsley@sifive.com> L: linux-riscv@lists.infradead.org S: Supported T: git https://github.com/sifive/riscv-linux.git N: sifive K: [^@]sifive The git tree there is dead, but it does give you your SiFive reviewer? That leaves us with three entries then? Grand with me, I don't care :) Created the above to double check the scope more than anything else. The one I was wondering about but forgot to mention was: Documentation/devicetree/bindings/riscv/ It's mostly definitions of cpu, soc and board compatibles, so I figure it could go with the dt stuff - and it's covered by the generic RISC-V entry for the changes that reflect extensions etc. Thanks, Conor. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should we merge arch/riscv/boot/dts via the SOC tree? @ 2022-11-08 13:32 ` Conor Dooley 0 siblings, 0 replies; 15+ messages in thread From: Conor Dooley @ 2022-11-08 13:32 UTC (permalink / raw) To: Arnd Bergmann, palmer, nicolas.ferre Cc: Conor Dooley, Palmer Dabbelt, kernel, Krzysztof Kozlowski, Masahiro Yamada, Marc Kleine-Budde, David S . Miller, linux-riscv, soc +CC Nicolas On Tue, Nov 08, 2022 at 01:51:37PM +0100, Arnd Bergmann wrote: > On Mon, Nov 7, 2022, at 19:31, Conor Dooley wrote: > > On Mon, Nov 07, 2022 at 08:46:00AM -0800, Palmer Dabbelt wrote: > >> This has come up a bunch of times, but I don't think we've ever really > >> made a decision. Historically that's not been such a big deal because > >> the RISC-V device trees were pretty inactive, but that's changed -- both > >> because Conor has been cleaning everything up, and also because there's > >> a bunch of SOCs showing up with RISC-V cores in them. We talked about > >> this again at plumbers a few times, but Arnd wasn't around it person so > >> I figured it's best to just start an email thread and see how people > >> feel. > >> > >> A lot of these new SOCs are based on Arm designs and the device trees > >> very much reflect that, so it makes sense to me to just keep the device > >> tree merges via as similar a path as possible. IIUC that happens via > >> the SOC tree these days, so it makes sense to me that we start handling > >> the RISC-V device trees that way as well. That would make things easier > >> for contributors, as they'll have one workflow for all their SOCs, but > >> also easier for me as a lot of this SOC stuff touches bits I really > >> don't understand and thus get kind of lost trying to review. > > > > Reviewing the Renesas/Allwinner stuff, it's p apparent to me that they > > need to go via the same tree for RISC-V and ARM. > > > >> Arnd: looks like you're handling most of the merges these days so this > >> would be increasing your workload. I feel kind of bad just dumping a > >> bunch of stuff on you, but I think at least now the RISC-V DTS are in > >> reasonable shape so hopefully it's not that bad. > > > > Warning free at least... :) > > I don't see a problem with merging this through the SoC tree, it > was always the plan to pick up related changes across architectures > where needed. > > The MIPS and PowerPC maintainers have so far preferred to handle > the changes through their respective trees, everything else > has been in the noise. Looking at the number of DT changesets since > linux-5.0 per architecture, I see > > 7748 arch/arm64/boot/dts > 6654 arch/arm/boot/dts > 197 arch/mips/boot/dts > 155 arch/riscv/boot/dts > 67 arch/powerpc/boot/dts > 35 arch/arc/boot/dts > 6 arch/openrisc/boot/dts > 5 arch/xtensa/boot/dts > 5 arch/nios2/boot/dts > 5 arch/microblaze/boot/dts > 2 arch/csky/boot/dts > 1 arch/loongarch/boot/dts > > >> On a somewhat related note, Conor has offered to pick up the otherwise > >> unmaintained RISC-V SOCs. That's sort of its own discussion, but if we > >> change over to the SOC tree we might as well just do everything at the > >> same time. > >> > >> Presumably we'd want to adjust the MAINTAINERS file in a handful of ways > >> to make sure patches end up in the right place. > > > > Arnd mentioned that that should cover stuff in drivers/{soc,firmware} as > > well as the dt, so with the assumption that that MAINTAINERS entry looks > > something like: > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index cf0f18502372..03e78d2e5cc6 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -17709,6 +17709,16 @@ F: arch/riscv/ > > N: riscv > > K: riscv > > > > +RISC-V/MISC SOC SUPPORT > > +M: Conor Dooley <conor@kernel.org> > > +L: linux-riscv@lists.infradead.org > > +S: Maintained > > +Q: https://patchwork.kernel.org/project/linux-riscv/list/ > > +T: git https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/ > > +F: arch/riscv/boot/dts/ > > +F: drivers/soc/microchip/ > > +F: drivers/soc/sifive/ > > I'd probably make separate entries here, at least for the > drivers/soc/microchip directory, I can see that being shared with > architectures other than RISC-V in the future (Added Nicolas to CC so that he's in the loop) Uh sure. It'd crossed my mind, but I filed it away in the "may happen some day" category. The arm stuff is going via the atmel directory at the moment so I was operating on the basis of "do it this way until something changes". Splitting is fine by me. As things stand, anything drivers/soc/microchip already CCs the linux-riscv list so maybe that can change alongside this. > and the sifive > directory should probably have at least a reviewer from > sifive.com even if you plan to route the patches my way for > them. Anything sifive should already be covered by: SIFIVE DRIVERS M: Palmer Dabbelt <palmer@dabbelt.com> M: Paul Walmsley <paul.walmsley@sifive.com> L: linux-riscv@lists.infradead.org S: Supported T: git https://github.com/sifive/riscv-linux.git N: sifive K: [^@]sifive The git tree there is dead, but it does give you your SiFive reviewer? That leaves us with three entries then? Grand with me, I don't care :) Created the above to double check the scope more than anything else. The one I was wondering about but forgot to mention was: Documentation/devicetree/bindings/riscv/ It's mostly definitions of cpu, soc and board compatibles, so I figure it could go with the dt stuff - and it's covered by the generic RISC-V entry for the changes that reflect extensions etc. Thanks, Conor. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should we merge arch/riscv/boot/dts via the SOC tree? 2022-11-08 13:32 ` Conor Dooley (?) @ 2022-11-08 13:42 ` Arnd Bergmann 2022-11-08 14:57 ` Conor Dooley -1 siblings, 1 reply; 15+ messages in thread From: Arnd Bergmann @ 2022-11-08 13:42 UTC (permalink / raw) To: linux-riscv On Tue, Nov 8, 2022, at 14:32, Conor Dooley wrote: > On Tue, Nov 08, 2022 at 01:51:37PM +0100, Arnd Bergmann wrote: >> On Mon, Nov 7, 2022, at 19:31, Conor Dooley wrote: >> >> I'd probably make separate entries here, at least for the >> drivers/soc/microchip directory, I can see that being shared with >> architectures other than RISC-V in the future > > (Added Nicolas to CC so that he's in the loop) > Uh sure. It'd crossed my mind, but I filed it away in the "may happen > some day" category. The arm stuff is going via the atmel directory at > the moment so I was operating on the basis of "do it this way until > something changes". > Splitting is fine by me. As things stand, anything drivers/soc/microchip > already CCs the linux-riscv list so maybe that can change alongside > this. Right, but I suppose there is a good chance of having more crossover between microchip riscv/arm/mips drivers in the future, and others like Renesas already have drivers/soc/ subdirectories that are shared. > > The one I was wondering about but forgot to mention was: > Documentation/devicetree/bindings/riscv/ > > It's mostly definitions of cpu, soc and board compatibles, so I figure > it could go with the dt stuff - and it's covered by the generic RISC-V > entry for the changes that reflect extensions etc. Right, that works. Arnd _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should we merge arch/riscv/boot/dts via the SOC tree? 2022-11-08 13:42 ` Arnd Bergmann @ 2022-11-08 14:57 ` Conor Dooley 2022-11-09 7:49 ` Arnd Bergmann 0 siblings, 1 reply; 15+ messages in thread From: Conor Dooley @ 2022-11-08 14:57 UTC (permalink / raw) To: Arnd Bergmann, nicolas.ferre; +Cc: linux-riscv On Tue, Nov 08, 2022 at 02:42:16PM +0100, Arnd Bergmann wrote: > On Tue, Nov 8, 2022, at 14:32, Conor Dooley wrote: > > On Tue, Nov 08, 2022 at 01:51:37PM +0100, Arnd Bergmann wrote: > >> On Mon, Nov 7, 2022, at 19:31, Conor Dooley wrote: > >> > >> I'd probably make separate entries here, at least for the > >> drivers/soc/microchip directory, I can see that being shared with > >> architectures other than RISC-V in the future > > > > (Added Nicolas to CC so that he's in the loop) > > Uh sure. It'd crossed my mind, but I filed it away in the "may happen > > some day" category. The arm stuff is going via the atmel directory at > > the moment so I was operating on the basis of "do it this way until > > something changes". > > Splitting is fine by me. As things stand, anything drivers/soc/microchip > > already CCs the linux-riscv list so maybe that can change alongside > > this. > > Right, but I suppose there is a good chance of having more > crossover between microchip riscv/arm/mips drivers in the > future, and others like Renesas already have drivers/soc/ > subdirectories that are shared. Aye, I'll make it separate. Will make the existing entry that references the directory more specific too (whitespace damaged): diff --git a/MAINTAINERS b/MAINTAINERS index 046ff06ff97f..5b48eea5e9bb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -17749,7 +17749,7 @@ F: drivers/mailbox/mailbox-mpfs.c F: drivers/pci/controller/pcie-microchip-host.c F: drivers/reset/reset-mpfs.c F: drivers/rtc/rtc-mpfs.c -F: drivers/soc/microchip/ +F: drivers/soc/microchip/mpfs-sys-controller.c F: drivers/spi/spi-microchip-core-qspi.c F: drivers/spi/spi-microchip-core.c F: drivers/usb/musb/mpfs.c > > The one I was wondering about but forgot to mention was: > > Documentation/devicetree/bindings/riscv/ > > > > It's mostly definitions of cpu, soc and board compatibles, so I figure > > it could go with the dt stuff - and it's covered by the generic RISC-V > > entry for the changes that reflect extensions etc. > > Right, that works. Cool. I assume your ommission of the SiFive bit from this mail means you're happy enough with it? Thanks, Conor. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: Should we merge arch/riscv/boot/dts via the SOC tree? 2022-11-08 14:57 ` Conor Dooley @ 2022-11-09 7:49 ` Arnd Bergmann 0 siblings, 0 replies; 15+ messages in thread From: Arnd Bergmann @ 2022-11-09 7:49 UTC (permalink / raw) To: Conor.Dooley, Nicolas Ferre; +Cc: linux-riscv On Tue, Nov 8, 2022, at 15:57, Conor Dooley wrote: > On Tue, Nov 08, 2022 at 02:42:16PM +0100, Arnd Bergmann wrote: > > I assume your ommission of the SiFive bit from this mail means you're > happy enough with it? Yes, that's fine. Arnd _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2022-11-13 15:53 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-11-07 16:46 Should we merge arch/riscv/boot/dts via the SOC tree? Palmer Dabbelt 2022-11-07 16:46 ` Palmer Dabbelt 2022-11-07 17:51 ` Krzysztof Kozlowski 2022-11-07 17:51 ` Krzysztof Kozlowski 2022-11-13 15:52 ` Icenowy Zheng 2022-11-13 15:52 ` Icenowy Zheng 2022-11-07 18:31 ` Conor Dooley 2022-11-07 18:31 ` Conor Dooley 2022-11-08 12:51 ` Arnd Bergmann 2022-11-08 12:51 ` Arnd Bergmann 2022-11-08 13:32 ` Conor Dooley 2022-11-08 13:32 ` Conor Dooley 2022-11-08 13:42 ` Arnd Bergmann 2022-11-08 14:57 ` Conor Dooley 2022-11-09 7:49 ` Arnd Bergmann
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.