New version with improvements and added features focusing device tree source files:

  • Improved Syntax highlighting colors;

  • Device Tree Compiler linter diagnostics;

  • Symbol lookup only on the file context, lookup on #include;

  • DocumentLink on #include and compatible strings that jumps for header .h/ device tree source include .dtsi / documentation .txt .yaml / implementation .c files;

    • mouse hover (list match files)

    • ctrl+click (open directly the .c file with the implementation)

  • label node property IntelliSense;

🎨 Improved Syntax Highlight Colors

Before:

After:

🌲 Device Tree Compiler Linter Diagnostics

⚠️ This feature depends on the device tree compiler/dtc. Make sure you have this package installed in your distribution.

🧪 This is experimental feature, be aware that unexpected behavior may occur.

When saving .dts or .dtsi files the extension automatically compiles and parse the output of the device tree compiler into diagnostic inputs:

🔣 Symbol Lookup (goto definition) Restricted to the File Context

🧪 This is experimental feature, be aware that unexpected behavior may occur.

Using ctags feature the DefinitionProvider shows a list of all symbols indexed for .dts or .dtsi files:

With the new DTSEngine the symbols index is done by file context. So the DefinitionProvider shows in the list only the symbols present in the context (includes):

🔗 Document Link to #include and compatible

#include and compatible = "match" directives are now resolved as links to: in the case of #include to the respective file pointed by the path, in the case of compatible = "match" to the source code .c and also .txt/.yaml documentation files that have the match string:

🧠 Label/Node/Property IntelliSense

🧪 This is experimental feature, be aware that unexpected behavior may occur.

The new DTSEngine uses the device tree bindings documentation, only .yaml files documentation supported, to give completion hints. The properties are binding by the compatible string:

IntellinSense also helps with reference tips for node overwriting. By typing & and after ctrl+space, a list of the nearest nodes will be presented. Don't worry about overwriting compatible, IntellinSense will use the compatible of the reference node for the hints:

🧪 Enabling Experimental Features

⚠️ That the previous user experience is not affected, these features presented here are not enabled by default. They are still in the testing phase, there may be performance issues and unhandled exceptions.

Caso você deseje já testar e trabalhar com as funcionalidades experimentais, você deve editar as seguintes configurações:

If you want to already give it a try and work with the experimental features, you should edit the following settings:

⚠️ They can be added either just for a specific workspace in {yourWorkSpaceFolder}/.vscode/settings.json, or in the global settings.json.

Disable the ctags index for .dts and .dtsi files, so that the symbol lookup searches only in the context of the file, you should remove the DTS entry from the configuration:

 "ctags.languages": [
        "C",
        "C++",
        "DTS",
        "Kconfig",
        "Make"
    ],

After removing the "DTS" from the list, generate the index again:

The new engine uses the .yaml files documentation of device tree bindings for IntelliSense. Use the following setting to point to the documentation folder path:

"devicetree.bindings": [
    "${workspaceFolder}/Documentation/devicetree/bindings"
],

⚠️ You can use the VS Code variable ${workspaceFolder} and open the root of the Linux repository or set this entry as a full path.

After these steps enable the experimental features by adding:

"kerneldev.experimental.newDtsEngine": true

⚠️ When saving this configuration change the VS Code instance will be automatically restarted.

With these settings no extra commands are needed. Just open a .dts or .dtsi file and enjoy the new features (or not 😅🪲).

✋ Final considerations

It is worth warning once again:

⚠️🧪 These are experimental features, be aware that unexpected behavior may occur.

I'm already presenting it out in public because I'm looking for feedback. Device tree use cases are quite broad and many specific cases can occur. If you use it and have an opinion, find a bug or have a use case that has not been addressed, please open an issue here: Issues · microhobby/linuxkerneldev (github.com)

You can also find me on social media: