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 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. Ciao, Thorsten
