gpio outputs that disable wireless to PCI Express Mini Card and RFKILL

gpio outputs that disable wireless to PCI Express Mini Card and RFKILL

[Tim Harvey]

Greetings,

The PCI Express Mini Card (aka Mini PCIe) spec calls out pin 20 as
W_DISABLE# to allow a PCIe host to disable the add-in card's radio
operation and we have run this to a GPIO on our boards for some time.
The M.2 specs also provide such signals. Is there any support in the
Linux RFKILL subsystem to define this?

Looking over the RFKILL subsystem I see support for wireless drivers
to register with rfkill to support on/off/state hooks and support for
gpio based rfkill 'input' switches but I haven't seen anything that
deals with GPIO 'outputs' to add-in card slots. Perhaps support for
this hasn't been deemed necessary because instead software
controllable methods are always used to control rfkill states for the
wireless devices on add-in cards?

Best regards,

Tim

Tim Harvey - Principal Software Engineer
Gateworks Corporation - http://www.gateworks.com/
3026 S. Higuera St. San Luis Obispo CA 93401
805-781-2000

Re: gpio outputs that disable wireless to PCI Express Mini Card and RFKILL

[Johannes Berg]

On Thu, 2016-12-29 at 07:07 -0800, Tim Harvey wrote:
> Greetings,
> 
> The PCI Express Mini Card (aka Mini PCIe) spec calls out pin 20 as
> W_DISABLE# to allow a PCIe host to disable the add-in card's radio
> operation and we have run this to a GPIO on our boards for some time.
> The M.2 specs also provide such signals. Is there any support in the
> Linux RFKILL subsystem to define this?

Not directly, but that depends on what you mean by "support". This
whole thing is relatively simple - it's an input signal to the wireless
NIC, so that any reaction to the input originates there.

Typically (I know about Intel and ath9k devices) changes in this input
either trigger an interrupt (Intel) or are polled for (ath9k), and then
the already existing rfkill instance for the wireless NIC will reflect
a "hard block" when the driver notifies upper layers of the new state.

Or did you mean you want to use the CPU to *control* this GPIO? In this
case, I'm not sure that the rfkill subsystem is appropriate, but there
apparently are some such cases already where the platform rfkill's
software state essentially toggles the wireless NIC's hardware state.

I'd argue this is useless though since if you toggle the thing from
software then you might as well rely entirely on software rfkill.

johannes