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
    about your driver list;
    do you have an idea of what the top 5 relevant ones would be?
    I'd be surprised if the top 5 together had less than 95% market share,
    so if we fix those we'd be mostly done already.

    > 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.

    if it's down userspace cannot currently expect this (if it does it's
    broken), just as it currently can't expect link notifications when the
    interface is down. It needs to have the interface up for this.
    (but point taken for a 3rd state)

    > In
    > that case, I'm pretty sure we need a third state rather than just "up"
    > or "down".

    so what do you want from this 3rd state? rough guess based on what I
    think the desktop wants (so please correct/append)

    In the third state you
    * don't expect to get or send "regular" packets
    * don't have a dhcp lease or anything like that
    * you do expect to get link change notification [1]
    * you do expect to be able to scan for access points [2]

    open questions
    * what if you get a WOL event?



    [1] What kind of latency would be allowed? Would an implementation be
    allowed to power up the phy say once per minute or once per 5 minutes to
    see if there is link? The implementation could do this progressively;
    first poll every X seconds, then after an hour, every minute etc.

    [2] would it be permissible to temporarily power up the device on scan?
    Eg how frequently does the desktop expect to poll for scanning, and what
    kind of latency would be tolerable?

    --
    if you want to mail me at work (you don't), use arjan (at) linux.intel.com
    Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

    -
    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 14:43    [W:3.647 / U:0.092 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site