Re: Inconsistent and ever-changing device naming in Zephyr


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

Join devel@lists.zephyrproject.org to automatically receive all group messages.