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

[Shuai Liu <847807867@qq.com>]

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.

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
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