Topics

Inconsistent and ever-changing device naming in Zephyr


Paul Sokolovsky
 

Hello,

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:
https://github.com/01org/zephyr.js/issues/665

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.
https://github.com/01org/zephyr.js/issues/676

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
"I2C_SS_0".


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
be:

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).

Whether a) is a viable solution in turn depends on paradigmatic decision
what aim Zephyr is trying to achieve:

I. Is it a common platform, literally, an Operating System, providing
consistent means to develop software *across* various hardware?

II. Or is it loose collection of APIs of working with hardware, with
the aim of getting most (or something) of a particular hardware,
without pledging much for consistency and portability across hardware.


It would be nice to get opinions of both the core maintainers and the
maintainers of particular ports, as well as specific suggestions how to
deal with the bugs above.


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Daniel Thompson <daniel.thompson@...>
 

On 06/02/17 13:34, Paul Sokolovsky wrote:
Hello,

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:
https://github.com/01org/zephyr.js/issues/665

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.
https://github.com/01org/zephyr.js/issues/676

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
"I2C_SS_0".


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
be:

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?


Daniel.


Maureen Helm
 

Hi Paul,

-----Original Message-----
From: Paul Sokolovsky [mailto:paul.sokolovsky@linaro.org]
Sent: Monday, February 06, 2017 7:34 AM
To: devel@lists.zephyrproject.org; Anas Nashif <anas.nashif@intel.com>;
Maureen Helm <maureen.helm@nxp.com>; sakari.poussa@intel.com;
geoff@linux.intel.com; Daniel Thompson <daniel.thompson@linaro.org>
Subject: Inconsistent and ever-changing device naming in Zephyr

Hello,

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:
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
b.com%2F01org%2Fzephyr.js%2Fissues%2F665&data=01%7C01%7Cmaureen.h
elm%40nxp.com%7C8e842c85d2ec427bb45308d44e94e0a3%7C686ea1d3bc2b4c
6fa92cd99c5c301635%7C0&sdata=%2BNQJiBZZiZO0DCFSerir9SPSDmLKfvWSzhT
wUJ3dgpg%3D&reserved=0

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.
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
b.com%2F01org%2Fzephyr.js%2Fissues%2F676&data=01%7C01%7Cmaureen.h
elm%40nxp.com%7C8e842c85d2ec427bb45308d44e94e0a3%7C686ea1d3bc2b4c
6fa92cd99c5c301635%7C0&sdata=u3JpPzybvD%2FcVNSzWzrw%2BsgGBbZ1vGK
AEwoLvmzyaaw%3D&reserved=0

Investigating the issues, the causes of them are:

1. frdm_k64f GPIO port naming changed from "GPIO_0" to (!!) "gpio_porta".
This is my fault. I was not aware the port names were being used this way. I tend to use the config names rather than the strings themselves. For example, in boards/arm/frdm_k64f/Kconfig.defconfig:

config FXOS8700_GPIO_NAME
default GPIO_MCUX_PORTC_NAME

Please, please let me know if you encounter problems like this again.


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


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
be:

a) Establish (well, reconfirm/clarify) and uphold consistent naming conventions
across ports, architectures, and boards.
Since you're most affected, mind making a proposal?


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).

Whether a) is a viable solution in turn depends on paradigmatic decision what
aim Zephyr is trying to achieve:

I. Is it a common platform, literally, an Operating System, providing consistent
means to develop software *across* various hardware?

II. Or is it loose collection of APIs of working with hardware, with the aim of
getting most (or something) of a particular hardware, without pledging much
for consistency and portability across hardware.


It would be nice to get opinions of both the core maintainers and the
maintainers of particular ports, as well as specific suggestions how to deal with
the bugs above.


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs Follow Linaro:
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
facebook.com%2Fpages%2FLinaro&data=01%7C01%7Cmaureen.helm%40nxp.
com%7C8e842c85d2ec427bb45308d44e94e0a3%7C686ea1d3bc2b4c6fa92cd99c5
c301635%7C0&sdata=0U09i2dq9yMB0XQPrUBcduLolSF2e2zEo%2BqHtBALOg4%
3D&reserved=0
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitte
r.com%2F%23!%2Flinaroorg&data=01%7C01%7Cmaureen.helm%40nxp.com%7
C8e842c85d2ec427bb45308d44e94e0a3%7C686ea1d3bc2b4c6fa92cd99c5c30163
5%7C0&sdata=n3rYqztnrOOxdvjXOY4zWhaADesQAle3S%2B%2FU0bFWzOk%3
D&reserved=0 -
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.l
inaro.org%2Flinaro-
blog&data=01%7C01%7Cmaureen.helm%40nxp.com%7C8e842c85d2ec427bb45
308d44e94e0a3%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=YQ3UqYJ
oivu24eyW1pNviWSouVTwpQMvmo2LjcxvfwE%3D&reserved=0


Andy Gross
 

On 6 February 2017 at 10:59, Daniel Thompson <daniel.thompson@linaro.org> wrote:
On 06/02/17 13:34, Paul Sokolovsky wrote:

Hello,

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:
https://github.com/01org/zephyr.js/issues/665

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.
https://github.com/01org/zephyr.js/issues/676

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
"I2C_SS_0".


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
be:

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
Linux.

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.


Paul Sokolovsky
 

Hello Daniel,

On Mon, 6 Feb 2017 16:59:26 +0000
Daniel Thompson <daniel.thompson@linaro.org> wrote:

[]

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?
I'm not familiar enough with devicetree details to imagine how exactly
that would be done, but Andy's response confirms it's possible to do
something along those ways. But as far as I can see, that still would
depend on establishing common conventions for naming. Perhaps, doing it
via DT would allow to achieve consistency easier, and verify/maintain
it.

But the current question is whether consistency is desirable at all,
i.e. would maintainers of individual SoCs agree each making some
changes to their code/config, and Zephyr maintainers agree to
uphold it afterwards. Given that DT has yet some way to go widely in
Zephyr, discussion or at least consideration of this "consistent
naming" idea might start in parallel.


Daniel.
Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Jon Medhurst (Tixy) <tixy@...>
 

On Wed, 2017-02-08 at 11:31 -0600, Andy Gross wrote:
On 6 February 2017 at 10:59, Daniel Thompson <daniel.thompson@linaro.org> wrote:
On 06/02/17 13:34, Paul Sokolovsky wrote:

Hello,

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:
https://github.com/01org/zephyr.js/issues/665

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.
https://github.com/01org/zephyr.js/issues/676

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
"I2C_SS_0".


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
be:

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
Linux.

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
that?

--
Tixy


Daniel Thompson <daniel.thompson@...>
 

On 08/02/17 20:39, Paul Sokolovsky wrote:
Hello Daniel,

On Mon, 6 Feb 2017 16:59:26 +0000
Daniel Thompson <daniel.thompson@linaro.org> wrote:

[]

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?
I'm not familiar enough with devicetree details to imagine how exactly
that would be done, but Andy's response confirms it's possible to do
something along those ways. But as far as I can see, that still would
depend on establishing common conventions for naming. Perhaps, doing it
via DT would allow to achieve consistency easier, and verify/maintain
it.

But the current question is whether consistency is desirable at all,
i.e. would maintainers of individual SoCs agree each making some
changes to their code/config, and Zephyr maintainers agree to
uphold it afterwards. Given that DT has yet some way to go widely in
Zephyr, discussion or at least consideration of this "consistent
naming" idea might start in parallel.
Personally I'm not a fan of gratuitously different naming (for example different driver writers arbitrarily selecting ALLCAPS and lowercase). However I *am* a fan of selecting labels from "facts" about the board (silk screening, datasheet port/connector names, etc).

As a trivial example I'd really dislike a system where "for consistency" we force BSPs to call something "UART-0" when the silkscreen (or front-panel) says "DB9-1".

I guess that is an argument *against* board-to-board consistency!


Daniel.


Erwan Gouriou
 

Hi Paul, 


But the current question is whether consistency is desirable at all,
i.e. would maintainers of individual SoCs agree each making some
changes to their code/config, and Zephyr maintainers agree to
uphold it afterwards. Given that DT has yet some way to go widely in
Zephyr, discussion or at least consideration of this "consistent
naming" idea might start in parallel.


For STM32, my view is as follows:
I understand the concern and need for having naming consistency,
thought, I'm concerned about different instances numbering.
Some starts from 0, some starts from 1:
UART_1 in ref manual being referenced as UART_2  in Zephyr 
could be source of error.

At least keeping numbering (or "lettering" for A/B/C) consistent from
board/manual to API is required from my point of view.
Then I'm ok if there is a naming convention "UART_x" accross vendors.

Erwan


Chuck Jordan <Chuck.Jordan@...>
 

Personally I'm not a fan of gratuitously different naming (for example different driver writers arbitrarily selecting ALLCAPS and lowercase).
However I *am* a fan of selecting labels from "facts" about the board (silk screening, datasheet port/connector names, etc).
As a trivial example I'd really dislike a system where "for consistency"
we force BSPs to call something "UART-0" when the silkscreen (or
front-panel) says "DB9-1".
I guess that is an argument *against* board-to-board consistency!
[chuck] Minor point, but the device driver talks to a UART and the UART may have a different designation on the schematic, not visible to the outside user.
A name like "DB9-1" is a physical connector name, and it can be unclear which UART is attached to it, which jumpers need to be changed, whether there is another layer of switching between UART and connector and so forth. I've seen boards where a UART can be directed to one of many different connectors via jumper choices. So opening "DB9-1" might fail if the jumpers are wrong, for example. Driver is for UART only ... not the physical wiring beyond the UART.


Andy Gross
 

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

Hello,

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:
https://github.com/01org/zephyr.js/issues/665

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.
https://github.com/01org/zephyr.js/issues/676

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
"I2C_SS_0".


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
be:

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
Linux.

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
that?
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
device.

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.

Regards,

Andy


Jon Medhurst (Tixy) <tixy@...>
 

On Thu, 2017-02-09 at 22:56 -0600, Andy Gross wrote:
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.
Hmm, my concern was about having to have per-board or per-soc yaml files
(which I think is a wrong step) e.g. to have to do mappings from say
FOO_UART_<REG_ADDRESS> to FOO_UART_0, FOO_UART_1 etc. Seems to me that
DT parser can be smart and sort things by <REG_ADDRESS> and assign them
instance numbers 0..N.

Also, if Zephyr device drivers are changed to use macro prefixes that
match device-tree compatibles, there is also no need for any driver
specific name mangling either.

E.g. if device-tree has:

uart@12340000 {
compatible = "foo,bar-uart";
reg = 0x12340000;

initerrupts = <11>, <12>;
initerrupt-names = "rx", "tx";
}

the DT parser outputs generated header with defines like:

#define FOO_BAR_UART_0 /* So we can easily test it exists */
#define FOO_BAR_UART_0_BASE_ADDRESS 0x12340000
#define FOO_BAR_UART_0_INTERRUPT_RX 11
#define FOO_BAR_UART_0_INTERRUPT_TX 12

Then current device drivers can just change the macro names it uses to
match that. And, for a transitional arrangement if there are still non-
DT users of the driver needing the Kconfig way, the driver can

#if !defined(FOO_BAR_UART_0_VALUE) && defined(CONFIG_FOOBAR_VALUE)
#define FOO_BAR_UART_0_VALUE CONFIG_FOOBAR_VALUE
#endif

Basically, I can see that device-driver specific config (e.g. the yaml
files) are going to be needed to specify things like Kconfig options
required to enable a driver, and for constructing data structures needed
for its initialisation (replacing the current #define/#ifdef/Kconfig
mess) but I don't see it as a good step if we _add_ to the the current
problem in the intermediate stages. E.g. by adding any per board or soc
yaml config or 'fixup' files.

--
Tixy


Daniel Thompson <daniel.thompson@...>
 

On 09/02/17 19:27, Chuck Jordan wrote:

Personally I'm not a fan of gratuitously different naming (for example different driver writers arbitrarily selecting ALLCAPS and lowercase).
However I *am* a fan of selecting labels from "facts" about the board (silk screening, datasheet port/connector names, etc).
As a trivial example I'd really dislike a system where "for consistency"
we force BSPs to call something "UART-0" when the silkscreen (or
front-panel) says "DB9-1".
I guess that is an argument *against* board-to-board consistency!
[chuck] Minor point, but the device driver talks to a UART and the
UART may have a different designation on the schematic, not visible
to the outside user. A name like "DB9-1" is a physical connector
name, and it can be unclear which UART is attached to it, which
jumpers need to be changed, whether there is another layer of
switching between UART and connector and so forth. I've seen boards
where a UART can be directed to one of many different connectors via
jumper choices.
Quite so, board designers have so many different ways they can make serial ports harder than necessary to use.

In fact that's *exactly* why peripheral naming needs ultimately should be a per-board decision in the BSP (possibly expressed via DT). Note that this does *not* mean that SoC-wide defaults are bad. SoC-wide defaults are great and simplify things for uses of sane or simple board designs.


So opening "DB9-1" might fail if the jumpers are
wrong, for example. Driver is for UART only ... not the physical
wiring beyond the UART.
Boards like this are rare and the BSP still has the option to call it whatever is neccessary to disambiguate.


Daniel.


Paul Sokolovsky
 

Hello Maureen,

On Tue, 7 Feb 2017 21:45:24 +0000
Maureen Helm <maureen.helm@nxp.com> wrote:

[]

1. frdm_k64f GPIO port naming changed from "GPIO_0" to (!!)
"gpio_porta".
This is my fault. I was not aware the port names were being used this
way. I tend to use the config names rather than the strings
themselves. For example, in boards/arm/frdm_k64f/Kconfig.defconfig:

config FXOS8700_GPIO_NAME
default GPIO_MCUX_PORTC_NAME

Please, please let me know if you encounter problems like this again.
Thanks for understanding of these issues.

[]
The question what to do about this. Possible high-level approaches
can be:

a) Establish (well, reconfirm/clarify) and uphold consistent naming
conventions across ports, architectures, and boards.
Since you're most affected, mind making a proposal?
Ok, let me also start with facts (in preference of starting with my own
opinion).

1. So, mentioned previously Zephyr.js project has code like this:
https://github.com/01org/zephyr.js/blob/master/src/zjs_gpio.c#L459 . In
other words, Zephyr.js expects GPIO_0, GPIO_1, GPIO_2, etc. It used to
be a fatal error if any device could not be opened. Couple of months
ago I contributed a patch which makes it a non-fatal condition, at at
the same time argued that it wouldn't scale for Zephyr.js to use such
naming and make other assumptions, like the # of ports available, etc.

2. Let's see how GPIO devices are named across various ports in 1.6.0
(I take that version as having old naming for Kinetis ports). (The list
is made using manual filtering of grep -i -r '"GPIO' results):

The config params for naming is also split between:

arch/ :

arc/soc/em9d/Kconfig.defconfig: default "GPIO_PORTA"
arc/soc/em11d/Kconfig.defconfig: default "GPIO_PORTB"
arc/soc/em7d/Kconfig.defconfig: default "GPIO_PORTC"
x86/soc/intel_quark/quark_x1000/Kconfig.defconfig.series: default "GPIO_CW"
x86/soc/intel_quark/quark_x1000/Kconfig.defconfig.series: default "GPIO_RW"
x86/soc/intel_quark/quark_x1000/Kconfig.defconfig.series: default "GPIO_0"

and drivers/gpio/:

gpio_stm32.c:GPIO_DEVICE_INIT("GPIOA", a, GPIOA_BASE, STM32_PORTA,
Kconfig.cmsdk_ahb: default "GPIO_0"
Kconfig.dw: default "GPIO_0"
Kconfig.k64: default "GPIO_0"
Kconfig.nrf5: default "GPIO_0"
Kconfig.pcal9535a: default "GPIO_P0"
Kconfig.qmsi: default "GPIO_0"
Kconfig.qmsi: default "GPIO_SS_1"
Kconfig.sch: default "GPIO_0"

So, from this listing it's clear that simplistic "use numbers for
identification, start from 0", as assumed by the Z.js code above,
wouldn't be achievable. One basic reason is given by Erwan Gouriou in
his response - if a vendor datasheet names devices (not necessarily GPIO
ports) from 1, and not 0, then it would be hard time to argue that
Zephyr should still count from 0, as indeed, that would be recurring
confusion point.

That would mean that point "b) Send a strong message to application
developers that they should not rely on any patterns of Zephyr device
naming" would be there no matter what.

Does that mean that there should not be any convention to Zephyr device
naming? Just as other participants in the discussion, I think it's
better to have them, because lack of conventions and directions may
mean that there would be "random" changes, as in case of Kinetis/MCUX
port name change discussed above.

Looking at the grep results above, I'd formulate guidelines as:

1. Devices of similar type should have consistent prefix, e.g. "GPIO_",
"I2C_", etc.
2. Device name should be uppercase.
3. Underscores should be used as separators.
4. Device type prefix should be separated by an underscore too (all
devicenames above follow that, except stm32 with "GPIOA", "GPIOB", etc.)
5. Device names should be short and avoid having superfluous parts.
E.g., it's a basic GPIO hardware fact that GPIO ping go packed in
ports. So, "GPIO_PORTA" is way too verbose and doesn't convey much
useful information in its "PORT" part.

Examples of good names: GPIO_0, GPIO_99, GPIO_A, GPIO_AA (27th port),
GPIO_SS_0 (as used by multicore-core Quark SoC above to differentiate
ports on different cores, hard to argue they shouldn't be doing that,
though I have no idea what "SS" means).

Examples of bad names: GPIOA (missing underscore), GPIO_PORTA (too
verbose, "PORT" is superfluous), GPIO_P0 ("P" apparently means port,
superfluous), gpio_1 (should be upper case), PIN_1 (even if it happens
to be 1 pin on a port, follow the standard prefix), GPO_1 (even if
it's output-only port/pin, follow the standard prefix).


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).
[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Paul Sokolovsky
 

Hello Daniel,

On Fri, 10 Feb 2017 11:54:27 +0000
Daniel Thompson <daniel.thompson@linaro.org> wrote:

On 09/02/17 19:27, Chuck Jordan wrote:

Personally I'm not a fan of gratuitously different naming (for
example different driver writers arbitrarily selecting ALLCAPS and
lowercase). However I *am* a fan of selecting labels from "facts"
about the board (silk screening, datasheet port/connector names,
etc).
As a trivial example I'd really dislike a system where "for
consistency" we force BSPs to call something "UART-0" when the
silkscreen (or front-panel) says "DB9-1".
I guess that is an argument *against* board-to-board consistency!
[chuck] Minor point, but the device driver talks to a UART and the
UART may have a different designation on the schematic, not visible
to the outside user. A name like "DB9-1" is a physical connector
name, and it can be unclear which UART is attached to it, which
jumpers need to be changed, whether there is another layer of
switching between UART and connector and so forth. I've seen boards
where a UART can be directed to one of many different connectors via
jumper choices.
Quite so, board designers have so many different ways they can make
serial ports harder than necessary to use.

In fact that's *exactly* why peripheral naming needs ultimately
should be a per-board decision in the BSP (possibly expressed via
DT). Note that this does *not* mean that SoC-wide defaults are bad.
SoC-wide defaults are great and simplify things for uses of sane or
simple board designs.
To clarify, the concern behind my original mail is exactly regarding
having a good consistent scheme for "SoC-wide defaults". Across SoCs of
course, and with an idea that "reference" boards for these SoCs (as
available in Zephyr upstream) would follow them.

With a usecase you present above - support for widely varying OEM
boards, I agree that it should be possible to override "anything", and
the only scalable way to do that appears to be the Device Tree.

(I would argue whether each and every OEM should override too much for
a particular board, and if many actually would do that, but that's
not the point of the discussion, it instead being that Zephyr should
provide flexibility to do so, while hopefully also giving good
guidelines on suggested naming, and provide in-tree device ports which
adhere to these guidelines).

[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Paul Sokolovsky
 

Hello Andy,

On Thu, 9 Feb 2017 22:56:40 -0600
Andy Gross <andy.gross@linaro.org> wrote:

[]

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.
Well, there're dozens of architectures in the world. Thousands of
individual SoC/MCU models using them, and millions of individual board
models using those SoCs. Generally, no OS can support this
million-variety upstream, and even if it gives *perfect* and the
*easiest* to use tools for that downstream, a lot of vendors behind
those millions of boards still won't use them right or at all
(projections roughly based on the Linux experience).

So, the talk is that "SoC" level should be the primary, and naming for
one SoC should be reasonably consistent with all the rest. Than a board
OEM can save a bunch of trouble both themselves and their users by just
naming their board signals what the SoC calls them - or go thru the
trouble of overriding them on OS, etc. levels, documenting how their
virtual signals map to real SoC's, etc.

[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Paul Sokolovsky
 

On Fri, 10 Feb 2017 11:47:02 +0000
"Jon Medhurst (Tixy)" <tixy@linaro.org> wrote:

On Thu, 2017-02-09 at 22:56 -0600, Andy Gross wrote:
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.
Hmm, my concern was about having to have per-board or per-soc yaml
files (which I think is a wrong step) e.g. to have to do mappings
from say FOO_UART_<REG_ADDRESS> to FOO_UART_0, FOO_UART_1 etc. Seems
to me that DT parser can be smart and sort things by <REG_ADDRESS>
and assign them instance numbers 0..N.
I understand this discusses details of DT bindings and processing, but
for my own and other folks' understanding, I'd like to point that for a
device name (as in: the string you pass to device_get_binding()
indeed), any automatic means of derivation e.g. based on base address
won't work. That's because ultimately these names should match a
datasheet (I guess it would be hard to find someone who'd challenge
that), and those means of identification are vendor-specific and look
arbitrary for the reset of the world.

For example, UART1's base address doesn't have to be greater than
UART0's. Examples of identification starting from 1 and using other
sequences (e.g. letters) were given before. And there can be arbitrary
gaps, e.g. a specific SoC may have Timers: 3, 4, and 7 (ditto for GPIO
ports, ditto for anything).

[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Jon Medhurst (Tixy) <tixy@...>
 

On Fri, 2017-02-10 at 17:43 +0300, Paul Sokolovsky wrote:
Hmm, my concern was about having to have per-board or per-soc yaml
files (which I think is a wrong step) e.g. to have to do mappings
from say FOO_UART_<REG_ADDRESS> to FOO_UART_0, FOO_UART_1 etc. Seems
to me that DT parser can be smart and sort things by <REG_ADDRESS>
and assign them instance numbers 0..N.
I understand this discusses details of DT bindings and processing, but
for my own and other folks' understanding, I'd like to point that for a
device name (as in: the string you pass to device_get_binding()
indeed), any automatic means of derivation e.g. based on base address
won't work.
Yes, I agree with that. That's why I original asked about which 'name'
aliases in DT we're being used for, a) the name you pass to
device_get_binding, or b) the name used in C macro name inside the
device implementation, or, I guess c) both, if you have different
aliases to do that.

a) makes sense and what this email thread seems to agree on, but b) was
what was hinted at when I asked about avoiding the need for the current
fixup file workaround in the RFC patchset. So I was trying to get some
clarity. (Guess that means I sorta hijacked the thread, sorry)

--
Tixy


Paul Sokolovsky
 

On Fri, 10 Feb 2017 15:08:29 +0000
"Jon Medhurst (Tixy)" <tixy@linaro.org> wrote:

On Fri, 2017-02-10 at 17:43 +0300, Paul Sokolovsky wrote:
Hmm, my concern was about having to have per-board or per-soc yaml
files (which I think is a wrong step) e.g. to have to do mappings
from say FOO_UART_<REG_ADDRESS> to FOO_UART_0, FOO_UART_1 etc.
Seems to me that DT parser can be smart and sort things by
<REG_ADDRESS> and assign them instance numbers 0..N.
I understand this discusses details of DT bindings and processing,
but for my own and other folks' understanding, I'd like to point
that for a device name (as in: the string you pass to
device_get_binding() indeed), any automatic means of derivation
e.g. based on base address won't work.
Yes, I agree with that. That's why I original asked about which 'name'
aliases in DT we're being used for, a) the name you pass to
device_get_binding, or b) the name used in C macro name inside the
device implementation, or, I guess c) both, if you have different
aliases to do that.

a) makes sense and what this email thread seems to agree on, but b)
was what was hinted at when I asked about avoiding the need for the
current fixup file workaround in the RFC patchset. So I was trying to
get some clarity. (Guess that means I sorta hijacked the thread,
sorry)
Nope, I really appreciate different people approaching this from
different sides, and considering the usecases and details they have in
mind. Well, I myself raised it with just one case in mind: how Zephyr
middleware like Zephyr.js, MicroPython, etc. can deal with that, but
of course there're more facets to it. And I don't hold my breath
for an immediate solution, but starting to search for a common ground
is definitely useful.


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Andy Gross
 

On 10 February 2017 at 08:43, Paul Sokolovsky
<paul.sokolovsky@linaro.org> wrote:
On Fri, 10 Feb 2017 11:47:02 +0000
"Jon Medhurst (Tixy)" <tixy@linaro.org> wrote:

On Thu, 2017-02-09 at 22:56 -0600, Andy Gross wrote:
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.
Hmm, my concern was about having to have per-board or per-soc yaml
files (which I think is a wrong step) e.g. to have to do mappings
from say FOO_UART_<REG_ADDRESS> to FOO_UART_0, FOO_UART_1 etc. Seems
to me that DT parser can be smart and sort things by <REG_ADDRESS>
and assign them instance numbers 0..N.
SoC uart mappings are one thing. Board uart mappings are another.
SoC uart mappings are merely assigning an index to a base address and
then generating the label based on some prefix. The yaml is just
about how to parse and build up the labels for the contents of the DT.
The DT needs to specify what the board uart mappings are and you will
have a per board DT file which includes a SoC file. And with a DT
overlay, we can then support application layer changes which today are
done in the prj files.


I understand this discusses details of DT bindings and processing, but
for my own and other folks' understanding, I'd like to point that for a
device name (as in: the string you pass to device_get_binding()
indeed), any automatic means of derivation e.g. based on base address
won't work. That's because ultimately these names should match a
datasheet (I guess it would be hard to find someone who'd challenge
that), and those means of identification are vendor-specific and look
arbitrary for the reset of the world.
The thing is, there is the datasheet and there is the board. From a
end user perspective, the only thing that matters is the board's
labeling. Board uart 0 may be SoC uart 3. And they did that because
they couldn't use uart0 because the rx/tx pins for that were being
used for something else.

And, the base address can't really be used to derive index because
there are plenty of vendors who don't to ordered addresses on nodes,
or they skip around.

On top of that, what if you have more than one unique UART IP on the
board? Which is uart0 then?

For example, UART1's base address doesn't have to be greater than
UART0's. Examples of identification starting from 1 and using other
sequences (e.g. letters) were given before. And there can be arbitrary
gaps, e.g. a specific SoC may have Timers: 3, 4, and 7 (ditto for GPIO
ports, ditto for anything).
Exactly.


Chuck Jordan <Chuck.Jordan@...>
 

Actually, I'm leaning toward the opinion that the names of the I/O shouldn't matter.
But what does matter, are the properties associated with that object.

Take GPIO, for example. Some GPIO implementation may support special capabilities like debounce and interrupts.
Other GPIO may not.
So given a NAME of an instance, you would want some means of fetching the "gestalt" (old Apple term) for that object.
Each named I/O instance, register with the I/O subsystem, probably needs to have "key-value" pairs that convey things about the instance.
You would also need to be able to iterate over I/O instances, and FILTER thru them to find ones that have the capabilities you're looking for. For example, you might want to search all I/O that are both GPIO, have DEBOUNCE and have INTERRUPT capability.
Or, suppose you want to search thru all I/O that is UART, and can support baud rates greater than 115200.
Or to search for a file-system capable mass storage device that has free space greater than 1MB.
The I/O abstraction layer should provide these details.

This allows the application developer, once they've figured out what name to use during an OPEN, to also check, via ioctl or some such, that their I/O is capable of supporting what they are after.
So the problem is not just knowing the name, its also knowing whether that named instance has the right-stuff.

-ChuckJ

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Paul Sokolovsky
Sent: Friday, February 10, 2017 4:31 AM
To: Maureen Helm <maureen.helm@nxp.com>
Cc: devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Inconsistent and ever-changing device naming in Zephyr

Hello Maureen,

On Tue, 7 Feb 2017 21:45:24 +0000
Maureen Helm <maureen.helm@nxp.com> wrote:

[]

1. frdm_k64f GPIO port naming changed from "GPIO_0" to (!!)
"gpio_porta".
This is my fault. I was not aware the port names were being used this
way. I tend to use the config names rather than the strings
themselves. For example, in boards/arm/frdm_k64f/Kconfig.defconfig:

config FXOS8700_GPIO_NAME
default GPIO_MCUX_PORTC_NAME

Please, please let me know if you encounter problems like this again.
Thanks for understanding of these issues.

[]
The question what to do about this. Possible high-level approaches
can be:

a) Establish (well, reconfirm/clarify) and uphold consistent naming
conventions across ports, architectures, and boards.
Since you're most affected, mind making a proposal?
Ok, let me also start with facts (in preference of starting with my own opinion).

1. So, mentioned previously Zephyr.js project has code like this:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_01org_zephyr.js_blob_master_src_zjs-5Fgpio.c-23L459&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=Ur8eT0ZY1DOjJtZ8biKXp_CyOvecmZtsphp7SXIsE1Y&m=Gw9v9P4sBeBQB2qCQBmDvQccbUBgnraP5ao9FIaBh98&s=EcdSrQuy87WyLUQVduyfZhZloOcN8_WXoy128Vjhbjo&e= . In other words, Zephyr.js expects GPIO_0, GPIO_1, GPIO_2, etc. It used to be a fatal error if any device could not be opened. Couple of months ago I contributed a patch which makes it a non-fatal condition, at at the same time argued that it wouldn't scale for Zephyr.js to use such naming and make other assumptions, like the # of ports available, etc.

2. Let's see how GPIO devices are named across various ports in 1.6.0 (I take that version as having old naming for Kinetis ports). (The list is made using manual filtering of grep -i -r '"GPIO' results):

The config params for naming is also split between:

arch/ :

arc/soc/em9d/Kconfig.defconfig: default "GPIO_PORTA"
arc/soc/em11d/Kconfig.defconfig: default "GPIO_PORTB"
arc/soc/em7d/Kconfig.defconfig: default "GPIO_PORTC"
x86/soc/intel_quark/quark_x1000/Kconfig.defconfig.series: default "GPIO_CW"
x86/soc/intel_quark/quark_x1000/Kconfig.defconfig.series: default "GPIO_RW"
x86/soc/intel_quark/quark_x1000/Kconfig.defconfig.series: default "GPIO_0"

and drivers/gpio/:

gpio_stm32.c:GPIO_DEVICE_INIT("GPIOA", a, GPIOA_BASE, STM32_PORTA,
Kconfig.cmsdk_ahb: default "GPIO_0"
Kconfig.dw: default "GPIO_0"
Kconfig.k64: default "GPIO_0"
Kconfig.nrf5: default "GPIO_0"
Kconfig.pcal9535a: default "GPIO_P0"
Kconfig.qmsi: default "GPIO_0"
Kconfig.qmsi: default "GPIO_SS_1"
Kconfig.sch: default "GPIO_0"

So, from this listing it's clear that simplistic "use numbers for identification, start from 0", as assumed by the Z.js code above, wouldn't be achievable. One basic reason is given by Erwan Gouriou in his response - if a vendor datasheet names devices (not necessarily GPIO
ports) from 1, and not 0, then it would be hard time to argue that Zephyr should still count from 0, as indeed, that would be recurring confusion point.

That would mean that point "b) Send a strong message to application developers that they should not rely on any patterns of Zephyr device naming" would be there no matter what.

Does that mean that there should not be any convention to Zephyr device naming? Just as other participants in the discussion, I think it's better to have them, because lack of conventions and directions may mean that there would be "random" changes, as in case of Kinetis/MCUX port name change discussed above.

Looking at the grep results above, I'd formulate guidelines as:

1. Devices of similar type should have consistent prefix, e.g. "GPIO_", "I2C_", etc.
2. Device name should be uppercase.
3. Underscores should be used as separators.
4. Device type prefix should be separated by an underscore too (all devicenames above follow that, except stm32 with "GPIOA", "GPIOB", etc.) 5. Device names should be short and avoid having superfluous parts.
E.g., it's a basic GPIO hardware fact that GPIO ping go packed in ports. So, "GPIO_PORTA" is way too verbose and doesn't convey much useful information in its "PORT" part.

Examples of good names: GPIO_0, GPIO_99, GPIO_A, GPIO_AA (27th port),
GPIO_SS_0 (as used by multicore-core Quark SoC above to differentiate ports on different cores, hard to argue they shouldn't be doing that, though I have no idea what "SS" means).

Examples of bad names: GPIOA (missing underscore), GPIO_PORTA (too verbose, "PORT" is superfluous), GPIO_P0 ("P" apparently means port, superfluous), gpio_1 (should be upper case), PIN_1 (even if it happens to be 1 pin on a port, follow the standard prefix), GPO_1 (even if it's output-only port/pin, follow the standard prefix).


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).
[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs Follow Linaro: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.facebook.com_pages_Linaro&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=Ur8eT0ZY1DOjJtZ8biKXp_CyOvecmZtsphp7SXIsE1Y&m=Gw9v9P4sBeBQB2qCQBmDvQccbUBgnraP5ao9FIaBh98&s=ZKgYBpmkadgt4k-GWgxk0qpEr54xDeQDKSf-91I0unU&e=
https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_-23-21_linaroorg&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=Ur8eT0ZY1DOjJtZ8biKXp_CyOvecmZtsphp7SXIsE1Y&m=Gw9v9P4sBeBQB2qCQBmDvQccbUBgnraP5ao9FIaBh98&s=pO_5cWLMg5XInmbA0OiEkBQSYK6IbxbX9-lnHVlwirA&e= - https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linaro.org_linaro-2Dblog&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=Ur8eT0ZY1DOjJtZ8biKXp_CyOvecmZtsphp7SXIsE1Y&m=Gw9v9P4sBeBQB2qCQBmDvQccbUBgnraP5ao9FIaBh98&s=CAFTnOsX1RZEqPKcLxbzK6nNCHo37S76ZsuUf6UNfqk&e=
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.zephyrproject.org_mailman_listinfo_zephyr-2Ddevel&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=Ur8eT0ZY1DOjJtZ8biKXp_CyOvecmZtsphp7SXIsE1Y&m=Gw9v9P4sBeBQB2qCQBmDvQccbUBgnraP5ao9FIaBh98&s=NICXw6qnd35aaKp2WfCFJND4zLjD53CZSxNLBk8sOkI&e=