Re: Inconsistent and ever-changing device naming in Zephyr

Andy Gross

On 10 February 2017 at 08:43, Paul Sokolovsky
<> wrote:
On Fri, 10 Feb 2017 11:47:02 +0000
"Jon Medhurst (Tixy)" <> 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).

Join to automatically receive all group messages.