Build error with stm32h747i_disco_m4

[jukkar]

Describe the bug
The compilation of websocket sample application in #19025 gives this build error:

make[3]: Entering directory '.../zephyr/sanity-out/stm32h747i_disco_m4/samples/net/sockets/websocket_client/samp
le.net.sockets.websocket_client'
[ 62%] Building C object zephyr/drivers/serial/CMakeFiles/drivers__serial.dir/uart_stm32.c.obj
.../zephyr/drivers/serial/uart_stm32.c:648:12: error: 'uart_stm32_init' defined but not used [-Werror=unused-fun
ction]
 static int uart_stm32_init(struct device *dev)
            ^~~~~~~~~~~~~~~
.../zephyr/drivers/serial/uart_stm32.c:614:37: error: 'uart_stm32_driver_api' defined but not used [-Werror=unus
ed-const-variable=]
 static const struct uart_driver_api uart_stm32_driver_api = {
                                     ^~~~~~~~~~~~~~~~~~~~~
.../zephyr/drivers/serial/uart_stm32.c:602:13: error: 'uart_stm32_isr' defined but not used [-Werror=unused-func
tion]
 static void uart_stm32_isr(void *arg)
             ^~~~~~~~~~~~~~
cc1: all warnings being treated as errors

I do not have anything stm32h747i_disco_m4 related in the sample.

To Reproduce

1. Fetch Simple Websocket & HTTP client API support #19025
2. sanitycheck -t websocket -p stm32h747i_disco_m4

Current version of #19025 blacklists this board, so in order to reproduce the issue, the sample.yaml files need to be edited and blacklisting removed.

Expected behavior
No error

Impact
Test fails. I will blacklist this board temporarily in order to proceed.

[erwango]

@jukkar, point is this board doesn't enable any UART device (for now at least).
Your sample somehow assumes it should be available.
This should be dealt with filtering, like following in board.yaml:

testing:
  ignore_tags:
    - net

[jukkar]

Your sample somehow assumes it should be available.

The sample is very generic, all the assumptions about UART are done somewhere in the system behind the curtains.

I am fine with your filtering suggestion, can you propose a patch for it?

[erwango]

The sample is very generic, all the assumptions about UART are done somewhere in the system behind the curtains.

Indeed, and few other samples have the same issue, such as nfc.
We actually miss an fiter step to say I don't support UART, and samples that need console or log filter it out. Because stating I don't support net or nfc is not true.

I am fine with your filtering suggestion, can you propose a patch for it?

Sure, will do.