From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] arm: dts: socfpga: fix DTC unit name warnings
Date: Mon, 18 Apr 2016 08:07:47 +0200 [thread overview]
Message-ID: <571479B3.5060804@denx.de> (raw)
In-Reply-To: <20160417215504.GB20337@amd>
Hello Pavel,
Am 17.04.2016 um 23:55 schrieb Pavel Machek:
> Hi!
>
>> Warning (unit_address_vs_reg): Node /soc/usbphy at 0 has a unit name,
>> but no reg property
>
> I don't know who produces the warnings, but perhaps fix the tool,
> instead?
This warnigns poping up with new DTC compilers, introduced from dtc
commit:
commit c9d9121683b35281239305e15adddfff2b462cf9
Author: Stephen Warren <swarren@nvidia.com>
Date: Fri Feb 19 15:59:29 2016 +1100
Warn on node name unit-address presence/absence mismatch
ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any
node that has a reg property must include a unit address in its name
with value matching the first entry in its reg property. Conversely, if
a node does not have a reg property, the node name must not include a
unit address. Also allow ranges property as it is deemed valid, but ePAPR
is not clear about it.
Implement a check for this. The code doesn't validate the format of the
unit address; ePAPR implies this may vary from (containing bus) binding
to binding, so doing so would be much more complex.
So, the DTS are wrong, and need fixing ...
>> @@ -9,5 +9,5 @@
>> #size-cells = <1>;
>> chosen { };
>> aliases { };
>> - memory { device_type = "memory"; reg = <0 0>; };
>> + memory at 0 { device_type = "memory"; reg = <0 0>; };
>> };
>
> This does not look like an improvement to me...
>
>> @@ -128,7 +128,7 @@
>> compatible = "fixed-clock";
>> };
>>
>> - main_pll: main_pll {
>> + main_pll: main_pll at 40 {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> #clock-cells = <0>;
>> @@ -136,7 +136,7 @@
>> clocks = <&osc1>;
>> reg = <0x40>;
>>
>> - mpuclk: mpuclk {
>> + mpuclk: mpuclk at 48 {
>> #clock-cells = <0>;
>> compatible = "altr,socfpga-perip-clk";
>> clocks = <&main_pll>;
>
> Neither do these, actually. So we have clock at fixed addresses. Why
> is it wrong?
see commit message ...
>> @@ -742,7 +742,7 @@
>> reg = <0xffd05000 0x1000>;
>> };
>>
>> - usbphy0: usbphy at 0 {
>> + usbphy0: usbphy {
>> #phy-cells = <0>;
>> compatible = "usb-nop-xceiv";
>> status = "okay";
>
> And this sounds like a bug waiting to happen..
Better fix would be to add the reg property .. could you help me?
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
next prev parent reply other threads:[~2016-04-18 6:07 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-15 10:41 [U-Boot] [PATCH] arm: dts: socfpga: fix DTC unit name warnings Heiko Schocher
2016-04-15 14:18 ` Marek Vasut
2016-04-18 4:55 ` Heiko Schocher
2016-04-18 10:36 ` Marek Vasut
2016-04-18 11:20 ` Heiko Schocher
2016-04-18 11:22 ` Marek Vasut
2016-04-17 21:55 ` Pavel Machek
2016-04-18 6:07 ` Heiko Schocher [this message]
2016-04-18 10:00 ` Pavel Machek
2016-04-18 10:35 ` Marek Vasut
2016-04-18 11:06 ` Heiko Schocher
2016-04-18 15:31 ` Tom Rini
2016-04-18 15:37 ` Marek Vasut
2016-04-18 15:46 ` Tom Rini
2016-04-18 17:52 ` Marek Vasut
2016-04-19 5:01 ` Heiko Schocher
2016-04-19 10:38 ` Marek Vasut
2016-04-19 4:47 ` Heiko Schocher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=571479B3.5060804@denx.de \
--to=hs@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox