1. 18 5月, 2013 8 次提交
    • F
      ath9k: fix aggregation stop/flush handling · 16e23428
      Felix Fietkau 提交于
      When aggregation stop is requested, don't run the mac80211 aggregation
      stop callback yet, while the session is still blocked.
      Also, when aggregation flush is requested, don't run the callback at all.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      16e23428
    • S
      ath9k_hw: Enable manual peak calibration for AR9485 · e99c60b5
      Sujith Manoharan 提交于
      Manual peak calibration is currently enabled only for
      AR9462 and AR9565. This is also required for AR9485.
      The initvals are also modified to disable HW peak calibration.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e99c60b5
    • A
      rtlwifi: rtl8192cu: Add new USB ID · 707a6152
      Albert Pool 提交于
      This adds the USB ID of the On Networks N300MA, clone of Netgear WNA3100M.
      Signed-off-by: NAlbert Pool <albertpool@solcon.nl>
      Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Reported-by: NAna Rey <Anazul77@hotmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      707a6152
    • A
      brcmfmac: announce P2P_DEVICE support in wiphy structure · 9af221b3
      Arend van Spriel 提交于
      P2P_DEVICE support was removed from brcmfmac for v3.9 kernel with
      the commit below:
      
      commit 1527c343
      Author: Arend van Spriel <arend@broadcom.com>
      Date:   Thu Apr 4 12:10:11 2013 +0200
      
          brcmfmac: remove advertising P2P device support
      
      However, it got merged into wireless-next. But for 3.10 brcmfmac does
      support P2P device. Putting it back with this commit.
      Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
      Signed-off-by: NArend van Spriel <arend@broadcom.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9af221b3
    • L
      rtlwifi: rtl8188ee: Fix warning when building on big-endian systems · 58dd3ff8
      Larry Finger 提交于
      In http://lkml.indiana.edu/hypermail/linux/kernel/1305.1/index.html,
      Geert Uytterhoeven reports a new warning when building 3.10-rc1 in
      this driver. This is caused by using a "#if" test to see if __LITTLE_ENDIAN
      is set, which fails for all big-endian systems. Change to "ifdef".
      Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      58dd3ff8
    • S
      ath9k: Fix crash on module unload · af690092
      Sujith Manoharan 提交于
      Make sure that any open relayfs files are closed before
      unregistering with mac80211, otherwise this crash is seen:
      
      [ 1331.097846] BUG: unable to handle kernel paging request at 6b6b6b8b
      [ 1331.098170] IP: [<c063d0d6>] debugfs_remove+0x26/0x80
      [ 1331.098170] *pdpt = 000000002f9aa001 *pde = 0000000000000000
      [ 1331.098170] Oops: 0000 [#1] PREEMPT SMP
      [ 1331.098170] Modules linked in: iptable_raw xt_CT nf_conntrack_ipv4 nf_defrag]
      [ 1331.098170] Pid: 4794, comm: rmmod Tainted: G        WC   3.9.1+ #5 To Be Fi.
      [ 1331.098170] EIP: 0060:[<c063d0d6>] EFLAGS: 00010202 CPU: 0
      [ 1331.098170] EIP is at debugfs_remove+0x26/0x80
      [ 1331.098170] EAX: f2f3acd0 EBX: f2f3acd0 ECX: 00000006 EDX: f8622348
      [ 1331.098170] ESI: 6b6b6b6b EDI: 00000001 EBP: ee251e14 ESP: ee251e0c
      [ 1331.098170]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      [ 1331.098170] CR0: 8005003b CR2: 6b6b6b8b CR3: 2e7b7000 CR4: 000007e0
      [ 1331.098170] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
      [ 1331.098170] DR6: ffff0ff0 DR7: 00000400
      [ 1331.098170] Process rmmod (pid: 4794, ti=ee250000 task=efaa2560 task.ti=ee25)
      [ 1331.098170] Stack:
      [ 1331.098170]  f241e170 0000000a ee251e1c f861394d ee251e28 c04e3088 f241e170 4
      [ 1331.098170]  c04e30fe f45482b0 ee251e54 c04e3187 f25e86b0 ee251e54 f8618748 0
      [ 1331.098170]  0000000a 00000001 ee251e68 f860065b f2509e20 f25085a0 f5b6e8a4 8
      [ 1331.098170] Call Trace:
      [ 1331.098170]  [<f861394d>] remove_buf_file_handler+0xd/0x20 [ath9k]
      [ 1331.098170]  [<c04e3088>] relay_remove_buf+0x18/0x30
      [ 1331.098170]  [<c04e30fe>] relay_close_buf+0x2e/0x40
      [ 1331.098170]  [<c04e3187>] relay_close+0x77/0xf0
      [ 1331.098170]  [<f8618748>] ? dpd_exit+0x38/0x40 [ath9k]
      [ 1331.098170]  [<f860065b>] ath9k_deinit_softc+0x8b/0xa0 [ath9k]
      [ 1331.098170]  [<f86006b8>] ath9k_deinit_device+0x48/0x60 [ath9k]
      [ 1331.098170]  [<f86107f1>] ath_pci_remove+0x31/0x50 [ath9k]
      [ 1331.098170]  [<c06dbff8>] pci_device_remove+0x38/0xc0
      [ 1331.098170]  [<c079daa4>] __device_release_driver+0x64/0xc0
      [ 1331.098170]  [<c079db97>] driver_detach+0x97/0xa0
      [ 1331.098170]  [<c079cacc>] bus_remove_driver+0x6c/0xe0
      [ 1331.098170]  [<c079c197>] ? bus_put+0x17/0x20
      [ 1331.098170]  [<c079cae3>] ? bus_remove_driver+0x83/0xe0
      [ 1331.098170]  [<c079e709>] driver_unregister+0x49/0x80
      [ 1331.098170]  [<c06dc138>] pci_unregister_driver+0x18/0x80
      [ 1331.098170]  [<f8610602>] ath_pci_exit+0x12/0x20 [ath9k]
      [ 1331.098170]  [<f8619ce0>] ath9k_exit+0x17/0x337 [ath9k]
      [ 1331.098170]  [<c09e537d>] ? mutex_unlock+0xd/0x10
      [ 1331.098170]  [<c04bd36c>] sys_delete_module+0x17c/0x250
      [ 1331.098170]  [<c0540dc4>] ? do_munmap+0x244/0x2d0
      [ 1331.098170]  [<c0540e96>] ? vm_munmap+0x46/0x60
      [ 1331.098170]  [<c09e8dc4>] ? restore_all+0xf/0xf
      [ 1331.098170]  [<c09ebf50>] ? __do_page_fault+0x4c0/0x4c0
      [ 1331.098170]  [<c04b18e4>] ? trace_hardirqs_on_caller+0xf4/0x180
      [ 1331.098170]  [<c09ef28d>] sysenter_do_call+0x12/0x38
      [ 1331.098170] Code: 90 8d 74 26 00 55 89 e5 83 ec 08 89 1c 24 89 74 24 04 3e 82
      [ 1331.098170] EIP: [<c063d0d6>] debugfs_remove+0x26/0x80 SS:ESP 0068:ee251e0c
      [ 1331.098170] CR2: 000000006b6b6b8b
      [ 1331.727971] ---[ end trace b5bb9f2066cef7f9 ]---
      
      Cc: <stable@vger.kernel.org>
      Acked-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
      Tested-by: NBen Greear <greearb@candelatech.com>
      Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      af690092
    • G
      net/wireless: ATH9K should depend on HAS_DMA · a01ae5b3
      Geert Uytterhoeven 提交于
      If NO_DMA=y:
      
      drivers/built-in.o: In function `ath9k_beacon_generate':
      drivers/net/wireless/ath/ath9k/beacon.c:146: undefined reference to `dma_unmap_single'
      drivers/net/wireless/ath/ath9k/beacon.c:174: undefined reference to `dma_map_single'
      drivers/net/wireless/ath/ath9k/beacon.c:176: undefined reference to `dma_mapping_error'
      drivers/built-in.o: In function `ath9k_beacon_remove_slot':
      drivers/net/wireless/ath/ath9k/beacon.c:252: undefined reference to `dma_unmap_single'
      drivers/built-in.o: In function `ath_descdma_setup':
      drivers/net/wireless/ath/ath9k/init.c:382: undefined reference to `dmam_alloc_coherent'
      drivers/built-in.o: In function `ath_edma_get_buffers':
      drivers/net/wireless/ath/ath9k/recv.c:616: undefined reference to `dma_sync_single_for_cpu'
      drivers/built-in.o: In function `ath_get_next_rx_buf':
      drivers/net/wireless/ath/ath9k/recv.c:740: undefined reference to `dma_sync_single_for_cpu'
      drivers/built-in.o: In function `ath_rx_edma_cleanup':
      drivers/net/wireless/ath/ath9k/recv.c:176: undefined reference to `dma_unmap_single'
      drivers/built-in.o: In function `ath_rx_cleanup':
      drivers/net/wireless/ath/ath9k/recv.c:340: undefined reference to `dma_unmap_single'
      drivers/built-in.o: In function `ath_rx_edma_buf_link':
      drivers/net/wireless/ath/ath9k/recv.c:122: undefined reference to `dma_sync_single_for_cpu'
      drivers/built-in.o: In function `ath_rx_tasklet':
      drivers/net/wireless/ath/ath9k/recv.c:1275: undefined reference to `dma_map_single'
      drivers/net/wireless/ath/ath9k/recv.c:1277: undefined reference to `dma_mapping_error'
      drivers/net/wireless/ath/ath9k/recv.c:1283: undefined reference to `dma_unmap_single'
      drivers/built-in.o: In function `ath_rx_edma_init':
      drivers/net/wireless/ath/ath9k/recv.c:226: undefined reference to `dma_map_single'
      drivers/net/wireless/ath/ath9k/recv.c:229: undefined reference to `dma_mapping_error'
      drivers/built-in.o: In function `ath_rx_init':
      drivers/net/wireless/ath/ath9k/recv.c:303: undefined reference to `dma_map_single'
      drivers/net/wireless/ath/ath9k/recv.c:306: undefined reference to `dma_mapping_error'
      drivers/built-in.o: In function `ath_tx_complete_buf':
      drivers/net/wireless/ath/ath9k/xmit.c:2088: undefined reference to `dma_unmap_single'
      drivers/built-in.o: In function `ath_txstatus_setup':
      drivers/net/wireless/ath/ath9k/xmit.c:2344: undefined reference to `dmam_alloc_coherent'
      drivers/built-in.o: In function `ath_tx_set_retry':
      drivers/net/wireless/ath/ath9k/xmit.c:307: undefined reference to `dma_sync_single_for_cpu'
      drivers/built-in.o: In function `ath_tx_setup_buffer':
      drivers/net/wireless/ath/ath9k/xmit.c:1887: undefined reference to `dma_map_single'
      drivers/net/wireless/ath/ath9k/xmit.c:1889: undefined reference to `dma_mapping_error'
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
      Cc: John W. Linville <linville@tuxdriver.com>
      Cc: linux-wireless@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a01ae5b3
    • D
      iwlegacy: remove inline marking of EXPORT_SYMBOL functions · becdbc59
      Denis Efremov 提交于
      EXPORT_SYMBOL and inline directives are contradictory to each other.
      The patch fixes this inconsistency.
      
      Found by Linux Driver Verification project (linuxtesting.org).
      Signed-off-by: NDenis Efremov <yefremov.denis@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      becdbc59
  2. 17 5月, 2013 5 次提交
  3. 09 5月, 2013 19 次提交
  4. 08 5月, 2013 1 次提交
  5. 07 5月, 2013 3 次提交
  6. 06 5月, 2013 1 次提交
  7. 05 5月, 2013 1 次提交
  8. 04 5月, 2013 2 次提交
    • T
      cxgb4: fix error recovery when t4_fw_hello returns a positive value · 777c2300
      Thadeu Lima de Souza Cascardo 提交于
      Since commit 636f9d37 ("cxgb4: Add
      support for T4 configuration file"), t4_fw_hello may return a positive
      value instead of 0 for success. The recovery code tests only for zero
      and fails recovery for any other value.
      
      This fix tests for negative error values and fails only on those cases.
      Error recovery after an error injection works after this change.
      Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      777c2300
    • K
      sky2: Fix crash on receiving VLAN frames · 88dccf5b
      Kirill Smelkov 提交于
      After recent 86a9bad3 (net: vlan: add protocol argument to packet
      tagging functions) my sky2 started to crash on receive of tagged
      frames, with backtrace similar to
      
          #CRASH!!!
          vlan_do_receive
          __netif_receive_skb_core
          __netif_receive_skb
          netif_receive_skb
          sky2_poll
          ...
          __net_rx_action
          __do_softirq
      
      The problem turned out to be:
      
          1) sky2 copies small packets from ring on RX, and in its
             receive_copy() skb header is copied manually field, by field, and
             only for some fields;
      
          2) 86a9bad3  added skb->vlan_proto, which vlan_untag() or
             __vlan_hwaccel_put_tag() set, and which is later used in
             vlan_do_receive().
      
             That patch updated copy_skb_header() for newly introduced
             skb->vlan_proto, but overlooked the need to also copy it in sky2's
             receive_copy().
      
      Because of 2, we have the following scenario:
      
          - frame is received and tagged in a ring, by sky2_rx_tag(). Both
            skb->vlan_proto and skb->vlan_tci are set;
      
          - later skb is decided to be copied, but skb->vlan_proto is
            forgotten and becomes 0.
      
          - in the beginning of vlan_do_receive() we call
      
              __be16 vlan_proto = skb->vlan_proto;
              vlan_dev = vlan_find_dev(skb->dev, vlan_proto, vlan_id);
      
            which eventually invokes
      
              vlan_proto_idx(vlan_proto)
      
            and that routine BUGs for everything except ETH_P_8021Q and
            ETH_P_8021AD.
      
            Oops.
      
      Fix it.
      
      P.S.
      
      Stephen, I wonder, why copy_skb_header() is not used in
      sky2.c::receive_copy() ? Problems, where receive_copy was updated field
      by field showed several times already, e.g.
      
          3f42941b    (sky2: propogate rx hash when packet is copied)
          e072b3fa    (sky2: fix receive length error in mixed non-VLAN/VLAN traffic)
      
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Cc: Mirko Lindner <mlindner@marvell.com>
      Signed-off-by: NKirill Smelkov <kirr@mns.spb.ru>
      Acked-by: NStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      88dccf5b