From: Danilo Krummrich <dakr@kernel.org>
To: Daniel Almeida <daniel.almeida@collabora.com>
Cc: "Viresh Kumar" <viresh.kumar@linaro.org>,
"Michael Turquette" <mturquette@baylibre.com>,
"Stephen Boyd" <sboyd@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>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Russell King" <linux@armlinux.org.uk>,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
rust-for-linux@vger.kernel.org
Subject: Re: [PATCH V2 2/2] rust: Add basic bindings for clk APIs
Date: Fri, 21 Feb 2025 15:47:57 +0100 [thread overview]
Message-ID: <Z7iSHR0F2QpiNpMZ@pollux> (raw)
In-Reply-To: <4AD8A8F3-EA7E-4FBE-9F0D-58CF7BB09ED5@collabora.com>
On Fri, Feb 21, 2025 at 11:29:21AM -0300, Daniel Almeida wrote:
>
>
> > On 21 Feb 2025, at 10:56, Danilo Krummrich <dakr@kernel.org> wrote:
> >
> > On Fri, Feb 21, 2025 at 12:03:39PM +0530, Viresh Kumar wrote:
> >> +/// A simple implementation of `struct clk` from the C code.
> >> +#[repr(transparent)]
> >> +pub struct Clk(*mut bindings::clk);
> >
> > I remember that Stephen explained that NULL is valid value for struct clk. As a
> > consequence, all functions implemented for `Clk` have to consider this.
>
> I am a bit confused here. If NULL is valid, then why should we have to specifically
> consider that in the functions? No functions so far explicitly dereferences that value,
> they only pass it to the clk framework.
This was badly phrased, the current implementation does not need to consider it
indeed. What I meant is that we have to consider it potentially. Especially,
when adding new functionality later on. For instance, when accessing fields of
struct clk directly. Maybe this only becomes relevant once we write a clk driver
itself in Rust, but still.
>
> Or are you referring to the safety comments only? In which case I do agree (sorry for
> the oversight by the way)
>
> >
> > I wonder if it could make sense to have a transparent wrapper type
> > `MaybeNull<T>` (analogous to `NonNull<T>`) to make this fact more obvious for
> > cases like this?
>
> MaybeNull<T> sounds nice.
Yeah, it's probably the correct thing to do, to make things obvious.
>
> >
> >> +
> >> +impl Clk {
> >> + /// Creates `Clk` instance for a device and a connection id.
> >> + pub fn new(dev: &Device, name: Option<&CStr>) -> Result<Self> {
> >> + let con_id = if let Some(name) = name {
> >> + name.as_ptr() as *const _
> >> + } else {
> >> + ptr::null()
> >> + };
> >> +
> >> + // SAFETY: It is safe to call `clk_get()`, on a device pointer earlier received from the C
> >> + // code.
> >> + Ok(Self(from_err_ptr(unsafe {
> >> + bindings::clk_get(dev.as_raw(), con_id)
> >> + })?))
> >> + }
> >> +
> >> + /// Obtain the raw `struct clk *`.
> >> + pub fn as_raw(&self) -> *mut bindings::clk {
> >> + self.0
> >> + }
> >> +
> >> + /// Clock enable.
> >> + pub fn enable(&self) -> Result<()> {
> >> + // SAFETY: By the type invariants, we know that `self` owns a reference, so it is safe to
> >> + // use it now.
> >
> > This is not true.
> >
> > 1. There is no type invariant documented for `Clk`.
> > 2. The pointer contained in an instance of `Clk` may be NULL, hence `self` does
> > not necessarily own a reference.
>
> >
> > The same applies for all other functions in this implementation.
> >
>
>
next prev parent reply other threads:[~2025-02-21 14:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-21 6:33 [PATCH V2 0/2] rust: Add basic clock bindings Viresh Kumar
2025-02-21 6:33 ` [PATCH V2 1/2] rust: Add clk helpers Viresh Kumar
2025-02-21 13:19 ` Daniel Almeida
2025-02-21 6:33 ` [PATCH V2 2/2] rust: Add basic bindings for clk APIs Viresh Kumar
2025-02-21 13:30 ` Daniel Almeida
2025-02-21 13:56 ` Danilo Krummrich
2025-02-21 14:29 ` Daniel Almeida
2025-02-21 14:47 ` Danilo Krummrich [this message]
2025-02-21 15:28 ` Sebastian Reichel
2025-02-21 21:59 ` Rob Herring
2025-02-24 9:59 ` Viresh Kumar
2025-03-05 20:09 ` Rob Herring
2025-03-06 4:48 ` Viresh Kumar
2025-02-24 9:45 ` Viresh Kumar
2025-02-21 14:42 ` Daniel Almeida
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=Z7iSHR0F2QpiNpMZ@pollux \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=daniel.almeida@collabora.com \
--cc=gary@garyguo.net \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mturquette@baylibre.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=sboyd@kernel.org \
--cc=tmgross@umich.edu \
--cc=viresh.kumar@linaro.org \
/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