linux-next: manual merge of the trivial tree with the wireless tree

[Stephen Rothwell]

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@xxxxxxxxxxxxxxxx

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/