From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Linux regressions mailing list <regressions@lists.linux.dev>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Laura Nao <laura.nao@collabora.com>,
mika.westerberg@linux.intel.com, linus.walleij@linaro.org,
brgl@bgdev.pl, kernel@collabora.com,
linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-acpi@vger.kernel.org,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
"kernelci.org bot" <bot@kernelci.org>
Subject: Re: [PATCH] gpiolib: acpi: Move ACPI device NULL check to acpi_can_fallback_to_crs()
Date: Tue, 21 May 2024 19:50:01 +0300 [thread overview]
Message-ID: <ZkzQuWmLZGhIQl-2@smile.fi.intel.com> (raw)
In-Reply-To: <Zky9bovo_99LwDfY@smile.fi.intel.com>
On Tue, May 21, 2024 at 06:27:42PM +0300, Andy Shevchenko wrote:
> On Tue, May 21, 2024 at 05:14:07PM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
> > On 21.05.24 16:53, Andy Shevchenko wrote:
> > > On Tue, May 21, 2024 at 04:26:32PM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
> > >> On 21.05.24 16:00, Andy Shevchenko wrote:
> > >>> On Tue, May 21, 2024 at 12:01:17PM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
> > >>>> On 13.05.24 12:02, Andy Shevchenko wrote:
> > >>>>> On Mon, May 13, 2024 at 11:56:10AM +0200, Laura Nao wrote:
...
> > >>>>> Thank you, I'll add this to my tree as we have already the release happened.
> > >>>>> I will be available after v6.10-rc1 is out.
> > >>>>
> > >>>> Hmm, what exactly do you mean with that? It sounds as you only want to
> > >>>> add this to the tree once -rc1 is out -- which seems likely at this
> > >>>> point, as that patch is not yet in -next. If that's the case allow me to
> > >>>> ask: why?
> > >>>
> > >>> Because:
> > >>>
> > >>> - that's the policy of Linux Next (do not include what's not supposed to be
> > >>> merged during merge window), Cc'ed to Stephen to clarify, it might be that
> > >>> I'm mistaken
> > >>>
> > >>> - the process of how we maintain the branches is to have them based on top of
> > >>> rc1 (rarely on other rcX and never on an arbitrary commit from vanilla
> > >
> > > Note, besides above reasons the one is (was in this case as you noticed)
> > > to wait until dependencies laid down in the upstream.
> >
> > Well, that can be a reason, sure. But I still wonder if Linus would have
> > preferred to get 49c02f6e901c and this fix for it in the same pull.
> > Sure, adding this fix would have been a late addition, but when it is a
> > fix and mentioned in the PR that from what I can see is no problem at
> > all for him.
>
>
> > >> Something like that is what I feared. And yes, some of that is true. But
> > >> the patch in this thread contains a Fixes: tag for commit 49c02f6e901c
> > >> which was merged during this merge window -- and that patch thus ideally
> > >> should (ideally after some testing in -next) be merge during the merge
> > >> window as well, to ensure the problem does not even hit -rc1.
> > >
> > >> That's something a lot of subsystem master all the time. The scheduler
> > >> for example:
> > >>
> > >> https://git.kernel.org/torvalds/c/6e5a0c30b616bfff6926ecca5d88e3d06e6bf79a
> > >> https://git.kernel.org/torvalds/c/8dde191aabba42e9c16c8d9c853a72a062db27ee
> > >>
> > >> Other subsystems (perf, x86, net) do this, too. Not sure how they
> > >> exactly do that with git; I think some (most?) have a dedicated -fixes
> > >> branch (based on master and fast-forwarded after Linus merged from it)
> > >> for that is also included in next in parallel to their "for-next"
> > >> branch. Stephen will know for sure.
> > >
> > > This part of the kernel is not so critical as scheduler, but in general I agree
> > > that sooner we get this in is better.
> >
> > Side note: with all those CIs that "sooner" became more important I'd
> > say, as I frequently see multiple CI systems running into and bisecting
> > problems -- which humans then look into and report, which is a waste of
> > time.
>
> Oh, yes, our processes are completely non-ideal. Once I tried to micro-optimize
> the way of Cc'ing people for the patches to avoid waste of resources and you
> know what? This is a dead end. I gave up, so I don't care anymore and don't
> buy this argument anymore. If people are serious about this, they should be
> serious consistently.
>
> For your reference:
> 20240423132024.2368662-1-andriy.shevchenko@linux.intel.com
>
> > > The other thing, that we have 3 regressions
> > > now for very this code. And some of them are still under discussions.
> > >
> > > Wouldn't be better to gather all fixes and send a bunch via proper process
> > > after rc1?
> >
> > Depends on the situation. As a general approach I'd say no, but there
> > definitely can be situations where that is wise.
> >
> > > This will ensure that everything we know about is covered properly
> > > and processed accordingly,
> > >
> > > In broader way, the process should be amended if you want a fast track for
> > > the patches like this. I'm on the second level here, Bart is the maintainer
> > > who sends PRs directly to Linus. Do we have anything like this?
> >
> > Pretty sure Linus wants maintains to just fast-track things when needed
> > by sending an additional PR; he multiple times said that this is not a
> > problem.
> >
> > But there is a way to fast track things: just ask Linus to pull a patch
> > from the list (e.g. in a reply to the patch while CCIng tim). He
> > multiple times said this is no problem for him, unless it becomes the
> > norm. This is documented in
> > Documentation/process/handling-regressions.rst /
> > https://docs.kernel.org/process/handling-regressions.html
>
> "For urgent regressions, consider asking Linus to pick up the fix straight from
> the mailing list: he is totally fine with that for uncontroversial fixes.
> Ideally though such requests should happen in accordance with the subsystem
> maintainers or come directly from them."
>
> The first thing I'm not so comfortable with is that Bart as a subsystem
> maintainer will be by-passed. The second one, is the metrics of urgency.
> I can assume that something from a TIP tree is really urgent and they
> even have established fast track for ages. But why do you think this fix
> is of the same level of urgency? I haven't found in the documentation
> the checklist which I can count numbers, compare with a table and have
> a clear answer "yes, I have do it".
FWIW, I have just sent a PR to Linus and GPIO maintainers with this one
included. Hopefully everybody is now happy.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2024-05-21 16:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240513095610.216668-1-laura.nao@collabora.com>
[not found] ` <ZkHlLLLoagsYlll7@smile.fi.intel.com>
2024-05-21 10:01 ` [PATCH] gpiolib: acpi: Move ACPI device NULL check to acpi_can_fallback_to_crs() Linux regression tracking (Thorsten Leemhuis)
2024-05-21 14:00 ` Andy Shevchenko
2024-05-21 14:26 ` Linux regression tracking (Thorsten Leemhuis)
2024-05-21 14:53 ` Andy Shevchenko
2024-05-21 15:14 ` Linux regression tracking (Thorsten Leemhuis)
2024-05-21 15:27 ` Andy Shevchenko
2024-05-21 16:50 ` Andy Shevchenko [this message]
2024-05-21 18:41 ` Linux regression tracking (Thorsten Leemhuis)
2024-05-21 22:58 ` Stephen Rothwell
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=ZkzQuWmLZGhIQl-2@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=bot@kernelci.org \
--cc=brgl@bgdev.pl \
--cc=kernel@collabora.com \
--cc=laura.nao@collabora.com \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=regressions@lists.linux.dev \
--cc=sfr@canb.auug.org.au \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).