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