rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Trevor Gross" <tmgross@umich.edu>
To: "FUJITA Tomonori" <fujita.tomonori@gmail.com>,
	<alex.gaynor@gmail.com>, <dakr@kernel.org>,
	<gregkh@linuxfoundation.org>, <ojeda@kernel.org>,
	<rafael@kernel.org>, <robh@kernel.org>, <saravanak@google.com>
Cc: <a.hindborg@kernel.org>, <aliceryhl@google.com>,
	<bhelgaas@google.com>, <bjorn3_gh@protonmail.com>,
	<boqun.feng@gmail.com>, <david.m.ertman@intel.com>,
	<devicetree@vger.kernel.org>, <gary@garyguo.net>,
	<ira.weiny@intel.com>, <kwilczynski@kernel.org>,
	<leon@kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-pci@vger.kernel.org>, <lossin@kernel.org>,
	<netdev@vger.kernel.org>, <rust-for-linux@vger.kernel.org>
Subject: Re: [PATCH v3 1/3] rust: device_id: split out index support into a separate trait
Date: Tue, 08 Jul 2025 23:10:48 -0400	[thread overview]
Message-ID: <DB7714QEA9EO.XB7BKFDO74JE@umich.edu> (raw)
In-Reply-To: <20250704041003.734033-2-fujita.tomonori@gmail.com>

On Fri Jul 4, 2025 at 12:10 AM EDT, FUJITA Tomonori wrote:
> Introduce a new trait `RawDeviceIdIndex`, which extends `RawDeviceId`
> to provide support for device ID types that include an index or
> context field (e.g., `driver_data`). This separates the concerns of
> layout compatibility and index-based data embedding, and allows
> `RawDeviceId` to be implemented for types that do not contain a
> `driver_data` field. Several such structures are defined in
> include/linux/mod_devicetable.h.
>
> Refactor `IdArray::new()` into a generic `build()` function, which
> takes an optional offset. Based on the presence of `RawDeviceIdIndex`,
> index writing is conditionally enabled. A new `new_without_index()`
> constructor is also provided for use cases where no index should be
> written.
>
> This refactoring is a preparation for enabling the PHY abstractions to
> use device_id trait.
>
> Acked-by: Danilo Krummrich <dakr@kernel.org>
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
> ---
>  rust/kernel/auxiliary.rs | 11 ++---
>  rust/kernel/device_id.rs | 91 ++++++++++++++++++++++++++++------------
>  rust/kernel/of.rs        | 15 ++++---
>  rust/kernel/pci.rs       | 11 ++---
>  4 files changed, 87 insertions(+), 41 deletions(-)

Few small suggestions if you wind up spinning this again:

> diff --git a/rust/kernel/device_id.rs b/rust/kernel/device_id.rs
> [...]
> @@ -68,7 +77,14 @@ impl<T: RawDeviceId, U, const N: usize> IdArray<T, U, N> {
>      /// Creates a new instance of the array.
>      ///
>      /// The contents are derived from the given identifiers and context information.
> -    pub const fn new(ids: [(T, U); N]) -> Self {
> +    ///
> +    /// # Safety
> +    ///
> +    /// If `offset` is `Some(offset)`, then:
> +    /// - `offset` must be the correct offset (in bytes) to the context/data field
> +    ///   (e.g., the `driver_data` field) within the raw device ID structure.
> +    /// - The field at `offset` must be correctly sized to hold a `usize`.
> +    const unsafe fn build(ids: [(T, U); N], offset: Option<usize>) -> Self {

Could you mention that calling with `offset` as `None` is always safe?
Also calling the arg `data_offset` might be more clear.

> @@ -92,7 +111,6 @@ impl<T: RawDeviceId, U, const N: usize> IdArray<T, U, N> {
>              infos[i] = MaybeUninit::new(unsafe { core::ptr::read(&ids[i].1) });
>              i += 1;
>          }
> -
>          core::mem::forget(ids);

This removes the space between a block and an expression, possibly
unintentional? :)

> @@ -109,12 +127,33 @@ impl<T: RawDeviceId, U, const N: usize> IdArray<T, U, N> {
>          }
>      }
>  
> +    /// Creates a new instance of the array without writing index values.
> +    ///
> +    /// The contents are derived from the given identifiers and context information.

Maybe the docs here should crosslink:

    If the device implements [`RawDeviceIdIndex`], consider using
    [`new`] instead.

> +    pub const fn new_without_index(ids: [(T, U); N]) -> Self {
> +        // SAFETY: Calling `Self::build` with `offset = None` is always safe,
> +        // because no raw memory writes are performed in this case.
> +        unsafe { Self::build(ids, None) }
> +    }
> +

With those changes, or as-is if there winds up not being another
version:

Reviewed-by: Trevor Gross <tmgross@umich.edu>

  reply	other threads:[~2025-07-09  3:11 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-04  4:10 [PATCH v3 0/3] rust: Build PHY device tables by using module_device_table macro FUJITA Tomonori
2025-07-04  4:10 ` [PATCH v3 1/3] rust: device_id: split out index support into a separate trait FUJITA Tomonori
2025-07-09  3:10   ` Trevor Gross [this message]
2025-07-11  3:17     ` FUJITA Tomonori
2025-07-04  4:10 ` [PATCH v3 2/3] rust: net::phy represent DeviceId as transparent wrapper over mdio_device_id FUJITA Tomonori
2025-07-09  3:23   ` Trevor Gross
2025-07-11  3:38     ` FUJITA Tomonori
2025-07-04  4:10 ` [PATCH v3 3/3] rust: net::phy Change module_phy_driver macro to use module_device_table macro FUJITA Tomonori
2025-07-09  3:39   ` Trevor Gross
2025-07-08  0:53 ` [PATCH v3 0/3] rust: Build PHY device tables by using " Jakub Kicinski
2025-07-08 10:45   ` Miguel Ojeda
2025-07-08 10:59     ` Danilo Krummrich
2025-07-08 10:59     ` FUJITA Tomonori
2025-07-08 12:47       ` Danilo Krummrich
2025-07-08 18:47         ` Miguel Ojeda
2025-07-08 22:51           ` Danilo Krummrich
2025-07-09  2:08             ` FUJITA Tomonori
2025-07-10 20:01               ` Danilo Krummrich
2025-07-10 23:03                 ` FUJITA Tomonori
2025-07-08 10:49   ` Danilo Krummrich

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=DB7714QEA9EO.XB7BKFDO74JE@umich.edu \
    --to=tmgross@umich.edu \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=bhelgaas@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=david.m.ertman@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=fujita.tomonori@gmail.com \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=ira.weiny@intel.com \
    --cc=kwilczynski@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=saravanak@google.com \
    /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;
as well as URLs for NNTP newsgroup(s).