Re: [GIT PULL] i2c for v7.4, part 2

[Andi Shyti]

On Mon, Oct 26, 2026 at 07:15:52AM -1000, Linus Torvalds wrote:
> On Sun, 25 Oct 2026 at 10:20, Andi Shyti <andi.shyti@xxxxxxxxxx> wrote:
> >
> > I'll now start queuing patches for a possible third week of the
> > merge window. Otherwise, they will go into v7.5.
> 
> NO!
> 
> I've taken this.
> 
> But the whole "merge window is for new development" needs to stop. I
> will *NOT* be taking any more patches from you that aren't fixes.
> 
> The merge window is for merging stuff that is ready BEFORE THE MERGE
> WINDOW STARTED.
> 
> It's absolutely not for "let's add more to the pile". Never has been,
> and never will be.
> 
> The merge window is two weeks NOT as a way to give maintainers two
> weeks (and no, it won't be three weeks this time, I've been keeping
> up) to create new stuff. It's so that the stuff that *was* ready
> before the merge window can be merged in a sane and controlled manner.
> 
> So no. No more of this "I'll have a second - or third - pile of
> stuff". If it wasn't ready before, then it wasn't ready, and it goes
> into the *next* merge window.

OK, got it!

Just to clarify, most of the patches in this pull request are
fixes or patches that were taken well before the merge window but
had to wait for some dependencies to be resolved. They have also
been tested in my -next branch for several -rc cycles now.

Since the merge window opened, I've added only two patches that
are not strictly fixes[*]. One is a trivial fix that doesn't
deserve a Fixes: tag, while the other has been properly reviewed
and in my tree for almost a week.

So, apart from this last patch, which I could drop to be fully
compliant, I believe this pull request meets your requirements.

Am I still missing something? Is there anything I can still do?

As for my mention of a possible third week and a part 3 (not this
part 2 pull request!), I was simply trying to check whether that
would be acceptable for trivial patches. I understand now that it
definitely isn't.

Thanks,
Andi

[*] f7b70efba269 ("i2c: sh_mobile: request IRQs after mapping registers")
    c2867bb0fa1d ("i2c: imx: add I2C_M_REV_DIR_ADDR and I2C_M_NOSTART")