[U-Boot] [PATCH] mips: fix DTC unit warnings

[Tom Rini]

On Fri, Apr 15, 2016 at 10:56:40AM -0600, Stephen Warren wrote:
> On 04/15/2016 10:30 AM, Tom Rini wrote:
> >On Fri, Apr 15, 2016 at 05:23:54PM +0200, Andreas Färber wrote:
> >>Am 15.04.2016 um 12:59 schrieb Heiko Schocher:
> >>>Fix following warnings for all mips based boards:
> >>>      mips:  +   pic32mzdask
> >>>+Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
> >>>+Warning (unit_address_vs_reg): Node /cpus/cpu at 0 has a unit name, but no reg property
> 
> Note that I am quite out-of-the-loop on these warning. I wrote the
> dtc patch that triggers them years ago, but it's only recently been
> applied due to Rob's efforts. I'm at most tangentially aware of the
> discussions surrounding applying it now.
> 
> 
> >>>diff --git a/arch/mips/dts/pic32mzda.dtsi b/arch/mips/dts/pic32mzda.dtsi
> 
> >>>  	cpus {
> >>>-		cpu at 0 {
> >>>+		cpu {
> >>>  			compatible = "mips,mips14kc";
> 
> Surely the correct fix is to add a reg property? (Of course, this
> depends on the binding definition; for ARM my assertion would
> certainly be true). If not, what does MIPS do about SMP? Even if you
> write, say, 4 nodes with name "cpu" they'll all become the same
> single node in the DTB.

So the likely answer here is that the dtsi is wrong and needs to be
fixed rather than just dropping @0.

> >>>diff --git a/arch/mips/dts/skeleton.dtsi b/arch/mips/dts/skeleton.dtsi
> 
> >>>-	memory {
> >>>+	memory at 0 {
> >>
> >>I have just been told on linux-rockchip mailing list that such a change
> >>should not be done as /memory is being special-cased in dtc warnings for
> >>the benefit of U-Boot. Supposedly U-Boot cannot handle updating memory
> >>size on /memory at 0.
> >>
> >>If that is untrue, please someone object on the Linux mailing lists.
> >
> >Uh, what?  From dtc:
> 
> I vaguely recall seeing discussion that /memory *would* be
> special-cased, but as you point out obviously isn't yet. I doubt
> it's anything to do with U-Boot itself, but rather the more general
> problem that if /memory at NNNN changes name based on what RAM is
> present, it's not possible for any bootloader to update it in a sane
> way (what node name do you search for to edit), or any OS to read it
> in a sane way (what node name do you search for to find out where
> memory is). As such, a special case is logically required.

Right, makes sense.  But it'll also have to handle that today (nearly)
everyone is /memory at NNNN.

> >commit c9d9121683b35281239305e15adddfff2b462cf9
> >Author: Stephen Warren <swarren at 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.
> >
> >     Signed-off-by: Stephen Warren <swarren at nvidia.com>
> >     [robh: also allow non-empty ranges]
> >     Signed-off-by: Rob Herring <robh at kernel.org>
> >     [moved new test in check_table]
> >     Signed-off-by: David Gibson <david at gibson.dropbear.id.au>
> >
> >That's where that warning comes from.
> >
> >But some real quick grepping makes it seem like the cpu at 0 error is also
> >a sign of a bigger problem in the dts file
> >
> >But I would suggest that whomever is making special case warnings for
> >U-Boot bring that up on the U-Boot mailing list or otherwise ask?  We're
> >not a black box...
> 
> Equally though, anyone working on DT in U-Boot should be hanging out
> on the device tree mailing list, and getting actively involved in
> discussions, rather than hiding here.

True.  And devicetree-spec is very quiet and devicetree is very very
loud, and somewhere along the line for me at least vger kicked me off,
sigh.  Fixing that at least.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160415/1f6114ff/attachment.sig>