Re: rfkill rewrite bug

[Johannes Berg <johannes@sipsolutions.net>]

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

On Sat, 2009-04-18 at 10:43 +0100, Alan Jenkins wrote:

> >> When I looked at the code earlier, I saw no obvious replacement for 
> >> rfkill_set_default().  So I tried disabling the wireless and rebooting 
> >> to see what happened.  It didn't like that :-).
> >>     
> >
> > Ok that wasn't too hard -- try this on top if you get a chance:
> >   
> 
> Great, that fixes the crash.
> 
> 
> 1) I think we need to add a resume method to eeepc-laptop.
> 
> Without this, funny things happen when I hibernate, disable wireless in
> the BIOS, and resume:
> 
>     ath5k phy0: failed to wake up the MAC chip
> 
> It's an really stupid thing to do, but it can happen.  It's bad from a
> UI point of view.  E.g. in network-manager, you can see a "wlan0"
> device, but it doesn't work.
> 
> The EEE rfkill is unusual in that it hotplugs the PCI device, making
> eeepc-laptop something like a custom pci hotplug driver.  With your
> rewrite, eeepc-laptop doesn't notice the state change on resume. 
> Previously, the rfkill-core would restore the pre-hibernation state,
> which would sort everything out.  I don't think anything else does this,
> so we can just add a resume method to eeepc-laptop.  The resume method
> would re-check the state and do the PCI hotplug dance if necessary.
> 
> If you agree, I can do the patch for this and send it to you.

Sounds good to me, yeah.

I could make the rfkill core do that at resume, but I'm not really sure
it's what we want -- there are too many cases imho:
 * hard rfkill might have changed
 * soft rfkill might still be ok in hw
 * soft rfkill might need reconfiguring
etc. I think generally it's saner to let the driver sort it out -- it
can always ask for the current state by using set_hw_state() or so.

> 2) Do you have any thoughts about an rfkill_set_default() equivalent? 
> AFAICS your current patch simply removes it.
> 
> This means that when I boot linux, it doesn't respect the previous
> rfkill state.  I can no longer disable the wireless in the BIOS setup
> screen, and the rfkill state won't be preserved over reboots.
> 
> I don't have a strong feeling about reboots _on their own_.  But I would
> be annoyed if the option in the BIOS setup screen stopped working in a
> future version of linux.  Admittedly it's only a matter of principle /
> nostalgia - since the eeepc-laptop was fixed to implement rfkill
> properly, I've never used the BIOS option in anger.

That's odd, I thought I added a set_sw_state() to rfkill which would
disable that rfkill. But there's rfkill_set_global_sw_state() which
should do what you want -- can you try replacing the EEE set_sw_state
call with that?

johannes

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