Johannes Berg wrote: > On Sat, 2009-04-18 at 16:49 +0100, Alan Jenkins wrote: > > >>> That's odd, I thought I added a set_sw_state() to rfkill which would >>> disable that rfkill. But there's rfkill_set_global_sw_state() which >>> should do what you want -- can you try replacing the EEE set_sw_state >>> call with that? >>> > No, that's done asynchronously in rfkill_sync_work(). But actually, heh, > that means set_sw_state can _not_ work before registering. > Ah, I think I see it now. Um, what's the use-case for calling set_sw_state() before registration? Is it actually needed? I think it was doing _something_. If the initial wireless state is soft-blocked, but rfkill.default_state = 1 (unblocked), then without the set_sw_state() call, the wireless would remain soft blocked. When the first sync_work calls rfkill_set_block(false), the "prev" value would also be false, so it would return without calling .set_block(). And you'd have an inconsistency, because "/sys/class/rfkill/rfkill0/state" would say "1" (unblocked). You'd have a similar problem the other way around, if the wireless was initially enabled, but the user specified rfkill.default_state = 0. So maybe you need a "first time, force sync" flag instead. That would also help if you had a write-only rfkill line, no? Regards Alan -- 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
