DT label vs nodelabel
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?
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 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). 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).
Michael R Rosen
Emerging Growth Incubation
Santa Clara, CA | 95054
Hi Michael,toggle quoted messageShow quoted text
Where can I find your patch? I'm interested in it as well.
On May 21, 2021, at 09:00 PM, Michael Rosen <michael.r.rosen@...> wrote:
I havent done it yet sorry; I was hoping to get a better understanding of the reason they are separate before going with one solution (just make node label available as a string separately or change it so label comes from node label instead of the label property).
From: devel@... <devel@...> On Behalf Of Martin Schröder
Sent: Friday, May 21, 2021 2:23 PM
To: Rosen, Michael R <michael.r.rosen@...>
Subject: Re: [Zephyr-devel] 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.
Kevin Townsend <email@example.com> writes:
Hi Martí,I get why you're asking this, but I don't think the project is totally
sold on discussions yet; is it?
The mailing list is still the only official place for discussions like
this that has archives.
Thanks for the historical context.
Seems like something worth putting into a GitHub ´discussion’ thread on the main zephyr repo for future access and updates, since DT in general has a learning curve for new users?
Marti Bolivar <firstname.lastname@example.org> writes:
Hi Kevin,I should also mention that I'm going to be giving a talk on the 2.5
device model that will cover all of this:
I'm hoping the recording of that will be something we can link to for
newcomers at some point.
On Sat, 22 May 2021 at 00:35, Bolivar, Marti <Marti.Bolivar@...> wrote:
I remember on a recent TSC call, Anas making the point (or perhaps it was Maureen?) that GitHub Discussions is still quite different than Slack or the mailing list, but that it might be a good long term repository of sticky issues like this that people can more easily stumble across.
It felt like a sensible suggestion to me, and this comment seemed like a good use case given how obscure DT can feel to new users.
PS: Sorry to hijack a useful discussion!
Kevin Townsend <email@example.com> writes:
Hi Marti,Yep, I was there too, but I don't recall that being a project-wide
decision. As far as I know, GitHub discussions are still in beta and
Zephyr is just experimenting with them.
It felt like a sensible suggestion to me, and this comment seemed like aI personally do not use or monitor GitHub Discussions. I watch Slack,
the mailing list, and any issues and PRs that get thrown my way.
If the TSC decides to add discussions to the list of official places
Zephyr gets Zephyred, I guess I'll have no choice but to wade in at that
But the above are already more than enough for me already ...
This is a good discussion too and I get where you're going, I just don't
want to start having to read discussions yet :).