From: Jouni Malinen <jkm@devicescape.com>
To: Ivo van Doorn <ivdoorn@gmail.com>
Cc: Dan Williams <dcbw@redhat.com>,
Mark Wallis <mwallis@serialmonkey.com>,
netdev@vger.kernel.org, David Zeuthen <davidz@redhat.com>
Subject: Re: Hardware button support for Wireless cards
Date: Mon, 15 May 2006 09:20:45 -0700 [thread overview]
Message-ID: <20060515162045.GA10717@instant802.com> (raw)
In-Reply-To: <200605151712.23639.IvDoorn@gmail.com>
On Mon, May 15, 2006 at 05:12:20PM +0200, Ivo van Doorn wrote:
> Well I would think it is cleaner to inform userspace that the button is pressed
> and let userspace sort out what exactly should happen.
> But I doubt it will be a good idea when the driver is sending and event _and_
> disabled the radio. It could be that the user wants something to be done
> before the radio is being disabled.
Some hardware designs disable the radio in hardware, some don't.. In
other words, the behavior would not be consistent between hardware
designs unless the radio would be disabled unconditionally in
software-processed case. I would like to be able to trust on the
rfkill to really kill the radio regardless of whether the user space
mechanism is in place or not, i.e., I see this as a function that can be
used to disable radio in environments were use of wireless devices is
not allowed for some reason.
Sending an event to user space would be a good additional indication
that the radio was disabled. If user space wants to do something first,
I would think that doing this with full software control (i.e., not
depending on any particular hardware button and just having a UI
mechanism for triggering this) would allow more consistent behavior.
--
Jouni Malinen PGP id EFC895FA
next prev parent reply other threads:[~2006-05-15 16:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-15 12:57 Hardware button support for Wireless cards Mark Wallis
2006-05-15 13:25 ` Jiri Benc
2006-05-15 13:59 ` Ivo van Doorn
2006-05-15 14:06 ` Sergey Vlasov
2006-05-15 14:37 ` Dan Williams
2006-05-15 15:12 ` Ivo van Doorn
2006-05-15 16:20 ` Jouni Malinen [this message]
2006-05-16 3:10 ` Mark Wallis
2006-05-25 15:15 ` [RFC PATCH 0/2] " Ivo van Doorn
2006-05-15 16:19 ` David Zeuthen
2006-05-15 15:27 ` Jason Lunz
2006-05-15 16:01 ` Michael Buesch
2006-05-15 19:12 ` Dan Williams
2006-05-15 19:32 ` Michael Buesch
2006-05-15 19:46 ` Jason Lunz
2006-05-15 21:42 ` Ivo van Doorn
2006-05-15 20:08 ` John W. Linville
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=20060515162045.GA10717@instant802.com \
--to=jkm@devicescape.com \
--cc=davidz@redhat.com \
--cc=dcbw@redhat.com \
--cc=ivdoorn@gmail.com \
--cc=mwallis@serialmonkey.com \
--cc=netdev@vger.kernel.org \
/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).