An error occurred fetching the project authors.
  1. 21 Nov, 2008 1 commit
    • Ivo van Doorn's avatar
      rt2x00: Cleanup TX/RX entry handling · 798b7adb
      Ivo van Doorn authored
      Merge the callback functions init_txentry() and
      init_rxentry(). This makes life in rt2x00lib a
      lot simpler and we can cleanup several functions.
      
      rt2x00pci contained "fake" FIELD definitions for
      descriptor words. This is not flexible since it
      assumes the driver will always have the same field
      to indicate if a driver is available or not.
      This should be dependent on the driver, and we
      should add a callback function for this.
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      798b7adb
  2. 31 Oct, 2008 2 commits
  3. 15 Oct, 2008 1 commit
  4. 06 Oct, 2008 1 commit
  5. 15 Sep, 2008 1 commit
    • Johannes Berg's avatar
      mac80211: fix virtual interfaces vs. injection · 25d834e1
      Johannes Berg authored
      Currently, virtual interface pointers passed to drivers might be
      from monitor interfaces and as such completely uninitialised
      because we do not tell the driver about monitor interfaces when
      those are created. Instead of passing them, we should therefore
      indicate to the driver that there is no information; do that by
      passing a NULL value and adjust drivers to cope with it.
      
      As a result, some mac80211 API functions also need to cope with
      a NULL vif pointer so drivers can still call them unconditionally.
      
      Also, when injecting frames we really don't want to pass NULL all
      the time, if we know we are the source address of a frame and have
      a local interface for that address, we can to use that interface.
      This also helps with processing the frame correctly for that
      interface which will help the 802.11w implementation. It's not
      entirely correct for VLANs or WDS interfaces because there the MAC
      address isn't unique, but it's already a lot better than what we
      do now.
      
      Finally, when injecting without a matching local interface, don't
      assign sequence numbers at all.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      25d834e1
  6. 29 Aug, 2008 3 commits
  7. 22 Aug, 2008 1 commit
    • Ivo van Doorn's avatar
      rt2x00: Implement HW encryption · 2bb057d0
      Ivo van Doorn authored
      Various rt2x00 devices support hardware encryption.
      
      Most of them require the IV/EIV to be generated by mac80211,
      but require it to be provided seperately instead of within
      the frame itself. This means that rt2x00lib should extract
      the data from the frame and place it in the frame descriptor.
      During RX the IV/EIV is provided in the descriptor by the
      hardware which means that it should be inserted into the
      frame by rt2x00lib.
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2bb057d0
  8. 01 Aug, 2008 1 commit
  9. 29 Jul, 2008 2 commits
    • Ivo van Doorn's avatar
      rt2x00: Clear queue entry flags during initialization · 9c0ab712
      Ivo van Doorn authored
      When the queues are being initialized the entry flags fields must be
      reset to 0. When this does not happen some entries might still be
      marked as "occupied" after an ifdown & ifup cycle which would trigger
      errors when the entry is being accessed:
      
      	phy0 -> rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 0.
      	Please file bug report to http://rt2x00.serialmonkey.com.
      
      This also fixes the mac80211 warning:
      
      	------------[ cut here ]------------
      	WARNING: at net/mac80211/tx.c:1238 ieee80211_master_start_xmit+0x30a/0x350 [mac80211]()
      
      which was triggered by the queue error.
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      9c0ab712
    • Ivo van Doorn's avatar
      rt2x00: Fix QOS sequence counting · 5adf6d63
      Ivo van Doorn authored
      When IEEE80211_TX_CTL_ASSIGN_SEQ is not set,
      the driver should disable hardware sequence counting
      to make sure the mac80211 provided counter is used.
      This fixes QOS sequence counting, since that is one
      of the cases where mac80211 provides a seperate
      sequence counter.
      
      By moving the sequence counting code to rt2x00queue
      we make sure that _all_ frames get the sequence counter,
      including RTS/CTS and Beacon frames.
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5adf6d63
  10. 14 Jul, 2008 2 commits
    • Ivo van Doorn's avatar
      rt2x00: Reorganize beacon handling · bd88a781
      Ivo van Doorn authored
      With the new beacon handling from mac80211 we can
      reorganize the beacon handling in rt2x00 as well.
      This patch will move the function to the TX handlers,
      and move all duplicate code into rt2x00queue.c.
      
      After this change the descriptor helper functions
      from rt2x00queue.c no longer need to be exported
      outside of rt2x00lib and can be declared static.
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      bd88a781
    • Ivo van Doorn's avatar
      rt2x00: Fix NULL pointer error in adhoc/master mode · 9a613195
      Ivo van Doorn authored
      As soon as an interface is enabled, and that interface is in adhoc or master mode,
      the device will start raising beacondone interrupts. But before the first interrupt is
      raised, mac80211 will probably not have send any beacons to the device yet, which
      results in a NULL pointer error when the skb is being freed.
      
      Note that the "raise beacondone interrupts without a beacon" is also a bug,
      and will be addressed later. The more important bug however is preventing
      the NULL pointer failt itself, since there might be other conditions that could trigger
      it as well.
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      9a613195
  11. 08 Jul, 2008 1 commit
  12. 27 Jun, 2008 1 commit
    • Ivo van Doorn's avatar
      rt2x00: Remove duplicate deinitialization · 61243d8e
      Ivo van Doorn authored
      When rt2x00queue_alloc_rxskbs() fails rt2x00queue_unitialize()
      will be called which will free all rxskb. So we don't need
      to do this in the rt2x00queue_alloc_rxskb() function as well.
      
      rt2x00queue_free_skb() unmaps the DMA but doesn't clear the
      allocation flag. Since the code is copied from rt2x00queue_unmap_skb()
      anyway (and that function does clear the flag) we might as well
      use that function directly.
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      61243d8e
  13. 26 Jun, 2008 4 commits
  14. 14 Jun, 2008 5 commits
  15. 22 May, 2008 4 commits
  16. 07 May, 2008 1 commit
  17. 13 Mar, 2008 1 commit
    • Ivo van Doorn's avatar
      rt2x00: Upgrade queue->lock to use irqsave · 5f46c4d0
      Ivo van Doorn authored
      The queue->lock could be grabbed from interrupt context,
      which could lead to lockdep panic like this:
      
      kernel: ======================================================
      kernel: [ INFO: soft-safe -> soft-unsafe lock order detected ]
      kernel: 2.6.25-0.95.rc4.fc9 #1
      kernel: ------------------------------------------------------
      kernel: rt2500pci/1251 [HC0[0]:SC0[1]:HE1:SE0] is trying to acquire:
      kernel:  (&queue->lock){--..}, at: [<ffffffff88213339>] rt2x00queue_get_entry+0x5a/0x81 [rt2x00lib]
      kernel:
      kernel: and this task is already holding:
      kernel:  (_xmit_IEEE80211){-...}, at: [<ffffffff8122e9a3>] __qdisc_run+0x84/0x1a9
      kernel: which would create a new lock dependency:
      kernel:  (_xmit_IEEE80211){-...} -> (&queue->lock){--..}
      kernel:
      kernel: but this new dependency connects a soft-irq-safe lock:
      kernel:  (_xmit_ETHER){-+..}
      kernel: ... which became soft-irq-safe at:
      kernel:   [<ffffffffffffffff>] 0xffffffffffffffff
      kernel:
      kernel: to a soft-irq-unsafe lock:
      kernel:  (&queue->lock){--..}
      kernel: ... which became soft-irq-unsafe at:
      kernel: ...  [<ffffffff810545a2>] __lock_acquire+0x62d/0xd63
      kernel:   [<ffffffff81054d36>] lock_acquire+0x5e/0x78
      kernel:   [<ffffffff812a1497>] _spin_lock+0x26/0x53
      kernel:   [<ffffffff88212f98>] rt2x00queue_reset+0x16/0x40 [rt2x00lib]
      kernel:   [<ffffffff88212fd4>] rt2x00queue_alloc_entries+0x12/0xab [rt2x00lib]
      kernel:   [<ffffffff88213091>] rt2x00queue_initialize+0x24/0xf2 [rt2x00lib]
      kernel:   [<ffffffff88212036>] rt2x00lib_start+0x3b/0xd4 [rt2x00lib]
      kernel:   [<ffffffff88212609>] rt2x00mac_start+0x18/0x1a [rt2x00lib]
      kernel:   [<ffffffff881b9a4b>] ieee80211_open+0x1f3/0x46d [mac80211]
      kernel:   [<ffffffff8121d980>] dev_open+0x4d/0x8b
      kernel:   [<ffffffff8121d41e>] dev_change_flags+0xaf/0x172
      kernel:   [<ffffffff81224fc2>] do_setlink+0x276/0x338
      kernel:   [<ffffffff81225198>] rtnl_setlink+0x114/0x116
      kernel:   [<ffffffff812262fc>] rtnetlink_rcv_msg+0x1d8/0x1f9
      kernel:   [<ffffffff8123649a>] netlink_rcv_skb+0x3e/0xac
      kernel:   [<ffffffff8122611a>] rtnetlink_rcv+0x29/0x33
      kernel:   [<ffffffff81235eed>] netlink_unicast+0x1fe/0x26b
      kernel:   [<ffffffff81236224>] netlink_sendmsg+0x2ca/0x2dd
      kernel:   [<ffffffff812103b3>] sock_sendmsg+0xfd/0x120
      kernel:   [<ffffffff812105a8>] sys_sendmsg+0x1d2/0x23c
      kernel:   [<ffffffff8100c1c7>] tracesys+0xdc/0xe1
      kernel:   [<ffffffffffffffff>] 0xffffffffffffffff
      
      This can be fixed by using the irqsave/irqrestore versions
      during the queue->lock handling.
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5f46c4d0
  18. 29 Feb, 2008 5 commits