Re: Inconsistent and ever-changing device naming in Zephyr


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

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