Hi Martin,
On 08.11.23 20:21, Martin Roth via coreboot wrote:
We are again considering running the devicetree.cb files through the C preprocessor before they're used by sconfig to generate the static configuration structures. This suggestion came up due to the desire to be able to have some control of devicetree with Kconfig. See footnote [1]. [...] Note: Even though proposal could greatly extend the flexibility of the devicetree, I'm not really a proponent of this idea. I'd rather add to the devicetree.cb grammar and generate the static code that uses the config options as discussed in [1]. If using the C preprocessor is the general preference though, I'll get behind that.
I very much agree. The preprocessor seems like a very big tool for the small problem discussed in [1]. The implementation would be simple, I guess. But with all the overhead of discussing rules, implementing linters, and trying not to make a mess where linters leave some slack, it seems much to complex for the original problem.
Personally, I wouldn't even want Kconfig option names in the device- trees. Due to the lack of scoping in Kconfig, the names are usually incredibly long. Additionally with the uppercase spelling, they would look alien in our devicetree. To control the on/off state of a device, I would suggest to match Kconfig names by convention. Since we already have names and naturally some scoping in the devicetree. For instance,
chip soc/amd/picasso device mmio 0xfedc4000 alias i2c_2 kconfig_enabled end end
Could become
.enabled = CONFIG(SOC_AMD_PICASSO_I2C_2_ENABLED),
Or if we want to allow defaults in case of absence of the Kconfig, it could be something like `kconfig(on)` or `kconfig(def_on)` or even with implied kconfig, just `default on` instead of `on`.
Nico