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:
signature.asc
Description: This is a digitally signed message part
