| Message ID | 20241009105759.579579-1-me@kloenk.dev |
|---|---|
| Headers | show |
| Series | rust: LED abstractions | expand |
On Wed, 09 Oct 2024, Fiona Behrens wrote: > This RFC implements a basic LED abstraction to show how this would work with rust. > > Currently this just implements a sample driver, to show how to use the abstraction, which just > prints the requested state, supporting a on/off LED and an led with brightness level up to 255 and > hardware blinking. I intend to write a hardware specific driver for submitting. > > The abstractions is a generic struct that holds a generic driver data on which the vtable is > implemented. Because this struct also holds the c led_classdev (include/linux/leds.h) struct this > struct is pinned and is using pin_init to create and directly register the LED. > Dropping the struct unregisteres the LED. I plan to also add devm functions later, but as device > abstractions in rust are not yet that far I opted agains that for the first iteration of the LED > abstractions. > > This is currently using core::time::Duration for the blinking interval, but will likely change that > to use the Delta time type from FUJITA Tomonori [1]. > > This is requiring the Opaque::try_ffi_init patch by Alice Ryhl[2] which just got merged into > char-misc-testing. > > [1]: https://lore.kernel.org/rust-for-linux/20241005122531.20298-3-fujita.tomonori@gmail.com/ > [2]: https://lore.kernel.org/rust-for-linux/20240926-b4-miscdevice-v1-1-7349c2b2837a@google.com/ > > Fiona Behrens (2): > rust: LED abstraction > samples: rust: led sample > > rust/kernel/leds.rs | 399 +++++++++++++++++++++++++++++++++++++++ > rust/kernel/lib.rs | 2 + > samples/rust/Kconfig | 10 + > samples/rust/Makefile | 1 + > samples/rust/rust_led.rs | 103 ++++++++++ > 5 files changed, 515 insertions(+) > create mode 100644 rust/kernel/leds.rs > create mode 100644 samples/rust/rust_led.rs FYI: I'm not ignoring this patch-set. On the contrary. I'm trying to place myself into a position where I can not only review it with some confidence, but use it to author LED drivers.
On 11 Nov 2024, at 10:41, Lee Jones wrote: > On Wed, 09 Oct 2024, Fiona Behrens wrote: > >> This RFC implements a basic LED abstraction to show how this would work with rust. >> >> Currently this just implements a sample driver, to show how to use the abstraction, which just >> prints the requested state, supporting a on/off LED and an led with brightness level up to 255 and >> hardware blinking. I intend to write a hardware specific driver for submitting. >> >> The abstractions is a generic struct that holds a generic driver data on which the vtable is >> implemented. Because this struct also holds the c led_classdev (include/linux/leds.h) struct this >> struct is pinned and is using pin_init to create and directly register the LED. >> Dropping the struct unregisteres the LED. I plan to also add devm functions later, but as device >> abstractions in rust are not yet that far I opted agains that for the first iteration of the LED >> abstractions. >> >> This is currently using core::time::Duration for the blinking interval, but will likely change that >> to use the Delta time type from FUJITA Tomonori [1]. >> >> This is requiring the Opaque::try_ffi_init patch by Alice Ryhl[2] which just got merged into >> char-misc-testing. >> >> [1]: https://lore.kernel.org/rust-for-linux/20241005122531.20298-3-fujita.tomonori@gmail.com/ >> [2]: https://lore.kernel.org/rust-for-linux/20240926-b4-miscdevice-v1-1-7349c2b2837a@google.com/ >> >> Fiona Behrens (2): >> rust: LED abstraction >> samples: rust: led sample >> >> rust/kernel/leds.rs | 399 +++++++++++++++++++++++++++++++++++++++ >> rust/kernel/lib.rs | 2 + >> samples/rust/Kconfig | 10 + >> samples/rust/Makefile | 1 + >> samples/rust/rust_led.rs | 103 ++++++++++ >> 5 files changed, 515 insertions(+) >> create mode 100644 rust/kernel/leds.rs >> create mode 100644 samples/rust/rust_led.rs > > FYI: I'm not ignoring this patch-set. On the contrary. I'm trying to > place myself into a position where I can not only review it with some > confidence, but use it to author LED drivers. > Ah amazing, the first RFC was to probe for a general would LED accept rust code, and this sounds like a yes. Nice! Currently still working on a LED driver for a Lenovo board that does not (as of when I started, and think still not yet) have a C driver for the LED. Current things missing is a static dmi match table (idea is to hardcoded that for now) and a abstraction for port memory but working on that, and can otherwise just go around that with unsafe calls in the driver itself. - Fiona > -- > Lee Jones [李琼斯]