rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: FUJITA Tomonori <fujita.tomonori@gmail.com>
To: tmgross@umich.edu
Cc: 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,
	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: Fri, 11 Jul 2025 12:17:09 +0900 (JST)	[thread overview]
Message-ID: <20250711.121709.1360562848053380480.fujita.tomonori@gmail.com> (raw)
In-Reply-To: <DB7714QEA9EO.XB7BKFDO74JE@umich.edu>

On Tue, 08 Jul 2025 23:10:48 -0400
"Trevor Gross" <tmgross@umich.edu> wrote:

> 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?

Indeed, added.

> Also calling the arg `data_offset` might be more clear.

Yeah, changed.

>> @@ -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? :)

Oops, unintentional. Dropped the change.

>> @@ -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.

Looks nice, added. [`new`] doesn't work so I use [`IdArray::new`].

>> +    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>

Thanks!

  reply	other threads:[~2025-07-11  3:17 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
2025-07-11  3:17     ` FUJITA Tomonori [this message]
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=20250711.121709.1360562848053380480.fujita.tomonori@gmail.com \
    --to=fujita.tomonori@gmail.com \
    --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=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 \
    --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;
as well as URLs for NNTP newsgroup(s).