Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history
yaml
---
r: 107084
b: refs/heads/master
c: 2fd9b22
h: refs/heads/master
v: v3
  • Loading branch information
Henrique de Moraes Holschuh authored and John W. Linville committed Jul 29, 2008
1 parent 2e85c53 commit 31f0ffb
Show file tree
Hide file tree
Showing 3 changed files with 23 additions and 6 deletions.
2 changes: 1 addition & 1 deletion [refs]
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: 734b5aa911dc65f4563048f069dfc631c9aa7de7
refs/heads/master: 2fd9b2212e25e6411b6f309707f4e2683d164250
20 changes: 16 additions & 4 deletions trunk/Documentation/rfkill.txt
Original file line number Diff line number Diff line change
Expand Up @@ -390,9 +390,10 @@ rfkill lines are inactive, it must return RFKILL_STATE_SOFT_BLOCKED if its soft
rfkill input line is active. Only if none of the rfkill input lines are
active, will it return RFKILL_STATE_UNBLOCKED.

If it doesn't implement the get_state() hook, it must make sure that its calls
to rfkill_force_state() are enough to keep the status always up-to-date, and it
must do a rfkill_force_state() on resume from sleep.
Since the device has a hardware rfkill line, it IS subject to state changes
external to rfkill. Therefore, the driver must make sure that it calls
rfkill_force_state() to keep the status always up-to-date, and it must do a
rfkill_force_state() on resume from sleep.

Every time the driver gets a notification from the card that one of its rfkill
lines changed state (polling might be needed on badly designed cards that don't
Expand Down Expand Up @@ -422,13 +423,24 @@ of the hardware is unknown), or read-write (where the hardware can be queried
about its current state).

The rfkill class will call the get_state hook of a device every time it needs
to know the *real* current state of the hardware. This can happen often.
to know the *real* current state of the hardware. This can happen often, but
it does not do any polling, so it is not enough on hardware that is subject
to state changes outside of the rfkill subsystem.

Therefore, calling rfkill_force_state() when a state change happens is
mandatory when the device has a hardware rfkill line, or when something else
like the firmware could cause its state to be changed without going through the
rfkill class.

Some hardware provides events when its status changes. In these cases, it is
best for the driver to not provide a get_state hook, and instead register the
rfkill class *already* with the correct status, and keep it updated using
rfkill_force_state() when it gets an event from the hardware.

rfkill_force_state() must be used on the device resume handlers to update the
rfkill status, should there be any chance of the device status changing during
the sleep.

There is no provision for a statically-allocated rfkill struct. You must
use rfkill_allocate() to allocate one.

Expand Down
7 changes: 6 additions & 1 deletion trunk/net/rfkill/rfkill.c
Original file line number Diff line number Diff line change
Expand Up @@ -252,7 +252,12 @@ EXPORT_SYMBOL_GPL(rfkill_epo);
* a notification by the firmware/hardware of the current *real*
* state of the radio rfkill switch.
*
* It may not be called from an atomic context.
* Devices which are subject to external changes on their rfkill
* state (such as those caused by a hardware rfkill line) MUST
* have their driver arrange to call rfkill_force_state() as soon
* as possible after such a change.
*
* This function may not be called from an atomic context.
*/
int rfkill_force_state(struct rfkill *rfkill, enum rfkill_state state)
{
Expand Down

0 comments on commit 31f0ffb

Please sign in to comment.