[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqJkrPubmM6m7KsaU9S=7j_qVq-U=dJ-500H2VDbT9CwdQ@mail.gmail.com>
Date: Fri, 20 Mar 2015 08:46:09 -0500
From: Rob Herring <robherring2@...il.com>
To: Frank Rowand <frowand.list@...il.com>
Cc: Rob Herring <robh+dt@...nel.org>,
Grant Likely <grant.likely@...aro.org>,
Russell King <linux@....linux.org.uk>,
Michal Marek <mmarek@...e.cz>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Kumar Gala <galak@...eaurora.org>,
Leif Lindholm <leif.lindholm@...aro.org>,
Mark Rutland <mark.rutland@....com>,
Pawel Moll <pawel.moll@....com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
linux-kbuild@...r.kernel.org,
Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [patch 0/7] dt: dtb version: add version info to dtb
On Wed, Mar 18, 2015 at 10:29 PM, Frank Rowand <frowand.list@...il.com> wrote:
> Rob,
>
> Can this be added to the next trees to get some test exposure before submitting
> to Linus?
No. I've yet to see anyone think this is a good idea.
> There is currently no way to tie a device tree blob (DTB) back to the source
> and environment used to create it. Add this information, including a DTB
> version number, which is somewhat analogous to the Linux kernel version number.
>
> The DTB version number is independent of the kernel version number, and is
> incremented for each make of one or more DTBs.
>
> The DTB information is placed in node /chosen/dtb-info. The data for this
> node will be automatically generated by the .dtb make system for any .dts
> that includes arch/arm/boot/dts/skeleton.dtsi, either directly or indirectly.
> This means that architectures other than arm will not receive this feature.
> This can be added to other architectures by modifying their skeleton.dtsi.
>
> There are 70 of the 557 arm .dts files that do not include skeleton.dtsi.
> Thus the .dtb files created for these systems will not have the
> /chosen/dtb-info node:
Actually, we really want to get rid of skeleton.dtsi. At least the
memory node because it obscures whether the memory node is correct or
not. Then if there is no memory node, there is not much point to it.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists