Re: rfkill rewrite bug

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]