Date:	Wed, 3 Jun 2009 10:07:35 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
Cc:	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Matt LaPlante <kernel1@...erdogtech.com>,
	Johannes Berg <johannes@...solutions.net>,
	"John W. Linville" <linville@...driver.com>
Subject: Re: linux-next: manual merge of the trivial tree with the wireless
 tree

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists