|
@@ -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
|
|
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
|
|
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.
|
|
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
|
|
when possible) the overall transmitter rfkill state, not of a particular rfkill
|
|
line.
|
|
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:
|
|
Example of a WLAN wireless driver connected to the rfkill subsystem:
|
|
--------------------------------------------------------------------
|
|
--------------------------------------------------------------------
|