[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aDMHEcpJn8nyJHFV@pollux.localdomain>
Date: Sun, 25 May 2025 14:03:29 +0200
From: Danilo Krummrich <dakr@...nel.org>
To: Michal Wilczynski <m.wilczynski@...sung.com>
Cc: Uwe Kleine-König <ukleinek@...nel.org>,
Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>,
Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <benno.lossin@...ton.me>,
Andreas Hindborg <a.hindborg@...nel.org>,
Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
Drew Fustini <drew@...7.com>, Guo Ren <guoren@...nel.org>,
Fu Wei <wefu@...hat.com>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>,
Marek Szyprowski <m.szyprowski@...sung.com>,
linux-kernel@...r.kernel.org, linux-pwm@...r.kernel.org,
rust-for-linux@...r.kernel.org, linux-riscv@...ts.infradead.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH RFC 2/6] pwm: Add Rust driver for T-HEAD TH1520 SoC
On Sat, May 24, 2025 at 11:14:56PM +0200, Michal Wilczynski wrote:
> diff --git a/drivers/pwm/pwm_th1520.rs b/drivers/pwm/pwm_th1520.rs
> new file mode 100644
> index 0000000000000000000000000000000000000000..4665e293e8d0bdc1a62a4e295cdaf4d47b3dd134
> --- /dev/null
> +++ b/drivers/pwm/pwm_th1520.rs
> @@ -0,0 +1,272 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2025 Samsung Electronics Co., Ltd.
> +// Author: Michal Wilczynski <m.wilczynski@...sung.com>
> +
> +//! Rust T-HEAD TH1520 PWM driver
> +use kernel::{c_st
> +
> +struct Th1520PwmChipData {
> + clk: Clk,
> + iomem: kernel::devres::Devres<IoMem<0>>,
Why IoMem<0>? If you put the expected memory region size for this chip instead
all your subsequent accesses can be iomem.write() / iomem.read() rather than the
fallible try_{read,write}() variants.
> +impl Th1520PwmChipData {
> + fn _config(
> + &self,
> + hwpwm: u32,
> + duty_ns: u64,
> + period_ns: u64,
> + target_polarity: pwm::Polarity,
> + ) -> Result<u32> {
> + let regs = self.iomem.try_access().ok_or_else(|| {
> + pr_err!("PWM-{}: Failed to access I/O memory in _config\n", hwpwm);
Here and throughout the whole driver, please use the dev_*!() print macros.
Drivers have no reason to use the pr_*!() macros.
> +impl pwm::PwmOps for Th1520PwmChipData {
> + // This driver implements get_state
> + fn apply(
> + pwm_chip_ref: &mut pwm::Chip,
> + pwm_dev: &mut pwm::Device,
> + target_state: &pwm::State,
> + ) -> Result {
I assume those callbacks can't race with pwmchip_remove() called from driver
remove()? I.e. the callbacks are guaranteed to complete before pwmchip_remove()
completes?
If so, this function signature can provide the parent device of the pwm::Chip as
device::Device<device::Bound> reference.
This would allow you to access iomem more efficiently.
Instead of
data.iomem.try_access()
you could do
data.iomem.access(parent) // [1]
which does get you rid of the atomic check and the RCU read side critical
section implied by try_access().
Actually, I should have added this comment and explanation to the abstraction
patch, but forgot about it. :)
[1] https://gitlab.freedesktop.org/drm/kernel/-/blob/drm-next/rust/kernel/devres.rs?ref_type=heads#L213
Powered by blists - more mailing lists