stm32u5.dtsi & SPI1's compatible node // How to know which driver gets used

[Dermiste]

Hi all,

Simple scenario, I am running the sample located at tests\drivers\spi\spi_loopback. I've put prints inside the driver located at drivers/spi/spi_ll_stm32.c which confirm that it's this one that is compiled and used.

However, there are three options in the "compatible" node of the SPI1 inside dts/arm/st/u5/stm32u5.dtsi:
compatible = "st,stm32h7-spi", "st,stm32-spi-fifo", "st,stm32-spi";

The doc states "If a node has more than one string in its compatible property, the build system looks for compatible bindings in the listed order and uses the first match.". In this case they all have a match but only the last one has a C implementation that includes a DT_DRV_COMPAT macro, I assume that is why the driver st_stm32_spi.c gets used, but what would be the need for the first two bindings since they don't have any special properties nor C implementation? Can't wrap my head around that

Thanks in advance

[ndrs-pst]

@Dermiste, Normally, I look inside the map file (zephyr.map) to determine which files have been compiled and used.
Regarding your concern, perhaps the maintainer can provide a more precise answer.

However, AFAIK, STM32 share the spi_ll_stm32.c among their series. So, instead of using only "st,stm32-spi" as the baseline, they add another distinguishing feature through an additional compatible property.

Thus, in the spi_ll_stm32.c file, you can see the compilation switch based on the compatible property.
For example, DT_HAS_COMPAT_STATUS_OKAY(st_stm32h7_spi) and DT_HAS_COMPAT_STATUS_OKAY(st_stm32_spi_fifo) are used to manage different STM32 series compatibility.

[ndrs-pst]

ping @erwango 😅

[erwango]

what would be the need for the first two bindings since they don't have any special properties nor C implementation?

If that's the question, then @ndrs-pst's response is pretty accurate. Additional bindings are used to manage different STM32 series compatibility in the same driver.

[Dermiste]

Ok,so just to confirm the first two bindings I showed are then dead ends and could be potentially used in the future to develop completely appart drivers. In the case of that SPI driver the compatibility to other stm hardwares is implemented directly inside it without the need for specific drivers.

[erwango]

Ok,so just to confirm the first two bindings I showed are then dead ends and could be potentially used in the future to develop completely appart drivers.

I would not call them as dead ends, they're actually used in existing spi_ll_stm32.c/h files to driver some specific features and hw variants

[ndrs-pst]

@Dermiste, you can see what's behind the seen. 😄

#define DT_HAS_COMPAT_STATUS_OKAY(compat) \
	IS_ENABLED(DT_CAT(DT_COMPAT_HAS_OKAY_, compat))

devicetree_generated.h

#define DT_COMPAT_HAS_OKAY_st_stm32h7_spi 1
#define DT_COMPAT_HAS_OKAY_st_stm32_spi_fifo 1
#define DT_COMPAT_HAS_OKAY_st_stm32_spi 1