[PATCH v3 1/2] Input: soc_button_array - fix MS Surface Pro 11 probe failure

[PATCH v3 1/2] Input: soc_button_array - fix MS Surface Pro 11 probe failure

[Hans de Goede]

On the MS Surface Pro 11 soc_button_array probing races with the GPIO
driver probing. If soc_button_array wins the race then gpiod_get() returns
EPROBE_DEFER, which should normally take care of retrying later, but
the soc_button_array code deliberately ignores EPROBE_DEFER causing it
to fail its probe() which causes the volume and power buttons to now work.

The ignoring of EPROBE_DEFER is there to deal with a problem specific to
older Bay Trail (BYT) and Cherry Trail (CHT) tablets which often use this
driver. Modify the error handling to only ignore EPROBE_DEFER on BYT and
CHT platforms and propagate EPROBE_DEFER normally on other platforms.

Fixes: bcf059578980 ("Input: soc_button_array - partial revert of support for newer surface devices")
Cc: stable@vger.kernel.org
Reported-by: Sergey Lebedev <lsa.uz@pm.me>
Closes: https://lore.kernel.org/lkml/20260830141355.55898-1-lsa.uz@pm.me/
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
---
This series has been tested on a Bay Trail tablet which needs the ignore
EPROBE_DEFER on BYT workaround because of a PMIC virtual GPIO.
---
Changes in v3:
- Add Fixes: tag
- Initialize irq to 0 (invalid IRQ) so that the new irq == -EPROBE_DEFER
  check does not potentially check an uninitialized variable (Shashiko)

Changes in v2:
- Also check for irq == -EPROBE_DEFER (Shashiko)
- Drop #ifdef X86-ified soc_intel_is_byt_or_cht() helper,
  linux/platform_data/x86/soc.h already contains non x86 stubs (Shashiko)
---
 drivers/input/misc/soc_button_array.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/input/misc/soc_button_array.c b/drivers/input/misc/soc_button_array.c
index b8cad415c62c..264c41f80d2b 100644
--- a/drivers/input/misc/soc_button_array.c
+++ b/drivers/input/misc/soc_button_array.c
@@ -16,6 +16,7 @@
 #include <linux/gpio/consumer.h>
 #include <linux/gpio_keys.h>
 #include <linux/gpio.h>
+#include <linux/platform_data/x86/soc.h>
 #include <linux/platform_device.h>
 
 static bool use_low_level_irq;
@@ -160,7 +161,7 @@ soc_button_device_create(struct platform_device *pdev,
 	struct gpio_keys_platform_data *gpio_keys_pdata;
 	const struct dmi_system_id *dmi_id;
 	int invalid_acpi_index = -1;
-	int error, gpio, irq;
+	int error, gpio, irq = 0;
 	int n_buttons = 0;
 
 	for (info = button_info; info->name; info++)
@@ -191,8 +192,9 @@ soc_button_device_create(struct platform_device *pdev,
 		error = soc_button_lookup_gpio(&pdev->dev, info->acpi_index, &gpio, &irq);
 		if (error || irq < 0) {
 			/*
-			 * Skip GPIO if not present. Note we deliberately
-			 * ignore -EPROBE_DEFER errors here. On some devices
+			 * Propagate -EPROBE_DEFER, skip button on other errors.
+			 *
+			 * -EPROBE_DEFER is ignored on Bay & Cherry Trail. Here
 			 * Intel is using so called virtual GPIOs which are not
 			 * GPIOs at all but some way for AML code to check some
 			 * random status bits without need a custom opregion.
@@ -201,6 +203,12 @@ soc_button_device_create(struct platform_device *pdev,
 			 * we do not have a driver for these so they will never
 			 * show up, therefore we ignore -EPROBE_DEFER.
 			 */
+			if ((error == -EPROBE_DEFER || irq == -EPROBE_DEFER) &&
+			    !(soc_intel_is_byt() || soc_intel_is_cht())) {
+				error = -EPROBE_DEFER;
+				goto err_free_mem;
+			}
+
 			continue;
 		}
 
-- 
2.55.0

[PATCH v3 2/2] Input: soc_button_array - check btns_desc->package.count

[Hans de Goede]

Check that btns_desc->package.count is not 0 before accessing
btns_desc->package.elements[0].

Fixes: 4c3362f44980 ("Input: soc_button_array - add support for ACPI 6.0 Generic Button Device")
Cc: stable@vger.kernel.org
Reported-by: Shashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/linux-input/20260909091440.3384C1F00A3A@smtp.kernel.org/
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
---
Changes in v3:
- This is a new patch in v3 of this series
---
 drivers/input/misc/soc_button_array.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/misc/soc_button_array.c b/drivers/input/misc/soc_button_array.c
index 264c41f80d2b..f08e29af531f 100644
--- a/drivers/input/misc/soc_button_array.c
+++ b/drivers/input/misc/soc_button_array.c
@@ -377,7 +377,7 @@ static struct soc_button_info *soc_button_get_button_info(struct device *dev)
 		}
 	}
 
-	if (!btns_desc) {
+	if (!btns_desc || !btns_desc->package.count) {
 		dev_err(dev, "ACPI Button Descriptors not found\n");
 		button_info = ERR_PTR(-ENODEV);
 		goto out;
-- 
2.55.0

Re: [PATCH v3 1/2] Input: soc_button_array - fix MS Surface Pro 11 probe failure

[Sergey Lebedev]

Hans,

It fixes it. Sixteen consecutive boots on the Surface Pro 11, every one with
both gpio-keys devices present and MSHW0040:00 bound. The baseline in my
report was 13 boots in 40.

  boots                     16
  buttons appeared          16
  first input at            1.242 - 1.377 s

For comparison the 13 stock successes ran 1.28 - 1.78 s, so no boot here was
slower than stock managed when it worked, and the spread is tighter. The unit
that binds this device by hand was disabled for the whole run, so nothing
masked the result.

Built on 7.0.0-30, Ubuntu 26.04; both patches apply to that kernel's copy of
the file as-is, 2/2 at an offset. Ubuntu ships the file unmodified - an
out-of-tree build of mainline v7.0's source carries the same srcversion as
Ubuntu's own module - so the tested source differs from stock by your patches
and nothing else.

One note for whoever tests this driver next rather than about the patch: on
this install soc_button_array is in the initramfs under MODULES=most, so
replacing the module under /lib/modules does nothing until update-initramfs
runs, and modinfo will report the new one while the old one is loaded. Three
boots of mine were recorded before I noticed. I checked
/sys/module/soc_button_array/srcversion on every boot above.

Patch 2/2 was in the same build and caused no regression, but I am not
claiming a test for it: the buttons appear here, so this machine's ACPI
descriptor package is not empty and the new check is never reached. So for
1/2 only:

Tested-by: Sergey Lebedev <lsa.uz@pm.me>

Sergey

Re: [PATCH v3 1/2] Input: soc_button_array - fix MS Surface Pro 11 probe failure

[Hans de Goede]

Hi,

On 9-Sep-26 12:25, Sergey Lebedev wrote:
> Hans,
> 
> It fixes it. Sixteen consecutive boots on the Surface Pro 11, every one with
> both gpio-keys devices present and MSHW0040:00 bound. The baseline in my
> report was 13 boots in 40.
> 
>   boots                     16
>   buttons appeared          16
>   first input at            1.242 - 1.377 s
> 
> For comparison the 13 stock successes ran 1.28 - 1.78 s, so no boot here was
> slower than stock managed when it worked, and the spread is tighter. The unit
> that binds this device by hand was disabled for the whole run, so nothing
> masked the result.
> 
> Built on 7.0.0-30, Ubuntu 26.04; both patches apply to that kernel's copy of
> the file as-is, 2/2 at an offset. Ubuntu ships the file unmodified - an
> out-of-tree build of mainline v7.0's source carries the same srcversion as
> Ubuntu's own module - so the tested source differs from stock by your patches
> and nothing else.
> 
> One note for whoever tests this driver next rather than about the patch: on
> this install soc_button_array is in the initramfs under MODULES=most, so
> replacing the module under /lib/modules does nothing until update-initramfs
> runs, and modinfo will report the new one while the old one is loaded. Three
> boots of mine were recorded before I noticed. I checked
> /sys/module/soc_button_array/srcversion on every boot above.
> 
> Patch 2/2 was in the same build and caused no regression, but I am not
> claiming a test for it: the buttons appear here, so this machine's ACPI
> descriptor package is not empty and the new check is never reached. So for
> 1/2 only:
> 
> Tested-by: Sergey Lebedev <lsa.uz@pm.me>

Great, thank you for testing!

Regards,

Hans