From: Michal Wilczynski <m.wilczynski@samsung.com>
To: "Uwe Kleine-König" <ukleinek@kernel.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
"Guo Ren" <guoren@kernel.org>, "Fu Wei" <wefu@redhat.com>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Alexandre Ghiti" <alex@ghiti.fr>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Benno Lossin" <lossin@kernel.org>,
"Michael Turquette" <mturquette@baylibre.com>,
"Drew Fustini" <fustini@kernel.org>,
"Daniel Almeida" <daniel.almeida@collabora.com>
Cc: linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
rust-for-linux@vger.kernel.org, linux-riscv@lists.infradead.org,
devicetree@vger.kernel.org,
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Subject: Re: [PATCH v14 0/7] Rust Abstractions for PWM subsystem with TH1520 PWM driver
Date: Fri, 12 Sep 2025 14:30:09 +0200 [thread overview]
Message-ID: <ba80945d-c3a4-457a-aa23-532df8709049@samsung.com> (raw)
In-Reply-To: <20250820-rust-next-pwm-working-fan-for-sending-v14-0-df2191621429@samsung.com>
On 8/20/25 10:35, Michal Wilczynski wrote:
> This patch series introduces Rust support for the T-HEAD TH1520 PWM
> controller and demonstrates its use for fan control on the Sipeed Lichee
> Pi 4A board.
>
> The primary goal of this patch series is to introduce a basic set of
> Rust abstractions for the Linux PWM subsystem. As a first user and
> practical demonstration of these abstractions, the series also provides
> a functional PWM driver for the T-HEAD TH1520 SoC. This allows control
> of its PWM channels and ultimately enables temperature controlled fan
> support for the Lichee Pi 4A board. This work aims to explore the use of
> Rust for PWM drivers and lay a foundation for potential future Rust
> based PWM drivers.
>
> The core of this series is a new rust/kernel/pwm.rs module that provides
> abstractions for writing PWM chip provider drivers in Rust. This has
> been significantly reworked from v1 based on extensive feedback. The key
> features of the new abstraction layer include:
>
> - Ownership and Lifetime Management: The pwm::Chip wrapper is managed
> by ARef, correctly tying its lifetime to its embedded struct device
> reference counter. Chip registration is handled by a pwm::Registration
> RAII guard, which guarantees that pwmchip_add is always paired with
> pwmchip_remove, preventing resource leaks.
>
> - Modern and Safe API: The PwmOps trait is now based on the modern
> waveform API (round_waveform_tohw, write_waveform, etc.) as recommended
> by the subsystem maintainer. It is generic over a driver's
> hardware specific data structure, moving all unsafe serialization logic
> into the abstraction layer and allowing drivers to be written in 100%
> safe Rust.
>
> - Ergonomics: The API provides safe, idiomatic wrappers for other PWM
> types (State, Args, Device, etc.) and uses standard kernel error
> handling patterns.
>
> The series is structured as follows:
> - Expose static function pwmchip_release.
> - Rust PWM Abstractions: The new safe abstraction layer.
> - TH1520 PWM Driver: A new Rust driver for the TH1520 SoC, built on
> top of the new abstractions.
> - Device Tree Bindings & Nodes: The remaining patches add the necessary
> DT bindings and nodes for the TH1520 PWM controller, and the PWM fan
> configuration for the Lichee Pi 4A board.
>
> Testing:
> Tested on the TH1520 SoC. The fan works correctly. The duty/period
> calculations are correct. Fan starts slow when the chip is not hot and
> gradually increases the speed when PVT reports higher temperatures.
>
> The patches doesn't contain any dependencies that are not currently in
> the mainline kernel anymore.
>
> ---
> Changes in v14:
> - Re-base on top of 6.17-rc1.
> - Cosmetic change in label function.
> - Link to v13: https://lore.kernel.org/r/20250806-rust-next-pwm-working-fan-for-sending-v13-0-690b669295b6@samsung.com
>
> Changes in v13:
> - Re-add the T-HEAD TH1520 PWM driver and its device tree bindings, as
> Iomem series got merged into mainline kernel.
> - Fix Args struct to be consistent with State - no Opaque needed for
> copies.
> - Replace tuple retur type in the PwmOps trait with dedicated struct
> for improved clarity.
> - Use build_assert for WfHw size, as it doesn't have to be runtime
> check.
> - Various cosmetic changes.
> - Link to v12: https://lore.kernel.org/r/20250717-rust-next-pwm-working-fan-for-sending-v12-0-40f73defae0c@samsung.com
>
> Changes in v12:
> - Reworked the PWM abstractions to use the subclassing pattern as
> suggested by reviewers.
> - pwm::Chip and its driver data are now allocated in a single, contiguous
> memory block via pwmchip_alloc() sizeof_priv argument.
> - Chip::new() now uses the pin init API to construct the driver data
> in place, removing the need for a separate allocation.
> - The PwmOps trait is now implemented directly by the driver data struct
> itself, removing the DrvData associated type and the ForeignOwnable
> trait.
> - The custom release handler has been updated to call drop_in_place on the driver
> data, ensuring destructors are run correctly before the underlying
> memory is freed.
> - Moved the pwmchip_release prototype in the C header to a separate
> section to clarify it is for FFI use only, as requested.
> - Added a Prerequisite-patch-id trailer to the cover letter to declare
> the dependency on the PWM_WFHWSIZE patch.
>
> - Link to v11: https://lore.kernel.org/r/20250710-rust-next-pwm-working-fan-for-sending-v11-0-93824a16f9ec@samsung.com
>
> Changes in v11:
> - Dropped driver and DT commits, as they don't compile based on publicly
> known commit.
> - Re-based on top of pwm/for-next.
> - Reverted back to devres::Devres::new_foreign_owned, as pwm/for-next
> doesn't contain 'register' re-factor, which is present in linux-next,
> queued for the next merge window. The conflict is trivial, simply
> change 'new_foreign_owned' -> 'register'.
> - Added list to MAINTAINERS entry as requested.
> - Link to v10: https://lore.kernel.org/r/20250707-rust-next-pwm-working-fan-for-sending-v10-0-d0c5cf342004@samsung.com
>
> Changes in v10:
> - Exported the C pwmchip_release function and called it from the custom
> Rust release_callback to fix a memory leak of the pwm_chip struct.
> - Removed the PwmOps::free callback, as it is not needed for idiomatic
> Rust resource management.
> - Removed the redundant is_null check for drvdata in the release handler,
> as the Rust API guarantees a valid pointer is always provided.
>
> - Link to v9: https://lore.kernel.org/r/20250706-rust-next-pwm-working-fan-for-sending-v9-0-42b5ac2101c7@samsung.com
>
> Changes in v9:
> - Encapsulated vtable setup in Chip::new(): The Chip::new() function is
> now generic over the PwmOps implementation. This allows it to create and
> assign the vtable internally, which simplifies the public API by
> removing the ops_vtable parameter from Registration::register().
> - Fixed memory leak with a release handler: A custom release_callback is
> now assigned to the embedded struct device's release hook. This
> guarantees that driver specific data is always freed when the chip is
> destroyed, even if registration fails.
> - The PwmOpsVTable is now defined as a const associated item to ensure
> it has a 'static lifetime.
> - Combined introductory commits: The Device, Chip, and PwmOps abstractions
> are now introduced in a single commit. This was necessary to resolve the
> circular dependencies between them and present a clean, compilable unit
> for review.
>
> - Link to v8: https://lore.kernel.org/r/20250704-rust-next-pwm-working-fan-for-sending-v8-0-951e5482c9fd@samsung.com
>
> Changes in v8:
> - Dropped already accepted commit, re-based on top of linux-next
> - Reworked the Chip and PwmOps APIs to address the drvdata() type-safety
> comment. Chip is now generic, and PwmOps uses an associated type
> to provide compile-time guarantees.
> - Added a parent device sanity check to Registration::register().
> - Updated drvdata() to return the idiomatic T::Borrowed<'_>.
> - added temporary unsafe blocks in the driver, as the current
> abstraction for Clk is neiter Safe nor Sync. I think eventually
> proper abstraction for Clk will be added as in a current state it's
> not very useful.
>
> - Link to v7: https://lore.kernel.org/r/20250702-rust-next-pwm-working-fan-for-sending-v7-0-67ef39ff1d29@samsung.com
>
> Changes in v7:
> - Made parent_device function private and moved casts to Device<Bound>
> there as well.
> - Link to v6: https://lore.kernel.org/r/20250701-rust-next-pwm-working-fan-for-sending-v6-0-2710932f6f6b@samsung.com
>
> Changes in v6:
> - Re-based on top of linux-next, dropped two already accepted commits.
> - After re-basing the IoMem dependent patchset stopped working,
> reworked it to use similar API like the PCI subsystem (I think it
> will end up the same). Re-worked the driver for it as well.
> - Remove the apply and get_state callbacks, and most of the State as
> well, as the old way of implementing drivers should not be possible
> in Rust. Left only enabled(), since it's useful for my driver.
> - Removed the public set_drvdata() method from pwm::Chip
> - Moved WFHWSIZE to the public include/linux/pwm.h header and renamed it
> to PWM_WFHWSIZE, allowing bindgen to create safe FFI bindings.
> - Corrected the ns_to_cycles integer calculation in the TH1520 driver to
> handle overflow correctly.
> - Updated the Kconfig entry for the TH1520 driver to select the Rust
> abstractions for a better user experience.
>
> - Link to v5: https://lore.kernel.org/r/20250623-rust-next-pwm-working-fan-for-sending-v5-0-0ca23747c23e@samsung.com
>
> Changes in v5:
> - Reworked `pwm::Chip` creation to take driver data directly, which
> allowed making the `chip.drvdata()` accessor infallible
> - added missing `pwm.c` file lost during the commit split (sorry !)
> - Link to v4: https://lore.kernel.org/r/20250618-rust-next-pwm-working-fan-for-sending-v4-0-a6a28f2b6d8a@samsung.com
>
> Changes in v4:
> - Reworked the pwm::Registration API to use the devres framework,
> addressing lifetime issue.
> - Corrected the PwmOps trait and its callbacks to use immutable references
> (&Chip, &Device) for improved safety.
> - Applied various code style and naming cleanups based on feedback
>
> - Link to v3: https://lore.kernel.org/r/20250617-rust-next-pwm-working-fan-for-sending-v3-0-1cca847c6f9f@samsung.com
>
> Changes in v3:
> - Addressed feedback from Uwe by making multiple changes to the TH1520
> driver and the abstraction layer.
> - Split the core PWM abstractions into three focused commits to ease
> review per Benno request.
> - Confirmed the driver now works correctly with CONFIG_PWM_DEBUG enabled
> by implementing the full waveform API, which correctly reads the
> hardware state.
> - Refactored the Rust code to build cleanly with
> CONFIG_RUST_BUILD_ASSERT_ALLOW=n, primarily by using the try_* family of
> functions for IoMem access.
> - Included several cosmetic changes and cleanups to the abstractions
> per Miguel review.
>
> - Link to v2: https://lore.kernel.org/r/20250610-rust-next-pwm-working-fan-for-sending-v2-0-753e2955f110@samsung.com
>
> Changes in v2:
> - Reworked the PWM abstraction layer based on extensive feedback.
> - Replaced initial devm allocation with a proper ARef<Chip> lifetime model
> using AlwaysRefCounted.
> - Implemented a Registration RAII guard to ensure safe chip add/remove.
> - Migrated the PwmOps trait from the legacy .apply callback to the modern
> waveform API.
> - Refactored the TH1520 driver to use the new, safer abstractions.
> - Added a patch to mark essential bus clocks as CLK_IGNORE_UNUSED to fix
> boot hangs when the PWM and thermal sensors are enabled.
> - Link to v1: https://lore.kernel.org/r/20250524-rust-next-pwm-working-fan-for-sending-v1-0-bdd2d5094ff7@samsung.com
>
> ---
> Michal Wilczynski (7):
> pwm: Export `pwmchip_release` for external use
> rust: pwm: Add Kconfig and basic data structures
> rust: pwm: Add complete abstraction layer
> pwm: Add Rust driver for T-HEAD TH1520 SoC
> dt-bindings: pwm: thead: Add T-HEAD TH1520 PWM controller
> riscv: dts: thead: Add PWM controller node
> riscv: dts: thead: Add PWM fan and thermal control
>
> .../devicetree/bindings/pwm/thead,th1520-pwm.yaml | 48 ++
> MAINTAINERS | 10 +
> arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dts | 67 ++
> arch/riscv/boot/dts/thead/th1520.dtsi | 7 +
> drivers/pwm/Kconfig | 24 +
> drivers/pwm/Makefile | 1 +
> drivers/pwm/core.c | 3 +-
> drivers/pwm/pwm_th1520.rs | 355 +++++++++
> include/linux/pwm.h | 6 +
> rust/bindings/bindings_helper.h | 1 +
> rust/helpers/helpers.c | 1 +
> rust/helpers/pwm.c | 20 +
> rust/kernel/lib.rs | 2 +
> rust/kernel/pwm.rs | 790 +++++++++++++++++++++
> 14 files changed, 1334 insertions(+), 1 deletion(-)
> ---
> base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
> change-id: 20250524-rust-next-pwm-working-fan-for-sending-552ad2d1b193
>
> Best regards,
Hi Uwe
Pinging in case this thread got lost in your mailbox.
Best regards,
--
Michal Wilczynski <m.wilczynski@samsung.com>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
prev parent reply other threads:[~2025-09-12 12:30 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20250820083539eucas1p127f39561c51a44d7d2b5ace73b5eca7b@eucas1p1.samsung.com>
2025-08-20 8:35 ` [PATCH v14 0/7] Rust Abstractions for PWM subsystem with TH1520 PWM driver Michal Wilczynski
2025-08-20 8:35 ` [PATCH v14 1/7] pwm: Export `pwmchip_release` for external use Michal Wilczynski
2025-08-20 20:30 ` Elle Rhumsaa
2025-09-15 10:00 ` Uwe Kleine-König
2025-09-24 19:30 ` Michal Wilczynski
2025-08-20 8:35 ` [PATCH v14 2/7] rust: pwm: Add Kconfig and basic data structures Michal Wilczynski
2025-08-20 20:35 ` Elle Rhumsaa
2025-09-15 10:13 ` Uwe Kleine-König
2025-09-24 20:10 ` Michal Wilczynski
2025-08-20 8:35 ` [PATCH v14 3/7] rust: pwm: Add complete abstraction layer Michal Wilczynski
2025-08-20 21:11 ` Elle Rhumsaa
2025-08-21 22:35 ` Michal Wilczynski
2025-08-20 8:35 ` [PATCH v14 4/7] pwm: Add Rust driver for T-HEAD TH1520 SoC Michal Wilczynski
2025-08-20 21:14 ` Elle Rhumsaa
2025-09-19 7:10 ` Uwe Kleine-König
2025-09-25 11:33 ` Michal Wilczynski
2025-08-20 8:35 ` [PATCH v14 5/7] dt-bindings: pwm: thead: Add T-HEAD TH1520 PWM controller Michal Wilczynski
2025-08-20 21:16 ` Elle Rhumsaa
2025-08-20 8:35 ` [PATCH v14 6/7] riscv: dts: thead: Add PWM controller node Michal Wilczynski
2025-08-20 21:17 ` Elle Rhumsaa
2025-08-20 8:35 ` [PATCH v14 7/7] riscv: dts: thead: Add PWM fan and thermal control Michal Wilczynski
2025-08-20 21:18 ` Elle Rhumsaa
2025-08-22 20:49 ` Drew Fustini
2025-08-23 10:13 ` Michal Wilczynski
2025-08-23 10:17 ` Michal Wilczynski
2025-08-23 14:20 ` Miguel Ojeda
2025-09-12 12:30 ` Michal Wilczynski [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ba80945d-c3a4-457a-aa23-532df8709049@samsung.com \
--to=m.wilczynski@samsung.com \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=alex@ghiti.fr \
--cc=aliceryhl@google.com \
--cc=aou@eecs.berkeley.edu \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=conor+dt@kernel.org \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=fustini@kernel.org \
--cc=gary@garyguo.net \
--cc=guoren@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=lossin@kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mturquette@baylibre.com \
--cc=ojeda@kernel.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robh@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
--cc=ukleinek@kernel.org \
--cc=wefu@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox