mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andi Shyti <andi.shyti@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
	 linux-i2c <linux-i2c@vger.kernel.org>
Subject: Re: [GIT PULL] i2c for v7.4, part 2
Date: Mon, 26 Oct 2026 18:42:01 +0100	[thread overview]
Message-ID: <at-MCkIj2_kLxgAY@zenone.zhora.eu> (raw)
In-Reply-To: <CAHk-=wiMOMfksBhvDa+huuNCAu_EfpxzLiSawNxdady0r=zFEg@mail.gmail.com>

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@kernel.org> 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")

  reply	other threads:[~2026-10-26 17:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-25 20:20 Andi Shyti
2026-10-26 17:15 ` Linus Torvalds
2026-10-26 17:42   ` Andi Shyti [this message]
2026-10-26 17:44     ` Andi Shyti
2026-10-26 17:24 ` pr-tracker-bot

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=at-MCkIj2_kLxgAY@zenone.zhora.eu \
    --to=andi.shyti@kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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

all inboxes | Powered by JetHome®