Hello there,
I've been testing this series of patch today for a new version of asus-laptop,
and this patch ("rfkill: do not allow userspace to override ALL RADIOS OFF")
introduces a bug in rfkill-input.
rfkill_epo() doesn't change the current_state of the tasks, and the various calls
to rfkill_schedule_set(..., RFKILL_STATE_ON) don't work if the last current_state
stored was already RFKILL_STATE_ON.
Anyway, the whole current_state thing seems completely useless and a source of
problems in rfkill-input, since state comparison is already done in rfkill, and
rfkill-input is more than likely to become out of sync with the real state.
Therefore I propose this additional patch to remove current_state completely from
rfkill-input.
- Fabien.
---
--- a/net/rfkill/rfkill-input.c 2008-06-22 21:16:15.000000000 +0200
+++ b/net/rfkill/rfkill-input.c 2008-06-22 21:20:01.000000000 +0200
@@ -30,27 +30,15 @@
spinlock_t lock; /* for accessing last and desired state */
unsigned long last; /* last schedule */
enum rfkill_state desired_state; /* on/off */
- enum rfkill_state current_state; /* on/off */
};
static void rfkill_task_handler(struct work_struct *work)
{
struct rfkill_task *task = container_of(work, struct rfkill_task, work);
- enum rfkill_state state;
mutex_lock(&task->mutex);
- /*
- * Use temp variable to fetch desired state to keep it
- * consistent even if rfkill_schedule_toggle() runs in
- * another thread or interrupts us.
- */
- state = task->desired_state;
-
- if (state != task->current_state) {
- rfkill_switch_all(task->type, state);
- task->current_state = state;
- }
+ rfkill_switch_all(task->type, task->desired_state);
mutex_unlock(&task->mutex);
}
@@ -94,7 +82,6 @@
.mutex = __MUTEX_INITIALIZER(n.mutex), \
.lock = __SPIN_LOCK_UNLOCKED(n.lock), \
.desired_state = RFKILL_STATE_ON, \
- .current_state = RFKILL_STATE_ON, \
}
static DEFINE_RFKILL_TASK(rfkill_wlan, RFKILL_TYPE_WLAN);
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
