From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Jiri Kosina <jkosina@suse.cz>
Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Matt LaPlante <kernel1@cyberdogtech.com>,
Johannes Berg <johannes@sipsolutions.net>,
"John W. Linville" <linville@tuxdriver.com>
Subject: linux-next: manual merge of the trivial tree with the wireless tree
Date: Wed, 3 Jun 2009 15:22:47 +1000 [thread overview]
Message-ID: <20090603152247.b52f552e.sfr@canb.auug.org.au> (raw)
Hi Jiri,
Today's linux-next merge of the trivial tree got a conflict in
Documentation/rfkill.txt between commit
c6d660ce29295d344fcdc3654274b4a0aad1a9c8 ("rfkill: rewrite") from the
wireless tree and commit 9976d9daf91d146724ad9c336f74c60d2195c386
("trivial: Miscellaneous documentation typo fixes") from the trivial tree.
I just used the version from the wireless tree since it has been
basically rewritten there (except I applied the "transmiter" to
"transmitter" fix - see below). Maybe the part of the trivial tree patch
that affects this file should be dropped.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc Documentation/rfkill.txt
index de941e3,bb17c65..0000000
--- a/Documentation/rfkill.txt
+++ b/Documentation/rfkill.txt
@@@ -111,20 -545,31 +111,20 @@@ The following sysfs entries exist for e
type: Name of the key type ("wlan", "bluetooth", etc).
state: Current state of the transmitter
0: RFKILL_STATE_SOFT_BLOCKED
- transmitter is forced off, but one can override it
- by a write to the state attribute;
+ transmitter is turned off by software
1: RFKILL_STATE_UNBLOCKED
- transmiter is (potentially) active
- transmitter is NOT forced off, and may operate if
- all other conditions for such operation are met
- (such as interface is up and configured, etc);
++ transmitter is (potentially) active
2: RFKILL_STATE_HARD_BLOCKED
transmitter is forced off by something outside of
- the driver's control. One cannot set a device to
- this state through writes to the state attribute;
- claim: 1: Userspace handles events, 0: Kernel handles events
-
-Both the "state" and "claim" entries are also writable. For the "state" entry
-this means that when 1 or 0 is written, the device rfkill state (if not yet in
-the requested state), will be will be toggled accordingly.
-
-For the "claim" entry writing 1 to it means that the kernel no longer handles
-key events even though RFKILL_INPUT input was enabled. When "claim" has been
-set to 0, userspace should make sure that it listens for the input events or
-check the sysfs "state" entry regularly to correctly perform the required tasks
-when the rkfill key is pressed.
-
-A note about input devices and EV_SW events:
-
-In order to know the current state of an input device switch (like
-SW_RFKILL_ALL), you will need to use an IOCTL. That information is not
-available through sysfs in a generic way at this time, and it is not available
-through the rfkill class AT ALL.
+ the driver's control.
+ claim: 0: Kernel handles events (currently always reads that value)
+
+rfkill devices also issue uevents (with an action of "change"), with the
+following environment variables set:
+
+RFKILL_NAME
+RFKILL_STATE
+RFKILL_TYPE
+
+The contents of these variables corresponds to the "name", "state" and
+"type" sysfs files explained above.
next reply other threads:[~2009-06-03 5:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-03 5:22 Stephen Rothwell [this message]
2009-06-03 8:07 ` linux-next: manual merge of the trivial tree with the wireless tree Jiri Kosina
2009-06-03 8:14 ` Johannes Berg
2009-11-17 4:49 Stephen Rothwell
2009-11-17 22:18 ` Jiri Kosina
2009-11-17 23:38 ` Stephen Rothwell
2011-04-11 3:28 Stephen Rothwell
2011-04-11 15:15 ` Justin P. Mattock
2011-04-11 15:17 ` Jiri Kosina
2011-04-11 15:24 ` Justin P. Mattock
2011-04-13 9:14 ` Jiri Kosina
2011-04-27 1:43 Stephen Rothwell
2011-04-27 9:22 ` Jiri Kosina
2013-08-21 4:20 Stephen Rothwell
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=20090603152247.b52f552e.sfr@canb.auug.org.au \
--to=sfr@canb.auug.org.au \
--cc=jkosina@suse.cz \
--cc=johannes@sipsolutions.net \
--cc=kernel1@cyberdogtech.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=linville@tuxdriver.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).