Date: Tue, 21 May 2024 17:53:06 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Linux regressions mailing list <regressions@...ts.linux.dev>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>,
	Laura Nao <laura.nao@...labora.com>,
	mika.westerberg@...ux.intel.com, linus.walleij@...aro.org,
	brgl@...ev.pl, kernel@...labora.com, linux-kernel@...r.kernel.org,
	linux-gpio@...r.kernel.org, linux-acpi@...r.kernel.org,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	"kernelci.org bot" <bot@...nelci.org>
Subject: Re: [PATCH] gpiolib: acpi: Move ACPI device NULL check to
 acpi_can_fallback_to_crs()

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:
> >>>> Following the relocation of the function call outside of
> >>>> __acpi_find_gpio(), move the ACPI device NULL check to
> >>>> acpi_can_fallback_to_crs().
> >>>
> >>> 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.

> 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. 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? 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?

Ideally I should be able to create a tag based on an (arbitrary) commit from
vanilla that is in the time of merge window and send it directly to Linus
(with the respective maintainer's Ack). That's what I call a fast track.
Maybe you can introduce and document a such?

-- 
With Best Regards,
Andy Shevchenko

Powered by blists - more mailing lists