DTS should use (one or more) prefixes on all defines

[SebastianBoe]

Kconfig and DTS are inconsistent in their naming convention. In Kconfig all defines are prefixed with CONFIG_. In DTS it is a mix of CONFIG_ and no prefix. Unless there is a good reason for DTS to generate macros without the CONFIG_ prefix we should start enforcing that DTS limits itself to CONFIG_.

Consistently prefixing with CONFIG_ effectively creates a namespace
and that is important for two reasons:

It reduces the likelihood of encountering aliasing issues with application code
if we can have a simple rule like:

"Preprocessor macros prefixed with CONFIG_ are reserved by the configuration system (DTS+Kconfig)."

It also makes it more predictable to a user where macros come from and therefore makes it easier to read the code, e.g. if he sees a macro:

FLASH_NRF_FLASH_WRITE_BLOCK_SIZE

vs.

CONFIG_FLASH_NRF_FLASH_WRITE_BLOCK_SIZE

[erwango]

@SebastianBoe , do you mean that everything which is generated from dts should use CONFIG_ name space?
Such as NORDIC_NRF5_I2C_40003000_LABEL would be CONFIG_NORDIC_NRF5_I2C_40003000_LABEL ?

[SebastianBoe]

Yes. Specifically everything in generated_dts_board.h.

[erwango]

Not sure to agree in that case.

Having dts generated bit and Kcong using same namespace would create confusion as we're not able anymore to say if this should be configured from Kcong or from dts.
Also I find it would be confusing to see, in .fixup files (even if we should eventually get rid of those):
#define CONFIG_UART_STM32_PORT_1_NAME CONFIG_ST_STM32_USART_40013800_LABEL

Besides, eveything dts generated is not available from Kconfig anymore. So these are different set of preprocessor macros. Eventually we should have a DTS_ namespace.

Last point, having no name space today allows for direct generation of aliases (cf #6979), and hence to get rid of bindings (such as .fixup). Having namespace for generated bits would enforce the need for bindings files. If required, we can live with it, but it's nice to live w/o it.

[SebastianBoe]

Having dts generated bit and Kcong using same namespace would create confusion as we're not able anymore to say if this should be configured from Kcong or from dts.

Not sure how that is better than today's situation, today there is a mix of CONFIG_ and non-CONFIG_ in DTS so you are not able to predict this now either.

Also I find it would be confusing to see, in .fixup files (even if we should eventually get rid of those):
#define CONFIG_UART_STM32_PORT_1_NAME CONFIG_ST_STM32_USART_40013800_LABEL

Could you elaborate on what is confusing?

Besides, eveything dts generated is not available from Kconfig anymore. So these are different set of preprocessor macros.

Correct, they are not available at the same time. But IMHO they should be available simultaneously as explained in issue #7214 .

Eventually we should have a DTS_ namespace.

I don't see the need for the configuration system to use a separate namespace for DTS_, but that would at least be better than todays situation.

[0] #7214

[erwango]

I don't see the need for the configuration system to use a separate namespace for DTS_, but that would at least be better than todays situation.

If one of the motivation is to ease identification by the user of where a configuration comes from, I think a dedicated name space makes sense.

@galak , any idea?

[b0661]

The meaning of CONFIG must be clear and unambiguous to the user. It shall also be clear who is the user.

In my view the

• user is the application developer (vs. driver/ kernel developer) and
• the meaning of CONFIG is "the application developer does have a choice".

Within this semantic system FLASH_NRF_FLASH_WRITE_BLOCK_SIZE should be FLASH_NRF_FLASH_WRITE_BLOCK_SIZE or DTS_FLASH_NRF_FLASH_WRITE_BLOCK_SIZE as there is most probably no choice (write block size is a property of the HW and not dependent on or controllable by the application).

[SebastianBoe]

@b0661 , are you proposing prefixing DTS defines with DTS_ or on a case-by-case basis either prefixing DTS defines with DTS_ or CONFIG_ depending on whether they should be application-controllable or not?

Technically everything in DTS is (and needs to be) controllable-by-application (unless we start limiting DTS to describe HW). Practically however it is not obvious what values are controllable and which are not. Some defines that one would assume were non-controllable, such as flash size, are commonly (unfortunately) overridden by application's to make space for their own modules.

[b0661]

@SebastianBoe, I think before investing the effort of re-organizing and prefixing a value by CONFIG (or any other "class" prefix) the meaning of such a prefix and the usage shall be clear and finally also documented.

At the moment the meaning of CONFIG is unclear. Mostly it may be "configuration variable created by kconfig" , but also others are using the CONFIG prefix. The perspective is tool oriented and not usage oriented. This may be fuilly acceptable if the goal is to identify the tool that created the configuration variable. This is also the most easy convention to impose. Another meaning, of CONFIG that I think you proposed is "this is a configuration variable of Zephyr" where you can combine DTS and kconfig.

My proposal is to look from the application developer view on Zephyr. I did a choice by kconfig and dts. CONFIG_xx documents my choice. Based on the CONFIG_xx defines I can adapt my application. The primary user of the CONFIG_xx defines is the application (kernel/ drivers still aso have to adhere to it).

Technically everything in DTS is (and needs to be) controllable-by-application (unless we start limiting DTS to describe HW).

I agree technically an application can alter everything in a DTS. To be more precise CONFIG should be used for the properties that are foreseen to be altered by the application - e.g.:

• activation of a driver (status)
  This is implicit as defines are only generated if status="ok".
• default clock selection/ enable/ divider/ multiplier ( assigned-clocks, assigned-clock-parents, assigned-clock-rates)
• default pin selection/ mux/ control (pinctrl-x with pinctrl-name(x) = "default")
• label (for this I´m not really convinced)

are you proposing prefixing DTS defines with DTS_ or on a case-by-case basis either prefixing DTS defines with DTS_ or CONFIG_ depending on whether they should be application-controllable or not?

To follow the "CONFIG_xx documents the application developwer choice" the CONFIG_xx defines may just be aliases. This way the defines generation for DTS can be kept uniform. The answer to your question is "both" !-). DTS is for driver/kernel developers to make clear where the define is coming from. The CONFIG aliases are for the application developer.

Some defines that one would assume were non-controllable, such as flash size, are commonly (unfortunately) overridden by application's to make space for their own modules.

Such defines should be split up in a total flash size (which is an inherent property of the HW) and one CONFIG_xx define for the flash space an application want´s to allocate. This might even help to detect allocation problems more clearly.

[SebastianBoe]

To follow the "CONFIG_xx documents the application developwer choice" the CONFIG_xx defines may just be aliases. This way the defines generation for DTS can be kept uniform. The answer to your question is "both" !-). DTS is for driver/kernel developers to make clear where the define is coming from. The CONFIG aliases are for the application developer.

This system would satisfy the main problem that this issue was trying to address, will re-write this issue to not include a solution, but just a problem description.

The complexity of this all annoys me though. I wonder if it would be possible to simplify the configuration system such that DTS_ is inherently not an application developer choice and CONFIG_ is. E.g. by limiting DTS_ to describe HW and not configure HW.