[PATCH 2/7] ARM: dts: skeleton: add unit name to memory node

[Joachim Eastwood]

On 30 March 2016 at 19:06, Mark Rutland <mark.rutland at arm.com> wrote:
> On Wed, Mar 30, 2016 at 06:15:35PM +0200, Joachim Eastwood wrote:
>> Hi Mark,
>>
>> On 30 March 2016 at 15:41, Mark Rutland <mark.rutland at arm.com> wrote:
>> > On Wed, Mar 30, 2016 at 04:06:56PM +0300, Vladimir Zapolskiy wrote:
>> >> On 30.03.2016 14:06, Mark Rutland wrote:
>> >> > On Wed, Mar 30, 2016 at 12:30:41AM +0200, Joachim Eastwood wrote:
>> >> >> Add unit name to memory to remove the following warning:
>> >> >>  Warning (unit_address_vs_reg): Node /memory has a reg or ranges
>> >> >>                            property, but no unit name
>> >> >
>> >> > If anything, it would be better to get rid of the memory node from the
>> >> > skeleton DTs.
>> >> >
>> >> > For DTs which have a memory node there's no problem, and DTs which
>> >> > expect a bootlaoder to fill things in have a logical place to document
>> >> > that fact.
>> >
>> >> The only problem I see if DTB is updated on a board but a board bootloader
>> >> on fix-up is capable to fill a preexisting "/memory" device node in only,
>> >> otherwise it is not clear why the device node is present in skeleton.dtsi.
>> >
>> > Sure. To clarify the above, what I expect that for this case is that the
>> > empty memory node would exist in the dts for that particular board,
>> > along with a comment, e.g.
>> >
>> >         /* The firmware/bootloader for $BOARD fills this in */
>> >         memory {
>> >                 device_type = "memory";
>> >                 reg = <0 0 0 0>;
>> >         };
>>
>> To avoid the warning with the new dtc this would need to be memory at 0.
>
> Hmm... That's a little sub-optimal in the case that a bootloader is
> patching this. Presumably a bootloader that needs an existing node won't
> patch the unit-address to match the reg (which might not start at 0).
>
> I'd rather not have the unit-address than have an incorrect
> unit-address, though I guess we don't have much of a choice here, unless
> there's some override we can place in the dts.
>
>> > That way you can tell at a glance that the lack of memory information in
>> > the DT for a board is intentional, and the bootloader still gets the
>> > node it expects.
>>
>> But this doesn't seem to be a "problem" with any of the DTs in
>> arch/arm/boot as they all defined a memory node.
>>
>> I used the following script to check for the memory node in all built dtb's.
>>   make ARCH=arm CONFIG_OF_ALL_DTBS=y dtbs
>>   for i in $(ls arch/arm/boot/dts/*.dtb); do
>>          m=$(scripts/dtc/dtc -I dtb -O dts $i | grep -m1 'memory.*{')
>>          if [ -z "$m" ]; then
>>                  echo "Missing memory node in $i"
>>           fi
>>   done
>>
>> So it should be pretty safe to just remove the memory node entry in
>> the skeleton files. Unless I have missed something with the script
>> above.
>
> The above might match reserved-memory nodes; it might be better to check
> for 'device_type\s*=\s*"memory"'.

I did check the output of the grep and it looks good. But there are
indeed DTs that are missing the 'device_type = "memory"' parameter.
Actually; _a lot_ or 438 of 741 to be exact. ugh...

I guess all those should be fixed up before we can remove the memory
node from skeleton. :/


> I assume that was run after deleting the memory node from the skeletons?

Yes :)


regards,
Joachim Eastwood