The test for the requirement of disabling wchar_t size warnings assumed
that $(CC) is used for linking, instead of $(LINK). With GCC $(LINK)
and $(CC) happen to be (in most cases) identical, but with LLVM they
are not. This results in issues with compiling with LLVM.
GCC on some platforms does need an executable stack to generate
trampoline code, but use of nested functions is not allowed in
RIOT's code base anyway.
`coap_build_reply()` may return negative values on error or
0 in the no-response case.
Don't use it to calculate a payload offset without checking first.
Due to the RIOT_EPOCH of 2020 this overflow will happen in year 2084. It would be scary if IoT devices are still around then.
We can save RAM and ROM. Furthermore, this overflow handling should block BACKUP power mode in order to keep track of the reference year.
There are STM32 families where all models use only the Synopsys DWC2 USB OTG core while others completely use only the USB Device FS core. For these families then either the driver `drivers/usbdev_synopsys_dwc2` or the driver `cpu/stm32/periph/usbdev` is used depending on the respective family. However, the STM32 families F1 and L4 use both cores. The correct driver must therefore be selected depending on the CPU line or CPU model.
There are STM32 families where all models use only the Synopsys DWC2 USB OTG core while others completely use only the USB Device FS core. For these families then either the driver `drivers/usbdev_synopsys_dwc2` or the driver `cpu/stm32/periph/usbdev` is used depending on the respective family. However, the STM32 families F1 and L4 use both cores. The correct driver must therefore be selected depending on the CPU line or CPU model.
This splits up the clock configs.
It allows CPU_FAM based file sourcing and also common CPU_FAMs.
The dependancies are also included in wildcards would be used for the CPU_FAM macro.
This should be much more readable.
This also takes into account the HSE speeds in order to match the make/header resolution.
Some hidden symbols were added to make sorting many CPU_SERIES dependencies easier.
This was added in #5837 and I don't believe is being used by anyone.
The fact that it isn't being maintained and doesn't really do that much
leads me to say better clean than not...
