On 03.08.19 03:35, David Gibson wrote:
> On Fri, Aug 02, 2019 at 01:02:47PM -0700, Frank Rowand wrote:
>> On 8/2/19 10:29 AM, Rob Herring wrote:
>>> On Thu, Aug 1, 2019 at 7:45 PM Frank Rowand <frowand.list@xxxxxxxxx> wrote:
>>>> Hi Paul,
>>>>
>>>> On 7/31/19 7:46 AM, Paul Spooren wrote:
>>>>> Hi,
>>>>>
>>>>> I hope this mail reaches the correct people!
>>>>>
>>>>> At OpenWrt[0] there are sometimes badly styled .dts files which waste
>>>>> human time to comment and fix, it would be nice to have some automatic
>>>>> checks for that. Is there a tool like astyle or clang-format for device
>>>>> tree files?
>>>> The bindings documents are being converted into a json-schema vocabulary.
>>>> Once in this format, the bindings to be used to validate .dts files.
>>>> See section "##Testing" in the file Documentation/devicetree/writing-schema.md
>>>> which is in the Linux kernel source tree for information on the validation
>>>> tools.
>>>>
>>>> Also, dtc has been adding many checks. See file checks.c in the dtc source
>>>> tree.
>>> Yes, but none of those concern formatting of dts files (e.g. 8
>>> character tabs, {} locations, spaces around '='). I think the dtc
>>> checks code is too late in the flow to check those things, but maybe
>>> it is possible now with the source annotations recently added now that
>>> I think about it? My original thought was adding something at the
>>> earlier stages with the bison/flex parsing (of which I really have no
>>> experience with).
>>>
>>> Rob
>>>
>> Good point, I mis-read Paul's email as a desire to catch errors instead
>> of style issues.
>>
>> One possible way to see formatting style issues uses the dtx_diff
>> script in the Linux kernel source tree:
>>
>> scripts/dtc/dtx_diff original.dts > new.dts
>> scripts/dtc/dtx_diff -f original.dts new.dts
>>
>> The first command will use dtc to reformat original.dts into new.dts.
>>
>> The second command will compare the original .dts to the reformatted
>> .dts. Without the "-f", it may be difficult to determine which node
>> a changed property is in.
>>
>> Due to the includes, it may be difficult to determine exactly which
>> source file contains any given line. The "-T" option will add file
>> and line information. "-T" will be useless on the second command,
>> because the file reported for original.dts will be different for
>> every line from the file reported for new.dts, but could be
>> useful to find the source in the original .dts:
>>
>> scripts/dtc/dtx_diff -T original.dts
>>
>> dtx_diff uses the dtc sort option by default. If you want the diff
>> to be ordered more like the original.dts, use:
>>
>> scripts/dtc/dtx_diff -u original.dts > new.dts
>> scripts/dtc/dtx_diff -u -f original.dts new.dts
> Right. More generally, dtc -I dts -O dts can kind of be used as a
> reformatting tool. Now that we have type annotations it should no
> longer mangle decisions about how to encode information which it would
> have in the past. It will still strip comments, however.
We came up with this idea before but comments are to important to drop
them. However it'd be a possibility to strip comments from the original
file, additionally convert the file back and forth and compare the
stripped original and the resulting file. This should at least be enough
for automatic testing, however a local script doing real linting would
be the only real solution...
> I do also wonder if the dts syntax is close enough to C that something
> like "indent" or "clang-format" would kind of work on it.
I played a bit with an online tool [0] for DTS, however I failed e.g. to
have lines starting with `#` correctly indented (is this an English
word?. Apart from that, clang-format did not complain about the file format.
[0]: https://zed0.co.uk/clang-format-configurator/
