netdev_ieee802154_submac: add opportunity to use legacy netdev driver

[fabian18]

Contribution description

When using the IEEE 802.15.4 radio HAL, I think support of a few netopts is lost becaus ethey have been implemented in the old _netdev.c implementation. This PR add a pointer to an optional old instance of the netdev driver to have its _get and _set function. For example when runnin IEEE802154 over LoRa I still want to see the currently used spreading factor, coding rate etc.

An old netdev instance can be set like here:

extern const netdev_driver_t sx126x_driver;

void sx126x_hal_setup(sx126x_t *dev, const sx126x_params_t *params, uint8_t index,
                      ieee802154_dev_t *hal, void (*event_cb)(void *arg), void *arg)
{
    (void)dev;
    (void)params;
    (void)hal;
    (void)index;
    (void)event_cb;
    (void)arg;
    /* legacy */
    memset((uint8_t *)dev + sizeof(dev->netdev), 0, sizeof(*dev) - sizeof(dev->netdev));
    netdev_t *netdev = &dev->netdev;
    netdev->driver = &sx126x_driver;

Testing procedure

Issues/PRs references

Split out from #21202

[benpicco]

For example when runnin IEEE802154 over LoRa I still want to see the currently used spreading factor, coding rate etc.

That should be handled via the (extended) ieee802154_phy_conf_t struct, see e.g. ieee802154_mr_oqpsk_conf_t

[riot-ci]

Murdock results

:heavy_check_mark: PASSED

d98a6e4f00f815af6cca50148be2aab0e6137067 netdev_ieee802154_submac: add opportunity to use legacy netdev driver

Success	Failures	Total	Runtime
10931	0	10932	11m:28s

Artifacts

• Documentation preview

[fabian18]

I struggle to see the way using ieee802154_phy_conf_t. The netopts in drivers/netdev_ieee802154_submac/netdev_ieee802154_submac.c are limited to IEEE 802.15.4 options.

[fabian18]

I still think it is better to reuse the driver_netdev::{set,get} for non IEEE802154 related netopts

[jia200x]

I struggle to see the way using ieee802154_phy_conf_t. The netopts in drivers/netdev_ieee802154_submac/netdev_ieee802154_submac.c are limited to IEEE 802.15.4 options.

Technically the LoRa modulation is not considered IEEE 802.15.4, so using the SubMAC on top of LoRa devices is still a bit out of the standard. If we are doing it anyway, I don't think it's too bad to assume LoRa PHY settings can be modeled as IEEE 802.15.4 PHY configurations, since LoRa transceiver are inherently IEEE 802.15.4 transceivers (they are capable of doing FSK)

[fabian18]

I want to be ale to control the PHY with ifconfig.

ieee802154_phy_conf_t is used in

• ieee802154_submac_init()
• _set(NETOPT_CHANNEL) -> ieee802154_set_channel_number()-> ieee802154_set_phy_conf()
• ieee802154_set_channel_page() -> ieee802154_set_phy_conf()
• _set(NETOPT_TX_POWER) -> ieee802154_set_tx_power() -> ieee802154_set_phy_conf()

This would mean an extension to LoRa would look like this:

• _set(NETOPT_SPREADING_FACTOR) -> ieee802154_(lora)_set_spreading_factor() -> ieee802154_set_phy_conf()

Then ieee802154_phy_conf_t and ieee802154_submac_t must add members for sf, cr, bw?