Re: Inconsistent and ever-changing device naming in Zephyr

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

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)

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.


Join to automatically receive all group messages.