On 5/30/09, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Sat, 2009-05-30 at 00:33 +0200, Tobias Doerffel wrote: > >> > 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 -- 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
