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

[Conor Dooley]

+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 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

(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 at dabbelt.com>
M:	Paul Walmsley <paul.walmsley at sifive.com>
L:	linux-riscv at 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.