Re: rfkill rewrite bug

[Alan Jenkins <alan-jenkins@tuffmail.co.uk>]

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