From: Johannes Berg <johannes@sipsolutions.net>
To: Tim Harvey <tharvey@gateworks.com>, linux-wireless@vger.kernel.org
Subject: Re: gpio outputs that disable wireless to PCI Express Mini Card and RFKILL
Date: Thu, 29 Dec 2016 16:18:08 +0100 [thread overview]
Message-ID: <1483024688.13037.1.camel@sipsolutions.net> (raw)
In-Reply-To: <CAJ+vNU33Z05DaQGER8KJoPX5g1w=HWjKFDbNs0S0gxKDcFV7bg@mail.gmail.com> (sfid-20161229_160911_547687_7AB8BEF3)
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
prev parent reply other threads:[~2016-12-29 15:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-29 15:07 gpio outputs that disable wireless to PCI Express Mini Card and RFKILL Tim Harvey
2016-12-29 15:18 ` Johannes Berg [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1483024688.13037.1.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=tharvey@gateworks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).