Claude review: rust: add basic serial device bus abstractions

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

This is the main patch — 574 lines of new Rust code, plus C helpers and build plumbing.

**C helpers (`rust/helpers/serdev.c`):** Correct. The three helpers wrap static inline functions that bindgen cannot see through.

**Kconfig:** Clean. `RUST_SERIAL_DEV_BUS_ABSTRACTIONS` is a `bool` that selects `SERIAL_DEV_BUS`, which is the right dependency direction.

**Typo in Parity doc comment:**
```rust
/// Even partiy.
Even = bindings::serdev_parity_SERDEV_PARITY_EVEN,
```
Should be `/// Even parity.`

**Broken rustdoc link in `write()` documentation:**
```rust
    /// Note that any accepted data has only been buffered by the controller. Use
    /// [ Device::wait_until_sent`] to make sure the controller write buffer has actually been
    /// emptied.
```
The link is malformed — `[ Device::wait_until_sent`]` has a space after `[` and mismatched backtick placement. Should be `[`Device::wait_until_sent`]` to match the correct form used elsewhere, e.g. in `write_all`:
```rust
    /// [`Device::wait_until_sent`] to make sure the controller write buffer has actually been
```

**`Timeout::Max` documentation:**
```rust
    /// Wait as long as possible.
    ///
    /// This is equivalent to [`kernel::task::MAX_SCHEDULE_TIMEOUT`].
    Max,
```
And the implementation:
```rust
    Self::Max => 0,
```
This works correctly because both `serdev_device_write` (line 271-272 of `core.c`) and `tty_wait_until_sent` convert `timeout == 0` to `MAX_SCHEDULE_TIMEOUT` internally. However, saying `Timeout::Max` "is equivalent to `MAX_SCHEDULE_TIMEOUT`" is misleading — it maps to 0, not to the `MAX_SCHEDULE_TIMEOUT` constant value (`LONG_MAX`). A reader unfamiliar with the C side's `if (timeout == 0) timeout = MAX_SCHEDULE_TIMEOUT;` convention could be confused. Consider rewording to something like "The underlying C API treats a timeout of 0 as waiting indefinitely (equivalent to `MAX_SCHEDULE_TIMEOUT`)."

**`Timeout::into_jiffies` overflow behavior:**
```rust
Self::Jiffies(value) => value.get().try_into().unwrap_or_default(),
```
On overflow, `unwrap_or_default()` yields 0, which means "wait forever" per the C API convention. This is a safe fallback (infinite wait rather than spurious timeout), but it might be worth documenting this intentional semantic since it's non-obvious.

**`probe_callback` — drvdata lifecycle on probe failure:**
```rust
sdev.as_ref().set_drvdata(try_pin_init!(PrivateData::<T> { ... }))?;
// ...
to_result(unsafe { bindings::serdev_device_open(sdev.as_raw()) })?;
// ...
let result = unsafe { data.__pinned_init(driver.as_mut_ptr()) };
unsafe { *private_data.error.get() = result.is_err() };
private_data.probe_complete.complete_all();
result.map(|()| 0)
```
If `serdev_device_open` succeeds but `T::probe` fails, the `PrivateData` is in drvdata with `error == true` and a successfully opened device. `PinnedDrop` for `PrivateData` calls `serdev_device_close`, but only if `PrivateData` is actually dropped. Since `remove_callback` won't be called on probe failure, cleanup depends on the prerequisite driver-lifetime framework dropping drvdata on error. This should work given the dependencies, but it's worth verifying the guarantee with the `device::CoreInternal` infrastructure.

**`receive_buf_callback` — completion wait:**
```rust
private_data.probe_complete.wait_for_completion();
```
This uses an unbounded wait. If probe hangs (e.g., firmware loading blocks), `receive_buf` will also hang. The serdev `receive_buf` callback is documented as "may sleep," so this is permitted, but worth noting.

**`write_all` return type handling:**
```rust
let ret = unsafe {
    bindings::serdev_device_write(self.as_raw(), data.as_ptr(), data.len(), timeout.into_jiffies())
};
to_result(ret as i32).map(|()| ret.unsigned_abs())
```
The `ret as i32` cast is safe here because only the error check uses the truncated value, and negative errnos always fit in `i32` (documented in the inline comment). The actual byte count comes from `ret.unsigned_abs()` using the original `isize` value. Correct.

**SAFETY comments:** Generally thorough and appropriate. The `unsafe impl Send/Sync` blocks have adequate justification based on reference counting and thread-safe method implementations.

---
Generated by Claude Code Patch Reviewer