lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <9f38bb32-9160-4acd-83d7-902d3e1cad72@samsung.com>
Date: Fri, 24 Oct 2025 18:17:46 +0200
From: Michal Wilczynski <m.wilczynski@...sung.com>
To: Uwe Kleine-König <ukleinek@...nel.org>
Cc: 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>, Andreas
	Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>, Trevor
	Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>, 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>, Benno
	Lossin <lossin@...nel.org>, Michael Turquette <mturquette@...libre.com>,
	Drew Fustini <fustini@...nel.org>, Daniel Almeida
	<daniel.almeida@...labora.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, Elle Rhumsaa
	<elle@...thered-steel.dev>, Krzysztof Kozlowski
	<krzysztof.kozlowski@...aro.org>
Subject: Re: [PATCH v16 0/7] Rust Abstractions for PWM subsystem with TH1520
 PWM driver



On 10/24/25 16:09, Uwe Kleine-König wrote:
> Hello Michael,
> 
> On Wed, Oct 22, 2025 at 10:34:42AM +0200, Michal Wilczynski wrote:
>> Since you mentioned last time that you were happy with the code, would
>> you please consider picking up this series for linux-next? It would be
>> great to get it in for wider testing to ensure everything is solid.
> 
> I took another look, and just being able to compile and understanding
> very little Rust, I came up with:
> 
> diff --git a/rust/kernel/pwm.rs b/rust/kernel/pwm.rs
> index 79fbb13cd47f..c8f9f5b61bfa 100644
> --- a/rust/kernel/pwm.rs
> +++ b/rust/kernel/pwm.rs
> @@ -15,38 +15,7 @@
>      prelude::*,
>      types::{ARef, AlwaysRefCounted, Opaque},
>  };
> -use core::{convert::TryFrom, marker::PhantomData, ptr::NonNull};
> +use core::{marker::PhantomData, ptr::NonNull};
> -
> -/// PWM polarity. Mirrors [`enum pwm_polarity`](srctree/include/linux/pwm.h).
> -#[derive(Copy, Clone, Debug, PartialEq, Eq)]
> -pub enum Polarity {
> -    /// Normal polarity (duty cycle defines the high period of the signal).
> -    Normal,
> -
> -    /// Inversed polarity (duty cycle defines the low period of the signal).
> -    Inversed,
> -}
> -
> -impl TryFrom<bindings::pwm_polarity> for Polarity {
> -    type Error = Error;
> -
> -    fn try_from(polarity: bindings::pwm_polarity) -> Result<Self, Error> {
> -        match polarity {
> -            bindings::pwm_polarity_PWM_POLARITY_NORMAL => Ok(Polarity::Normal),
> -            bindings::pwm_polarity_PWM_POLARITY_INVERSED => Ok(Polarity::Inversed),
> -            _ => Err(EINVAL),
> -        }
> -    }
> -}
> -
> -impl From<Polarity> for bindings::pwm_polarity {
> -    fn from(polarity: Polarity) -> Self {
> -        match polarity {
> -            Polarity::Normal => bindings::pwm_polarity_PWM_POLARITY_NORMAL,
> -            Polarity::Inversed => bindings::pwm_polarity_PWM_POLARITY_INVERSED,
> -        }
> -    }
> -}
>  
>  /// Represents a PWM waveform configuration.
>  /// Mirrors struct [`struct pwm_waveform`](srctree/include/linux/pwm.h).
> @@ -89,22 +58,6 @@ fn from(wf: Waveform) -> Self {
>      }
>  }
>  
> -/// Wrapper for PWM state [`struct pwm_state`](srctree/include/linux/pwm.h).
> -#[repr(transparent)]
> -pub struct State(bindings::pwm_state);
> -
> -impl State {
> -    /// Creates a `State` wrapper by taking ownership of a C `pwm_state` value.
> -    pub(crate) fn from_c(c_state: bindings::pwm_state) -> Self {
> -        State(c_state)
> -    }
> -
> -    /// Returns `true` if the PWM signal is enabled.
> -    pub fn enabled(&self) -> bool {
> -        self.0.enabled
> -    }
> -}
> -
>  /// Describes the outcome of a `round_waveform` operation.
>  #[derive(Debug, Clone, Copy, PartialEq, Eq)]
>  pub enum RoundingOutcome {
> @@ -164,13 +117,6 @@ pub fn label(&self) -> Option<&CStr> {
>          Some(unsafe { CStr::from_char_ptr(label_ptr) })
>      }
>  
> -    /// Gets a copy of the current state of this PWM device.
> -    pub fn state(&self) -> State {
> -        // SAFETY: `self.as_raw()` gives a valid pointer. `(*self.as_raw()).state`
> -        // is a valid `pwm_state` struct. `State::from_c` copies this data.
> -        State::from_c(unsafe { (*self.as_raw()).state })
> -    }
> -
>      /// Sets the PWM waveform configuration and enables the PWM signal.
>      pub fn set_waveform(&self, wf: &Waveform, exact: bool) -> Result {
>          let c_wf = bindings::pwm_waveform::from(*wf);
> 
> Does that make sense?

Hi Uwe,

Yes, that makes perfect sense.

I agree with your patch. I initially thought the State wrapper might be
necessary for the TH1520 driver, but I was able to refactor it to work
without it.

On reflection, both Polarity and State are really remnants of the older,
legacy API. Removing them is a good cleanup; it ensures future Rust
drivers will use the modern waveform API and avoids potential confusion.

> 
> I consider applying your series and put the above space on top, to
> create my first Rust patch :-)

Great ! Congratulations on your first Rust patch :-)

On a related note there is this diff necessary to make CLIPPY happy:
diff --git a/drivers/pwm/pwm_th1520.rs b/drivers/pwm/pwm_th1520.rs
index 0ad38b78be85..a6c3b6025152 100644
--- a/drivers/pwm/pwm_th1520.rs
+++ b/drivers/pwm/pwm_th1520.rs
@@ -185,7 +185,7 @@ fn round_waveform_tohw(
         );
 
         Ok(pwm::RoundedWaveform {
-            status: status,
+            status,
             hardware_waveform: wfhw,
         })
     }

I could re-send the patchset, but since you're making a patch anyway
maybe you would also like to pick this ?

> 
> Best regards
> Uwe

Best regards,
-- 
Michal Wilczynski <m.wilczynski@...sung.com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ