Re: [PATCH RFC 06/12] rust: serial: Add minimal serial-core polling console support

[Kwanghoon Son]

On Fri, Oct 30, 2026 at 10:16:11AM +0800, Shuai Liu wrote:
> Hi Kwanghoon,
> 
> I reviewed the Rust side of this series (the serial abstractions in
> 06/12) and did not find any soundness issues. In particular I verified:
> 
> - uart_port.lock is initialized by the serial core in
>   uart_add_one_port(), so zeroing the Opaque port storage and relying
>   on the core to initialize the lock is safe.
> 
> - The set_termios() adapter unconditionally taking the UART lock is
>   correct: the serial core callers (uart_change_line_settings(),
>   uart_set_options() and the console resume path) do not hold the port
>   lock when invoking the port->set_termios() callback.
> 
> - The console callback accesses to driver->state are protected by the
>   ownership chain: the port holds an Arc<Driver>, the console is
>   unregistered before the serial state is freed, and removal drains
>   the console readers via SRCU.
> 

Thanks for review.

> One thing to consider: SERIAL_BFLB_RUST depends on COMMON_CLK, which
> cannot be enabled on x86, so neither the driver nor the abstractions
> get build coverage from the Rust CI (allmodconfig on x86). Something

I don't understand for now, COMMON_CLK not possible on x86?
or you mean CI not supported?

> like "depends on RISCV || COMPILE_TEST" (with the clk dependency
> handled for the COMPILE_TEST case), or splitting the abstraction
> Kconfig entry from the driver entry, might make it easier to
> build-test.

> 
> While reviewing I also wrote KUnit tests for the pure-logic paths that
> can be exercised without hardware. The patch is attached; results with
> kunit.py under QEMU on arm64:
> 
>   rust_kernel_serial: pass:8 fail:0 skip:0 total:8
> 
> and CLIPPY=1 is clean. Feel free to squash it into 06/12 or keep it on
> top of the series.
> 
> Best regards,
> Shuai Liu
> 

Best regards,
Kwang.