linux-kernel - Re: [PATCH V3 2/2] rust: Add initial clk abstractions

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250307072322.5w2i7dxtcaani2ok@vireshk-i7>
Date: Fri, 7 Mar 2025 12:53:22 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
	Stephen Boyd <sboyd@...nel.org>
Cc: Michael Turquette <mturquette@...libre.com>,
	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>,
	Russell King <linux@...linux.org.uk>, linux-clk@...r.kernel.org,
	linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Daniel Almeida <daniel.almeida@...labora.com>
Subject: Re: [PATCH V3 2/2] rust: Add initial clk abstractions

On 06-03-25, 12:58, Stephen Boyd wrote:
> Quoting Viresh Kumar (2025-03-05 20:40:28)
> > 2. clk is enabled / disabled from different routines:
> > 
> >    In this case the caller needs to call dismiss to avoid the automatic freeing
> >    of resource. Alternatively the returned value can be stored too somewhere,
> >    but I am not sure if it what users will end up doing.
> > 
> >    fn probe(...) -> Result {
> >         clk.enable()?.dismiss();
> 
> Yuck. Can't we tie the lifetime of the clk to the consumer device driver
> so that when the driver is unbound the clk is dropped

Yes, that is how it would work right now, the driver needs to store the clk
instance locally. As soon as Clk would be dropped, clk_put() will be called.

> and it decrements all the enables/prepares and puts the clk with clk_put()?

Miguel, how do you suggest we do this ?

> A ScopeGuard could probably be used for that on the struct Clk itself,

Not sure if I misunderstood that, but as soon as Clk goes out of scope,
clk_put() will be called from drop() anyway.

> but we would
> want to track the enables and prepares in the rust wrapper code until
> the struct clk can be inspected directly.

So Rust abstraction needs to do some sort of refcounting for this I believe. Not
sure if we want to do it and if yes, then how.

> The problem is we don't know how a platform may implement the clk API,
> and CCF hasn't taken over the entire kernel yet so we can't rely on some
> private API between the CCF and the rust wrapper to know how many
> clk_disable()s to call, or even rely on clk_put() to do the work for us.
> Can the rust wrappers depend on CONFIG_COMMON_CLK? If they did then we
> could have some private API between rust and CCF. We probably don't want
> rust code to _not_ use COMMON_CLK underneath so we can encourage the
> last few holdouts to migrate to CCF. I'd lean towards depending on
> COMMON_CLK for the rust wrappers in this case.

Sure.

-- 
viresh