STM32F303 advanced-control timers missing CR2 definitions

[dlaw]

The following definitions should be added for STM32F303 TIM1, TIM8, TIM20:

TIM1:
  CR2:
    MMS2:
      "Reset": [0b0000, "Reset - the UG bit from the TIMx_EGR register is used as trigger output (TRGO2). If the reset is generated by the trigger input (slave mode controller configured in reset mode), the signal on TRGO2 is delayed compared to the actual reset"]
      Enable: [0b0001, "Enable - the Counter Enable signal CNT_EN is used as trigger output (TRGO2). It is useful to start several timers at the same time or to control a window in which a slave timer is enabled. The Counter Enable signal is generated by a logic AND between the CEN control bit and the trigger input when configured in Gated mode. When the Counter Enable signal is controlled by the trigger input, there is a delay on TRGO2, except if the Master/Slave mode is selected (see the MSM bit description in TIMx_SMCR register)"]
      Update: [0b0010, "Update - the update event is selected as trigger output (TRGO2). For instance, a master timer can then be used as a prescaler for a slave timer"]
      ComparePulse: [0b0011, "Compare pulse - the trigger output sends a positive pulse when the CC1IF flag is to be set (even if it was already high), as soon as a capture or compare match occurs (TRGO2)"]
      CompareOC1: [0b0100, "Compare - OC1REFC signal is used as trigger output (TRGO2)"]
      CompareOC2: [0b0101, "Compare - OC2REFC signal is used as trigger output (TRGO2)"]
      CompareOC3: [0b0110, "Compare - OC3REFC signal is used as trigger output (TRGO2)"]
      CompareOC4: [0b0111, "Compare - OC4REFC signal is used as trigger output (TRGO2)"]
      CompareOC5: [0b1000, "Compare - OC5REFC signal is used as trigger output (TRGO2)"]
      CompareOC6: [0b1001, "Compare - OC6REFC signal is used as trigger output (TRGO2)"]
      PulseOC4: [0b1010, "Compare Pulse - OC4REFC rising or falling edges generate pulses on TRGO2"]
      PulseOC6: [0b1011, "Compare Pulse - OC6REFC rising or falling edges generate pulses on TRGO2"]
      RisingOC4_6: [0b1100, "Compare Pulse - OC4REFC or OC6REFC rising edges generate pulses on TRGO2"]
      RisingOC4_FallingOC6: [0b1101, "Compare Pulse - OC4REFC rising or OC6REFC falling edges generate pulses on TRGO2"]
      RisingOC5_6: [0b1110, "Compare Pulse - OC5REFC or OC6REFC rising edges generate pulses on TRGO2"]
      RisingOC5_FallingOC6: [0b1111, "Compare Pulse - OC5REFC rising or OC6REFC falling edges generate pulses on TRGO2"]
    OIS?N:
      Reset: [0, "OCxN=0 after a dead-time when MOE=0"]
      Set: [1, "OCxN=1 after a dead-time when MOE=0"]
    OIS?:
      Reset: [0, "OCx=0 (after a dead-time if OCx(N) is implemented) when MOE=0"]
      Set: [1, "OCx=1 (after a dead-time if OCx(N) is implemented) when MOE=0"]
    CCUS:
      Bit: [0, "When capture/compare control bits are preloaded (CCPC=1), they are updated by setting the COMG bit only"]
      BitOrEdge: [1, "When capture/compare control bits are preloaded (CCPC=1), they are updated by setting the COMG bit or when an rising edge occurs on TRGI"]
    CCPC:
      NotPreloaded: [0, "CCxE, CCxNE and OCxM bits are not preloaded"]
      Preloaded: [1, "CCxE, CCxNE and OCxM bits are preloaded"]

These are the same definitions as already present in peripherals/tim/tim1_wl.yaml for a few other chips. However, only CR2 from this file applies to the F303. The other registers (other than CR2) which are defined in this file do not match the F303.

I can take a stab at patching this but I'm a little lost by the directory structure -- would appreciate a pointer for how to put this in to avoid extra duplication.

[burrbull]

Entry point for f303 is devices/stm32f303.yaml. Patching structure is a tree of includes of yaml.
Timer enumeratedValue patches should be in peripherals/tim.

[dlaw]

Thanks for the pointers. A few different approaches occur to me. Which of these would be preferred?

1. Copy-paste TIM1 CR2 definitions from peripherals/tim/tim1_wl.yaml into a new file peripherals/tim/tim1_f303_cr2.yaml, which is included by devices/stm32f303.yaml. This is a correct solution but now the same value definitions are duplicated in two different files.
2. Remove TIM1 CR2 definitions from peripherals/tim/tim1_wl.yaml and move them into a new file peripherals/tim/tim1_cr2.yaml, which is included by devices/stm32f303.yaml as well as by all the other devices which were previously including tim1_wl.yaml. No duplication, but we add complexity to the file structure.
3. Remove TIM1 CR2 definitions from peripherals/tim/tim1_wl.yaml and move them into peripherals/tim/tim_advanced.yaml. This would seem to be the nicest solution, but I am not sure how to go about verifying whether "all" instances of the advanced-control timer have these fields present in CR2, or if it's only a subset of the STM32 parts which have this.