On Wed, 3 Jun 2009, Stephen Rothwell wrote:
> 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.
Hi,
thanks for letting me know. I have dropped the Documentation/rfkill.txt
hunk completely.
Wireless guys, will you please apply the transmiter -> transmitter fix to
your tree?
Thanks.
> --- 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.
>
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
