On 5/30/09, Johannes Berg [off-list ref] wrote:

On Sat, 2009-05-30 at 00:33 +0200, Tobias Doerffel wrote:

quoted

quoted

Could you try to work against v11
of my rfkill patch, or better even against the cfg80211 rfkill instead?

I didn't look at both of them yet. However I think we first should try to
get
current rfkill support into mainline as fast as possible. Improvements and

adaptations to reworked rfkill framework can follow.

No other comments from me -- but since the v11 of the rfkill rewrite
will certainly hit the tree before your patch (it's almost in) you
_will_ have to work against it. I'll also try to make the cfg80211
rfkill hit the tree very soon for reasons I'll explain elsewhere -- you
would be better off working against that because then your rfkill code
is very very very simple and doesn't need to do much at all.

johannes

Btw, I believe the new rfkill core behaviour should avoid the concern
I raised about the EeePC.

Reminder: the eeepc-laptop implements platform rfkill on the original
model(s) by hotplugging the entire ath5k device.  If you boot with it
in the blocked state, the old rfkill core would "lock in" that state
as the default.  If you then hotplug the ath5k device _and it comes up
with an rfkill device of it's own_, my concern is that the new rfkill
device would be initialized to a blocked state.  It would be
impossible to enable the wireless.

The new core removes this idea of a separate "default" state, so it
can't have this problem.

Regards
Alan