Re: [RFC] rfkill: remove set_global_sw_state()

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

Johannes Berg wrote:
> On Mon, 2009-06-08 at 12:10 +0100, Alan Jenkins wrote:
>
>   
>>>> -		rfkill_set_sw_state(wwan_rfkill, hp_wmi_wwan_state());
>>>>  		err = rfkill_register(wwan_rfkill);
>>>>  		if (err)
>>>>  			goto register_wwan_err;
>>>>     
>>>>         
>>> Hmm. Anyone know anything about HP? That kinda looks persistent too.
>>>   
>>>       
>> Quite possibly.  I just don't know, and it's never been treated that way
>> before.  The old core, when I first read it, you were supposed to report
>> the initial state so that it knew whether it differed from the default
>> state.  So the core could "optimise away" the initialization if the
>> current state was the same.  Then rfkill_set_default() was added, but it
>> was only used in tp-acpi and then eeepc-laptop.
>>     
>
> Oh, good point. Then maybe that was just to avoid the core
> initialisation that I just always did for ease of use.
>
>   
>> The counter is the sony-laptop case.  That driver also hits ACPI to
>> query it's current state.  But apparently it doesn't always power up in
>> a useful state, because there's a specific git commit which forces the
>> radios to unblock at load time.
>>
>>
>> I think this patch should preserve the existing behaviour.  But the
>> rfkill rewrite as a whole is a good opportunity to re-check this issue. 
>> There's only a few maintainers to contact so I don't mind doing it -
>> unless you were going to check with them about the rewrite anyway?
>>     
>
> I wasn't planning on doing anything more than before -- where I had
> copied hopefully all maintainers on the rewrite patch.
>
>
>   
>>> Ah, this is the quirky backward compat code you're talking about. I
>>> guess we need it, although I don't particularly like it.
>>>   
>>>       
>> I don't like it either.  The patch as a whole only makes sense because
>> rfkill-input is going away, so the global states will become less
>> important.  When you use rfkill-input, you really want the individual
>> states to match the global ones, otherwise your user experience
>> suffers.  When you don't use rfkill-input, the "global" states will just
>> be load-time defaults (once suspend is fixed).
>>     
>
> Yeah. Want to fix suspend too? I would now, but I really need to get
> lunch first :)
>   

Sure, will do!