[RFC] drivers: ieee802154: PHY and MAC offloading configuration policy

This RFC defines the policy for driver (radio/offloading) configuration in the IEEE 802.15.4 subsystem. The main intention of this RFC is to keep the L2 and user facing driver configuration API simple, vendor agnostic, future proof and stable.

The PHY specification represents more than half of the IEEE 802.15.4 standard and grows. Furthermore vendors increasingly wish to optimize application performance by offloading MAC-features to firmware or even hardware. This RFC analyzes the IEEE 802.15.4 driver configuration space and maps it onto Zephyr architecture elements. Wherever possible it should build on concepts from the standard.

1. Layers

   • driver hardware
   • driver firmware (may be multiple per hardware)
   • L2: native/OT
   • upper layers / network
   • app

2. Namespaces

   • Global defaults: 100% standard based except fro proprietary extensions, possibly exposed to L2 via attr_get()
   • Global (const): Kconfig, read via attr_get()
   • Per driver/hardware (const): Kconfig, attr_get()
   • Per driver instance/iface (const): DT, attr_get()
   • Per app (const): net settings
   • Per app/driver instance/iface (dynamic): net_mgmt (app) & configure() (L2)

3. Protocol Stacks

   There are few differences between native L2 and Thread relating to PHY configuration. Thread fills a few gaps in the standard to improve cross-vendor compatibility. Standard protocols (vanilla WPANs, DTME, TSCH, CSL, RIT, ranging, SRM, etc.) are decoupled from PHY by design, so no need for extra PHY config there. We need to cater for a few OT implementation quirks unrelated to the Thread standard and we have an architecture to do so, see the OT example The same mechanism will work for other protocol stacks we may want to support in the future (ISA 100.11a, ...).

4. PHY

   Some of the PHYs have few options (e.g. O-QPSK, BPSK), others are highly configurable (SUN FSK, LECIM, TVWS, to some extent UWB). The per-PHY configuration model depends on the PHY's physics, modulation and coding approach. The configuration architecture therefore SHALL provide per-PHY configuration namespaces. The standard separates configuration parameters common across PHYs and prestructures the PHY-specific data model. Subsystem configuration SHALL follow the standard here.

5. Hardware/Driver

   Standardized hardware or driver options SHALL NOT be exposed on a per-driver basis, even if only a single supported hardware or driver implements a given option initially. There still exists a lot of technical debt in that respect although the worst parts have been fixed by now. Users SHALL NOT be exposed to per-driver instances of the same standard configuration option (e.g. representing the same standard PHY PIB attribute). This is important to keep applications as vendor-agnostic as possible which is one of Zephyr's main advantages over vendor-specific SDKs.

   In code, standard options or constants (e.g. symbol rates) SHOULD NOT be redefined on a per-driver basis (e.g. via local #defines). Where duplicate definitions still exist, they SHOULD be lifted to subsystem level whenever a driver is being updated.

   Recent hardware is increasingly standard conforming. But there are still some quirks as vendors try to differentiate themselves. E.g. TI's CCxxxx (from 11xx up to the latest 26x7) is highly configurable on PHY level which makes it very flexible for custom (proprietary) applications. Similarly most available hardware provides at least a few non-standard options. We SHALL ensure that non-standard features can be exposed, otherwise it is not attractive for vendors to support Zephyr. But proprietary hardware-specific configuration SHALL be isolated in driver specific defaults, Kconfig, DT or custom extensions to runtime configuration. If patterns emerge across drivers we MAY iterate upon them to make them driver/hardware agnostic (i.e. lift them to sub-system level as de-facto standards).

Originally posted by @fgrandel in #62413 (comment)