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!
next prev parent 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).