[PATCH 1/2] RISC-V: virt: riscvemu: use new-style DT overlay syntax
Marco Felsch
m.felsch at pengutronix.de
Mon Feb 20 01:16:54 PST 2023
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 at 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 at 0 {
> >> - target-path = "/soc";
> >> - __overlay__ {
> >> - #address-cells = <2>;
> >> - #size-cells = <2>;
> >> - sram at 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
More information about the barebox
mailing list