12 Mar, 2011

1 commit


26 Feb, 2011

2 commits

  • For devices supported by iwlwifi sometimes
    off-channel transmissions need to be handled
    by the device completely. To support this
    mac80211 needs to pass the frame directly
    to the driver and not through the TX path
    as the driver needs the frame and channel
    information at the same time.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     
  • The return value of the tx operation is commonly
    misused by drivers, leading to errors. All drivers
    will drop frames if they fail to TX the frame, and
    they must also properly manage the queues (if they
    didn't, mac80211 would already warn).

    Removing the ability for drivers to return a BUSY
    value also allows significant cleanups of the TX
    TX handling code in mac80211.

    Note that this also fixes a bug in ath9k_htc, the
    old "return -1" there was wrong.

    Signed-off-by: Johannes Berg
    Tested-by: Sedat Dilek [ath5k]
    Acked-by: Gertjan van Wingerde [rt2x00]
    Acked-by: Larry Finger [b43, rtl8187, rtlwifi]
    Acked-by: Luciano Coelho [wl12xx]
    Signed-off-by: John W. Linville

    Johannes Berg
     

20 Jan, 2011

1 commit

  • The aggregation code currently doesn't implement the
    buffer size negotiation. It will always request a max
    buffer size (which is fine, if a little pointless, as
    the mac80211 code doesn't know and might just use 0
    instead), but if the peer requests a smaller size it
    isn't possible to honour this request.

    In order to fix this, look at the buffer size in the
    addBA response frame, keep track of it and pass it to
    the driver in the ampdu_action callback when called
    with the IEEE80211_AMPDU_TX_OPERATIONAL action. That
    way the driver can limit the number of subframes in
    aggregates appropriately.

    Note that this doesn't fix any drivers apart from the
    addition of the new argument -- they all need to be
    updated separately to use this variable!

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

06 Jan, 2011

1 commit


14 Dec, 2010

1 commit

  • The 802.11 spec states that the STA that generated the last Beacon frame shall
    be the STA that response to a probe request. This is important for congestion
    reduction when a probe request is received - only 1 node in an adhoc BSS
    will transmit a response. While mac80211 drivers should provide the
    tx_last_beacon function to report if they transmitted the last beacon many
    do not. As an attempt to reduce probe response congestion default this
    to 0 such that a node not implementing this capability does not contribute
    to unnecessary congestion.

    In a modern medium sized office environment I see upwards of 100 probe
    requests per second received at a given node from various hardware/OS/drivers
    doing zeroconf 'active probing' as opposed to passively listening for beacons.
    With a modest 10-node adhoc network consisting of drivers that do not implement
    this tx_last_beacon feature, I have seen this result in the simultaneous xmit
    of probe responses accumulating to 500 probe responses per second because of
    collisions which brings the adhoc network to its knees as well as causes
    needless congestion.

    Signed-off-by: John W. Linville

    Tim Harvey
     

17 Nov, 2010

2 commits

  • Allow antenna configuration by calling driver's function for it.

    We disallow antenna configuration if the wiphy is already running, mainly to
    make life easier for 802.11n drivers which need to recalculate HT capabilites.

    Signed-off-by: Bruno Randolf
    Signed-off-by: John W. Linville

    Bruno Randolf
     
  • The lower driver is notified when the fragmentation threshold changes
    and upon a reconfig of the interface.

    If the driver supports hardware TX fragmentation, don't fragment
    packets in the stack.

    Signed-off-by: Arik Nemtsov
    Signed-off-by: John W. Linville

    Arik Nemtsov
     

17 Sep, 2010

1 commit

  • When a driver advertises p2p device support,
    mac80211 will handle it, but internally it will
    rewrite the interface type to STA/AP rather than
    P2P-STA/GO since otherwise a lot of paths need
    to be touched that are otherwise identical. A
    p2p boolean tells drivers whether or not a given
    interface will be used for p2p or not.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

28 Aug, 2010

1 commit

  • Add support to mac80211 for changing the interface
    type even when the interface is UP, if the driver
    supports it.

    To achieve this
    * add a new driver callback for switching,
    * split some of the interface up/down code out
    into new functions (do_open/do_stop), and
    * maintain an own __SDATA_RUNNING bit that will
    not be set during interface type, so that any
    other code doesn't use the interface.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

30 Jun, 2010

1 commit


15 Jun, 2010

5 commits

  • There is a circular locking dependency when configuring the
    hardware ARP filters on association, occurring when flushing the mac80211
    workqueue. This is what happens:

    [ 92.026800] =======================================================
    [ 92.030507] [ INFO: possible circular locking dependency detected ]
    [ 92.030507] 2.6.34-04781-g2b2c009 #85
    [ 92.030507] -------------------------------------------------------
    [ 92.030507] modprobe/5225 is trying to acquire lock:
    [ 92.030507] ((wiphy_name(local->hw.wiphy))){+.+.+.}, at: [] flush_workq
    ueue+0x0/0xb0
    [ 92.030507]
    [ 92.030507] but task is already holding lock:
    [ 92.030507] (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x12/0x20
    [ 92.030507]
    [ 92.030507] which lock already depends on the new lock.
    [ 92.030507]
    [ 92.030507]
    [ 92.030507] the existing dependency chain (in reverse order) is:
    [ 92.030507]
    [ 92.030507] -> #2 (rtnl_mutex){+.+.+.}:
    [ 92.030507] [] lock_acquire+0xdb/0x110
    [ 92.030507] [] mutex_lock_nested+0x44/0x300
    [ 92.030507] [] rtnl_lock+0x12/0x20
    [ 92.030507] [] ieee80211_assoc_done+0x6c/0xe0 [mac80211]
    [ 92.030507] [] ieee80211_work_work+0x31d/0x1280 [mac80211]

    [ 92.030507] -> #1 ((&local->work_work)){+.+.+.}:
    [ 92.030507] [] lock_acquire+0xdb/0x110
    [ 92.030507] [] worker_thread+0x22a/0x370
    [ 92.030507] [] kthread+0x96/0xb0
    [ 92.030507] [] kernel_thread_helper+0x4/0x10
    [ 92.030507]
    [ 92.030507] -> #0 ((wiphy_name(local->hw.wiphy))){+.+.+.}:
    [ 92.030507] [] __lock_acquire+0x1c0c/0x1d50
    [ 92.030507] [] lock_acquire+0xdb/0x110
    [ 92.030507] [] flush_workqueue+0x4e/0xb0
    [ 92.030507] [] ieee80211_stop_device+0x2b/0xb0 [mac80211]
    [ 92.030507] [] ieee80211_stop+0x3e5/0x680 [mac80211]

    The locking in this case is quite complex. Fix the problem by rewriting the
    way the hardware ARP filter list is handled - i.e. make a copy of the address
    list to the bss_conf struct, and provide that list to the hardware driver
    when needed.

    The current patch will enable filtering also in promiscuous mode. This may need
    to be changed in the future.

    Reported-by: Reinette Chatre
    Signed-off-by: Juuso Oikarinen
    Signed-off-by: John W. Linville

    Juuso Oikarinen
     
  • Currently, driver tracing is sometimes invoked
    after and sometimes before the actual driver
    callback. This is fine as long as the driver
    has no tracing itself, but as soon as it does
    it gets confusing.

    To make traces containing such information
    easier to read, introduce a return tracer in
    mac80211 that essentially brackets any driver
    tracing, and invoke the real trace before the
    driver's callback, only showing the return
    value, if any, afterwards.

    Since tracing records the process, there's no
    problem with overlapping calls if that should
    happen.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     
  • Allow drivers to sleep, and indicate this in
    the documentation. ath9k has some locking I
    don't understand, so keep it safe and disable
    BHs in it, all other drivers look fine with
    the context change.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     
  • To prepare for allowing drivers to sleep in
    ampdu_action, change the locking in the TX
    aggregation code to use the mutex the RX part
    already uses. The spinlock is still necessary
    around some code to avoid races with TX, but
    now we can also synchronize_net() to avoid
    getting an inconsistent sequence number.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     
  • To prepare for allowing drivers to sleep in
    ampdu_action, change the locking in the RX
    aggregation code to use a mutex, so that it
    would already allow drivers to sleep. But
    explicitly disable BHs around the callback
    for now since the TX part cannot yet sleep,
    and drivers' locking might require it.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

08 Jun, 2010

2 commits


05 Jun, 2010

1 commit


04 Jun, 2010

1 commit

  • Some hardware allow extended filtering of ARP frames not intended for
    the host. To perform such filtering, the hardware needs to know the current
    IP address(es) of the host, bound to its interface.

    Add support for ARP filtering to mac80211 by adding a new op to the driver
    interface, allowing to configure the current IP addresses. This op is called
    upon association with the currently configured address(es), and when
    associated whenever the IP address(es) change.

    This patch adds configuration of IPv4 addresses only, as IPv6 addresses don't
    need ARP filtering.

    Signed-off-by: Juuso Oikarinen
    Reviewed-by: Johannes Berg
    Signed-off-by: John W. Linville

    Juuso Oikarinen
     

18 May, 2010

1 commit


13 May, 2010

1 commit

  • This adds support for offloading the channel switch
    operation to devices that support such, typically
    by having specific firmware API for it. The reasons
    for this could be that the firmware provides better
    timing or that regulatory enforcement done by the
    device requires special handling of CSAs.

    In order to allow drivers to specify the timing to
    the device, the new channel_switch callback will
    pass through the received frame's mactime, where
    available.

    Signed-off-by: Wey-Yi Guy
    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

06 May, 2010

1 commit


28 Apr, 2010

1 commit

  • When scanning, it is somewhat important to scan
    on the correct virtual interface. All drivers
    that currently implement hw_scan only support a
    single virtual interface, but that may change
    and then we'd want to be ready.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

24 Apr, 2010

1 commit


20 Apr, 2010

1 commit


04 Apr, 2010

1 commit

  • Converts the list and the core manipulating with it to be the same as uc_list.

    +uses two functions for adding/removing mc address (normal and "global"
    variant) instead of a function parameter.
    +removes dev_mcast.c completely.
    +exposes netdev_hw_addr_list_* macros along with __hw_addr_* functions for
    manipulation with lists on a sandbox (used in bonding and 80211 drivers)

    Signed-off-by: Jiri Pirko
    Signed-off-by: David S. Miller

    Jiri Pirko
     

09 Feb, 2010

2 commits

  • get_tx_stats() driver operation is not currently used anywhere in mac80211
    and there are no plans to use it in the not-so-near future. So it can go
    without anyone missing it.

    Signed-off-by: Kalle Valo
    Acked-by: Johannes Berg
    Signed-off-by: John W. Linville

    Kalle Valo
     
  • Many drivers would like to sleep during station
    addition and removal, and currently have a high
    complexity there from not being able to.

    This introduces two new callbacks sta_add() and
    sta_remove() that drivers can implement instead
    of using sta_notify() and that can sleep, and
    the new sta_add() callback is also allowed to
    fail.

    The reason we didn't do this previously is that
    the IBSS code wants to insert stations from the
    RX path, which is a tasklet, so cannot sleep.
    This patch will keep the station allocation in
    that path, but moves adding the station to the
    driver out of line. Since the addition can now
    fail, we can have IBSS peer structs the driver
    rejected -- in that case we still talk to the
    station but never tell the driver about it in
    the control.sta pointer. If there will ever be
    a driver that has a low limit on the number of
    stations and that cannot talk to any stations
    that are not known to it, we need to do come up
    with a new strategy of handling larger IBSSs,
    maybe quicker expiry or rejecting peers.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

26 Jan, 2010

1 commit


23 Jan, 2010

1 commit


13 Jan, 2010

1 commit


29 Dec, 2009

3 commits

  • To make it easier to notice cases of calling sleeping ops in atomic context,
    annotate driver-ops.h with appropiate might_sleep() calls. At the same time,
    also document in mac80211.h the op functions with missing contexts.

    mac80211 doesn't seem to use get_tx_stats anywhere currently. Just to be on
    the safe side, I documented it to be atomic, but hopefully the op can be
    removed in the future.

    Compile-tested only.

    Signed-off-by: Kalle Valo
    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Kalle Valo
     
  • All its members (vif, mac_addr, type) are now available
    in the vif struct directly, so we can pass that instead
    of the conf struct. I generated this patch (except the
    mac80211 and header file changes) with this semantic
    patch:

    @@
    identifier conf, fn, hw;
    type tp;
    @@
    tp fn(struct ieee80211_hw *hw,
    -struct ieee80211_if_init_conf *conf)
    +struct ieee80211_vif *vif)
    {
    type
    +vif->type
    |
    -conf->mac_addr
    +vif->addr
    |
    -conf->vif
    +vif
    )
    ...>
    }

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     
  • We've long lacked a good confirmation that frames
    have really gone out, e.g. before going off-channel
    for a scan. Add a flush() operation that drivers
    can implement to provide that confirmation, and use
    it in a few places:
    * before scanning sends the nullfunc frames
    * after scanning sends the nullfunc frames, if any
    * when going idle, to send any pending frames

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

22 Dec, 2009

2 commits

  • It's not all that useful to have the vif/sdata pointer,
    we'd rather refer to the interfaces by their name.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     
  • For bluetooth 3, we will most likely not have
    a netdev for a virtual interface (sdata), so
    prepare for that by reducing the reliance on
    having a netdev. This patch moves the name
    and address fields into the sdata struct and
    uses them from there all over. Some work is
    needed to keep them sync'ed, but that's not
    a lot of work and in slow paths anyway.

    In doing so, this also reduces the number of
    pointer dereferences in many places, because
    of things like sdata->dev->dev_addr becoming
    sdata->vif.addr.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

19 Nov, 2009

1 commit

  • The entire aggregation code currently operates on the
    hw pointer and station addresses, but that needs to
    change to make stations purely per-vif; As one step
    preparing for that make the aggregation code callable
    with the station, or by the combination of virtual
    interface and station address.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

29 Aug, 2009

1 commit

  • Due to the way the tasklets work in mac80211 there's
    no need to ever disable them.

    However, we need to clear the pending packets when
    taking down the last interface because otherwise
    the tx_pending_tasklet might be queued if the
    driver mucks with the queues (which it shouldn't).

    I've had a situation occasionally with ar9170 in
    which ksoftirq was using 100% CPU time because
    a disabled tasklet was scheduled, and I think that
    was due to ar9170 receiving a packet while the
    tasklet was disabled. That's strange and it really
    should not do that for other reasons, but there's
    no need to waste that much CPU time over it, it
    should just warn instead.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

20 Aug, 2009

1 commit

  • Over time, a whole bunch of drivers have come up
    with their own scheme to delay the configure_filter
    operation to a workqueue. To be able to simplify
    things, allow configure_filter to sleep, and add
    a new prepare_multicast callback that drivers that
    need the multicast address list implement. This new
    callback must be atomic, but most drivers either
    don't care or just calculate a hash which can be
    done atomically and then uploaded to the hardware
    non-atomically.

    A cursory look suggests that at76c50x-usb, ar9170,
    mwl8k (which is actually very broken now), rt2x00,
    wl1251, wl1271 and zd1211 should make use of this
    new capability.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg