Review DMA implementation for Undefined Behavior (UB)

[ryan-summers]

It was noted by James Munns that we may need to use an UnsafeCell internal wrapper on the DMA reception buffers to prevent invoking undefined behavior by the Rust compiler (i.e. two owners of the memory cell)

[jamesmunns]

@ryan-summers if you can point me to the driver impl(s) I can give a review, or at least my opinions.

[ryan-summers]

The implementations are specifically in:

• https://github.com/quartiq/stabilizer/blob/main/src/hardware/adc.rs#L426 - for DMA RX of N u16s from a SPI peripheral

Note that there's a few single-byte transfers in there that are not concerning - the memory is static and entirely owned by the DMA module and is never modified.

It's worth noting that this is a double-buffered DMA implementation using the STM32H7xx-Hal. This is implemented here for swapping the DMA double-buffer for the next transfer

[dnadlinger]

Possibly related: nightly now emits warnings like this (same for other DMA/Ethernet description ring buffers), and it seems like this is going to turn into deny by default in 2024 still

warning: creating a mutable reference to mutable static is discouraged
   --> src/hardware/adc.rs:378:25
    |
378 |                           ADC_BUF.write(Default::default())
    |                           ^^^^^^^ mutable reference to mutable static
...
446 | / adc_input!(
447 | |     Adc1Input, 1, Stream3, Stream4, Stream5, SPI3, Channel2, Tim2Ch2, Channel2,
448 | |     Tim3Ch2
449 | | );
    | |_- in this macro invocation
    |
    = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/static-mut-references.html>
    = note: mutable references to mutable statics are dangerous; it's undefined behavior if any other pointer to the static is used or if any other reference is created for the static while the mutable reference lives
    = note: this warning originates in the macro `adc_input` (in Nightly builds, run with -Z macro-backtrace for more info)

I am not sure I understand the documentation here – is ptr::addr_of_mut!(ADC_BUF) a valid "fix"?

[jordens]

c.f. #84 and stm32-rs/stm32h7xx-hal#518
and #910 for uninitialized ITCM

[jordens]

Only remaining thing left AFAICT is the two &mut to the constant DMA sources for the ADC completion/trigger handling. THey could either be split for convenience or once the HAL gets around to doing it, made &.
The rest are HAL issues.