From: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org,
jdl-CYoMK+44s/E@public.gmane.org,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: [RFC PATCH v6 0/2] dtc: dts source location annotation
Date: Fri, 02 Oct 2015 21:44:05 -0700 [thread overview]
Message-ID: <560F5D15.9060606@gmail.com> (raw)
Proof of concept patch.
Annotates input source file and line number of nodes and properties
as comments in output .dts file when --annotate flag is supplied.
A common dts source file convention is for a system .dts file
to include default SOC and/or device .dtsi files and then add
additional system specific properties or over-ride property values
from the .dtsi files. It can be a time consuming and error prone
exercise to determine exactly what nodes, properties, and property
values are in the final .dtb binary blob and where they originated.
Modify the dtc compiler to read a (possibly cpp pre-processed) .dts
file and for the output .dts annotate each node and property with
the corresponding source location.
As an example, one device tree node for the dragonboard in the
Linux kernel source tree (hand edited to remove leading path
components) is:
----- long format -----
sdhci@f9824900 { /* qcom-apq8074-dragonboard.dts:14.3-18.5 */
compatible = "qcom,sdhci-msm-v4"; /* qcom-msm8974.dtsi:240.4-37 */
reg = <0xf9824900 0x11c 0xf9824000 0x800>; /* qcom-msm8974.dtsi:241.4-49 */
reg-names = "hc_mem", "core_mem"; /* qcom-msm8974.dtsi:242.4-37 */
interrupts = <0x0 0x7b 0x0 0x0 0x8a 0x0>; /* qcom-msm8974.dtsi:243.4-38 */
interrupt-names = "hc_irq", "pwr_irq"; /* qcom-msm8974.dtsi:244.4-42 */
clocks = <0xd 0xd8 0xd 0xd7>; /* qcom-msm8974.dtsi:245.4-36 */
clock-names = "core", "iface"; /* qcom-msm8974.dtsi:246.4-34 */
status = "ok"; /* qcom-apq8074-dragonboard.dts:17.4-18 */
bus-width = <0x8>; /* qcom-apq8074-dragonboard.dts:15.4-20 */
non-removable; /* qcom-apq8074-dragonboard.dts:16.4-18 */
}; /* qcom-apq8074-dragonboard.dts:14.3-18.5 */
----- short format -----
sdhci@f9824900 { /* qcom-apq8074-dragonboard.dts:14 */
compatible = "qcom,sdhci-msm-v4"; /* qcom-msm8974.dtsi:240 */
reg = <0xf9824900 0x11c 0xf9824000 0x800>; /* qcom-msm8974.dtsi:241 */
reg-names = "hc_mem", "core_mem"; /* qcom-msm8974.dtsi:242 */
interrupts = <0x0 0x7b 0x0 0x0 0x8a 0x0>; /* qcom-msm8974.dtsi:243 */
interrupt-names = "hc_irq", "pwr_irq"; /* qcom-msm8974.dtsi:244 */
clocks = <0xd 0xd8 0xd 0xd7>; /* qcom-msm8974.dtsi:245 */
clock-names = "core", "iface"; /* qcom-msm8974.dtsi:246 */
status = "ok"; /* qcom-apq8074-dragonboard.dts:17 */
bus-width = <0x8>; /* qcom-apq8074-dragonboard.dts:15 */
non-removable; /* qcom-apq8074-dragonboard.dts:16 */
}; /* qcom-apq8074-dragonboard.dts:18 */
qcom-apq8074-dragonboard.dts:
- last referenced the sdhci node
- changed the value of the "status" property from "disabled" to "ok"
- added two properties, "bus-width" and "non-removable"
qcom-msm8974.dtsi:
- initially set the value the "status" property to "disabled"
(not visible in the annotated .dts)
- provided all of the other property values
When the dtc compiler is run within the Linux kernel build system,
the path of the source files will be the full absolute path, just
as seen for gcc warnings and errors. I always trim away the path
leading up to the Linux kernel source tree by passing the kernel
build output through a sed pipe. I have done the same to the
above example to remove the excessive verbosity in the source paths.
Implementation notes:
- Added new function srcpos_string_short() which is similar to
srcpos_string() but limits the location information to one
line number. The fuller output of srcpos_string() adds noise
to the annotation which (in my opinion) is not especially
useful in this specific context.
The one downside to this choice is that the column numbers for
multiple properties on the same input line will not be reported.
This is unlikely to be an issue unless a .dts contains all of
the properties on a single line (which might be the case for
a machine generated .dts). I do not think that the extra
noise for the common case justifies handling this case.
- The source location of each node and property is saved in the
respective node or property during the parse phase because
the source location information from current_srcfile is no longer
available when the final values are written out from dt_to_source()
and the functions that it calls.
- A check is added to dtc.c to ensure that input and output format
are both device tree source. An alternate choice would be to
turn off the --annotate flag if either the input file or the
output file is not device tree source. In the alternate case,
the disabling of --annotate could be silent or a warning could
be issued.
TODO:
- Update "make check" tests to reflect review comments.
- Test against a wider set of .dts files. There are some rules
that I did not test extensively (and some rules, such as delete
that I did not test at all in this version).
- Change the --annotate option to choose either long or short format.
- Fix location for: devicetree: '/' nodedef
Changes from v5:
- Add more pointer checking to patch 1.
- Change from two to one srcpos fields in struct node. Move the
logic to choose begin or end to the annotation print logic for
the case of short location format.
- Move the setting of srcpos back to name_node() and build_prop()
instead of adding new functions to save that information.
- Patch 2 reports the location in long format (beginning and end
of the object). Adding patch 3 changes for format to short (the
current source line only).
next reply other threads:[~2015-10-03 4:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-03 4:44 Frank Rowand [this message]
[not found] ` <560F5D15.9060606-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-10-03 4:49 ` [RFC PATCH v6 1/3] dtc: protect against null pointer dereference in srcpos_string() Frank Rowand
[not found] ` <560F5E44.9080006-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-10-06 4:10 ` David Gibson
[not found] ` <20151006041000.GI3861-RXTfZT5YzpxwFLYp8hBm2A@public.gmane.org>
2015-10-06 7:32 ` Frank Rowand
[not found] ` <56137904.9080203-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-10-06 10:46 ` David Gibson
2015-10-03 4:52 ` [RFC PATCH v6 2/3] dtc: dts source location annotation Frank Rowand
[not found] ` <560F5F20.30709-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-10-06 4:56 ` David Gibson
[not found] ` <20151006045607.GK3861-RXTfZT5YzpxwFLYp8hBm2A@public.gmane.org>
2015-10-06 7:38 ` Frank Rowand
[not found] ` <56137A6B.6080805-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-10-07 5:27 ` David Gibson
2015-10-06 7:45 ` Frank Rowand
[not found] ` <56137C1E.8060005-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-10-07 5:32 ` David Gibson
[not found] ` <20151007053246.GS3861-RXTfZT5YzpxwFLYp8hBm2A@public.gmane.org>
2015-10-07 6:58 ` Frank Rowand
[not found] ` <560F5FB5.3020602@gmail.com>
[not found] ` <560F5FB5.3020602-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-10-06 5:01 ` [RFC PATCH v6 3/3] dtc: dts source location annotation, short location format David Gibson
[not found] ` <20151006050114.GL3861-RXTfZT5YzpxwFLYp8hBm2A@public.gmane.org>
2015-10-06 7:32 ` Frank Rowand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=560F5D15.9060606@gmail.com \
--to=frowand.list-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org \
--cc=devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=jdl-CYoMK+44s/E@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).