quite prepared to be told i'm totally off-base here, but the DM/SPL dependencies in the drivers/core/Kconfig file seem a bit odd, but that might be just my misunderstanding of how DM and SPL work together.
first quick observation -- based on the naming convention i read somewhere, it seems that the Kbuild variable "SPL_DM" should actually be "DM_SPL". i'm sure i remember reading that the naming standard for DM-related variables should be "CONFIG_DM_*" but that's not a big deal. onward ...
using a wandboard configuration, and enabling SPL, then driver model *and* driver model for SPL, one sees (partial list only) the Kbuild entries:
[*] Enable Driver Model [*] Enable Driver Model for SPL [*] Support numbered aliases in device tree [ ] Support numbered aliases in device tree in SPL [*] Support register maps [*] Support register maps in SPL [*] Support system controllers [*] Support system controllers in SPL [*] Support simple-bus driver [ ] Support simple-bus driver in SPL [*] Translate addresses using fdt_translate_address [ ] Translate addresses using fdt_translate_address in SPL
where the list above represents pairs of settings, one non-SPL, one for SPL. so far, so good.
but if one then deselects "Enable Driver Model for SPL", one is still left with some of those (ostensibly) SPL-related entries:
[ ] Support numbered aliases in device tree in SPL [*] Support register maps in SPL [*] Support system controllers in SPL
a quick look at the Kconfig file shows that some of those "for SPL" entries depend on SPL_DM, while the others depend only on DM. is that the way it's meant to be? i don't know enough about how the driver model relates to SPL, so it's entirely possible the above is entirely correct, it just looks a bit weird.
in any event, that Kconfig file could still be refactored to avoid new entries popping up in arbitrary places depending on what you select or deselect.
thoughts?
rday