[RFC] drivers: ieee802154: PHY configuration

[fgrandel]

The following started as a comment in #62413 but is probably worth a proper RFC.

I'll update this RFC with my current thoughts re PHY configuration in the IEEE 802.15.4 subsystem so people can comment and I can refer to it when implementing parts of it.

Right now we probably have less need for non-standard/vendor specific extensions in existing drivers than it seems if one looks at the many existing driver-specific Kconfig options. Most existing configuration options are standard options in the wrong place.

One random example:

• CC12xx and CC13xx support the same SUN FSK standard PHYs, so it doesn't make a lot of sense to keep these in the driver. Probably some common IEEE 802.15.4 driver yaml makes sense there. How can we support this w/o excessive complexity in the configuration?
• The two SubG TI drivers also support non-standard PHYs which need to be configurable. Therefore vendor/protocol specific options on all levels also need to be catered for (see 2, 3, 5, 6 below) even if it's the smaller problem, as those can easily be encapsulated and we already have a good framework for it.

The PHY specification is more than half of the standard and is still the fastest growing part. First we need to thoroughly understand the structure of the IEEE 802.15.4 PHY configuration space and then we have to systematically map it onto existing Zephyr architecture elements. Once we have the full picture it will be easy to find the "right" place for each and every requirement that might come up in the future - it may be DT it also may be not. Luckily the standardization committee has done most of the hard work, we just need to apply their concepts.

Here comes my current mind model of the required multi-dimensional IEEE 802.15.4 PHY configuration space which embeds DT but goes beyond. It is spanned by several orthogonal dimensions. Please let me know what I'm missing:

1. Granularity

   • Global defaults: 100% standard based (this is mostly what this PR starts off)
   • Global (const): Kconfig
   • Per driver (const): Kconfig
   • Per driver instance/interface (const): DT
   • Per driver instance/interface (dynamic): net_mgmt (app) & driver_api->configure() (L2)

2. Horizontal Layers

   • PHY aspects of driver hardware
   • PHY aspects of driver firmware (may be multiple per hardware)
   • L2 <-> PHY configuration interfaces
   • upper layers <-> PHY configuration interfaces (to be avoided - but bad design of upper layers may force us)

3. Vertical Stacks

   There are very few differences between native L2 and Thread relating to PHY configuration. Thread only 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 probably no need for extra PHY config there. We need to cater for a few OT implementation quirks unrelated to the Thread standard and we already have an architecture to do so. The same mechanism will work for PHY extensions/refinements of protocols we may want to support in the future (ISA 100.11a, ...).

4. PHY

   This PR only gives a glimpse of what can be configured on a per PHY level. Some of the PHYs are mostly standardized (e.g. O-QPSK, BPSK), others are highly configurable (SUN FSK, LECIM, TVWS, to a lesser extent UWB). Providing a good configuration model requires intimate knowledge of the PHY specific physics, modulation and coding approach which is challenging. The best we can do for now is ensuring that the configuration architecture includes well encapsulated driver-agnostic "configuration namespaces/containers" for each PHY. Luckily the standard has done the hard work of extracting what is common across PHYs and pushing down and prestructuring the PHY-specific data model. We just need to read and follow the standard here - this PR is an example of that approach.

5. Hardware

   Recent hardware is increasingly standard conforming. But there are some quirks. Vendors try to differentiate via non-standard options or try to create their own de-facto standard. TI's CCxxxx (from 11xx up to the latest 26x7) is a good example as it is highly configurable on PHY level which makes it very flexible for custom applications. All datasheets I've opened document at least a few non-standard options. The configuration can easily be isolated in this case in driver specific defaults, Kconfig, DT and our new API for well-encapsulated custom extensions to runtime configuration. So this is not a problem in practice. For non-standard options I propose we be tolerant and live the diversity to resist premature abstractions. If patterns emerge in practice we can still iterate upon them to make them driver agnostic.

   The opposite is true for standard options: We need to be much more careful in the future to extract configuration defined by the standard that is per definition NOT hardware specific such that drivers don't re-invent the wheel all the time (as can be seen in current drivers). We can repeat the same O-QSPK symbol rate in 10 defines in the code - I don't mind. But exposing users to 10 configuration options - one per driver - that essentially all manipulate the same standard PHY PIB attribute is really bad.

6. Vendor Firmware

   Vendor specific driver firmware can have tons of configuration options - some standard some not (nRF5 is a good example). Our challenge here will again be to extract what is part of the standard so that users wanting to switch between drivers or using multiple of them don't have to learn each and every driver firmware configuration model. Of course there are limits to what makes sense and we should resist the temptation for premature abstraction. Again my approach would be to live diversity and wait for patterns to emerge when it comes to non-standard configuration options. But we should be very strict in the future to extract standard options whenever possible rather than letting driver maintainers simply wrap their vendor-specific and mostly non-reusable custom API for those.

Of course none of this should be introduced just for the sake of it but strictly on an as-needed basis. I'm spanning up this framework to avoid the mistake of the past that the first driver requiring some configuration inside this space establishes it in some driver specific Kconfig variable which we then have to support forever although it was probably some standardized PHY configuration that would have much better been supported via driver-agnostic DT or runtime configuration.

My intention is all about the user facing API becoming simpler, more vendor agnostic, future proof and stable. That's also why I'm being a little defensive, conservative and slow - we've been shooting a little to quickly in the past which now causes us some extra work and headache (see this PR) - but that's also normal and not a big problem IMO.

Originally posted by @fgrandel in #62413 (comment)