Adding CONFIG_PM=y to prj.conf containing CONFIG_LORA=y causes the device to not boot up

[jpro-tt]

Describe the bug
Hello, I've recently found an issue related to adding CONFIG_PM=y to prj.conf containing CONFIG_LORA=y. Whenever I combine these two configs in prj.conf, my device doesn't boot. I use Wio-E5 Development Kit (LoRa_E5_Dev_Board).

To Reproduce
Steps to reproduce the behavior:

1. Add CONFIG_PM=y to prj.conf in sample drivers/lora/send
2. west build -p always -b lora_e5_dev_board samples/drivers/lora/send
3. west flash

Other samples may be used, but they also fail to work.

Expected behavior
A device boots and prints logs to UART console.

Impact
I cannot use power management in my applications using LoRaWAN.

Logs and console output
There is no output in console.

Additional context
I use default devicetree in these samples.

[github-actions]

Hi @jpro-tt! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[JordanYates]

Are you able to attach a debugger when it fails to boot to see where it is stuck?
The SX126x drivers do not use PM themselves, and I do not have a STM32WL to test this myself.

[knthm]

This is a duplicate of #59194.

The STM32WL SoC will have entered STOP2 before the UART boot splash prints and the LoRa message transmission has been attempted.

The UART and SPI drivers don't yet have a mechanism to recover from their configuration loss after the SoC enters STOP2. UART simply won't work, but SPI will deadlock the system when it attempts a bus transaction.

See #59200 for fixes to both (note you need to add the required reinit-power-states DT property for the respective USART and SPI peripherals).