lkml.org 
[lkml]   [2006]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Network drivers that don't suspend on interface down
    From
    Date
    On Wed, 2006-12-20 at 15:00 +0100, Jiri Benc wrote:
    > On Wed, 20 Dec 2006 12:53:14 +0000, Matthew Garrett wrote:
    > > The situation is more complicated for wireless. Userspace expects to be
    > > able to get scan results from the card even if the interface is down.
    >
    > User space should get an error when trying to get scan results from the
    > interface that is down. Some drivers are broken and don't do this but
    > when they're fixed there is no problem here.

    Entirely correct. If the card is DOWN, the radio should be off (both TX
    & RX) and it should be in max power save mode. If userspace expects to
    be able to get the card to do _anything_ when it's down, that's just
    110% wrong. You can't get link events for many wired cards when they
    are down, so I fail to see where userspace could expect to do anything
    with a wireless card when it's down too.

    > > In that case, I'm pretty sure we need a third state rather than just
    > > "up" or "down".
    >
    > We have that third state, it's IFF_DORMANT. Not supported yet by any
    > wireless driver/stack, unfortunately.

    So we have 3 states? What purpose does DORMANT serve and what is
    allowed in DORMANT?

    Also, how does rfkill fit into this? rfkill implies killing TX, but do
    we have the granularity to still receive while the transmit paths are
    powered down?

    Dan

    > Thanks,
    >
    > Jiri
    >

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-12-20 19:13    [W:4.823 / U:0.140 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site