UartConfig::new() panics with unreachable!() on ESP32-H2 (SourceClock cannot map UART_SCLK_DEFAULT = PLL_F48M)

[ManfredFr]

UartConfig::new() panics with unreachable!() on ESP32-H2 (SourceClock::from_raw cannot map UART_SCLK_DEFAULT)

esp-idf-hal version: 0.45.2
ESP-IDF version: v5.3.3
Chip: ESP32-H2 (rev v0.1)
Toolchain: nightly, riscv32imac-esp-espidf, std

Bug

On the ESP32-H2, constructing a UartConfig panics immediately:

let config = esp_idf_svc::hal::uart::config::Config::new(); // panics

thread 'main' (1) panicked at .../esp-idf-hal-0.45.2/src/uart.rs:282:22:
internal error: entered unreachable code
abort() was called at PC ... on core 0

The device boot-loops before user code can do anything about it.

Cause

Config's Default/new() initializes source_clock: SourceClock::default(),
which calls SourceClock::from_raw(soc_periph_uart_clk_src_legacy_t_UART_SCLK_DEFAULT)
(uart.rs:257-264). On the ESP32-H2 the default UART source clock is
PLL_F48M (soc_periph_uart_clk_src_legacy_t_UART_SCLK_PLL_F48M), and the
SourceClock enum has no variant for it — the H2 cfg flags enable none of
apb_clk / pll_f40m_clk / pll_f80m_clk for this value, so from_raw
falls through to _ => unreachable!() (uart.rs:282).

Because the panic happens inside Config::new() itself, the
.source_clock(...) builder can never run — there is no user-side workaround
through this API. (We worked around it by driving the UART via raw
esp-idf-sys FFI.)

Expected

Either a SourceClock::PLL_F48M variant gated on
esp_idf_soc_uart_support_pll_f48m_clk, or from_raw mapping unknown values
to a sensible fallback instead of unreachable!().

Reproduction

Any std ESP-IDF project for esp32h2 with esp-idf-hal 0.45.2 / ESP-IDF 5.3.3:

fn main() {
    esp_idf_svc::sys::link_patches();
    let _cfg = esp_idf_svc::hal::uart::config::Config::new(); // panics on H2
}