From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: serdev: add rust private data to serdev_device Date: Tue, 28 Apr 2026 14:14:44 +1000 Message-ID: In-Reply-To: <20260427-rust_serdev-v6-2-173798d5e1a3@posteo.de> References: <20260427-rust_serdev-v6-0-173798d5e1a3@posteo.de> <20260427-rust_serdev-v6-2-173798d5e1a3@posteo.de> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review Adds `void *rust_private_data` to `struct serdev_device` with a doc comment: ```c * @rust_private_data: Private data for the rust abstraction. This should * not be used by the C drivers. ``` **Design concern:** This adds a void pointer to a C struct solely for Rust's benefit. It's needed because `drvdata` is already used for the driver's own data (T), and the Rust abstraction layer needs a separate location for its internal `PrivateData` (a `Completion` + error flag for probe/receive synchronization). There's no compile-time enforcement preventing C drivers from touching this field. **Minor:** The field is uninitialized in C (no `= NULL` in allocators). The Rust side sets it during probe before it's read anywhere, so this is fine in practice, but it might be worth considering whether the serdev core allocator (`serdev_device_alloc`) should zero-initialize it for safety. Actually, `kzalloc` is typically used, so it should be zeroed. No blocking issues, but this design choice merits subsystem maintainer buy-in (and the cover letter appropriately asks Rob Herring about this). --- --- Generated by Claude Code Patch Reviewer