Re: Inconsistent and ever-changing device naming in Zephyr

Andy Gross

On 9 February 2017 at 03:52, Jon Medhurst (Tixy) <> wrote:
On Wed, 2017-02-08 at 11:31 -0600, Andy Gross wrote:
On 6 February 2017 at 10:59, Daniel Thompson <> wrote:
On 06/02/17 13:34, Paul Sokolovsky wrote:


Writing on this was in my TODO at least since November, but I expected
this to be a controversial topic, so kind of skipped it. Controversial,
as in: different parties finding to be "obvious" quite different, if
not opposite solutions to the problem. Well, the breakage continues,
so this should be raised.

(Recent) facts:

1. Update to Kinetis (BOARD=frdm_k64f) port broke GPIO support in a
(complex) Zephyr-based application, Zephyr.js:

2. A day or two, Arduino 101 I2C support in Zephyr.js was updated,
apparently because Zephyr upgrade broke it. Today it became known that
the fix for Arduino 101 broke FRDM-K64F.

Investigating the issues, the causes of them are:

1. frdm_k64f GPIO port naming changed from "GPIO_0" to (!!) "gpio_porta".

2. Name of (one of) I2C device for arduino_101 changed from "I2C_0" to

This is not the first time when device names change in Zephyr (see
reference above to November 2016), it's the first time (at least for
last half-year), when the naming changes in relatively well developed
ports, which leads to cascade of breakage in the one. And one case, it
can be seen how inconsistent naming (and changes of it) can be.

The question what to do about this. Possible high-level approaches can

a) Establish (well, reconfirm/clarify) and uphold consistent naming
conventions across ports, architectures, and boards.

b) Send a strong message to application developers that they should
not rely on any patterns of Zephyr device naming, and even on the naming
at all, and instead should treat it as a configuration parameter, which
ultimately should be set by a user (and thus apps should make such
configuration explicit and easy for users).

Or c) inherit the device names from device tree?

I don't actually remember that much about the proposed DT tooling but it
should certainly be included in this discussion.

It might be made slightly more complex by the presence of aliased names in
DT (often used to bridge SoC datasheet namings into board based names). I
guess Zephyr might prefer to use the most-derived alias rather then the SoC
datasheet name?
The alias {} node can indeed be used for this. But unless we define a
specific format, parsing this might be interesting. However we have
some solutions for that if we want to go that route. A board specific
yaml file could specify the alias format. It's need to be something
that can co-exist with existing DT files that might be imported from

Maybe something along the lines of:
zephyr,uart-0 = &node@xxxxxxxx;
zephyr,uart-1 = &node@xxxxxxxx;
and so on and so forth. These can ghost the aliases already present
if they have something like uart0 = &node@xxxxxxxx; The zephyr,XXXXX
need to be standardized for each device type. We strip the zephyr
part and the generated string name becomes UART-0 or UART0 or whatever
standard we want.

I think this solves both the unified naming and the assigning of the
names to specific nodes.
So, if I get this right, this is device-tree aliases being used to
specify the driver name in Zephy? I.e. the drv_name parameter passed to
DEVICE_INIT and the string passed to device_get_binding to get a pointer
to that driver instance.

I thought aliases we're going to be used as a method to replace the
'fixup' files in the current DT RFC patches by matching device-tree node
names (<compataible-string>_<address>_<property>) to driver defines
(<foo>_<port_N>_<bar> or similar)

Is the latter wrong? Or is it a different alias entry in DT used for
Right now the device names are defined in the Kconfig options. The
device tree aims to replace that by determining that via the contents
of the device tree file. Not only the device name needs to be derived
but also the current information that is fixed up by the fixup file.

So from a Linux perspective, the alias is used by client programs to
determine the device node for specific things. A good example is
mapping of serial ports to make sure the console ends up on the right

In the zephyr use case, we don't care about client programs using the
compiled blob. And we don't want to conflict with DTS files that have
been imported from Linux and that need to work in both Zephyr and
Linux (STM has some examples coming of this). One way around this
collision is to follow the example of the zephyr entries in the
chosen{} node. Perhaps it would be better to define a zephyr node
that contains the zephyr specific mappings and the sram, flash, and
console entries.

That brings us to the device names themselves. I am of two minds on
this. On one hand, the names need to match the names on the board or
board documentation. It makes it difficult for users to have to
determine the zephyr name that matches the silkscreen name. On the
other hand, having all these different formats trigger my OCD. I feel
stronger about the silkscreen/documentation matching the names. So
place my vote in the chaos column.

As for matching device names to #defines to device tree data, I think
the solution for that lies in the YAML file itself. As part of the
config, we put in the device name we want and this is used to parse
the DT and get the right mapping. In addition this allows us to
generate whatever device specific prefix we need.



Join to automatically receive all group messages.