[GIT PULL] rust-i2c-fixes for 7.1-rc7

[GIT PULL] rust-i2c-fixes for 7.1-rc7

[Igor Korotin]

The following changes since commit e43ffb69e0438cddd72aaa30898b4dc446f664f8:

   Linux 7.1-rc6 (2026-05-31 15:14:24 -0700)

are available in the Git repository at:

   https://github.com/ikrtn/linux.git tags/rust-i2c-7.1-rc7

for you to fetch changes up to 4eb422482ca5d924d7212ad2ca1cb7ea6f5b524d:

   rust: i2c: fix I2cAdapter refcounts double increment (2026-06-06 
15:19:27 +0100)

----------------------------------------------------------------
rust: i2c: fix I2cAdapter refcount double increment

A single bugfix for the Rust I2C abstractions, targeting 7.1.

`I2cAdapter::get` calls `i2c_get_adapter()` which returns a pointer with
an already-incremented refcount. The code then converts the raw pointer to
an `ARef` via `.into()`, which calls `inc_ref()` again through the
`From<&T> for ARef<T>` impl — resulting in a leaked device and module
reference on every call.

The fix uses `ARef::from_raw()` instead, which takes ownership of the
existing refcount without incrementing it.

Signed-off-by: Igor Korotin <igor.korotin@linux.dev>

----------------------------------------------------------------
Nicolás Antinori (1):
       rust: i2c: fix I2cAdapter refcounts double increment

  rust/kernel/i2c.rs | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

Re: [GIT PULL] rust-i2c-fixes for 7.1-rc7

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

On Sat, Jun 06, 2026 at 06:39:19PM +0100, Igor Korotin wrote:
> The following changes since commit e43ffb69e0438cddd72aaa30898b4dc446f664f8:
> 
>   Linux 7.1-rc6 (2026-05-31 15:14:24 -0700)
> 
> are available in the Git repository at:
> 
>   https://github.com/ikrtn/linux.git tags/rust-i2c-7.1-rc7
> 
> for you to fetch changes up to 4eb422482ca5d924d7212ad2ca1cb7ea6f5b524d:
> 
>   rust: i2c: fix I2cAdapter refcounts double increment (2026-06-06 15:19:27
> +0100)

Thanks, pulled. I was away over the weekend, so it couldn't make it into
rc7. But I will send it out later this week for 7.1 surely.

Please be already aware that from 7.2 on, you will need send pull
requests to Andi who takes over the I2C subsystem. I will write a
seperate mail about the handover later today.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [GIT PULL] rust-i2c-fixes for 7.1-rc7

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

Hi all,

(adding a few more people to CC to have a potentially bigger discussion)

> Please be already aware that from 7.2 on, you will need send pull
> requests to Andi who takes over the I2C subsystem. I will write a
> seperate mail about the handover later today.

Done now [1]. On a second thought, after pulling in the I2C abstractions
a few times now, I wonder meanwhile if the Rust-tree wouldn't be the
better path to upstream. The abstractions are way more Rust than they
are I2C. And potential merge-conflicts come from generic Rust
abstraction updates, not from I2C.

This is Andi's choice now, of course. Just wanted to give my 2 cents
here...

Happy hacking,

   Wolfram

[1] https://lore.kernel.org/r/20260609091612.8228-3-wsa+renesas@sang-engineering.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [GIT PULL] rust-i2c-fixes for 7.1-rc7

[Igor Korotin]

Hello Wolfram

On June 9, 2026 10:26:40 AM GMT+01:00, Wolfram Sang <wsa+renesas@sang-engineering.com> wrote:
>Hi all,
>
>(adding a few more people to CC to have a potentially bigger discussion)
>
>> Please be already aware that from 7.2 on, you will need send pull
>> requests to Andi who takes over the I2C subsystem. I will write a
>> seperate mail about the handover later today.
>
>Done now [1]. On a second thought, after pulling in the I2C abstractions
>a few times now, I wonder meanwhile if the Rust-tree wouldn't be the
>better path to upstream. The abstractions are way more Rust than they
>are I2C. And potential merge-conflicts come from generic Rust
>abstraction updates, not from I2C.
>
>This is Andi's choice now, of course. Just wanted to give my 2 cents
>here...

Thanks for the heads-up on the handover — noted, I'll direct pull requests to Andi from 7.2 onward.

On the Rust-tree question: I don't have a strong preference either way from a workflow perspective, but technically your reasoning makes sense to me. As long as the changes don't introduce or alter any I2C-specific behavior — and so far they don't — routing them through the Rust tree seems like the more natural fit, and would avoid spurious merge conflicts driven by generic abstraction updates rather than anything I2C-related.

Ultimately Andi's call, of course. Happy to adapt to whatever process works best.

Cheers
Igor

Re: [GIT PULL] rust-i2c-fixes for 7.1-rc7

[Miguel Ojeda]

On Tue, Jun 9, 2026 at 2:15 PM Igor Korotin <igor.korotin@linux.dev> wrote:
>
> On the Rust-tree question: I don't have a strong preference either way from a workflow perspective, but technically your reasoning makes sense to me. As long as the changes don't introduce or alter any I2C-specific behavior — and so far they don't — routing them through the Rust tree seems like the more natural fit, and would avoid spurious merge conflicts driven by generic abstraction updates rather than anything I2C-related.

Yeah, this is a common question -- I hope I can clarify a bit...

It is true that in most cases Rust changes in abstractions do not need
to change the C side, which is good (and something we tried to
show/emphasize early on in Rust for Linux).

However, the key part is catching changes in the other direction, i.e.
on the C side of the subsystem that need to be reflected on the Rust
one. And, more generally, coordinating the subsystem -- in a sense,
the programming language is an implementation detail, and the experts
of the subsystem and its subtleties are the maintainers there.

So that is why, generally speaking, changes are meant to go through
their respective trees. Sometimes we may take treewide changes through
the Rust tree to simplify logistics. (The Rust tree can also act as a
"fallback tree" when needed, and there can be exceptional cases where
abstractions end up maintained in a subtree of the Rust one.)

I have some more details in:

  - https://rust-for-linux.com/contributing#the-rust-subsystem
  - https://rust-for-linux.com/rust-kernel-policy

(Cc' Andi, by the way)

Cheers,
Miguel