Should we merge arch/riscv/boot/dts via the SOC tree?

[Arnd Bergmann]

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 at kernel.org>
> +L:	linux-riscv at 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