Bluetooth: Host: Fix monitor UART selection

[jhedberg]

Most boards set zephyr,bt-mon-uart to point at the same device as zephyr,console. It's still useful to have the possibility of having these as two different devices, however it's also useful to fall back to the UART console in case a dedicated monitor UART hasn't been specified.

This also ensures that the fallback only happens if the console UART isn't enabled, but a DT chosen property exists for it. Additionally, we now get a user friendly error in case the Bluetooth UART monitor feature has been enabled in Kconfig but there isn't a suitable UART available for it in devicetree.

[alwa-nordic]

I don't know if it's right to treat zephyr,console as a free-for-all. It is reserved for the console driver.

zephyr/doc/build/dts/api/api.rst

Lines 397 to 398 in 124aae3

	* - zephyr,console
	- Sets UART device used by console driver

At the very least, we should only grab it if CONFIG_UART_CONSOLE=n. Otherwise, we will clobber the console's UART output with binary data. What do you think?

Is there a way to ensure only one driver grabs a DT device?

[alwa-nordic]

Most boards set zephyr,bt-mon-uart to point at the same device as zephyr,console.

Some wild thinking: Wouldn't it be better if we made it so btmon is not enabled by a kconfig, but rather by the presence of the zephyr,bt-mon-uart DT chosen? Boards should define zephyr,bt-mon-uart to enable btmon by default, and only then. I can see a need to parameterize devkit boards with "functionality switches", but this logic should be explicit in the board subsystem, and it should be such that zephyr,bt-mon-uart chosen does not exits when not enabled. And when it exists, it should give exclusive access to a device.

[jhedberg]

@alwa-nordic all good points. Admittedly I was looking for a quick fix here for the fact that I realized none of the Silabs boards set a zephyr,bt-mon-uart chosen property. The idea of removing the prompt (user settability) from the Kconfig option and instead setting it based on the existence of the chosen property sounds like a clean solution, however then it's fair to argue that CONFIG_UART_CONSOLE should also be enabled the same way.

Either way, we do have issue independent of this PR, since if you go and set Bluetooth logs to use BT_MONITOR it does not disable UART_CONSOLE, which means that you get both drivers on most boards enabled and trying to use the same device.

[jhedberg]

At the very least, we should only grab it if CONFIG_UART_CONSOLE=n. Otherwise, we will clobber the console's UART output with binary data. What do you think?

I've updated the PR accordingly, and I think this may be a worthwhile short-term improvement. Longer term (post-4.0) we could look into enabling these Kconfig options based on the existence of DT chosen properties.