DTS metadata should be made available to Kconfig

[SebastianBoe]

Note that this is now one of the tasks listed in #8499.

The list of sub-tasks in this particular tasks, from my conversations (@SebastianBoe feel free to add others here):

• Modifying the CMake build system so that DT is processed before Kconfig
• Defining a template of Kconfig option that DT can generate so that Kconfig options can depend on. i.e. DT creates and enables CONFIG_HAS_HW_SPI and Kconfig depends on it for CONFIG_SPI
• Define and implement the interaction of DT with the build system in general
• Remove all references to Kconfig symbols from DTS

Original description:

How your SW is configured and what SW is available is dependent on what your HW looks like. It is not the other way around, that your board's HW description depends on what kind of SW you want.

Therefore we need to move DTS processing from after Kconfig to before Kconfig. This requires a lot of effort and will break all manner of things. But I believe it will result in a simpler and better integrated configuration system in the end.

A configuration architecture that this would enable (if we also start feeding DTS information into Kconfig somehow):

Use DTS to express what HW is present and feed this immutable information into Kconfig.
Use a (HW-support pruned) Kconfig tree to express that the user can enable and configure SW according to the immutable constraints of the HW.

The idea of feeding HW-information into Kconfig is not new. It is currently being done with BOARD and ARCH. This proposal simply extends the amount of HW information that is imported to take greater advantage of DTS information. When DTS information is only available after all SW configuration has completed it's usefulness in the configuration system is very minimal.

[carlescufi]

Tentatively added assignees in order to get feedback from them.

[ulfalizer]

There's an upcoming Kconfig feature (that I've had some input in) that might come in handy here.

It's a kind of simple preprocessor (that runs during parsing), where you can do stuff like this:

config FOO
        string
        default "$(shell some-cmd --foo --bar)"

After expansion, that would turn into e.g.

config FOO
        string
        default "output from some-cmd"

Things then work like they usually do. It turns out that things get super complex if you don't limit it to a simple preprocessor.

It would also support a "$(success some-cmd)" function for checking the exit status of some-cmd (which would expand to either "n" or "y"), and variables (think make variables).

I'm waiting for it to get added to the C tools before I add it to Kconfiglib. We've been arguing some details.

[SebastianBoe]

Is there an RFC or similair for this?

I'm not too worried about the mechanism for injecting DTS symbols into Kconfig. That seems trivial to me, the biggest effort is going to be porting DTS sources to not rely on Kconfig as it does today.

That effort is so large, that there must be broad agreement that this makes sense. If not we are just going to have to accept and work-around that Kconfig can not configure based on information in DTS.

Workarounds could include;

Keep information that we want Kconfig to have access to out of DTS sources (limit the scope of DTS).
Duplicate DTS information in Kconfig.
Generate DTS from Kconfig.

[erwango]

@SebastianBoe , can we consider shield case (#6837, even if not merged yet) in this discussion, where a Kconfig value that enable use of a particular shield (CONFIG_SHIELD_XXX=y) adds shield.overlay to board dts file ?

[SebastianBoe]

The shield use-case will not be possible as it is implemented today.

In the new architecture one would have to use another mechanism than Kconfig to attach shield description's to board descriptions.

[ulfalizer]

@SebastianBoe
See https://lkml.org/lkml/2018/5/17/97 for the latest version of the patchset that adds the preprocessor. It has a description too.

[SebastianBoe]

This issue re-appeared when @b0661 tried to use device tree data in #5799.

When device tree is placed after Kconfig everything becomes backwards.

Instead of using Device Tree to describe hardware, and Kconfig to configure SW we end up doing the opposite. E.g. an SoC might use KConfig to declare that SPI is supported CONFIG_SPI=y and an application might use a Device tree overlay to prune the SPI driver.

I'm not able to describe this properly, but I'm convinced that there is something seriously wrong with
the configuration system.

IMHO we need to figure out what we are doing (by resolving #7230) and then figure out what we want to do.

I suspect that we need to be more strict about what we put in DT. It is difficult to be sure, because it is difficult to understand what we are doing right now, but I suspect that if we use DeviceTree as a description language and Kconfig as a configuration language we will end up with a simpler
and more useful system than what we have now.

[erwango]

I suspect that we need to be more strict about what we put in DT

Device Tree proposes a specification to describe hardware and is used in variety of projects (https://www.devicetree.org/specifications/).
HW description should be SW agnostic and we should be able to work with dts files common with Linux for instance. So we should work with existing dts files and dts speficication.

This might appear as a constraint, but I think on the contrary that it will help providing clear and objective guidelines on what should be in DT and what should go in Kconfig.

[erwango]

In the new architecture one would have to use another mechanism than Kconfig to attach shield description's to board descriptions.

ok, as long as this remains doable.