Out of tree (driver) configuration support #13631
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -9,6 +9,13 @@ | |
| # | ||
| # Clock controller drivers | ||
| # | ||
|
|
||
| config CLOCK_CONTROL_MUST_USE_OUT_OF_TREE_DRIVER | ||
|
There was a problem hiding this comment. hmmm, why do we need to have Kconfigs for this? Are we going to have such a kconfig for each driver subsystem? Are we talking about 2 conflicting drivers and we would select the one out of tree instead of the one in the tree? In short, this looks like a hack to me. Need some documentation or a design proposal explaining how this can be done in a generic way without polluting Kconfig with such options. There was a problem hiding this comment.
Please prove me wrong @ulfalizer; it is unavoidable to pollute the kconfig with these options without resolving #8181, which is not going to happen any time soon. For your other questions, please see the commit message in 8f1e6cb There was a problem hiding this comment. The reasoning is described in this commit message: 8f1e6cb, but I think @thomasstenersen might want to update the PR description with a clear definition of the problem and why these additional Kconfig options are required. There was a problem hiding this comment. Edit: hadn't refreshed the page before commenting. I can copy the following comment to the PR description. It provides an answer to what would be my initial reaction to seeing this PR as well :) Yes we need this, unfortunately. This is for the case were an out-of-tree component for some reason must use it's own driver. There is no way in Kconfig that I and others have found to effectively de-select a Kconfig choice/config without severely polluting the Zephyr configuration files.
I would add it at a per use-case/need basis. But this is a generic pattern, yes.
Yes. And the fact that they are not only conflicting but another subsystem must use the out-of-tree one. We also want this switch to happen automatically, so if I select a different BLE controller in the menuconfig, the correct driver dependencies are resolved without the need for other changes by the user.
I would like it for there to be a nicer way of doing this. But as far as I can tell, this is the most pragmatic, least intrusive and nicest way of handling out-of-tree dependencies like this. IMO the only way of actually solving the root problem is to resolve #8181.
What would such a proposal look like? Could I add more to 8f1e6cb to explain the why and how better? |
||
| bool | ||
| help | ||
| This option can be enabled by an out-of-tree library if it | ||
| needs to take control over the clock controller. | ||
|
|
||
thomasstenersen marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| menuconfig CLOCK_CONTROL | ||
| bool "Hardware clock controller support" | ||
| help | ||
|
|
@@ -23,18 +30,15 @@ module = CLOCK_CONTROL | |
| module-str = clock control | ||
| source "subsys/logging/Kconfig.template.log_config" | ||
|
|
||
|
|
||
| if !CLOCK_CONTROL_MUST_USE_OUT_OF_TREE_DRIVER | ||
thomasstenersen marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| source "drivers/clock_control/Kconfig.nrf" | ||
| source "drivers/clock_control/Kconfig.quark_se" | ||
| source "drivers/clock_control/Kconfig.stm32" | ||
| source "drivers/clock_control/Kconfig.beetle" | ||
| source "drivers/clock_control/Kconfig.mcux_ccm" | ||
| source "drivers/clock_control/Kconfig.mcux_sim" | ||
| source "drivers/clock_control/Kconfig.rv32m1" | ||
| endif # !CLOCK_CONTROL_MUST_USE_OUT_OF_TREE_DRIVER | ||
|
|
||
| endif # CLOCK_CONTROL | ||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this could be called
CLOCK_CONTROL_OUT_OF_TREE_DRIVERor the like, to shorten it a bit. It might be clear anyway that there must be an out-of-tree driver if it's on.@carlescufi suggested something similar. He's more familiar than me with Bluetooth though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(@carlescufi) We had a naming discussion here: #13631 (comment)
The reason for the
_MUST_USE_(originally_HAS_) was to keep consistency with other select-able Kconfig symbols. If we keep select-able symbols on the form<noun>_<verb>_<noun>(FOO_HAS_BAR), it is much easier to keep your sanity when working with the Kconfig files.The name is verbose, but I'd rather sacrifice verbosity for clarity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you really want to enforce the
<noun>_<verb>_<noun>(which I don't think we could call a convention right now except for the_HAS_case) then I would go for something like*_SELECT_OOTorREQUIRE_OOTsomething like that.MUST_USEsounds convoluted and verbose to me.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The original proposal of _HAS_ didn't make sense, but now I'm unsure if we actually considered using an option without HAS. As Ulf says, if the OOT driver is enabled, that does imply that the other drivers can't be. The symbol for an enabled out-of-tree driver would look like:
CLOCK_CONTROL_OUT_OF_TREE_DRIVER