Re: [PATCH 1/2] RISC-V: virt: riscvemu: use new-style DT overlay syntax

[Marco Felsch <m.felsch@pengutronix.de>]

On 23-02-20, Ahmad Fatoum wrote:
> On 20.02.23 09:37, Marco Felsch wrote:
> > Hi Ahmad,
> > 
> > On 23-02-17, Ahmad Fatoum wrote:
> >> DTC nowdays also supports a much less verbose syntax for DT overlays
> >> that is internally converted to the usual much more verbose fragment
> >> syntax. Switch to it.
> >>
> >> No functional change intended.
> >>
> >> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >> ---
> >>  .../riscv/boards/riscvemu/overlay-of-sram.dts | 197 ++++++++----------
> >>  1 file changed, 90 insertions(+), 107 deletions(-)
> >>
> >> diff --git a/arch/riscv/boards/riscvemu/overlay-of-sram.dts b/arch/riscv/boards/riscvemu/overlay-of-sram.dts
> >> index 092fb02518b9..395fde84c1a9 100644
> >> --- a/arch/riscv/boards/riscvemu/overlay-of-sram.dts
> >> +++ b/arch/riscv/boards/riscvemu/overlay-of-sram.dts
> >> @@ -3,127 +3,110 @@
> >>  /dts-v1/;
> >>  /plugin/;
> >>  
> >> -/ {
> >> -	fragment@0 {
> >> -		target-path = "/soc";
> >> -		__overlay__ {
> >> -			#address-cells = <2>;
> >> -			#size-cells = <2>;
> >> -			sram@1000 {
> >> -				compatible = "mtd-ram";
> >> -				reg = <0 0x1000 0 0x10000>;
> >> -				#address-cells = <1>;
> >> -				#size-cells = <1>;
> >> +&{/soc} {
> > 
> > We could also move everything under the root node right? So the
> > following is also possible:
> > 
> > &{/} {
> > 	chosen {
> > 		environment {
> > 		};
> > 	};
> > 	soc {
> > 	};
> > };
> > 
> > If that is the case I would change it to the above syntax instead of
> > having several ones. Apart from that the change looks good to me.
> 
> I'd rather be explicit. For example htif below is supposed to be under
> SoC IMO, yet riscvemu places it under /. Being explicit at least gives
> a warning at runtime. I could move some stuff under / { } and leave
> override others by symbol, but what does this improve?

I got your point, maybe it is worth adding it to the commit message. So
we can remember in a few year why we have chosen the explicit approach.

Regards,
  Marco