ieee802154/submac: handle non standard modulations #21527
Conversation
fabian18
requested review from
miri64,
PeterKietzmann,
bergzand and
jia200x
as code owners
github-actions
bot
added
Platform: native
crasbe
added
Type: enhancement
| @@ -692,6 +822,9 @@ int ieee802154_submac_init(ieee802154_submac_t *submac, const network_uint16_t * | |||
|
|
|||
| submac->phy_mode = ieee802154_cap_to_phy_mode(1 << bit); | |||
| } | |||
| else { | |||
| submac->phy_mode = IEEE802154_PHY_DISABLED; /* non standard */ | |||
There was a problem hiding this comment.
You can just add IEEE802154_PHY_LORA if you want to.
No need to abuse the IEEE802154_PHY_DISABLED for that - this is our enum, we can add to it what we want.
There was a problem hiding this comment.
ifconfig showing phy: DISABLED already confused some people.
However something with IEEE802154_...._LORA is not really something that I would like to introduce.
I would like that the radio HAL could be used for LoRa, but not that I put LoRa stuff in the IEEE 802154 radio hal, because it is too much experimental.
Bottomline: IEEE802154_PHY_UNKNOWN is something I would propose instead.
There was a problem hiding this comment.
What if we also want to add IEEE802154_PHY_NRF24LP?
Just because it isn't a IEEE standard doesn't mean we can add it to our enum - 6LoWPAN over nRF24L01+ isn't a standard either.
If it eases your worries, how about IEEE802154_PHY_NSTD_LORA?
There was a problem hiding this comment.
IEEE802154_PHY_NSTD_LORA would not make a big difference to me.
If you are certain I will just add IEEE802154_PHY_LORA.
Contribution description
The key feature of this PR is to reuse the
confparameter as an output inSo the driver that is using an unknown IEEE.802.15.4 modulation can set ACK timeout and CSMA backoff.
This is crucial for #21202.
Testing procedure
Issues/PRs references
Follow up from #19668.
Split out from #21202