spi: Try to get ACPI GPIO IRQ earlier

PATCH In review Hans de Goede 3 participants 11 messages Nov 2, 2025 – Nov 6, 2025

Subsystems (3)

Stable branch ACPI SPI

lore

Share & tools

lore

Hans de Goede

author

2025-11-02 19:09 UTC #0 lore raw

PATCH 1/1 spi: Try to get ACPI GPIO IRQ earlier

Since commit d24cfee7f63d ("spi: Fix acpi deferred irq probe"), the acpi_dev_gpio_irq_get() call gets delayed till spi_probe() is called on the SPI device.

If there is no driver for the SPI device then the move to spi_probe() results in acpi_dev_gpio_irq_get() never getting called. This may cause problems by leaving the GPIO pin floating because this call is responsible for setting up the GPIO pin direction and/or bias according to the values from the ACPI tables.

Re-add the removed acpi_dev_gpio_irq_get() in acpi_register_spi_device() to ensure the GPIO pin is always correctly setup, while keeping the acpi_dev_gpio_irq_get() call added to spi_probe() to deal with -EPROBE_DEFER returns caused by the GPIO controller not having a driver yet.

Link https://bbs.archlinux.org/viewtopic.php?id=302348

Fixes d24cfee7f63d ("spi: Fix acpi deferred irq probe")

Cc [email protected]

Signed-off-by Hans de Goede <[email protected]>

---
 drivers/spi/spi.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

drivers/spi/spi.c +10 -0

index 2e0647a06890..8588e8562220 100644
@@ -2851,6 +2851,16 @@ static acpi_status acpi_register_spi_device(struct spi_controller *ctlr,
 	acpi_set_modalias(adev, acpi_device_hid(adev), spi->modalias,
 			  sizeof(spi->modalias));
 
+	/*
+	 * This gets re-tried in spi_probe() for -EPROBE_DEFER handling in case
+	 * the GPIO controller does not have a driver yet. This needs to be done
+	 * here too, because this call sets the GPIO direction and/or bias.
+	 * Setting these needs to be done even if there is no driver, in which
+	 * case spi_probe() will never get called.
+	 */
+	if (spi->irq < 0)
+		spi->irq = acpi_dev_gpio_irq_get(adev, 0);
+
 	acpi_device_set_enumerated(adev);
 
 	adev->power.flags.ignore_parent = true;

Signature · 1 line

2.51.1

Andy Shevchenko

2025-11-03 09:35 UTC #1 lore raw

Quoted 10 lines · Hans de Goede

Since commit d24cfee7f63d ("spi: Fix acpi deferred irq probe"), the acpi_dev_gpio_irq_get() call gets delayed till spi_probe() is called on the SPI device.
If there is no driver for the SPI device then the move to spi_probe() results in acpi_dev_gpio_irq_get() never getting called. This may cause problems by leaving the GPIO pin floating because this call is responsible for setting up the GPIO pin direction and/or bias according to the values from the ACPI tables.

Quoted 5 lines

Re-add the removed acpi_dev_gpio_irq_get() in acpi_register_spi_device() to ensure the GPIO pin is always correctly setup, while keeping the acpi_dev_gpio_irq_get() call added to spi_probe() to deal with -EPROBE_DEFER returns caused by the GPIO controller not having a driver yet.

Even before following the link to some papering over module via the link below I wondered, if the I²C case should be covered as well. The
https://github.com/alexpevzner/hotfix-kvadra-touchpad refers to I²C enabled touchpads.

Quoted 1 line

Link https://bbs.archlinux.org/viewtopic.php?id=302348

...

I'm not against the SPI fix, but is it confirmed that it really fixes the issue?

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Hans de Goede

author

2025-11-03 09:57 UTC #2 lore raw

Hi,

Quoted 22 lines · Andy Shevchenko

Quoted 10 lines · Hans de Goede
Since commit d24cfee7f63d ("spi: Fix acpi deferred irq probe"), the acpi_dev_gpio_irq_get() call gets delayed till spi_probe() is called on the SPI device.
If there is no driver for the SPI device then the move to spi_probe() results in acpi_dev_gpio_irq_get() never getting called. This may cause problems by leaving the GPIO pin floating because this call is responsible for setting up the GPIO pin direction and/or bias according to the values from the ACPI tables.
Quoted 5 lines
Re-add the removed acpi_dev_gpio_irq_get() in acpi_register_spi_device() to ensure the GPIO pin is always correctly setup, while keeping the acpi_dev_gpio_irq_get() call added to spi_probe() to deal with -EPROBE_DEFER returns caused by the GPIO controller not having a driver yet.
Even before following the link to some papering over module via the link below I wondered, if the I²C case should be covered as well. The
https://github.com/alexpevzner/hotfix-kvadra-touchpad refers to I²C enabled touchpads.

Quoted 5 lines

Quoted 1 line
Link https://bbs.archlinux.org/viewtopic.php?id=302348
...
I'm not against the SPI fix, but is it confirmed that it really fixes the issue?

Yes Mark and I got an offlist email bisecting this to the:

Fixes d24cfee7f63d ("spi: Fix acpi deferred irq probe")

commit (on a stable kernel series) and a later email confirming that this patch fixes it.

It seems that leaving the fingerprint reader enable pin (the first GPIO listed in _CRS which is an output only pin, is likely the enable pin) floating is causing these issues. So in a way the acpi_dev_gpio_irq_get() fixing this by forcing the enable pin to no longer float is a bit of luck. But things did work before d24cfee7f63d ("spi: Fix acpi deferred irq probe") so we need this to fix a regression and as you indicate it seems
like a good idea in general and maybe we should also do this for i2c.

As for doing something similar for I2C devices, that is an interesting question. Even though it is possible I'm not aware of any i2c-devices which have a userspace driver like SPI/USB fingerprint readers do, so on i2c I would expect probe() to always get called. So I'm not sure it is necessary there.

Regards,

Hans

Andy Shevchenko

2025-11-03 10:13 UTC #3 lore raw

Quoted 24 lines · Hans de Goede

Quoted 23 lines · Andy Shevchenko
Quoted 10 lines · Hans de Goede
Since commit d24cfee7f63d ("spi: Fix acpi deferred irq probe"), the acpi_dev_gpio_irq_get() call gets delayed till spi_probe() is called on the SPI device.
If there is no driver for the SPI device then the move to spi_probe() results in acpi_dev_gpio_irq_get() never getting called. This may cause problems by leaving the GPIO pin floating because this call is responsible for setting up the GPIO pin direction and/or bias according to the values from the ACPI tables.
Quoted 5 lines
Re-add the removed acpi_dev_gpio_irq_get() in acpi_register_spi_device() to ensure the GPIO pin is always correctly setup, while keeping the acpi_dev_gpio_irq_get() call added to spi_probe() to deal with -EPROBE_DEFER returns caused by the GPIO controller not having a driver yet.
Even before following the link to some papering over module via the link below I wondered, if the I²C case should be covered as well. The
https://github.com/alexpevzner/hotfix-kvadra-touchpad refers to I²C enabled touchpads.
Quoted 1 line
Link https://bbs.archlinux.org/viewtopic.php?id=302348

...

Quoted 8 lines

Quoted 1 line
I'm not against the SPI fix, but is it confirmed that it really fixes the issue?
Yes Mark and I got an offlist email bisecting this to the:
Fixes d24cfee7f63d ("spi: Fix acpi deferred irq probe")
commit (on a stable kernel series) and a later email confirming that this patch fixes it.

Shouldn't we use Closes in this case instead of Link?

Quoted 6 lines

It seems that leaving the fingerprint reader enable pin (the first GPIO listed in _CRS which is an output only pin, is likely the enable pin) floating is causing these issues. So in a way the acpi_dev_gpio_irq_get() fixing this by forcing the enable pin to no longer float is a bit of luck. But things did work before d24cfee7f63d ("spi: Fix acpi deferred irq probe") so we need this to fix a regression

Yeah, fixing a regression is good thing, but not papering over the issue.

Quoted 8 lines

and as you indicate it seems
like a good idea in general and maybe we should also do this for i2c.
As for doing something similar for I2C devices, that is an interesting question. Even though it is possible I'm not aware of any i2c-devices which have a userspace driver like SPI/USB fingerprint readers do, so on i2c I would expect probe() to always get called. So I'm not sure it is necessary there.

Reading the problem statement (the second paragraph) I lean towards a generic solution residing somewhere in drivers/acpi/scan.c (like acpi_init_device_object() / acpi_bus_attach() calls), although I don't see a quick way how to achieve this. It seems would require a bit of refactoring to allow ACPI glue code to call specific subsystem calls or making a GPIOLIB to provide some "early" initialisation flow(s).

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Hans de Goede

author

2025-11-03 10:20 UTC #4 lore raw

Hi,

Quoted 30 lines · Andy Shevchenko

Quoted 24 lines · Hans de Goede
Quoted 23 lines · Andy Shevchenko
Quoted 10 lines · Hans de Goede
Since commit d24cfee7f63d ("spi: Fix acpi deferred irq probe"), the acpi_dev_gpio_irq_get() call gets delayed till spi_probe() is called on the SPI device.
If there is no driver for the SPI device then the move to spi_probe() results in acpi_dev_gpio_irq_get() never getting called. This may cause problems by leaving the GPIO pin floating because this call is responsible for setting up the GPIO pin direction and/or bias according to the values from the ACPI tables.
Quoted 5 lines
Re-add the removed acpi_dev_gpio_irq_get() in acpi_register_spi_device() to ensure the GPIO pin is always correctly setup, while keeping the acpi_dev_gpio_irq_get() call added to spi_probe() to deal with -EPROBE_DEFER returns caused by the GPIO controller not having a driver yet.
Even before following the link to some papering over module via the link below I wondered, if the I²C case should be covered as well. The
https://github.com/alexpevzner/hotfix-kvadra-touchpad refers to I²C enabled touchpads.
Quoted 1 line
Link https://bbs.archlinux.org/viewtopic.php?id=302348
...
Quoted 2 lines
Quoted 1 line
I'm not against the SPI fix, but is it confirmed that it really fixes the issue?

Quoted 8 lines

Quoted 6 lines
Yes Mark and I got an offlist email bisecting this to the:
Fixes d24cfee7f63d ("spi: Fix acpi deferred irq probe")
commit (on a stable kernel series) and a later email confirming that this patch fixes it.
Shouldn't we use Closes in this case instead of Link?

I guess so.

Quoted 8 lines

Quoted 6 lines
It seems that leaving the fingerprint reader enable pin (the first GPIO listed in _CRS which is an output only pin, is likely the enable pin) floating is causing these issues. So in a way the acpi_dev_gpio_irq_get() fixing this by forcing the enable pin to no longer float is a bit of luck. But things did work before d24cfee7f63d ("spi: Fix acpi deferred irq probe") so we need this to fix a regression
Yeah, fixing a regression is good thing, but not papering over the issue.

I agree in principle, but this is a quick and safe way to fix the regression, where as the generic fix you describe below is likely months away and also has significant risks of causing regressions in various places, see below.

Quoted 9 lines

Quoted 8 lines
and as you indicate it seems
like a good idea in general and maybe we should also do this for i2c.
As for doing something similar for I2C devices, that is an interesting question. Even though it is possible I'm not aware of any i2c-devices which have a userspace driver like SPI/USB fingerprint readers do, so on i2c I would expect probe() to always get called. So I'm not sure it is necessary there.

Quoted 6 lines

Reading the problem statement (the second paragraph) I lean towards a generic solution residing somewhere in drivers/acpi/scan.c (like acpi_init_device_object() / acpi_bus_attach() calls), although I don't see a quick way how to achieve this. It seems would require a bit of refactoring to allow ACPI glue code to call specific subsystem calls or making a GPIOLIB to provide some "early" initialisation flow(s).

I guess that you want to do the direction and bias init on all GPIOs listed in _CRS, at least for devices with status == present ?

I was wondering about the same thing, but ACPI tables are full of, well, erm, garbage in various places so I'm afraid that doing this for all GPIO _CRS resources is likely to cause a whole lot of pain.

Typically the firmware already sets up the direction + bias of all used pins. I'm pretty sure the BIOS-es have some GPIO init table especially for this somewhere.

Now those init-tables may have bugs, but I'm seriously worried about the implication of doing the direction + bios setup for all _CRS GPIO entries. I have simply seen too much non sense devices (with _STA returning 0x0f) listing GPIOs also actually used elsewhere to think this is a good idea.

Regards,

Hans

Andy Shevchenko

2025-11-03 13:15 UTC #5 lore raw

Quoted 26 lines · Hans de Goede

Quoted 25 lines · Andy Shevchenko
Quoted 24 lines · Hans de Goede
Quoted 23 lines · Andy Shevchenko
Quoted 10 lines · Hans de Goede
Since commit d24cfee7f63d ("spi: Fix acpi deferred irq probe"), the acpi_dev_gpio_irq_get() call gets delayed till spi_probe() is called on the SPI device.
If there is no driver for the SPI device then the move to spi_probe() results in acpi_dev_gpio_irq_get() never getting called. This may cause problems by leaving the GPIO pin floating because this call is responsible for setting up the GPIO pin direction and/or bias according to the values from the ACPI tables.
Quoted 5 lines
Re-add the removed acpi_dev_gpio_irq_get() in acpi_register_spi_device() to ensure the GPIO pin is always correctly setup, while keeping the acpi_dev_gpio_irq_get() call added to spi_probe() to deal with -EPROBE_DEFER returns caused by the GPIO controller not having a driver yet.
Even before following the link to some papering over module via the link below I wondered, if the I²C case should be covered as well. The
https://github.com/alexpevzner/hotfix-kvadra-touchpad refers to I²C enabled touchpads.
Quoted 1 line
Link https://bbs.archlinux.org/viewtopic.php?id=302348

...

Quoted 20 lines

Quoted 10 lines
Quoted 8 lines
Quoted 1 line
I'm not against the SPI fix, but is it confirmed that it really fixes the issue?
Yes Mark and I got an offlist email bisecting this to the:
Fixes d24cfee7f63d ("spi: Fix acpi deferred irq probe")
commit (on a stable kernel series) and a later email confirming that this patch fixes it.
Shouldn't we use Closes in this case instead of Link?
I guess so.
Quoted 7 lines
Quoted 6 lines
It seems that leaving the fingerprint reader enable pin (the first GPIO listed in _CRS which is an output only pin, is likely the enable pin) floating is causing these issues. So in a way the acpi_dev_gpio_irq_get() fixing this by forcing the enable pin to no longer float is a bit of luck. But things did work before d24cfee7f63d ("spi: Fix acpi deferred irq probe") so we need this to fix a regression

Quoted 6 lines

Quoted 1 line
Yeah, fixing a regression is good thing, but not papering over the issue.
I agree in principle, but this is a quick and safe way to fix the regression, where as the generic fix you describe below is likely months away and also has significant risks of causing regressions in various places, see below.

Perhaps we should add a TODO / FIXME there as well? So at least we will know that this is not a proper solution.

Quoted 16 lines

Quoted 9 lines
Quoted 8 lines
and as you indicate it seems
like a good idea in general and maybe we should also do this for i2c.
As for doing something similar for I2C devices, that is an interesting question. Even though it is possible I'm not aware of any i2c-devices which have a userspace driver like SPI/USB fingerprint readers do, so on i2c I would expect probe() to always get called. So I'm not sure it is necessary there.
Quoted 6 lines
Reading the problem statement (the second paragraph) I lean towards a generic solution residing somewhere in drivers/acpi/scan.c (like acpi_init_device_object() / acpi_bus_attach() calls), although I don't see a quick way how to achieve this. It seems would require a bit of refactoring to allow ACPI glue code to call specific subsystem calls or making a GPIOLIB to provide some "early" initialisation flow(s).

Quoted 2 lines

I guess that you want to do the direction and bias init on all GPIOs listed in _CRS, at least for devices with status == present ?

For the devices that are serial busses only (I²C, SPI, UART).

Quoted 9 lines

I was wondering about the same thing, but ACPI tables are full of, well, erm, garbage in various places so I'm afraid that doing this for all GPIO _CRS resources is likely to cause a whole lot of pain.
Typically the firmware already sets up the direction + bias of all used pins. I'm pretty sure the BIOS-es have some GPIO init table especially for this somewhere.

Quoted 5 lines

Now those init-tables may have bugs, but I'm seriously worried about the implication of doing the direction + bios setup for all _CRS GPIO entries. I have simply seen too much non sense devices (with _STA returning 0x0f) listing GPIOs also actually used elsewhere to think this is a good idea.

Btw, other GPIO initialisation issues we have been solving by adding quirks. Why this one can't be targeted with the same approach?

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Andy Shevchenko

Reviewed-by

2025-11-06 10:16 UTC #6 lore raw

Quoted 27 lines · Andy Shevchenko

Quoted 26 lines · Hans de Goede
Quoted 25 lines · Andy Shevchenko
Quoted 24 lines · Hans de Goede
Quoted 23 lines · Andy Shevchenko
Quoted 10 lines · Hans de Goede
Since commit d24cfee7f63d ("spi: Fix acpi deferred irq probe"), the acpi_dev_gpio_irq_get() call gets delayed till spi_probe() is called on the SPI device.
If there is no driver for the SPI device then the move to spi_probe() results in acpi_dev_gpio_irq_get() never getting called. This may cause problems by leaving the GPIO pin floating because this call is responsible for setting up the GPIO pin direction and/or bias according to the values from the ACPI tables.
Quoted 5 lines
Re-add the removed acpi_dev_gpio_irq_get() in acpi_register_spi_device() to ensure the GPIO pin is always correctly setup, while keeping the acpi_dev_gpio_irq_get() call added to spi_probe() to deal with -EPROBE_DEFER returns caused by the GPIO controller not having a driver yet.
Even before following the link to some papering over module via the link below I wondered, if the I²C case should be covered as well. The
https://github.com/alexpevzner/hotfix-kvadra-touchpad refers to I²C enabled touchpads.
Quoted 1 line
Link https://bbs.archlinux.org/viewtopic.php?id=302348

...

Quoted 22 lines

Quoted 22 lines
Quoted 10 lines
Quoted 8 lines
Quoted 1 line
I'm not against the SPI fix, but is it confirmed that it really fixes the issue?
Yes Mark and I got an offlist email bisecting this to the:
Fixes d24cfee7f63d ("spi: Fix acpi deferred irq probe")
commit (on a stable kernel series) and a later email confirming that this patch fixes it.
Shouldn't we use Closes in this case instead of Link?
I guess so.
Quoted 8 lines
Quoted 6 lines
It seems that leaving the fingerprint reader enable pin (the first GPIO listed in _CRS which is an output only pin, is likely the enable pin) floating is causing these issues. So in a way the acpi_dev_gpio_irq_get() fixing this by forcing the enable pin to no longer float is a bit of luck. But things did work before d24cfee7f63d ("spi: Fix acpi deferred irq probe") so we need this to fix a regression
Yeah, fixing a regression is good thing, but not papering over the issue.

Quoted 7 lines

Quoted 4 lines
I agree in principle, but this is a quick and safe way to fix the regression, where as the generic fix you describe below is likely months away and also has significant risks of causing regressions in various places, see below.
Perhaps we should add a TODO / FIXME there as well? So at least we will know that this is not a proper solution.

Assuming it's added

Reviewed-by Andy Shevchenko <[email protected]>

as a quick fix of the regression. But in long term I would like to see the real solution here.

Quoted 38 lines

Quoted 16 lines
Quoted 9 lines
Quoted 8 lines
and as you indicate it seems
like a good idea in general and maybe we should also do this for i2c.
As for doing something similar for I2C devices, that is an interesting question. Even though it is possible I'm not aware of any i2c-devices which have a userspace driver like SPI/USB fingerprint readers do, so on i2c I would expect probe() to always get called. So I'm not sure it is necessary there.
Quoted 6 lines
Reading the problem statement (the second paragraph) I lean towards a generic solution residing somewhere in drivers/acpi/scan.c (like acpi_init_device_object() / acpi_bus_attach() calls), although I don't see a quick way how to achieve this. It seems would require a bit of refactoring to allow ACPI glue code to call specific subsystem calls or making a GPIOLIB to provide some "early" initialisation flow(s).
Quoted 2 lines
I guess that you want to do the direction and bias init on all GPIOs listed in _CRS, at least for devices with status == present ?
For the devices that are serial busses only (I²C, SPI, UART).
Quoted 9 lines
I was wondering about the same thing, but ACPI tables are full of, well, erm, garbage in various places so I'm afraid that doing this for all GPIO _CRS resources is likely to cause a whole lot of pain.
Typically the firmware already sets up the direction + bias of all used pins. I'm pretty sure the BIOS-es have some GPIO init table especially for this somewhere.
Quoted 5 lines
Now those init-tables may have bugs, but I'm seriously worried about the implication of doing the direction + bios setup for all _CRS GPIO entries. I have simply seen too much non sense devices (with _STA returning 0x0f) listing GPIOs also actually used elsewhere to think this is a good idea.
Btw, other GPIO initialisation issues we have been solving by adding quirks. Why this one can't be targeted with the same approach?

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Mark Brown

maintainer

2025-11-06 11:34 UTC #7 lore raw

In reply to Hans de Goede

Quoted 11 lines · Hans de Goede

Since commit d24cfee7f63d ("spi: Fix acpi deferred irq probe"), the acpi_dev_gpio_irq_get() call gets delayed till spi_probe() is called on the SPI device.
If there is no driver for the SPI device then the move to spi_probe() results in acpi_dev_gpio_irq_get() never getting called. This may cause problems by leaving the GPIO pin floating because this call is responsible for setting up the GPIO pin direction and/or bias according to the values from the ACPI tables.
[...]

Applied to

https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/1] spi: Try to get ACPI GPIO IRQ earlier

      commit: 3cd2018e15b3d66d2187d92867e265f45ad79e6f

All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying to this mail.

Thanks,
Mark

Hans de Goede

author

2025-11-06 12:23 UTC #8 lore raw

Hi Mark,

Quoted 13 lines · Mark Brown

Quoted 11 lines · Hans de Goede
Since commit d24cfee7f63d ("spi: Fix acpi deferred irq probe"), the acpi_dev_gpio_irq_get() call gets delayed till spi_probe() is called on the SPI device.
If there is no driver for the SPI device then the move to spi_probe() results in acpi_dev_gpio_irq_get() never getting called. This may cause problems by leaving the GPIO pin floating because this call is responsible for setting up the GPIO pin direction and/or bias according to the values from the ACPI tables.
[...]

Quoted 8 lines

Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi: Try to get ACPI GPIO IRQ earlier
      commit: 3cd2018e15b3d66d2187d92867e265f45ad79e6f

Thank you.

I believe that Andy's Reviewed-by was intended for a v2 with extending the comment with an extra paragraph with something like:

"TODO: ideally the setup of the GPIO should be handled in a generic manner in the ACPI/gpiolib core code".

Since you've already merged this now l'll prepare a follow-up patch to extend the comment with that info.

Regards,

Hans

Mark Brown

maintainer

2025-11-06 13:05 UTC #9 lore raw

Quoted 2 lines · Hans de Goede

I believe that Andy's Reviewed-by was intended for a v2 with extending the comment with an extra paragraph with something like:

Possibly, but that got sent well after I'd got things into CI anyway and I didn't see it till after the CI had run.

Quoted 2 lines

Since you've already merged this now l'll prepare a follow-up patch to extend the comment with that info.

Sure.

Andy Shevchenko

2025-11-06 13:09 UTC #10 lore raw

In reply to Hans de Goede

Quoted 2 lines · Hans de Goede

Quoted 1 line · Mark Brown
On Sun, 02 Nov 2025 20:09:21 +0100, Hans de Goede wrote:

[...]

Quoted 9 lines

Quoted 8 lines
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi: Try to get ACPI GPIO IRQ earlier
      commit: 3cd2018e15b3d66d2187d92867e265f45ad79e6f

Quoted 7 lines

Thank you.
I believe that Andy's Reviewed-by was intended for a v2 with extending the comment with an extra paragraph with something like:
"TODO: ideally the setup of the GPIO should be handled in a generic manner in the ACPI/gpiolib core code".

Yes.

Quoted 2 lines

Since you've already merged this now l'll prepare a follow-up patch to extend the comment with that info.

Thanks!

Signature · 2 lines

With Best Regards,
Andy Shevchenko