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

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