| Message ID | 20240513095610.216668-1-laura.nao@collabora.com |
|---|---|
| State | Accepted |
| Commit | 4bcc9bba48fa1dfd4c0029b9bb201d90b90d58a3 |
| Headers | show |
| Series | gpiolib: acpi: Move ACPI device NULL check to acpi_can_fallback_to_crs() | expand |
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.
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
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.
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
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?
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
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".
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.
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
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.
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,