1. 26 6月, 2014 1 次提交
  2. 25 4月, 2014 1 次提交
  3. 23 4月, 2014 2 次提交
  4. 16 4月, 2014 1 次提交
  5. 28 3月, 2014 1 次提交
  6. 01 3月, 2014 1 次提交
  7. 25 2月, 2014 1 次提交
  8. 17 2月, 2014 1 次提交
  9. 11 1月, 2014 1 次提交
    • J
      net: core: explicitly select a txq before doing l2 forwarding · f663dd9a
      Jason Wang 提交于
      Currently, the tx queue were selected implicitly in ndo_dfwd_start_xmit(). The
      will cause several issues:
      
      - NETIF_F_LLTX were removed for macvlan, so txq lock were done for macvlan
        instead of lower device which misses the necessary txq synchronization for
        lower device such as txq stopping or frozen required by dev watchdog or
        control path.
      - dev_hard_start_xmit() was called with NULL txq which bypasses the net device
        watchdog.
      - dev_hard_start_xmit() does not check txq everywhere which will lead a crash
        when tso is disabled for lower device.
      
      Fix this by explicitly introducing a new param for .ndo_select_queue() for just
      selecting queues in the case of l2 forwarding offload. netdev_pick_tx() was also
      extended to accept this parameter and dev_queue_xmit_accel() was used to do l2
      forwarding transmission.
      
      With this fixes, NETIF_F_LLTX could be preserved for macvlan and there's no need
      to check txq against NULL in dev_hard_start_xmit(). Also there's no need to keep
      a dedicated ndo_dfwd_start_xmit() and we can just reuse the code of
      dev_queue_xmit() to do the transmission.
      
      In the future, it was also required for macvtap l2 forwarding support since it
      provides a necessary synchronization method.
      
      Cc: John Fastabend <john.r.fastabend@intel.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: e1000-devel@lists.sourceforge.net
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Acked-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f663dd9a
  10. 19 12月, 2013 1 次提交
  11. 10 12月, 2013 2 次提交
  12. 16 11月, 2013 4 次提交
  13. 15 10月, 2013 1 次提交
  14. 01 10月, 2013 1 次提交
  15. 23 8月, 2013 1 次提交
    • B
      mwifiex: do not create AP and P2P interfaces upon driver loading · 1211c961
      Bing Zhao 提交于
      Bug 60747 - 1286:2044 [Microsoft Surface Pro]
          Marvell 88W8797 wifi show 3 interface under network
      https://bugzilla.kernel.org/show_bug.cgi?id=60747
      
      This issue was also reported previously by OLPC and some folks from
      the community.
      
      There are 3 network interfaces with different types being created
      when mwifiex driver is loaded:
      
      1. mlan0 (infra. STA)
      2. uap0 (AP)
      3. p2p0 (P2P_CLIENT)
      
      The Network Manager attempts to use all 3 interfaces above without
      filtering the managed interface type. As the result, 3 identical
      interfaces are displayed under network manager. If user happens to
      click on an entry under which its interface is uap0 or p2p0, the
      association will fail.
      
      Work around it by removing the creation of AP and P2P interfaces
      at driver loading time. These interfaces can be added with 'iw' or
      other applications manually when they are needed.
      Signed-off-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NAvinash Patil <patila@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      1211c961
  16. 02 8月, 2013 1 次提交
  17. 27 7月, 2013 1 次提交
  18. 24 7月, 2013 2 次提交
  19. 23 7月, 2013 1 次提交
    • D
      mwifiex: fix IRQ enable/disable · 232fde06
      Daniel Drake 提交于
      During tear down (e.g. mwifiex_sdio_remove during system suspend),
      mwifiex left IRQs enabled for a significant period of time when it was
      unable to handle them correctly. This caused interrupt storms and
      interfered with the bluetooth interface on the same SDIO card.
      
      Solve this by disabling interrupts at the point when they can no longer
      be handled correctly, which is at the start of mwifiex_remove_card().
      
      For cleanliness, we now enable interrupts in the mwifiex_add_card() path,
      to be symmetrical with the disabling of interrupts. We also couple the
      registration of the sdio IRQ handler with the actual enable/disable of
      interrupts at the hardware level.
      
      I also removed a write to this register in mwifiex_init_sdio which seemed
      pointless and won't cause any ill effects now that we only register
      the SDIO IRQ handler when we are ready to accept interrupts.
      
      Includes some corrections from Amitkumar Karwar.
      Signed-off-by: NDaniel Drake <dsd@laptop.org>
      Acked-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      232fde06
  20. 18 6月, 2013 1 次提交
    • D
      mwifiex: fix memory corruption when unsetting multicast list · 6390d885
      Daniel Drake 提交于
      When trying to unset a previously-set multicast list (i.e. the new list
      has 0 entries), mwifiex_set_multicast_list() was calling down to
      mwifiex_request_set_multicast_list() while leaving
      mcast_list.num_multicast_addr as an uninitialized value.
      
      We were arriving at mwifiex_cmd_mac_multicast_adr() which would then
      proceed to do an often huge memcpy of
      mcast_list.num_multicast_addr*ETH_ALEN bytes, causing memory corruption
      and hard to debug crashes.
      
      Fix this by setting mcast_list.num_multicast_addr to 0 when no multicast
      list is provided. Similarly, fix up the logic in
      mwifiex_request_set_multicast_list() to unset the multicast list that
      was previously sent to the hardware in such cases.
      Signed-off-by: NDaniel Drake <dsd@laptop.org>
      Acked-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6390d885
  21. 13 6月, 2013 1 次提交
  22. 23 5月, 2013 2 次提交
  23. 09 5月, 2013 1 次提交
  24. 09 3月, 2013 1 次提交
  25. 15 11月, 2012 2 次提交
    • B
      mwifiex: process RX packets in SDIO IRQ thread directly · 601216e1
      Bing Zhao 提交于
      ksdioirqd has higher priority than kworker. Process RX packets
      in SDIO IRQ thread (ksdioirqd/mmcX) directly instead of deferring
      the work to kworker to avoid the extra latency.
      This improves TCP throughput 15~20% on an ARM platform with SDIO
      2.0 controller.
      Signed-off-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      601216e1
    • A
      mwifiex: add multi-queue support · 47411a06
      Avinash Patil 提交于
      This patch adds support for multiple TX queues inside mwifiex
      driver. Four different queues according to WMM access categories
      are defined for each virtual interface. When a packet is
      received from netdev for transmission, tx pending count for
      particular queue is incremented and if tx pending count has
      reached upper water-mark, this queue is stopped instead of
      stopping all queues. Similarly when a packet is successfully
      transmitted from device, tx pending count is decremented per
      queue and if pending count falls below lower water-mark, queue
      operations are again resumed. This ensures that not all
      tranmission is blocked if traffic with particular TOS value
      suddenly increases.
      
      Also wake all queues after association/IBSS_join/uAP_BSS_start
      to enable traffic on all queues.
      Signed-off-by: NAvinash Patil <patila@marvell.com>
      Signed-off-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      47411a06
  26. 30 10月, 2012 1 次提交
  27. 29 9月, 2012 2 次提交
  28. 12 9月, 2012 1 次提交
  29. 07 8月, 2012 1 次提交
  30. 12 7月, 2012 1 次提交
  31. 23 6月, 2012 1 次提交