Re: rfkill rewrite bug

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

Johannes Berg wrote:
> On Sat, 2009-04-18 at 18:48 +0100, Alan Jenkins wrote:
>
>   
>> Ah, I think I see it now.
>>
>> Um, what's the use-case for calling set_sw_state() before registration? 
>> Is it actually needed?
>>     
>
> Probably not. I thought you would use it to update the core's idea of
> your state. But the core always forces you to its idea of the state :)
>
>   
>> 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?
>>     
>
> Not sure what you mean -- the sync is always done on register()?
>
> johannes
>   

Sorry, I misread the code again.  I thought rfkill_set_block() returned
early if the new state was equal to the old one, but it doesn't.