From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8FDB01400A; Sun, 7 Apr 2024 09:54:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.70.40.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712483669; cv=none; b=k6SUiO2xkgjKAPqllnGK9B0p6k6TBc8iOYoPQZMAoWh1QBDVOYzGXjvvzTdnno2wKW8V73vgUtt2fphJgODgP5CHvdLvxs0XRBX+cDSVNFgj6Lmx2J4vNRqG8y9/JSCzmdEO6bH/sbsrjtiBFbTjqkhgv9hl6h+JzrOyeppipsM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712483669; c=relaxed/simple; bh=i8Pf56totbaL2ToXcQKolVxiIZ/TpmMBAZ0t/LCkK3w=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=rhonBt7I33DAy3G2CIYqRWZqLmalo0Efb8Fbms11oUw0ShCQrxIQbkl0PX0wGyu2dKkyo3DzVd9zlzAnFoQZSd6tRSSUQ/LcjARqTboBS3+9DgQpZOzdSLJBiFa3ObWu53aaRNER8tJygYStqC5TU5DyeDShvQsOwv2VOijLybA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=proton.me; spf=pass smtp.mailfrom=proton.me; dkim=pass (2048-bit key) header.d=proton.me header.i=@proton.me header.b=loS8/9k4; arc=none smtp.client-ip=185.70.40.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=proton.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=proton.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=proton.me header.i=@proton.me header.b="loS8/9k4" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1712483664; x=1712742864; bh=FpPOsxrlm7kGglog0YaejIMtnmrT68wmHt8AAfV1foA=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=loS8/9k4aV1FTA3BHgGAukGuWqqeBVljBwDIWzkAUljm/0zq6hSqJ8lBwn2P5rfB7 7hgv5H2yThaIDK4kSj+MbPpjK7d++cHJcljgs/mFixr8gzLtHjkP/88V2kHVawH6js 7P3nOU6SklxAWyFecLxPypNogf82q7zCbK7g2raSQfhM4Ov7Py6moiNoNxkxRwWR2e MmkVjKt1ESsQQMsKZEFCIQwNNeUCgVQLjaUEB7KskCCP5DUYbizydYKDirxFuoNagl v4xhZwOUDNXemN2PNDfDaWK9UrfSplCR2bBZk8bxfFt5paquQALAo39ev4FS7oslvb tv2kLnKfdTylg== Date: Sun, 07 Apr 2024 09:54:19 +0000 To: Viresh Kumar , "Rafael J. Wysocki" , Miguel Ojeda , Miguel Ojeda , Alex Gaynor , Wedson Almeida Filho , Boqun Feng , Gary Guo , =?utf-8?Q?Bj=C3=B6rn_Roy_Baron?= , Andreas Hindborg , Alice Ryhl From: Benno Lossin Cc: linux-pm@vger.kernel.org, Vincent Guittot , Stephen Boyd , Nishanth Menon , rust-for-linux@vger.kernel.org, Manos Pitsidianakis , Erik Schilling , =?utf-8?Q?Alex_Benn=C3=A9e?= , Joakim Bech , linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 1/3] rust: Add bindings for OPP framework Message-ID: In-Reply-To: <06bb914eae00671a69b393bf86bb01ddec86c16f.1712314032.git.viresh.kumar@linaro.org> References: <06bb914eae00671a69b393bf86bb01ddec86c16f.1712314032.git.viresh.kumar@linaro.org> Feedback-ID: 71780778:user:proton Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I took a quick look and left some comments from the Rust side of view. On 05.04.24 13:09, Viresh Kumar wrote: > +/// Equivalent to `struct dev_pm_opp_config` in the C Code. > +pub struct Config { > + token: Option, > + clk_names: Option>>, Why are you using `Pin>`? The vector may reallocate the backing storage at any point in time. > + prop_name: Option>, > + regulator_names: Option>>, > + genpd_names: Option>>, > + supported_hw: Option>>, > + required_devs: Option>>, > + _data: PhantomData, > +} [...] > + /// Sets the configuration with the OPP core. > + pub fn set(&mut self, dev: &Device) -> Result<()> { > + // Already configured. > + if self.token.is_some() { Why does the config hold onto this token? Would it make sense to consume the config and return a `Handle` or `Token` abstraction? Then you don't need to check if the config has been "used" before. > + return Err(EBUSY); > + } > + > + let (_clk_list, clk_names) =3D match &self.clk_names { > + Some(x) =3D> { > + let list =3D to_c_str_array(x)?; > + let ptr =3D list.as_ptr(); > + (Some(list), ptr) > + } > + None =3D> (None, ptr::null()), > + }; [...] > +/// Operating performance point (OPP). > +/// > +/// # Invariants > +/// > +/// `ptr` is valid, non-null, and has a non-zero reference count. One of= the references is owned by > +/// `self`, and will be decremented when `self` is dropped. > +#[repr(transparent)] > +pub struct OPP(*mut bindings::dev_pm_opp); I think you should use the `ARef` pattern instead: #[repr(transparent)] pub struct OPP(Opaque); unsafe impl AlwaysRefCounted for OPP { // ... } Then you can use `ARef` everywhere you use `OPP` currently. --=20 Cheers, Benno