Re: DT label vs nodelabel
"Michael Rosen via lists.zephyrproject.org"
Hey,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'sI'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
https://github.com/zephyrproject-rtos/zephyr/pull/34589 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
I understand that while label properties don't need to be unique (ie,Kumar has an open PR for enforcing unique label properties, FYI:
In a project I am working on, theres many new devicetree nodes whichOne 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.