From: Hans de Goede <hidden> Date: 2026-09-09 09:39:39
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 <redacted>
Closes: https://lore.kernel.org/lkml/20260830141355.55898-1-lsa.uz@pm.me/
Signed-off-by: Hans de Goede <redacted>
---
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(-)
From: Hans de Goede <hidden> Date: 2026-09-09 09:39:41
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 <redacted>
---
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(-)
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 <redacted>
Sergey
From: Hans de Goede <hidden> Date: 2026-09-10 08:43:51
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 <redacted>
On Wed, Sep 09, 2026 at 11:39:33AM +0200, Hans de Goede wrote:
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 <redacted>
Closes: https://lore.kernel.org/lkml/20260830141355.55898-1-lsa.uz@pm.me/
Signed-off-by: Hans de Goede <redacted>