MAINTAINERS | 5 +- drivers/tty/serdev/Kconfig | 7 + rust/bindings/bindings_helper.h | 1 + rust/helpers/helpers.c | 1 + rust/helpers/serdev.c | 22 ++ rust/kernel/lib.rs | 2 + rust/kernel/serdev.rs | 599 +++++++++++++++++++++++++++++++++++++ samples/rust/Kconfig | 11 + samples/rust/Makefile | 1 + samples/rust/rust_driver_serdev.rs | 90 ++++++ 10 files changed, 738 insertions(+), 1 deletion(-)
This patch series adds the serdev device bus rust abstraction into the
kernel.
This abstraction will be used by a driver,
which targets the MCU devices in Synology devices.
Kari Argillander also messaged me, stating that he wants to write a
watchdog driver with this abstraction (needing initial device data).
This series depends on [1].
[1] https://lore.kernel.org/rust-for-linux/20260530132736.3298549-1-dakr@kernel.org/
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
Changes in v14:
- fix issues reported by Sashiko:
- fix missing Sync
- fix write buffers allowed with data.len() > i32::MAX
- fix sample driver possibly stalling on full tx buffer
- Link to v13: https://patch.msgid.link/20260712-rust_serdev-v13-0-2c4060bc8e30@posteo.de
Changes in v13:
- Added Acked-by trailer from Rob. Consider this a RESEND.
- Link to v12: https://patch.msgid.link/20260603-rust_serdev-v12-0-3400ffb88b12@posteo.de
Changes in v12:
- fix CoreInternal instead of BoundInternal
- Link to v11: https://patch.msgid.link/20260531-rust_serdev-v11-0-dee8e0d830f1@posteo.de
Changes in v11:
- redo changes from v9 with the following fixes:
- fix memory leak on probe failure
- fix possible access of dropped drvdata from receive_buf
- Link to v10: https://patch.msgid.link/20260530-rust_serdev-v10-0-65d1d5db876c@posteo.de
Changes in v10:
- revert everything from v9, except BoundInternal
- use mutex to ensure receive_buf won't be called on a dropped drvdata.
- Link to v9: https://patch.msgid.link/20260530-rust_serdev-v9-0-f8b5fccb49c3@posteo.de
Changes in v9:
- make use of BoundInternal
- use PrivateData wrapper and drop rust_private_data field
- use non-devm version of serdev_device_open
- Link to v8: https://patch.msgid.link/20260530-rust_serdev-v8-0-2a95f1da22a7@posteo.de
Changes in v8:
- adapted to driver-lifetime v5 patch series
- add MAINTAINERS file patch
- Link to v7: https://patch.msgid.link/20260429-rust_serdev-v7-0-0d89c791b5c8@posteo.de
Changes in v7:
- adapted to driver-lifetime patch series
- Link to v6: https://patch.msgid.link/20260427-rust_serdev-v6-0-173798d5e1a3@posteo.de
Changes in v6:
- rebased onto v7.1-rc1
- Link to v5: https://patch.msgid.link/20260420-rust_serdev-v5-0-57e8ba0519f3@posteo.de
Changes in v5:
- fix typo in documentation
- Link to v4: https://lore.kernel.org/r/20260411-rust_serdev-v4-0-845e960c6627@posteo.de
Changes in v4:
- fixed not selecting rust serdev abstraction in sample
- Link to v3: https://lore.kernel.org/r/20260313-rust_serdev-v3-0-c9a3af214f7f@posteo.de
Changes in v3:
- fix vertical import style
- add Kconfig entry for the rust abstraction
- fix documentation in include/linux/serdev.h
- rename private_data to rust_private_data
- fix `complete_all` <-> `wait_for_completion` typo
- move drvdata_borrow call after the completion
- Link to v2: https://lore.kernel.org/r/20260306-rust_serdev-v2-0-e9b23b42b255@posteo.de
Changes in v2:
- fix documentation in `serdev::Driver::write` and
`serdev::Driver::write_all`
- remove use of `dev_info` in probe from the sample
- remove `properties_parse` from the sample
- add optional `baudrate` property to the sample
- remove 1. patch
- remove `TryFrom<&device::Device<Ctx>> for &serdev::Device<Ctx>`
implementation
- fix import style
- add patch to return reference in `devres::register` to fix safety
issue
- add patch to add private data to serdev_device, to fix
`Device.drvdata()` from failing
- simplify abstraction by removing ability to receive the initial
transmission. It may be added later in a separate patch series if
needed.
- Link to v1: https://lore.kernel.org/r/20251220-rust_serdev-v1-0-e44645767621@posteo.de
---
Markus Probst (3):
rust: add basic serial device bus abstractions
samples: rust: add Rust serial device bus sample device driver
MAINTAINERS: serdev: Add self for serdev
MAINTAINERS | 5 +-
drivers/tty/serdev/Kconfig | 7 +
rust/bindings/bindings_helper.h | 1 +
rust/helpers/helpers.c | 1 +
rust/helpers/serdev.c | 22 ++
rust/kernel/lib.rs | 2 +
rust/kernel/serdev.rs | 599 +++++++++++++++++++++++++++++++++++++
samples/rust/Kconfig | 11 +
samples/rust/Makefile | 1 +
samples/rust/rust_driver_serdev.rs | 90 ++++++
10 files changed, 738 insertions(+), 1 deletion(-)
---
base-commit: 1137d8b5df06137fb49513cc923b3b24d94cb809
change-id: 20251217-rust_serdev-ee5481e9085c
prerequisite-message-id: 20260530132736.3298549-1-dakr@kernel.org
prerequisite-patch-id: 310c6bee038ca3909a8e5e58ec12b74f7189b869
prerequisite-patch-id: 92812c3d42b29504838e6dc66c307ff5c035bb5e
On Wed, Jul 15, 2026 at 09:00:14PM +0000, Markus Probst wrote: > This patch series adds the serdev device bus rust abstraction into the > kernel. > > This abstraction will be used by a driver, > which targets the MCU devices in Synology devices. > > Kari Argillander also messaged me, stating that he wants to write a > watchdog driver with this abstraction (needing initial device data). > > This series depends on [1]. > > [1] https://lore.kernel.org/rust-for-linux/20260530132736.3298549-1-dakr@kernel.org/ > > Signed-off-by: Markus Probst <markus.probst@posteo.de> Given there are no objections, I'll go queue this up now, thanks. greg k-h
On 7/17/26 12:55 PM, Greg Kroah-Hartman wrote: > On Wed, Jul 15, 2026 at 09:00:14PM +0000, Markus Probst wrote: >> This patch series adds the serdev device bus rust abstraction into the >> kernel. >> >> This abstraction will be used by a driver, >> which targets the MCU devices in Synology devices. >> >> Kari Argillander also messaged me, stating that he wants to write a >> watchdog driver with this abstraction (needing initial device data). >> >> This series depends on [1]. >> >> [1] https://lore.kernel.org/rust-for-linux/20260530132736.3298549-1-dakr@kernel.org/ >> >> Signed-off-by: Markus Probst <markus.probst@posteo.de> > > Given there are no objections, I'll go queue this up now, thanks. You'll need the patches from [1] as well. Thanks, Danilo
On Fri, 2026-07-17 at 12:55 +0200, Greg Kroah-Hartman wrote: > On Wed, Jul 15, 2026 at 09:00:14PM +0000, Markus Probst wrote: > > This patch series adds the serdev device bus rust abstraction into the > > kernel. > > > > This abstraction will be used by a driver, > > which targets the MCU devices in Synology devices. > > > > Kari Argillander also messaged me, stating that he wants to write a > > watchdog driver with this abstraction (needing initial device data). > > > > This series depends on [1]. > > > > [1] https://lore.kernel.org/rust-for-linux/20260530132736.3298549-1-dakr@kernel.org/ > > > > Signed-off-by: Markus Probst <markus.probst@posteo.de> > > Given there are no objections, I'll go queue this up now, thanks. Thanks for merging, but I haven't seen the dependency https://lore.kernel.org/rust-for-linux/20260530132736.3298549-1-dakr@kernel.org/ getting picked yet (its at least not in linux-next), so it might not even compile. Not sure whats holding the patch back though. Thanks - Markus Probst > > greg k-h
On 7/17/26 1:14 PM, Markus Probst wrote: > On Fri, 2026-07-17 at 12:55 +0200, Greg Kroah-Hartman wrote: >> On Wed, Jul 15, 2026 at 09:00:14PM +0000, Markus Probst wrote: >>> This patch series adds the serdev device bus rust abstraction into the >>> kernel. >>> >>> This abstraction will be used by a driver, >>> which targets the MCU devices in Synology devices. >>> >>> Kari Argillander also messaged me, stating that he wants to write a >>> watchdog driver with this abstraction (needing initial device data). >>> >>> This series depends on [1]. >>> >>> [1] https://lore.kernel.org/rust-for-linux/20260530132736.3298549-1-dakr@kernel.org/ >>> >>> Signed-off-by: Markus Probst <markus.probst@posteo.de> >> >> Given there are no objections, I'll go queue this up now, thanks. > Thanks for merging, but I haven't seen the dependency > > https://lore.kernel.org/rust-for-linux/20260530132736.3298549-1-dakr@kernel.org/ > > getting picked yet (its at least not in linux-next), so it might not > even compile. Not sure whats holding the patch back though. (Ah, saw this just after I replied to the other thread.) Nothing is holding them back other than requiring a user (which is your work), so I did not pick them up. Also note that tty and driver-core are different trees, so picking it up in driver-core would not have helped tty. Thanks, Danilo
On Fri, Jul 17, 2026 at 01:22:40PM +0200, Danilo Krummrich wrote: > On 7/17/26 1:14 PM, Markus Probst wrote: > > On Fri, 2026-07-17 at 12:55 +0200, Greg Kroah-Hartman wrote: > >> On Wed, Jul 15, 2026 at 09:00:14PM +0000, Markus Probst wrote: > >>> This patch series adds the serdev device bus rust abstraction into the > >>> kernel. > >>> > >>> This abstraction will be used by a driver, > >>> which targets the MCU devices in Synology devices. > >>> > >>> Kari Argillander also messaged me, stating that he wants to write a > >>> watchdog driver with this abstraction (needing initial device data). > >>> > >>> This series depends on [1]. > >>> > >>> [1] https://lore.kernel.org/rust-for-linux/20260530132736.3298549-1-dakr@kernel.org/ > >>> > >>> Signed-off-by: Markus Probst <markus.probst@posteo.de> > >> > >> Given there are no objections, I'll go queue this up now, thanks. > > Thanks for merging, but I haven't seen the dependency > > > > https://lore.kernel.org/rust-for-linux/20260530132736.3298549-1-dakr@kernel.org/ > > > > getting picked yet (its at least not in linux-next), so it might not > > even compile. Not sure whats holding the patch back though. > (Ah, saw this just after I replied to the other thread.) > > Nothing is holding them back other than requiring a user (which is your work), > so I did not pick them up. > > Also note that tty and driver-core are different trees, so picking it up in > driver-core would not have helped tty. Should I drop this from the tty tree and take it through driver-core instead? If so, no problem for me, just let me know. thanks, greg k-h
On Fri Jul 17, 2026 at 1:03 PM BST, Greg Kroah-Hartman wrote: > On Fri, Jul 17, 2026 at 01:22:40PM +0200, Danilo Krummrich wrote: >> On 7/17/26 1:14 PM, Markus Probst wrote: >> > On Fri, 2026-07-17 at 12:55 +0200, Greg Kroah-Hartman wrote: >> >> On Wed, Jul 15, 2026 at 09:00:14PM +0000, Markus Probst wrote: >> >>> This patch series adds the serdev device bus rust abstraction into the >> >>> kernel. >> >>> >> >>> This abstraction will be used by a driver, >> >>> which targets the MCU devices in Synology devices. >> >>> >> >>> Kari Argillander also messaged me, stating that he wants to write a >> >>> watchdog driver with this abstraction (needing initial device data). >> >>> >> >>> This series depends on [1]. >> >>> >> >>> [1] https://lore.kernel.org/rust-for-linux/20260530132736.3298549-1-dakr@kernel.org/ >> >>> >> >>> Signed-off-by: Markus Probst <markus.probst@posteo.de> >> >> >> >> Given there are no objections, I'll go queue this up now, thanks. >> > Thanks for merging, but I haven't seen the dependency >> > >> > https://lore.kernel.org/rust-for-linux/20260530132736.3298549-1-dakr@kernel.org/ >> > >> > getting picked yet (its at least not in linux-next), so it might not >> > even compile. Not sure whats holding the patch back though. >> (Ah, saw this just after I replied to the other thread.) >> >> Nothing is holding them back other than requiring a user (which is your work), >> so I did not pick them up. >> >> Also note that tty and driver-core are different trees, so picking it up in >> driver-core would not have helped tty. > > Should I drop this from the tty tree and take it through driver-core > instead? If so, no problem for me, just let me know. FWIW this series will also conflict quite significantly with https://lore.kernel.org/driver-core/20260629-id_info-v2-0-56fccbe9c5ef@garyguo.net/ which is routed via driver-core tree. Best, GAry
On Fri Jul 17, 2026 at 2:07 PM CEST, Gary Guo wrote:
> FWIW this series will also conflict quite significantly with
> https://lore.kernel.org/driver-core/20260629-id_info-v2-0-56fccbe9c5ef@garyguo.net/
> which is routed via driver-core tree.
Yeah, but I think it should be trivial (see below)? However, routing serdev
through driver-core does indeed avoid this.
Thanks,
Danilo
diff --git a/rust/kernel/serdev.rs b/rust/kernel/serdev.rs
index 0ffcef1849d2..a1161dd9f37f 100644
--- a/rust/kernel/serdev.rs
+++ b/rust/kernel/serdev.rs
@@ -174,7 +174,8 @@ extern "C" fn probe_callback(sdev: *mut bindings::serdev_device) -> kernel::ffi:
//
// INVARIANT: `sdev` is valid for the duration of `probe_callback()`.
let sdev = unsafe { &*sdev.cast::<Device<device::CoreInternal<'_>>>() };
- let info = <Self as driver::Adapter>::id_info(sdev.as_ref());
+ // SAFETY: `sdev` has been matched by the serial device bus via its device ID table.
+ let info = unsafe { <Self as driver::Adapter>::id_info(sdev.as_ref()) };
from_result(|| {
sdev.as_ref().set_drvdata(try_pin_init!(PrivateData::<T> {
@@ -334,7 +335,6 @@ macro_rules! module_serdev_device_driver {
///
/// kernel::of_device_table!(
/// OF_TABLE,
-/// MODULE_OF_TABLE,
/// <MyDriver as serdev::Driver>::IdInfo,
/// [
/// (of::DeviceId::new(c"test,device"), ())
@@ -343,7 +343,6 @@ macro_rules! module_serdev_device_driver {
///
/// kernel::acpi_device_table!(
/// ACPI_TABLE,
-/// MODULE_ACPI_TABLE,
/// <MyDriver as serdev::Driver>::IdInfo,
/// [
/// (acpi::DeviceId::new(c"LNUXBEEF"), ())
diff --git a/samples/rust/rust_driver_serdev.rs b/samples/rust/rust_driver_serdev.rs
index a12b1412db30..51b4898cd855 100644
--- a/samples/rust/rust_driver_serdev.rs
+++ b/samples/rust/rust_driver_serdev.rs
@@ -20,14 +20,12 @@ struct SampleDriver {
kernel::of_device_table!(
OF_TABLE,
- MODULE_OF_TABLE,
<SampleDriver as serdev::Driver>::IdInfo,
[(of::DeviceId::new(c"test,rust_driver_serdev"), ())]
);
kernel::acpi_device_table!(
ACPI_TABLE,
- MODULE_ACPI_TABLE,
<SampleDriver as serdev::Driver>::IdInfo,
[(acpi::DeviceId::new(c"LNUXBEEF"), ())]
);
On Fri, 2026-07-17 at 14:20 +0200, Danilo Krummrich wrote:
> diff --git a/rust/kernel/serdev.rs b/rust/kernel/serdev.rs
> index 0ffcef1849d2..a1161dd9f37f 100644
> --- a/rust/kernel/serdev.rs
> +++ b/rust/kernel/serdev.rs
> @@ -174,7 +174,8 @@ extern "C" fn probe_callback(sdev: *mut bindings::serdev_device) -> kernel::ffi:
> //
> // INVARIANT: `sdev` is valid for the duration of `probe_callback()`.
> let sdev = unsafe { &*sdev.cast::<Device<device::CoreInternal<'_>>>() };
> - let info = <Self as driver::Adapter>::id_info(sdev.as_ref());
> + // SAFETY: `sdev` has been matched by the serial device bus via its device ID table.
> + let info = unsafe { <Self as driver::Adapter>::id_info(sdev.as_ref()) };
>
> from_result(|| {
> sdev.as_ref().set_drvdata(try_pin_init!(PrivateData::<T> {
> @@ -334,7 +335,6 @@ macro_rules! module_serdev_device_driver {
> ///
> /// kernel::of_device_table!(
> /// OF_TABLE,
> -/// MODULE_OF_TABLE,
> /// <MyDriver as serdev::Driver>::IdInfo,
> /// [
> /// (of::DeviceId::new(c"test,device"), ())
> @@ -343,7 +343,6 @@ macro_rules! module_serdev_device_driver {
> ///
> /// kernel::acpi_device_table!(
> /// ACPI_TABLE,
> -/// MODULE_ACPI_TABLE,
> /// <MyDriver as serdev::Driver>::IdInfo,
> /// [
> /// (acpi::DeviceId::new(c"LNUXBEEF"), ())
> diff --git a/samples/rust/rust_driver_serdev.rs b/samples/rust/rust_driver_serdev.rs
> index a12b1412db30..51b4898cd855 100644
> --- a/samples/rust/rust_driver_serdev.rs
> +++ b/samples/rust/rust_driver_serdev.rs
> @@ -20,14 +20,12 @@ struct SampleDriver {
>
> kernel::of_device_table!(
> OF_TABLE,
> - MODULE_OF_TABLE,
> <SampleDriver as serdev::Driver>::IdInfo,
> [(of::DeviceId::new(c"test,rust_driver_serdev"), ())]
> );
>
> kernel::acpi_device_table!(
> ACPI_TABLE,
> - MODULE_ACPI_TABLE,
> <SampleDriver as serdev::Driver>::IdInfo,
> [(acpi::DeviceId::new(c"LNUXBEEF"), ())]
> );
Not sure if necessary for a conflict resolution, but
Reviewed-by: Markus Probst <markus.probst@posteo.de>
Thanks
- Markus Probst
On Fri Jul 17, 2026 at 2:03 PM CEST, Greg Kroah-Hartman wrote: > Should I drop this from the tty tree and take it through driver-core > instead? If so, no problem for me, just let me know. Either should work, you can also take [1] through the tty tree, I don't think there will be any conflicts. [1] https://lore.kernel.org/rust-for-linux/20260530132736.3298549-1-dakr@kernel.org/
On Fri, Jul 17, 2026 at 02:07:48PM +0200, Danilo Krummrich wrote: > On Fri Jul 17, 2026 at 2:03 PM CEST, Greg Kroah-Hartman wrote: > > Should I drop this from the tty tree and take it through driver-core > > instead? If so, no problem for me, just let me know. > > Either should work, you can also take [1] through the tty tree, I don't think > there will be any conflicts. > > [1] https://lore.kernel.org/rust-for-linux/20260530132736.3298549-1-dakr@kernel.org/ > Hm, that gets messy. I'll just add these patches to the driver core tree, along with the above linked ones, to keep things simple. thanks, greg k-h
On Fri Jul 17, 2026 at 3:12 PM CEST, Greg Kroah-Hartman wrote: > Hm, that gets messy. I'll just add these patches to the driver core > tree, along with the above linked ones, to keep things simple. Yeah, that's cleaner, thanks!
© 2016 - 2026 Red Hat, Inc.