drivers: model IEEE 802.15.4 devices in Kconfig #17789
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
benpicco
reviewed
Mar 10, 2022
This was referenced Mar 11, 2022
|
I split some dependencies |
e4c2a42 to
554a9d2
Compare
a08dcb6 to
1a3081e
Compare
|
CI passed with the limited build, I'll remove the last commit now and give it another run |
1a3081e to
1b21ee3
Compare
|
Looking good @MrKevinWeiss |
|
Can we rerun 1 more time now that the kconfig checks are actually working? |
MrKevinWeiss
approved these changes
Jul 27, 2022
|
And that is why we check 😄 |
1b21ee3 to
b3ac6b7
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Contribution description
This models all IEEE 802.15.4 device drivers and the related modules (mostly netdev). Similarly to #17739, this modifies the related tests to avoid using the full GNRC stack. Some tests allow access to device-specific features (e.g., batmon in at86rf215), all these are kept.
A question regarding modelling + UI (maybe @jia200x has some insight): currently a radio can implement netdev or the radio HAL. In the second case, when the top level user (e.g. a network stack or the current tests) requires to interact via the netdev interface, the
netdev_ieee802154_submacmodule is required to fill the gap. So far, I added a symbol that indicates the presence of a radio HAL implementer (selected by the specific driver). Depending on whethernetdevis used, the submac module is used (ifnetdevis used, and a driver implements radio HAL -> bring submac). This has a shortcoming: if an application (or other module) wants to use two devices implementing different interfaces (netdev vs. HAL), the submac will be pulled. We could create an extra symbol (e.g.,USE_NETDEV_INTERFACE) that indicates that whatever network device you have, you want to interact using netdev, but I'm not sure that's the way. Thoughts?Testing procedure
Issues/PRs references
Depends on #17790Depends on #17791Depends on #17792