Re: DT label vs nodelabel

Bolivar, Marti

Hi Mike,

"Michael Rosen via"
<> writes:


In Zephyr's devicetree, there are two separate concepts when it comes
to naming a node with a unique name: label property and node label. Is
there a design reason why these two have been kept separate or is it
just historic?
TL;DR it's historic.


The 'label property' and 'node label' concepts come from the devicetree
specification itself. The way they've been used in Zephyr is historic.

Label properties were used first because they work better with how
Zephyr's device model was historically defined. You can use node labels
now also as a result of various changes to the DT tooling and the device

The device_get_binding() function predates the use of devicetree/DT in
zephyr. When DT support was added, 'struct device' objects started being
defined from DT nodes. Since device_get_binding() was what was available
to get a device, it was necessary to associate a string with each node
to be able to pass to device_get_binding() and get the actual device

Before v2.3, there was no concept of a 'node identifier' in the DT API.

There wasn't even really an "API" for devicetree; users had to use the
generated macros directly.

Starting with v2.3, you can use node labels to get node identifiers, but
in v2.3 and v2.4 you still had to get a label property to pass to
device_get_binding(), like so:

my_device = device_get_binding(DT_LABEL(DT_NODELABEL(my_node_label)));

In v2.5, DEVICE_DT_GET() and friends were added, and all of the in-tree
device drivers were reworked to support them. Since then, you can just
get the device directly at build time:

my_device = DEVICE_DT_GET(DT_NODELABEL(my_node_label));

The "old" way with device_get_binding() is still supported for

It seems to me it would be more convenient to leverage devicetree's
node label feature to provide each node that needs to be accessed the
string version of that label for use as DT_LABEL is used.
I'm not sure what you mean.

When it comes to getting device structs, there is no need to get the
node label as a string now that DT_NODELABEL() and DEVICE_DT_GET()

I have a pet project to remove device_get_binding() from all the
samples, to make this more obvious. I managed to get merged in time
for v2.6, and will continue the project once the v2.7 merge window

There are a few edge cases where device_get_binding() is still required,
but most of the time, it's not necessary and is in fact better not to
use it.

I understand that while label properties don't need to be unique (ie,
not enforced by devicetree to be unique unlike node label), for how
they are typically used (device_get_binding), they do need to be
unique (which devicetree can enforce if node label were used instead).
Kumar has an open PR for enforcing unique label properties, FYI:

In a project I am working on, theres many new devicetree nodes which
would be nice to have a nicer name for debugging available in C than
the full path (the node name isnt unique due to the structure of the
device tree, a lot of the nodes are something like nodelabel1:
generic_name@0, nodelabel2: generic_name@1) and it would be nice if we
could just leverage the node label we are adding to the devicetree
rather than also adding an additional label property (I have been
thinking of making a patch to access node label as a string from the
node id and wondered if I should do it with the intention of replacing
the label property in Zephyr entirely or not).
One problem is that while node labels *are* unique, an individual node
may have zero, one, or many node labels, so saying "the" node label for
a node doesn't quite work in the general case. There might not be a node
label, or there might be more than one.

So I think node labels are not suitable for replacing the label property
entirely, but at the same time, label properties are increasingly
optional at this point.

That said, if you would like to propose devicetree.h API extensions that
can handle all the 0/1/many node labels cases and provide node labels as
strings for debugging use, please send a PR! We can try to merge it for
2.7 when the merge window opens up again.



Michael R Rosen
Firmware Engineer
Emerging Growth Incubation
Santa Clara, CA | 95054

Join to automatically receive all group messages.