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

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

[Palmer Dabbelt]

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.

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

[Palmer Dabbelt]

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

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

[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.

Best regards,
Krzysztof

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

[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.

Best regards,
Krzysztof


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Conor Dooley]

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.

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

[Conor Dooley]

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

Re: 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@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

Re: 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@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

Re: 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@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.

Re: 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@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

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

[Arnd Bergmann]

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

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

[Conor Dooley]

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

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

[Arnd Bergmann]

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

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

[Icenowy Zheng]

在 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

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

[Icenowy Zheng]

在 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