| Message ID | 1457352735-24453-1-git-send-email-sudeep.holla@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Mar 7, 2016 at 6:12 AM, Sudeep Holla <sudeep.holla@arm.com> wrote: > Commit fa38a82096a1 ("scripts/dtc: Update to upstream version > 53bf130b1cdd") added warnings on node name unit-address presence/absence > mismatch in device trees. > > This patch fixes those warning on all the juno/vexpress platforms where > unit-address is present in node name while the reg/ranges property is > not present. > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > --- > arch/arm64/boot/dts/arm/foundation-v8.dtsi | 2 +- > arch/arm64/boot/dts/arm/juno-base.dtsi | 14 +++++----- > arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 30 +++++++++++----------- > arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts | 2 +- > arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi | 14 +++++----- > .../boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts | 10 ++++---- > 6 files changed, 36 insertions(+), 36 deletions(-) > > Hi Rob, > > I am not sure if the intention of commit fa38a82096a1 is to fix even > existing warnings or not. I saw warning with today's -next branch. Yes. I'm dropping it for 4.6 though. > Let me know. > > Regards, > Sudeep > > diff --git a/arch/arm64/boot/dts/arm/foundation-v8.dtsi b/arch/arm64/boot/dts/arm/foundation-v8.dtsi > index 9314f3943269..ba03c934a861 100644 > --- a/arch/arm64/boot/dts/arm/foundation-v8.dtsi > +++ b/arch/arm64/boot/dts/arm/foundation-v8.dtsi > @@ -89,7 +89,7 @@ > <0 63 4>; > }; > > - smb { > + smb@0,08000000 { Drop the comma and leading zeros. Comma is for distinct fields like bus,dev,func on PCI. This is the next warning I'm working on... > compatible = "arm,vexpress,v2m-p1", "simple-bus"; > arm,v2m-memory-map = "rs1"; > #address-cells = <2>; /* SMB chipselect number and offset */ > diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi > index 4b6172b0f2cb..3841e82fa6f8 100644 > --- a/arch/arm64/boot/dts/arm/juno-base.dtsi > +++ b/arch/arm64/boot/dts/arm/juno-base.dtsi > @@ -105,13 +105,13 @@ > clocks { > compatible = "arm,scpi-clocks"; > > - scpi_dvfs: scpi_clocks@0 { > + scpi_dvfs: scpi-clocks-0 { > compatible = "arm,scpi-dvfs-clocks"; > #clock-cells = <1>; > clock-indices = <0>, <1>, <2>; > clock-output-names = "atlclk", "aplclk","gpuclk"; > }; > - scpi_clk: scpi_clocks@3 { > + scpi_clk: scpi-clocks-1 { > compatible = "arm,scpi-variable-clocks"; > #clock-cells = <1>; > clock-indices = <3>; > @@ -154,7 +154,7 @@ > clock-names = "pxlclk"; > > port { > - hdlcd1_output: endpoint@0 { > + hdlcd1_output: endpoint0 { Just "endpoint" or add the reg property if there is another endpoint. > remote-endpoint = <&tda998x_1_input>; > }; > }; > @@ -168,7 +168,7 @@ > clock-names = "pxlclk"; > > port { > - hdlcd0_output: endpoint@0 { > + hdlcd0_output: endpoint0 { > remote-endpoint = <&tda998x_0_input>; > }; > }; > @@ -196,7 +196,7 @@ > compatible = "nxp,tda998x"; > reg = <0x70>; > port { > - tda998x_0_input: endpoint@0 { > + tda998x_0_input: endpoint0 { > remote-endpoint = <&hdlcd0_output>; > }; > }; > @@ -206,7 +206,7 @@ > compatible = "nxp,tda998x"; > reg = <0x71>; > port { > - tda998x_1_input: endpoint@0 { > + tda998x_1_input: endpoint0 { > remote-endpoint = <&hdlcd1_output>; > }; > }; > @@ -243,7 +243,7 @@ > <0x00000008 0x80000000 0x1 0x80000000>; > }; > > - smb { > + smb@0,08000000 { > compatible = "simple-bus"; > #address-cells = <2>; > #size-cells = <1>; > diff --git a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi > index 413f1b9ebcd4..3d4af126df6e 100644 > --- a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi > +++ b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi > @@ -46,7 +46,7 @@ > arm,vexpress,site = <0>; > arm,v2m-memory-map = "rs1"; > > - mb_fixed_3v3: fixedregulator@0 { > + mb_fixed_3v3: fixedregulator0 { fixed-regulator-0 perhaps. > compatible = "regulator-fixed"; > regulator-name = "MCC_SB_3V3"; > regulator-min-microvolt = <3300000>; > @@ -59,42 +59,42 @@ > #address-cells = <1>; > #size-cells = <0>; > > - button@1 { > + button1 { > debounce_interval = <50>; > wakeup-source; > linux,code = <116>; > label = "POWER"; > gpios = <&iofpga_gpio0 0 0x4>; > }; > - button@2 { > + button2 { > debounce_interval = <50>; > wakeup-source; > linux,code = <102>; > label = "HOME"; > gpios = <&iofpga_gpio0 1 0x4>; > }; > - button@3 { > + button3 { > debounce_interval = <50>; > wakeup-source; > linux,code = <152>; > label = "RLOCK"; > gpios = <&iofpga_gpio0 2 0x4>; > }; > - button@4 { > + button4 { > debounce_interval = <50>; > wakeup-source; > linux,code = <115>; > label = "VOL+"; > gpios = <&iofpga_gpio0 3 0x4>; > }; > - button@5 { > + button5 { > debounce_interval = <50>; > wakeup-source; > linux,code = <114>; > label = "VOL-"; > gpios = <&iofpga_gpio0 4 0x4>; > }; > - button@6 { > + button6 { > debounce_interval = <50>; > wakeup-source; > linux,code = <99>; > @@ -159,7 +159,7 @@ > compatible = "syscon", "simple-mfd"; > reg = <0x010000 0x1000>; > > - led@08.0 { > + led0 { In hindsight, we probably should have done "reg = <0x8 0>" for register and bit offsets. Is "0" the best description of this led (i.e. is there some h/w defined name)? > compatible = "register-bit-led"; > offset = <0x08>; > mask = <0x01>;
On Thu, 2016-03-17 at 16:44 -0500, Rob Herring wrote: > On Mon, Mar 7, 2016 at 6:12 AM, Sudeep Holla <sudeep.holla@arm.com> wrote: > > Commit fa38a82096a1 ("scripts/dtc: Update to upstream version > > 53bf130b1cdd") added warnings on node name unit-address presence/absence > > mismatch in device trees. > > > > This patch fixes those warning on all the juno/vexpress platforms where > > unit-address is present in node name while the reg/ranges property is > > not present. > > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > --- > > arch/arm64/boot/dts/arm/foundation-v8.dtsi | 2 +- > > arch/arm64/boot/dts/arm/juno-base.dtsi | 14 +++++----- > > arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 30 +++++++++++----------- > > arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts | 2 +- > > arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi | 14 +++++----- > > .../boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts | 10 ++++---- > > 6 files changed, 36 insertions(+), 36 deletions(-) > > > > Hi Rob, > > > > I am not sure if the intention of commit fa38a82096a1 is to fix even > > existing warnings or not. I saw warning with today's -next branch. > > Yes. I'm dropping it for 4.6 though. > > > Let me know. > > > > Regards, > > Sudeep > > > > diff --git a/arch/arm64/boot/dts/arm/foundation-v8.dtsi b/arch/arm64/boot/dts/arm/foundation-v8.dtsi > > index 9314f3943269..ba03c934a861 100644 > > --- a/arch/arm64/boot/dts/arm/foundation-v8.dtsi > > +++ b/arch/arm64/boot/dts/arm/foundation-v8.dtsi > > @@ -89,7 +89,7 @@ > > <0 63 4>; > > }; > > > > - smb { > > + smb@0,08000000 { > > Drop the comma and leading zeros. Comma is for distinct fields like > bus,dev,func on PCI. So what is the correct way of representing 2 cell addresses? Not just those that are logically 64-bit addresses, (which I guess could be just a single number), but things like vexpress motherboard where we have Chip-select and Offset values? I looked at ePAPR but it just says 'The unit-address must match the first address specified in the reg property of the node.' and lists valid characters for unit address, which includes ,._+-
On Fri, Mar 18, 2016 at 5:32 AM, Jon Medhurst (Tixy) <tixy@linaro.org> wrote: > On Thu, 2016-03-17 at 16:44 -0500, Rob Herring wrote: >> On Mon, Mar 7, 2016 at 6:12 AM, Sudeep Holla <sudeep.holla@arm.com> wrote: >> > Commit fa38a82096a1 ("scripts/dtc: Update to upstream version >> > 53bf130b1cdd") added warnings on node name unit-address presence/absence >> > mismatch in device trees. >> > >> > This patch fixes those warning on all the juno/vexpress platforms where >> > unit-address is present in node name while the reg/ranges property is >> > not present. >> > >> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> >> > --- >> > arch/arm64/boot/dts/arm/foundation-v8.dtsi | 2 +- >> > arch/arm64/boot/dts/arm/juno-base.dtsi | 14 +++++----- >> > arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 30 +++++++++++----------- >> > arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts | 2 +- >> > arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi | 14 +++++----- >> > .../boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts | 10 ++++---- >> > 6 files changed, 36 insertions(+), 36 deletions(-) >> > >> > Hi Rob, >> > >> > I am not sure if the intention of commit fa38a82096a1 is to fix even >> > existing warnings or not. I saw warning with today's -next branch. >> >> Yes. I'm dropping it for 4.6 though. >> >> > Let me know. >> > >> > Regards, >> > Sudeep >> > >> > diff --git a/arch/arm64/boot/dts/arm/foundation-v8.dtsi b/arch/arm64/boot/dts/arm/foundation-v8.dtsi >> > index 9314f3943269..ba03c934a861 100644 >> > --- a/arch/arm64/boot/dts/arm/foundation-v8.dtsi >> > +++ b/arch/arm64/boot/dts/arm/foundation-v8.dtsi >> > @@ -89,7 +89,7 @@ >> > <0 63 4>; >> > }; >> > >> > - smb { >> > + smb@0,08000000 { >> >> Drop the comma and leading zeros. Comma is for distinct fields like >> bus,dev,func on PCI. > > So what is the correct way of representing 2 cell addresses? Not just > those that are logically 64-bit addresses, (which I guess could be just > a single number), but things like vexpress motherboard where we have > Chip-select and Offset values? 64-bit address is just a single number. 2 cells with distinct fields should generally be ...@<cell1>,<cell2> If you have your own bus type, you can devise whatever you like as long as it is reviewed. > I looked at ePAPR but it just says 'The unit-address must > match the first address specified in the reg property of the node.' and > lists valid characters for unit address, which includes ,._+- Yes, we need to clarify this some. Rob
On Fri, 2016-03-18 at 08:09 -0500, Rob Herring wrote: > On Fri, Mar 18, 2016 at 5:32 AM, Jon Medhurst (Tixy) <tixy@linaro.org> wrote: > > On Thu, 2016-03-17 at 16:44 -0500, Rob Herring wrote: > >> On Mon, Mar 7, 2016 at 6:12 AM, Sudeep Holla <sudeep.holla@arm.com> wrote: [...] > >> > Let me know. > >> > > >> > Regards, > >> > Sudeep > >> > > >> > diff --git a/arch/arm64/boot/dts/arm/foundation-v8.dtsi b/arch/arm64/boot/dts/arm/foundation-v8.dtsi > >> > index 9314f3943269..ba03c934a861 100644 > >> > --- a/arch/arm64/boot/dts/arm/foundation-v8.dtsi > >> > +++ b/arch/arm64/boot/dts/arm/foundation-v8.dtsi > >> > @@ -89,7 +89,7 @@ > >> > <0 63 4>; > >> > }; > >> > > >> > - smb { > >> > + smb@0,08000000 { > >> > >> Drop the comma and leading zeros. Comma is for distinct fields like > >> bus,dev,func on PCI. > > > > So what is the correct way of representing 2 cell addresses? Not just > > those that are logically 64-bit addresses, (which I guess could be just > > a single number), but things like vexpress motherboard where we have > > Chip-select and Offset values? > > 64-bit address is just a single number. > 2 cells with distinct fields should generally be ...@<cell1>,<cell2> > > If you have your own bus type, you can devise whatever you like as > long as it is reviewed. > > > I looked at ePAPR but it just says 'The unit-address must > > match the first address specified in the reg property of the node.' and > > lists valid characters for unit address, which includes ,._+- > > Yes, we need to clarify this some. Yes, because there is already quite a bit of use of @X,Y for two cell 64-bit addresses (Tegra mostly, I assume they're 64-bit addresses). And for 32-bit addresses lots of use of leading zeros to pad address to consistence number of digits, both in unit names and in reg properties. $ grep '@0[^ ^,]' -R arch/arm/boot/dts | wc -l 1300
On Fri, Mar 18, 2016 at 9:15 AM, Jon Medhurst (Tixy) <tixy@linaro.org> wrote: > On Fri, 2016-03-18 at 08:09 -0500, Rob Herring wrote: >> On Fri, Mar 18, 2016 at 5:32 AM, Jon Medhurst (Tixy) <tixy@linaro.org> wrote: >> > On Thu, 2016-03-17 at 16:44 -0500, Rob Herring wrote: >> >> On Mon, Mar 7, 2016 at 6:12 AM, Sudeep Holla <sudeep.holla@arm.com> wrote: > [...] >> >> > Let me know. >> >> > >> >> > Regards, >> >> > Sudeep >> >> > >> >> > diff --git a/arch/arm64/boot/dts/arm/foundation-v8.dtsi b/arch/arm64/boot/dts/arm/foundation-v8.dtsi >> >> > index 9314f3943269..ba03c934a861 100644 >> >> > --- a/arch/arm64/boot/dts/arm/foundation-v8.dtsi >> >> > +++ b/arch/arm64/boot/dts/arm/foundation-v8.dtsi >> >> > @@ -89,7 +89,7 @@ >> >> > <0 63 4>; >> >> > }; >> >> > >> >> > - smb { >> >> > + smb@0,08000000 { >> >> >> >> Drop the comma and leading zeros. Comma is for distinct fields like >> >> bus,dev,func on PCI. >> > >> > So what is the correct way of representing 2 cell addresses? Not just >> > those that are logically 64-bit addresses, (which I guess could be just >> > a single number), but things like vexpress motherboard where we have >> > Chip-select and Offset values? >> >> 64-bit address is just a single number. >> 2 cells with distinct fields should generally be ...@<cell1>,<cell2> >> >> If you have your own bus type, you can devise whatever you like as >> long as it is reviewed. >> >> > I looked at ePAPR but it just says 'The unit-address must >> > match the first address specified in the reg property of the node.' and >> > lists valid characters for unit address, which includes ,._+- >> >> Yes, we need to clarify this some. > > Yes, because there is already quite a bit of use of @X,Y for two cell > 64-bit addresses (Tegra mostly, I assume they're 64-bit addresses). That is because briefly we were telling folks to do that until Ben H clarified when commas are appropriate. > And for 32-bit addresses lots of use of leading zeros to pad address to > consistence number of digits, both in unit names and in reg properties. > > $ grep '@0[^ ^,]' -R arch/arm/boot/dts | wc -l > 1300 I'm working on dtc checks for both. I also learned yesterday some TI DTs use the full address rather than the local untranslated address. Rob
diff --git a/arch/arm64/boot/dts/arm/foundation-v8.dtsi b/arch/arm64/boot/dts/arm/foundation-v8.dtsi index 9314f3943269..ba03c934a861 100644 --- a/arch/arm64/boot/dts/arm/foundation-v8.dtsi +++ b/arch/arm64/boot/dts/arm/foundation-v8.dtsi @@ -89,7 +89,7 @@ <0 63 4>; }; - smb { + smb@0,08000000 { compatible = "arm,vexpress,v2m-p1", "simple-bus"; arm,v2m-memory-map = "rs1"; #address-cells = <2>; /* SMB chipselect number and offset */ diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi index 4b6172b0f2cb..3841e82fa6f8 100644 --- a/arch/arm64/boot/dts/arm/juno-base.dtsi +++ b/arch/arm64/boot/dts/arm/juno-base.dtsi @@ -105,13 +105,13 @@ clocks { compatible = "arm,scpi-clocks"; - scpi_dvfs: scpi_clocks@0 { + scpi_dvfs: scpi-clocks-0 { compatible = "arm,scpi-dvfs-clocks"; #clock-cells = <1>; clock-indices = <0>, <1>, <2>; clock-output-names = "atlclk", "aplclk","gpuclk"; }; - scpi_clk: scpi_clocks@3 { + scpi_clk: scpi-clocks-1 { compatible = "arm,scpi-variable-clocks"; #clock-cells = <1>; clock-indices = <3>; @@ -154,7 +154,7 @@ clock-names = "pxlclk"; port { - hdlcd1_output: endpoint@0 { + hdlcd1_output: endpoint0 { remote-endpoint = <&tda998x_1_input>; }; }; @@ -168,7 +168,7 @@ clock-names = "pxlclk"; port { - hdlcd0_output: endpoint@0 { + hdlcd0_output: endpoint0 { remote-endpoint = <&tda998x_0_input>; }; }; @@ -196,7 +196,7 @@ compatible = "nxp,tda998x"; reg = <0x70>; port { - tda998x_0_input: endpoint@0 { + tda998x_0_input: endpoint0 { remote-endpoint = <&hdlcd0_output>; }; }; @@ -206,7 +206,7 @@ compatible = "nxp,tda998x"; reg = <0x71>; port { - tda998x_1_input: endpoint@0 { + tda998x_1_input: endpoint0 { remote-endpoint = <&hdlcd1_output>; }; }; @@ -243,7 +243,7 @@ <0x00000008 0x80000000 0x1 0x80000000>; }; - smb { + smb@0,08000000 { compatible = "simple-bus"; #address-cells = <2>; #size-cells = <1>; diff --git a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi index 413f1b9ebcd4..3d4af126df6e 100644 --- a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi +++ b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi @@ -46,7 +46,7 @@ arm,vexpress,site = <0>; arm,v2m-memory-map = "rs1"; - mb_fixed_3v3: fixedregulator@0 { + mb_fixed_3v3: fixedregulator0 { compatible = "regulator-fixed"; regulator-name = "MCC_SB_3V3"; regulator-min-microvolt = <3300000>; @@ -59,42 +59,42 @@ #address-cells = <1>; #size-cells = <0>; - button@1 { + button1 { debounce_interval = <50>; wakeup-source; linux,code = <116>; label = "POWER"; gpios = <&iofpga_gpio0 0 0x4>; }; - button@2 { + button2 { debounce_interval = <50>; wakeup-source; linux,code = <102>; label = "HOME"; gpios = <&iofpga_gpio0 1 0x4>; }; - button@3 { + button3 { debounce_interval = <50>; wakeup-source; linux,code = <152>; label = "RLOCK"; gpios = <&iofpga_gpio0 2 0x4>; }; - button@4 { + button4 { debounce_interval = <50>; wakeup-source; linux,code = <115>; label = "VOL+"; gpios = <&iofpga_gpio0 3 0x4>; }; - button@5 { + button5 { debounce_interval = <50>; wakeup-source; linux,code = <114>; label = "VOL-"; gpios = <&iofpga_gpio0 4 0x4>; }; - button@6 { + button6 { debounce_interval = <50>; wakeup-source; linux,code = <99>; @@ -159,7 +159,7 @@ compatible = "syscon", "simple-mfd"; reg = <0x010000 0x1000>; - led@08.0 { + led0 { compatible = "register-bit-led"; offset = <0x08>; mask = <0x01>; @@ -167,7 +167,7 @@ linux,default-trigger = "heartbeat"; default-state = "on"; }; - led@08.1 { + led1 { compatible = "register-bit-led"; offset = <0x08>; mask = <0x02>; @@ -175,7 +175,7 @@ linux,default-trigger = "mmc0"; default-state = "off"; }; - led@08.2 { + led2 { compatible = "register-bit-led"; offset = <0x08>; mask = <0x04>; @@ -183,7 +183,7 @@ linux,default-trigger = "cpu0"; default-state = "off"; }; - led@08.3 { + led3 { compatible = "register-bit-led"; offset = <0x08>; mask = <0x08>; @@ -191,7 +191,7 @@ linux,default-trigger = "cpu1"; default-state = "off"; }; - led@08.4 { + led4 { compatible = "register-bit-led"; offset = <0x08>; mask = <0x10>; @@ -199,7 +199,7 @@ linux,default-trigger = "cpu2"; default-state = "off"; }; - led@08.5 { + led5 { compatible = "register-bit-led"; offset = <0x08>; mask = <0x20>; @@ -207,14 +207,14 @@ linux,default-trigger = "cpu3"; default-state = "off"; }; - led@08.6 { + led6 { compatible = "register-bit-led"; offset = <0x08>; mask = <0x40>; label = "vexpress:6"; default-state = "off"; }; - led@08.7 { + led7 { compatible = "register-bit-led"; offset = <0x08>; mask = <0x80>; diff --git a/arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts b/arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts index 20addabbd127..0d0df795809c 100644 --- a/arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts +++ b/arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts @@ -104,7 +104,7 @@ <0 63 4>; }; - smb { + smb@0,08000000 { compatible = "simple-bus"; #address-cells = <2>; diff --git a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi index 88a7583ed7a7..09d97e1a8948 100644 --- a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi +++ b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi @@ -226,7 +226,7 @@ }; }; - v2m_fixed_3v3: fixedregulator@0 { + v2m_fixed_3v3: fixedregulator { compatible = "regulator-fixed"; regulator-name = "3V3"; regulator-min-microvolt = <3300000>; @@ -238,7 +238,7 @@ compatible = "arm,vexpress,config-bus"; arm,vexpress,config-bridge = <&v2m_sysreg>; - v2m_oscclk1: osc@1 { + v2m_oscclk1: osc { /* CLCD clock */ compatible = "arm,vexpress-osc"; arm,vexpress-sysreg,func = <1 1>; @@ -247,27 +247,27 @@ clock-output-names = "v2m:oscclk1"; }; - reset@0 { + reset { compatible = "arm,vexpress-reset"; arm,vexpress-sysreg,func = <5 0>; }; - muxfpga@0 { + muxfpga { compatible = "arm,vexpress-muxfpga"; arm,vexpress-sysreg,func = <7 0>; }; - shutdown@0 { + shutdown { compatible = "arm,vexpress-shutdown"; arm,vexpress-sysreg,func = <8 0>; }; - reboot@0 { + reboot { compatible = "arm,vexpress-reboot"; arm,vexpress-sysreg,func = <9 0>; }; - dvimode@0 { + dvimode { compatible = "arm,vexpress-dvimode"; arm,vexpress-sysreg,func = <11 0>; }; diff --git a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts index bb3c26d1154d..00024be0c9b0 100644 --- a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts +++ b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts @@ -93,7 +93,7 @@ compatible = "arm,vexpress,config-bus"; arm,vexpress,config-bridge = <&v2m_sysreg>; - smbclk: osc@4 { + smbclk: osc4 { /* SMC clock */ compatible = "arm,vexpress-osc"; arm,vexpress-sysreg,func = <1 4>; @@ -102,7 +102,7 @@ clock-output-names = "smclk"; }; - volt@0 { + volt0 { /* VIO to expansion board above */ compatible = "arm,vexpress-volt"; arm,vexpress-sysreg,func = <2 0>; @@ -112,7 +112,7 @@ regulator-always-on; }; - volt@1 { + volt1 { /* 12V from power connector J6 */ compatible = "arm,vexpress-volt"; arm,vexpress-sysreg,func = <2 1>; @@ -120,7 +120,7 @@ regulator-always-on; }; - temp@0 { + temp0 { /* FPGA temperature */ compatible = "arm,vexpress-temp"; arm,vexpress-sysreg,func = <4 0>; @@ -128,7 +128,7 @@ }; }; - smb { + smb@0,08000000 { compatible = "simple-bus"; #address-cells = <2>;
Commit fa38a82096a1 ("scripts/dtc: Update to upstream version 53bf130b1cdd") added warnings on node name unit-address presence/absence mismatch in device trees. This patch fixes those warning on all the juno/vexpress platforms where unit-address is present in node name while the reg/ranges property is not present. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> --- arch/arm64/boot/dts/arm/foundation-v8.dtsi | 2 +- arch/arm64/boot/dts/arm/juno-base.dtsi | 14 +++++----- arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 30 +++++++++++----------- arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts | 2 +- arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi | 14 +++++----- .../boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts | 10 ++++---- 6 files changed, 36 insertions(+), 36 deletions(-) Hi Rob, I am not sure if the intention of commit fa38a82096a1 is to fix even existing warnings or not. I saw warning with today's -next branch. Let me know. Regards, Sudeep