-
Notifications
You must be signed in to change notification settings - Fork 8.2k
Out of tree (driver) configuration support #13631
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
da850d5
b35d39a
2478ce5
f92154f
8f1e6cb
8e8c9fe
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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" | ||
|
|
||
| source "drivers/clock_control/Kconfig.nrf" | ||
|
|
||
| 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