[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
    On Thu, 2006-12-21 at 01:15 +0000, Matthew Garrett wrote:
    > On Wed, Dec 20, 2006 at 01:12:51PM -0500, Dan Williams wrote:
    > > 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.
    > Because it works on the common hardware? If there's documentation about
    > what userspace can legitimately expect, then I'm happy to defer to that.
    > But in the absence of any indication as to what functionality users can
    > depend on, deciding that existing functionality is a bug is, well,
    > impolite.
    > > 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?
    > Is rfkill not just primarily an interface for us getting events when the
    > radio changes state? Every time I read up on it I get a little more
    > confused - some time I really need to make sense of it...

    That's OK, it's really complicated. There are 3 cases of rfkill
    switches AFAICT:

    a) tied to the wireless hardware, switch kills hardware directly
    b) tied to wireless hardware, but driver handles the kill request
    c) just another key, a separate key driver handles the event and asks
    the wireless driver to kill the card

    It's also complicated because some switches are supposed to rfkill both
    an 802.11 module _and_ a bluetooth module at the same time, or I guess
    some laptops may even have one rfkill switch for each wireless device.
    Furthermore, some people want to 'softkill' the hardware via software
    without pushing the key, which is a subset of (b) or (c) above.

    It sucks. But we _need_ a unified interface to handle it.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-12-21 04:07    [W:0.031 / U:113.624 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site