Enhance to not directly access GPIO register

[hlyi]

Hi @jnilo1, I am creating a separated request based upon the discussion in #119.

Currently, s40button is directly access GPIO register space with hardcoded GPIO pin. Could we make the following enhancements:

1. avoid hardcoding pin number in the source c code, and extract from the device-tree. So it can be ported to a different platform easily.
2. avoid directly access GPIO register, can we use the similar method as the one used for the status LED?

Thanks!

[jnilo1]

Hi @hlyi,

Done — this is implemented and bench-verified, and will ship in the next release as s40button v2.

What changed

The daemon no longer touches GPIO registers at all. It now goes through the kernel GPIO character device (/dev/gpiochip0, uAPI v2 ioctls — raw, no libgpiod dependency, still a small static musl binary):

• Pin from the device tree: the board DTS now names the SoC GPIO lines (gpio-line-names on the gpio controller node — "reset-button" at line 9 on the Lidl board), and s40button finds its line by that name. Porting to a different board = moving the name in your DTS, zero code change.
• Fallback + override: on a kernel without line names it falls back to line 9, and -p <line 0-31> forces an explicit offset — handy for bring-up before your DTS is settled.
• The press logic (100 ms poll, debounce, 5 s long-press → recover_efr32 -q, LED feedback) is unchanged.

Why this fixes your G4 button specifically

Claiming the line through the kernel means the gpio-rtl819x driver's request() hook runs: it switches the pad to GPIO mode (CNR/DIR) and applies the PIN_MUX_SEL_2 pad-mux for pads B2–B6. Your G4 button sits on GPIO 14 (pad B6) — the pad-mux step that v1 never performed, which is why it stayed dead in #119. With v2, s40button -p 14 (or "reset-button" at index 14 in your gpio-line-names) gets the mux for free on claim.

On "the same method as the status LED"

We kept the spirit rather than the letter: the status LED goes through a kernel driver that owns its pin via the GPIO consumer API, and the button now does the same (kernel owns the line for the lifetime of the daemon's request fd; a second consumer gets a clean EBUSY). We deliberately did not enable the input subsystem / gpio-keys: it would cost kernel size on a 1.9 MB kernel partition and a userspace rewrite for no functional gain over the cdev poll.

Bench-verified on the Lidl gateway: name discovery, claim, idle-state read, line exclusivity, init-script restart.

[jnilo1]

Shipped — s40button v2 (GPIO cdev, line by DTS name, -p override) is in v3.10.0, released today. On your G4, s40button -p 14 (or "reset-button" at index 14 in your gpio-line-names) gets the B6 pad-mux applied on claim, as described above.

[hlyi]

@jnilo1 Thanks for the enhancement and releasing it!