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. -- 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
