On 31 March 2016 at 12:38, Mark Rutland <mark.rutland@xxxxxxx> wrote:
> On Wed, Mar 30, 2016 at 10:45:06PM +0200, Joachim Eastwood wrote:
>> On 30 March 2016 at 19:06, Mark Rutland <mark.rutland@xxxxxxx> wrote:
>> > On Wed, Mar 30, 2016 at 06:15:35PM +0200, Joachim Eastwood wrote:
>> >> 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. :/
>
> Ouch, yes. :(
>
> That said, the cahnges don't need to be an atomic operation. We could
> start adding device_type = "memory" to dts immediately (in as whatever
> size batches maintainers are happy with), as a duplicate device_type
> shouldn't be problematic.
Yes, that is true.
> When we hit critical mass, we could then remove the skeleton memory
> nodes, fixing up any remaining fallout.
>
> As for the mechanical changes, it sounds like we need coccinelle for DT.
>
> That, or a laptop, a long flight, and a gin and tonic.
:-)
I'll see if I can cook up something with awk.
Anyway, I am dropping the memory node changes from this patch set so I
can get a pull request sent to arm-soc for lpc18xx sooner rather than
later.
regards,
Joachim Eastwood
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
