[PATCH] gpiolib: acpi: Move ACPI device NULL check to acpi_can_fallback_to_crs()

[PATCH] gpiolib: acpi: Move ACPI device NULL check to acpi_can_fallback_to_crs()

[Laura Nao]

Following the relocation of the function call outside of
__acpi_find_gpio(), move the ACPI device NULL check to
acpi_can_fallback_to_crs().

Signed-off-by: Laura Nao <laura.nao@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reported-by: "kernelci.org bot" <bot@kernelci.org>
Closes: https://lore.kernel.org/all/20240426154208.81894-1-laura.nao@collabora.com/
Fixes: 49c02f6e901c ("gpiolib: acpi: Move acpi_can_fallback_to_crs() out of __acpi_find_gpio()")
---
v1: https://lore.kernel.org/all/20240509104605.538274-1-laura.nao@collabora.com/T/#u
---
 drivers/gpio/gpiolib-acpi.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
index 553a5f94c00a..c7483cd800ee 100644
--- a/drivers/gpio/gpiolib-acpi.c
+++ b/drivers/gpio/gpiolib-acpi.c
@@ -939,7 +939,7 @@ static bool acpi_can_fallback_to_crs(struct acpi_device *adev,
 				     const char *con_id)
 {
 	/* Never allow fallback if the device has properties */
-	if (acpi_dev_has_props(adev) || adev->driver_gpios)
+	if (!adev || acpi_dev_has_props(adev) || adev->driver_gpios)
 		return false;
 
 	return con_id == NULL;
@@ -978,10 +978,10 @@ __acpi_find_gpio(struct fwnode_handle *fwnode, const char *con_id, unsigned int
 	}
 
 	/* Then from plain _CRS GPIOs */
-	if (!adev || !can_fallback)
-		return ERR_PTR(-ENOENT);
+	if (can_fallback)
+		return acpi_get_gpiod_by_index(adev, NULL, idx, info);
 
-	return acpi_get_gpiod_by_index(adev, NULL, idx, info);
+	return ERR_PTR(-ENOENT);
 }
 
 struct gpio_desc *acpi_find_gpio(struct fwnode_handle *fwnode,
-- 
2.30.2

Re: [PATCH] gpiolib: acpi: Move ACPI device NULL check to acpi_can_fallback_to_crs()

[Andy Shevchenko]

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.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] gpiolib: acpi: Move ACPI device NULL check to acpi_can_fallback_to_crs()

[Linux regression tracking (Thorsten Leemhuis)]

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? I'd say it should be fixes rather sooner than later, as other
people might run into this as well and then have to deal with bisecing,
reporting, ...

Ciao, Thorsten

Re: [PATCH] gpiolib: acpi: Move ACPI device NULL check to acpi_can_fallback_to_crs()

[Andy Shevchenko]

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

> I'd say it should be fixes rather sooner than later, as other
> people might run into this as well and then have to deal with bisecing,
> reporting, ...

Yes, but we have a process during merge window, it's special and different
from vX.Y-rc1..vX.Y times.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] gpiolib: acpi: Move ACPI device NULL check to acpi_can_fallback_to_crs()

[Linux regression tracking (Thorsten Leemhuis)]

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

Re: [PATCH] gpiolib: acpi: Move ACPI device NULL check to acpi_can_fallback_to_crs()

[Andy Shevchenko]

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

Re: [PATCH] gpiolib: acpi: Move ACPI device NULL check to acpi_can_fallback_to_crs()

[Linux regression tracking (Thorsten Leemhuis)]

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

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.

> 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

Ciao, Thorsten

Re: [PATCH] gpiolib: acpi: Move ACPI device NULL check to acpi_can_fallback_to_crs()

[Andy Shevchenko]

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

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] gpiolib: acpi: Move ACPI device NULL check to acpi_can_fallback_to_crs()

[Andy Shevchenko]

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

Re: [PATCH] gpiolib: acpi: Move ACPI device NULL check to acpi_can_fallback_to_crs()

[Linux regression tracking (Thorsten Leemhuis)]

On 21.05.24 17:27, 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:
> [...]
>>> 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.

Well, that's why the last sentence you quoted is there; but yeah, the
"sub-subsystem" case it only kinda indirectly covered there. I can add
something about it if people feel that this is needed. But in the end
I'd say in this case Bart should be involved or the one that feeds this
to Linus. We'll see soon how both react to your PR. Thx for that BTW!

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

We get into "best to ask Linus directly" territory here. I suspect
things for him boil down to "a fix is a fix; if it was reviewed and
ideally in next for ~2 days, let's just merge it to get rid of the
regression, unless there are strong reasons to wait a bit more (for
example if the fix is dangerous and better should be in -next somewhat
longer)".

Ciao, Thorsten

Re: [PATCH] gpiolib: acpi: Move ACPI device NULL check to acpi_can_fallback_to_crs()

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 833 bytes --]

Hi Andy,

On Tue, 21 May 2024 17:00:08 +0300 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>
> 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

My current daily reports say "Do not add any work intended for v6.11 to
your linux-next included branches until after v6.10-rc1 has been
released".  i.e. we don't want new development work added to linux-next
during the merge window as that may just cause unnecessary conflicts or
build failures while we are trying to just get the merge window done.

I have always said (maybe not recently) that bug fixes are always
welcome.  Also, more urgent bug fixes often just bypass linux-next.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]