[lkml]   [2009]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ath5k-devel] [PATCH] ath5k: added initial RFKILL support
    On 5/30/09, Johannes Berg <> 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.


     \ /
      Last update: 2009-05-30 17:29    [W:0.024 / U:0.780 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site