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

Palmer Dabbelt
2022-11-07T16:47:04Z

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.