the startup .s files refer to symbols defined in the linker script, but where is the linker script(s)?

Additional context

Is there a specific reason to not use '__IO' for peripheral register definitions instead of '__IOM' as per guidelines for versions greater than v4.2?

typedef struct { __IO uint32_t SR; /*!< ADC status register, Address offset: 0x00 */ __IO uint32_t CR1; /*!< ADC control register 1, Address offset: 0x04 */ __IO uint32_t CR2; /*!< ADC control register 2, Address offset: 0x08 */ __IO uint32_t SMPR1; /*!< ADC sample time register 1, Address offset: 0x0C */ __IO uint32_t SMPR2; /*!< ADC sample time register 2, Address offset: 0x10 */ __IO uint32_t JOFR1; /*!< ADC injected channel data offset register 1, Address offset: 0x14 */ __IO uint32_t JOFR2; /*!< ADC injected channel data offset register 2, Address offset: 0x18 */ __IO uint32_t JOFR3; /*!< ADC injected channel data offset register 3, Address offset: 0x1C */ __IO uint32_t JOFR4; /*!< ADC injected channel data offset register 4, Address offset: 0x20 */ __IO uint32_t HTR; /*!< ADC watchdog higher threshold register, Address offset: 0x24 */ __IO uint32_t LTR; /*!< ADC watchdog lower threshold register, Address offset: 0x28 */ __IO uint32_t SQR1; /*!< ADC regular sequence register 1, Address offset: 0x2C */ __IO uint32_t SQR2; /*!< ADC regular sequence register 2, Address offset: 0x30 */ __IO uint32_t SQR3; /*!< ADC regular sequence register 3, Address offset: 0x34 */ __IO uint32_t JSQR; /*!< ADC injected sequence register, Address offset: 0x38*/ __IO uint32_t JDR1; /*!< ADC injected data register 1, Address offset: 0x3C */ __IO uint32_t JDR2; /*!< ADC injected data register 2, Address offset: 0x40 */ __IO uint32_t JDR3; /*!< ADC injected data register 3, Address offset: 0x44 */ __IO uint32_t JDR4; /*!< ADC injected data register 4, Address offset: 0x48 */ __IO uint32_t DR; /*!< ADC regular data register, Address offset: 0x4C */ } ADC_TypeDef;

https://developer.arm.com/documentation/ka002980/latest

Note:
Since CMSIS-Core V4.20 the macros __I, __O and __IO should only be used for scalar variables. For peripheral register definitions in structures, the macros __IM, __OM and __IOM should now be used. The definition __IM always contains the const type qualifier because C++ does not optimize struct-members to constants. This way, registers can be write-protected even in C++.

or https://github.com/ARM-software/CMSIS_5/blob/develop/CMSIS/Core/Include/core_cm4.h#L229
/* following defines should be used for structure members */ #define __IM volatile const /*! Defines 'read only' structure member permissions */ #define __OM volatile /*! Defines 'write only' structure member permissions */ #define __IOM volatile /*! Defines 'read / write' structure member permissions */

The definition of __STM32F4xx_CMSIS_VERSION in stm32f4xx.h reads
#define __STM32F4xx_CMSIS_VERSION ((__STM32F4xx_CMSIS_VERSION_MAIN << 24)\ |(__STM32F4xx_CMSIS_VERSION_SUB1 << 16)\ |(__STM32F4xx_CMSIS_VERSION_SUB2 << 8 )\ |(__STM32F4xx_CMSIS_VERSION))
resulting in a compilation error when used. It should instead read
#define __STM32F4xx_CMSIS_VERSION ((__STM32F4xx_CMSIS_VERSION_MAIN << 24)\ |(__STM32F4xx_CMSIS_VERSION_SUB1 << 16)\ |(__STM32F4xx_CMSIS_VERSION_SUB2 << 8 )\ |(__STM32F4xx_CMSIS_VERSION_RC))

Describe the bug
All headers for F4 board have this

#define GPIO_MODER_MODE8_Msk             GPIO_MODER_MODER2_Msk

Changing 8 to 2 seems odd.
All surrounding lines have consistent numbering so it would make more sense to change it to

#define GPIO_MODER_MODE8_Msk             GPIO_MODER_MODER8_Msk

Describe the bug

#define FLASH_ACR_LATENCY_Msk (0xFUL << FLASH_ACR_LATENCY_Pos) /*!< 0x0000000F */

there are only 3 bits

#define FLASH_ACR_LATENCY_Msk (0x7UL << FLASH_ACR_LATENCY_Pos) /*!< 0x00000007 */

maybe it's not critical but misleading

It seems that the GPIO peripheral is largely the same for all but the STM32F1 family. Still, macros that seem to refer to the exact same thing are named inconsistently, e.g.:

• GPIO_OSPEEDER_OSPEED0: STM32L0
• GPIO_OSPEEDER_OSPEEDR0: STM32F0, STM32F2, STM32F3, STM32F4, STM32F7, STM32G4, STM32L1, STM32L4
• GPIO_OSPEEDR_OSPEED0: STM32F2, STM32F4, STM32G0, STM32G4, STM32L4, STM32L5, STM32U5, STM32WB, STM32WL
• GPIO_OSPEEDR_OSPEEDR0: STM32F0, STM32F7

Are there any plans to at least provide aliases (e.g. #define GPIO_OSPEEDR_OSPEED0 GPIO_OSPEEDER_OSPEEDR0) so that there is one canonical name for each macro that works across families?

According to RM0402, all STM32F412 chips can configure MCO2 in RCC_CFGR register.

The stm32f412cx.h header doesn't have the definition of MCO2 bits. I guess it is done this way because all stm32f412cx chips are in UFQFPN48 package, which doesn't have PC9 pin (MCO2 pin).

The problem is that changing the MCO2 source clock(to a clock that is disabled) reduces power consumption.

Wouldn't it make sense to define the MCO2 bits for all STM32F412 bit despite the fact the PC9 pin is not present?