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

[Stephen Warren <swarren@wwwdotorg.org>]

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.

>>> 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.

>
> 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.
>
>      Signed-off-by: Stephen Warren <swarren@nvidia.com>
>      [robh: also allow non-empty ranges]
>      Signed-off-by: Rob Herring <robh@kernel.org>
>      [moved new test in check_table]
>      Signed-off-by: David Gibson <david@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.