Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6: (1075 commits)
  myri10ge: update driver version number to 1.4.3-1.369
  r8169: add shutdown handler
  r8169: preliminary 8168d support
  r8169: support additional 8168cp chipset
  r8169: change default behavior for mildly identified 8168c chipsets
  r8169: add a new 8168cp flavor
  r8169: add a new 8168c flavor (bis)
  r8169: add a new 8168c flavor
  r8169: sync existing 8168 device hardware start sequences with vendor driver
  r8169: 8168b Tx performance tweak
  r8169: make room for more specific 8168 hardware start procedure
  r8169: shuffle some registers handling around (8168 operation only)
  r8169: new phy init parameters for the 8168b
  r8169: update phy init parameters
  r8169: wake up the PHY of the 8168
  af_key: fix SADB_X_SPDDELETE response
  ath9k: Fix return code when ath9k_hw_setpower() fails on reset
  ath9k: remove nasty FAIL macro from ath9k_hw_reset()
  gre: minor cleanups in netlink interface
  gre: fix copy and paste error
  ...

1 files changed, 28 insertions, 4 deletions

diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
index 6fcb3060dec5..b65f0799df48 100644
--- a/Documentation/rfkill.txt
+++ b/Documentation/rfkill.txt
@@ -341,6 +341,8 @@ key that does nothing by itself, as well as any hot key that is type-specific
 3.1 Guidelines for wireless device drivers
 ------------------------------------------
 
+(in this text, rfkill->foo means the foo field of struct rfkill).
+
 1. Each independent transmitter in a wireless device (usually there is only one
 transmitter per device) should have a SINGLE rfkill class attached to it.
 
@@ -363,10 +365,32 @@ This rule exists because users of the rfkill subsystem expect to get (and set,
 when possible) the overall transmitter rfkill state, not of a particular rfkill
 line.
 
-5. During suspend, the rfkill class will attempt to soft-block the radio
-through a call to rfkill->toggle_radio, and will try to restore its previous
-state during resume.  After a rfkill class is suspended, it will *not* call
-rfkill->toggle_radio until it is resumed.
+5. The wireless device driver MUST NOT leave the transmitter enabled during
+suspend and hibernation unless:
+
+	5.1. The transmitter has to be enabled for some sort of functionality
+	like wake-on-wireless-packet or autonomous packed forwarding in a mesh
+	network, and that functionality is enabled for this suspend/hibernation
+	cycle.
+
+AND
+
+	5.2. The device was not on a user-requested BLOCKED state before
+	the suspend (i.e. the driver must NOT unblock a device, not even
+	to support wake-on-wireless-packet or remain in the mesh).
+
+In other words, there is absolutely no allowed scenario where a driver can
+automatically take action to unblock a rfkill controller (obviously, this deals
+with scenarios where soft-blocking or both soft and hard blocking is happening.
+Scenarios where hardware rfkill lines are the only ones blocking the
+transmitter are outside of this rule, since the wireless device driver does not
+control its input hardware rfkill lines in the first place).
+
+6. During resume, rfkill will try to restore its previous state.
+
+7. After a rfkill class is suspended, it will *not* call rfkill->toggle_radio
+until it is resumed.
+
 
 Example of a WLAN wireless driver connected to the rfkill subsystem:
 --------------------------------------------------------------------