Stable driver analysis tracking issue

[MabezDev]

Of the four drivers we're choosing to stabilize initially, we need to analyse them and determine a number of things.

• Does the driver meet all expectations in the API-GUIDELINES document?
  • This is not just limited to the driver itself, but any substructs, configs, helpers - everything
• Does the driver encapsulate the hardware it's designed to drive?
  • Does it offer an API that utilizes all hardware features?
  • If it doesn't, will the current API prevent us from adding that additional support in the future?
    • We should analyse the TRMs and find extra modes / alternate operation features
    • This is really important to think about, once we commit it will be a long time before we can change anything.
    • We don't need to support everything in 1.0, but we must design a driver that it extensible beyond 1.0 (without breaking changes)
• Can the driver as a whole be stabilized?
  • Perhaps some parts/modes are not a polished and stable as other parts of the driver
  • Could we partially stabilize some of this
  • We should be conservative at first, and we can relax some unstable flags as the beta phase progresses before 1.0

Please note that this is analysis work that needs to be done, here we will analyse what's wrong. Once the analysis is complete, we can do the following:

• Depending on the result of some parts, fix the code (light refactors, like naming etc)
• Mark part of the driver as unstable
  • Remember this is not 1.0 yet, we can relax some of these prior to 1.0

• Stable driver analysis: GPIO #2492
• Stable driver analysis: UART #2495
• Stable driver analysis: I2C master #2493
• Stable driver analysis: SPI master #2494