From: Igor Korotin <igor.korotin.linux@gmail.com>
To: Danilo Krummrich <dakr@kernel.org>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Wolfram Sang" <wsa+renesas@sang-engineering.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Viresh Kumar" <viresh.kumar@linaro.org>,
"Asahi Lina" <lina+kernel@asahilina.net>,
"Wedson Almeida Filho" <wedsonaf@gmail.com>,
"Alex Hung" <alex.hung@amd.com>,
"Tamir Duberstein" <tamird@gmail.com>,
"Xiangfei Ding" <dingxiangfei2009@gmail.com>,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
linux-i2c@vger.kernel.org
Subject: Re: [PATCH v2 1/4] rust: i2c: add basic I2C device and driver abstractions
Date: Mon, 7 Jul 2025 11:28:50 +0100 [thread overview]
Message-ID: <0ae92ad8-810f-4c10-a442-c403755cbab7@gmail.com> (raw)
In-Reply-To: <aGg2qkyrKBIPiSeE@cassiopeiae>
On 7/4/25 21:16, Danilo Krummrich wrote:
> On Fri, Jul 04, 2025 at 04:36:57PM +0100, Igor Korotin wrote:
>> Implement the core abstractions needed for I2C drivers, including:
>>
>> * `i2c::Driver` — the trait drivers must implement, including `probe`
>>
>> * `i2c::Device` — a safe wrapper around `struct i2c_client`
>>
>> * `i2c::Adapter` — implements `driver::RegistrationOps` to hook into the
>> generic `driver::Registration` machinery
>>
>> * `i2c::DeviceId` — a `RawDeviceId` implementation for I2C device IDs
>>
>> Signed-off-by: Igor Korotin <igor.korotin.linux@gmail.com>
>> ---
>> MAINTAINERS | 2 +
>> rust/bindings/bindings_helper.h | 1 +
>> rust/helpers/helpers.c | 1 +
>> rust/helpers/i2c.c | 15 ++
>> rust/kernel/i2c.rs | 391 ++++++++++++++++++++++++++++++++
>> rust/kernel/lib.rs | 2 +
>> 6 files changed, 412 insertions(+)
>> create mode 100644 rust/helpers/i2c.c
>> create mode 100644 rust/kernel/i2c.rs
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 7f8ddeec3b17..688a0ff23e69 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -11363,6 +11363,8 @@ F: include/linux/i2c-smbus.h
>> F: include/linux/i2c.h
>> F: include/uapi/linux/i2c-*.h
>> F: include/uapi/linux/i2c.h
>> +F: rust/helpers/i2c.c
>> +F: rust/kernel/i2c.rs
>
> Is this agreed with the maintainer?
>
> There are multiple possible options, for instance:
>
> 1) Maintain the Rust abstractions as part of the existing MAINTAINERS entry.
> Optionally, the author can be added as another maintainer or reviewer.
>
> 2) Add a separate MAINTAINERS entry; patches still go through the same
> subsystem tree.
>
> 3) Add a separate MAINTAINERS entry; patches don't go through the subsystem
> tree (e.g. because the subsystem maintainers don't want to deal with it).
>
> I usually recommend (1), which is what is proposes here, but that's of course up
> to you and the I2C maintainer.
>
> @Wolfram: In case there's no agreement yet, what's your preference of
> maintainership for this?
>
Oh, that makes sense - I didn’t realize I needed the current
maintainer’s sign-off to add new files under their MAINTAINERS entry.
As for being added as a reviewer or co-maintainer, I’m not yet confident
in my Rust skills. I’m learning Rust from scratch and, given my
extensive C-kernel background, I thought I’d start by contributing
something useful to the Rust side.
>> + }
>> +
>> + extern "C" fn shutdown_callback(pdev: *mut bindings::i2c_client) {
>> + let pdev = unsafe { &*pdev.cast::<Device<device::Core>>() };
>> +
>> + T::shutdown(pdev);
>> + }
>> +
>> + /// The [`i2c::IdTable`] of the corresponding driver.
>> + fn i2c_id_table() -> Option<IdTable<<Self as driver::Adapter>::IdInfo>> {
>> + T::I2C_ID_TABLE
>> + }
>> +
>> + /// Returns the driver's private data from the matching entry in the [`i2c::IdTable`], if any.
>> + ///
>> + /// If this returns `None`, it means there is no match with an entry in the [`i2c::IdTable`].
>> + fn i2c_id_info(dev: &Device) -> Option<&'static <Self as driver::Adapter>::IdInfo> {
>> + let table = Self::i2c_id_table()?;
>> +
>> + // SAFETY:
>> + // - `table` has static lifetime, hence it's valid for read,
>> + // - `dev` is guaranteed to be valid while it's alive, and so is `pdev.as_ref().as_raw()`.
>> + let raw_id = unsafe { bindings::i2c_match_id(table.as_ptr(), dev.as_raw()) };
>> +
>> + if raw_id.is_null() {
>> + None
>> + } else {
>> + // SAFETY: `DeviceId` is a `#[repr(transparent)` wrapper of `struct i2c_device_id` and
>
> Nit: Missing ']', probably a copy-paste mistake from other busses.
>
>
> Yes? :)
>
Yes, a lot of the code in this patch series is copy-paste of other
chunks of the existing Rust code because these parts are not part of
generic device/driver code.
I've made the same in ACPI patch series. I have already asked in that
patch series, if I need explicitly
mention that in the code or commit messages, I'm happy to do that.
>
> Just a note, this won't be needed in the future, I have patches in the
queue
> that let you use generic accessors from the generic Device type. [1]
>
> [1] https://lore.kernel.org/lkml/20250621195118.124245-3-dakr@kernel.org/
>
>
> Just a heads-up, this trait will be split up. [2]
>
> [2]
https://lore.kernel.org/lkml/20250704041003.734033-2-fujita.tomonori@gmail.com/
>
>
> Better use from_result() here.
>
>
> I like to do that as well, but I usually get asked to use drop()
instead, let's
> do that here as well. :)
>
>
> For now I think you have to ensure that I2C is built-in.
>
Noted. Thanks for the review.
Best Regards
Igor
next prev parent reply other threads:[~2025-07-07 10:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-04 15:33 [PATCH v2 0/4] rust: i2c: Add basic I2C driver abstractions Igor Korotin
2025-07-04 15:36 ` [PATCH v2 1/4] rust: i2c: add basic I2C device and " Igor Korotin
2025-07-04 20:16 ` Danilo Krummrich
2025-07-07 10:28 ` Igor Korotin [this message]
2025-07-07 10:47 ` Miguel Ojeda
2025-07-07 11:23 ` Igor Korotin
2025-07-10 14:04 ` Igor Korotin
2025-07-10 14:46 ` Danilo Krummrich
2025-07-04 15:39 ` [PATCH v2 2/4] rust: i2c: add manual I2C device creation abstractions Igor Korotin
2025-07-04 19:54 ` Danilo Krummrich
2025-07-07 10:35 ` Igor Korotin
2025-07-07 11:20 ` Igor Korotin
2025-07-07 12:02 ` Danilo Krummrich
2025-07-07 14:31 ` Igor Korotin
2025-07-07 14:39 ` Danilo Krummrich
2025-07-04 15:41 ` [PATCH v2 3/4] samples: rust: add Rust I2C sample driver Igor Korotin
2025-07-04 15:43 ` [PATCH v2 4/4] samples: rust: add Rust manual I2C device creation sample Igor Korotin
2025-07-04 19:58 ` 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=0ae92ad8-810f-4c10-a442-c403755cbab7@gmail.com \
--to=igor.korotin.linux@gmail.com \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=alex.hung@amd.com \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=dingxiangfei2009@gmail.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=lina+kernel@asahilina.net \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tamird@gmail.com \
--cc=tmgross@umich.edu \
--cc=viresh.kumar@linaro.org \
--cc=wedsonaf@gmail.com \
--cc=wsa+renesas@sang-engineering.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).