From: Dirk Behme <dirk.behme@de.bosch.com>
To: "Remo Senekowitsch" <remo@buenzli.dev>,
"Rob Herring" <robh@kernel.org>,
"Saravana Kannan" <saravanak@google.com>,
"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>,
"Danilo Krummrich" <dakr@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>
Cc: <linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>,
<rust-for-linux@vger.kernel.org>
Subject: Re: [PATCH v3 5/7] rust: property: Add child accessor and iterator
Date: Wed, 30 Apr 2025 08:26:50 +0200 [thread overview]
Message-ID: <e2dbf92f-5024-4dd2-848f-3d9e2f85698c@de.bosch.com> (raw)
In-Reply-To: <20250425150130.13917-6-remo@buenzli.dev>
On 25/04/2025 17:01, Remo Senekowitsch wrote:
> Allow Rust drivers to access children of a fwnode either by name or by
> iterating over all of them.
>
> In C, there is the function `fwnode_get_next_child_node` for iteration
> and the macro `fwnode_for_each_child_node` that helps with handling the
> pointers. Instead of a macro, a native iterator is used in Rust such
> that regular for-loops can be used.
>
> Signed-off-by: Remo Senekowitsch <remo@buenzli.dev>
> ---
> rust/kernel/device/property.rs | 79 +++++++++++++++++++++++++++++++++-
> 1 file changed, 78 insertions(+), 1 deletion(-)
>
> diff --git a/rust/kernel/device/property.rs b/rust/kernel/device/property.rs
> index 9505cc35d..0a0cb0c02 100644
> --- a/rust/kernel/device/property.rs
> +++ b/rust/kernel/device/property.rs
> @@ -13,7 +13,7 @@
> error::{to_result, Result},
> prelude::*,
> str::{CStr, CString},
> - types::Opaque,
> + types::{ARef, Opaque},
> };
>
> impl Device {
> @@ -52,6 +52,27 @@ pub fn fwnode(&self) -> Option<&FwNode> {
> pub struct FwNode(Opaque<bindings::fwnode_handle>);
>
> impl FwNode {
> + /// # Safety
> + ///
> + /// Callers must ensure that:
> + /// - The reference count was incremented at least once.
> + /// - They relinquish that increment. That is, if there is only one
> + /// increment, callers must not use the underlying object anymore -- it is
> + /// only safe to do so via the newly created `ARef<FwNode>`.
> + unsafe fn from_raw(raw: *mut bindings::fwnode_handle) -> ARef<Self> {
> + // SAFETY: As per the safety requirements of this function:
> + // - `NonNull::new_unchecked`:
> + // - `raw` is not null
> + // - `ARef::from_raw`:
> + // - `raw` has an incremented refcount
> + // - that increment is relinquished, i.e. it won't be decremented
> + // elsewhere.
Quite minor: There is some inconsistency on using the '.' above. The two
`raw` sentences don't have it while the last 'that increment ...' has it.
> + // CAST: It is safe to cast from a `*mut fwnode_handle` to
> + // `*mut FwNode`, because `FwNode` is defined as a
> + // `#[repr(transparent)]` wrapper around `fwnode_handle`.
> + unsafe { ARef::from_raw(ptr::NonNull::new_unchecked(raw.cast())) }
> + }
> +
> /// Obtain the raw `struct fwnode_handle *`.
> pub(crate) fn as_raw(&self) -> *mut bindings::fwnode_handle {
> self.0.get()
> @@ -238,6 +259,62 @@ pub fn property_read<'fwnode, 'name, T: Property>(
> name,
> }
> }
> +
> + /// Returns first matching named child node handle.
> + pub fn get_child_by_name(&self, name: &CStr) -> Option<ARef<Self>> {
> + // SAFETY: `self` and `name` are valid by their type invariants.
> + let child =
> + unsafe { bindings::fwnode_get_named_child_node(self.as_raw(), name.as_char_ptr()) };
> + if child.is_null() {
> + return None;
> + }
> + // SAFETY:
> + // - `fwnode_get_named_child_node` returns a pointer with its refcount
> + // incremented.
> + // - That increment is relinquished, i.e. the underlying object is not
> + // used anymore except via the newly created `ARef`.
> + Some(unsafe { Self::from_raw(child) })
> + }
> +
> + /// Returns an iterator over a node's children.
> + pub fn children<'a>(&'a self) -> impl Iterator<Item = ARef<FwNode>> + 'a {
> + let mut prev: Option<ARef<FwNode>> = None;
> +
> + core::iter::from_fn(move || {
> + let prev_ptr = match prev.take() {
> + None => ptr::null_mut(),
> + Some(prev) => {
> + // We will pass `prev` to `fwnode_get_next_child_node`,
> + // which decrements its refcount, so we use
> + // `ARef::into_raw` to avoid decrementing the refcount
> + // twice.
> + let prev = ARef::into_raw(prev);
> + prev.as_ptr().cast()
> + }
> + };
> + // SAFETY:
> + // - `self.as_raw()` is valid by its type invariant.
> + // - `prev_ptr` may be null, which is allowed and corresponds to
> + // getting the first child. Otherwise, `prev_ptr` is valid, as it
> + // is the stored return value from the previous invocation.
> + // - `prev_ptr` has its refount incremented.
> + // - The increment of `prev_ptr` is relinquished, i.e. the
> + // underlying object won't be unsed anymore.
Typo: unsed -> used (?)
Dirk
next prev parent reply other threads:[~2025-04-30 6:27 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-25 15:01 [PATCH v3 0/7] More Rust bindings for device property reads Remo Senekowitsch
2025-04-25 15:01 ` [PATCH v3 1/7] rust: property: Move property_present to separate file Remo Senekowitsch
2025-04-25 15:25 ` Danilo Krummrich
2025-04-30 6:14 ` Dirk Behme
2025-04-25 15:01 ` [PATCH v3 2/7] rust: property: Enable printing fwnode name and path Remo Senekowitsch
2025-04-25 15:48 ` Danilo Krummrich
2025-04-30 7:44 ` Dirk Behme
2025-04-25 15:01 ` [PATCH v3 3/7] rust: property: Introduce PropertyGuard Remo Senekowitsch
2025-04-25 15:35 ` Danilo Krummrich
2025-04-26 6:19 ` Dirk Behme
2025-04-26 10:15 ` Danilo Krummrich
2025-04-26 11:08 ` Remo Senekowitsch
2025-04-26 14:19 ` Danilo Krummrich
2025-04-26 14:35 ` Dirk Behme
2025-04-26 15:02 ` Danilo Krummrich
2025-04-26 21:50 ` Remo Senekowitsch
2025-04-27 22:12 ` John Hubbard
2025-04-28 20:18 ` Rob Herring
2025-04-28 20:25 ` John Hubbard
2025-04-28 21:10 ` Rob Herring
2025-04-27 6:11 ` Dirk Behme
2025-04-27 12:23 ` Danilo Krummrich
2025-04-28 5:03 ` Dirk Behme
2025-04-28 16:09 ` Danilo Krummrich
2025-04-28 20:48 ` Rob Herring
2025-04-28 21:21 ` Danilo Krummrich
2025-04-28 21:50 ` Remo Senekowitsch
2025-04-29 8:50 ` Danilo Krummrich
2025-04-25 15:01 ` [PATCH v3 4/7] rust: property: Add bindings for reading device properties Remo Senekowitsch
2025-04-25 15:01 ` [PATCH v3 5/7] rust: property: Add child accessor and iterator Remo Senekowitsch
2025-04-30 6:26 ` Dirk Behme [this message]
2025-04-25 15:01 ` [PATCH v3 6/7] rust: property: Add property_get_reference_args Remo Senekowitsch
2025-04-25 15:01 ` [PATCH v3 7/7] samples: rust: platform: Add property read examples Remo Senekowitsch
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=e2dbf92f-5024-4dd2-848f-3d9e2f85698c@de.bosch.com \
--to=dirk.behme@de.bosch.com \
--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=dakr@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rafael@kernel.org \
--cc=remo@buenzli.dev \
--cc=robh@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=saravanak@google.com \
--cc=tmgross@umich.edu \
/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
all inboxes | Powered by JetHome®