Johannes Berg wrote:
> On Sat, 2009-04-18 at 09:17 +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.
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.
Thanks
Alan
--
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
