Exporting hardware kill switches (hks) to userspace

Summarizing current state:

Using gpio-keys

Until recently we exported HKS as keys to userspace, that had several problems:

Upsides:

• trivial to use on the kernel side, existing driver

Downsides:

• keys are not associated to a device so it's not clear e.g. which wifi device is toggled off
• keys indicate intend (turn s.th. off) instead of state (which prompted g-s-d to e.g. hit airplane mode), accentuated by us reusing keysyms for that purpose
• keys being pressed all the time leads to interesting results over the stack (like key repeat triggering in)
• single key can't be bound to multiple keysyms

Using rfkill-hks

So we came up with rfkill-hks (!77 (closed))

Upsides:

• relatively simple on the kernel side
• can indicate state
• well integrated into the stack (g-s-d, ...)
• could be extended to ACPI based systems

Downsides:

• hks are (currently) not associated to a device so it's not clear e.g. which wifi device is toggled off. This is fixable though (at least most of the time, see below)
• current gpio can't be bound to multiple hks, fixable (see !77 (closed))
• not all hks are rfkill: camera, mic

In order to make the hks driver aware we'd have to do s.th. like https://source.puri.sm/Librem5/linux-next/-/issues/252#note_137170 which is nice since the driver gets awareness there's no power available (which afaik wouldn't work when modelling this as regulator). This only works nicely for DT devices, e.g. a USB modem would need another way to learn about the GPIO.

Using Regulator/supply framework

Upsides:

• existing framework and it's basically what is happening hardware wise

Downsides:

• userspace knows nothing about it
• drivers expect to be able to turn on regulators which wouldn't work for hks so we'd need handling there as well

So with the above i'd continue with the rfkill route atm to tie drivers to it as a base for upstream discussion. Input is very welcome here already!