diff options
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/rfkill.txt | 32 |
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 | |||
341 | 3.1 Guidelines for wireless device drivers | 341 | 3.1 Guidelines for wireless device drivers |
342 | ------------------------------------------ | 342 | ------------------------------------------ |
343 | 343 | ||
344 | (in this text, rfkill->foo means the foo field of struct rfkill). | ||
345 | |||
344 | 1. Each independent transmitter in a wireless device (usually there is only one | 346 | 1. Each independent transmitter in a wireless device (usually there is only one |
345 | transmitter per device) should have a SINGLE rfkill class attached to it. | 347 | transmitter per device) should have a SINGLE rfkill class attached to it. |
346 | 348 | ||
@@ -363,10 +365,32 @@ This rule exists because users of the rfkill subsystem expect to get (and set, | |||
363 | when possible) the overall transmitter rfkill state, not of a particular rfkill | 365 | when possible) the overall transmitter rfkill state, not of a particular rfkill |
364 | line. | 366 | line. |
365 | 367 | ||
366 | 5. During suspend, the rfkill class will attempt to soft-block the radio | 368 | 5. The wireless device driver MUST NOT leave the transmitter enabled during |
367 | through a call to rfkill->toggle_radio, and will try to restore its previous | 369 | suspend and hibernation unless: |
368 | state during resume. After a rfkill class is suspended, it will *not* call | 370 | |
369 | rfkill->toggle_radio until it is resumed. | 371 | 5.1. The transmitter has to be enabled for some sort of functionality |
372 | like wake-on-wireless-packet or autonomous packed forwarding in a mesh | ||
373 | network, and that functionality is enabled for this suspend/hibernation | ||
374 | cycle. | ||
375 | |||
376 | AND | ||
377 | |||
378 | 5.2. The device was not on a user-requested BLOCKED state before | ||
379 | the suspend (i.e. the driver must NOT unblock a device, not even | ||
380 | to support wake-on-wireless-packet or remain in the mesh). | ||
381 | |||
382 | In other words, there is absolutely no allowed scenario where a driver can | ||
383 | automatically take action to unblock a rfkill controller (obviously, this deals | ||
384 | with scenarios where soft-blocking or both soft and hard blocking is happening. | ||
385 | Scenarios where hardware rfkill lines are the only ones blocking the | ||
386 | transmitter are outside of this rule, since the wireless device driver does not | ||
387 | control its input hardware rfkill lines in the first place). | ||
388 | |||
389 | 6. During resume, rfkill will try to restore its previous state. | ||
390 | |||
391 | 7. After a rfkill class is suspended, it will *not* call rfkill->toggle_radio | ||
392 | until it is resumed. | ||
393 | |||
370 | 394 | ||
371 | Example of a WLAN wireless driver connected to the rfkill subsystem: | 395 | Example of a WLAN wireless driver connected to the rfkill subsystem: |
372 | -------------------------------------------------------------------- | 396 | -------------------------------------------------------------------- |