Re: tidy STM32 SPI driver

[Chris Holgate <chris@zynaptic.com>]

Apologies for breaking the thread, but I don't actually subscribe to the
patches list so can't just hit reply!

Bart wrote:

> This SPI driver did not use linker garbage collection the way I
> intended for SPI drivers. It created a C++ object in
> src/spi_stm32_init.cxx which was places in libextras.a. Hence the C++
> object was always part of any application link, and because of the
> KEEP(*.ctors) in the linker script its constructor would never get
> garbage-collected. Net result: all applications would end up with the
> C++ object, the constructor, and the cyg_spi_cortexm_stm32_init()
> function, even if SPI was never used.

That bit of code was essentially a cut and paste from the AT91 SPI
driver, which sounds as though it may suffer from the same problem.

> I also looked at moving the three SPI buses into separate modules,
> built unconditionally. Again linker magic would ensure that only buses
> actually used by the application would end up in the application, with
> no need for developers to enable the relevant CDL components. This
> does not look entirely feasible right now, there are too many per-bus
> configuration options.

Getting rid of the 'bus enable' checkboxes would definitely be a good thing.

Generally, the configuration options are only used to statically
initialise the 3 bus data structures - so it should be fairly easy to
pull each bus data structure declaration into a separate compile unit
with per-bus constructors and function tables.  The common core
functions would then only be pulled in if at least one of the per-bus
compile units were actually referenced.

I'll have a look at it.

Chris.