1. 01 3月, 2014 6 次提交
  2. 13 2月, 2014 14 次提交
  3. 05 2月, 2014 1 次提交
  4. 09 1月, 2014 1 次提交
  5. 19 12月, 2013 2 次提交
  6. 10 12月, 2013 1 次提交
  7. 27 8月, 2013 2 次提交
  8. 02 8月, 2013 1 次提交
  9. 27 7月, 2013 1 次提交
  10. 24 7月, 2013 3 次提交
  11. 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
  12. 20 6月, 2013 2 次提交
  13. 23 5月, 2013 3 次提交
  14. 24 4月, 2013 1 次提交
  15. 09 4月, 2013 1 次提交
    • A
      mwifiex: fix infinite loop by removing NO_PKT_PRIO_TID · 333f6b22
      Andreas Fenkart 提交于
      Using NO_PKT_PRIO_TID and tx_pkts_queued to check for an empty
      state, can lead to a contradictory state, resulting in an
      infinite loop. Currently queueing and dequeuing of packets is
      not synchronized, and can happen concurrently. While tx_pkts_queued
      is incremented when adding a packet, max prio is set to NO_PKT when
      the WMM list is empty. If a packet is added right after the check
      for empty, but before setting max prio to NO_PKT, that packet is
      trapped and creates an infinite loop.
      
      Because of the new packet, tx_pkts_queued is at least 1, indicating
      wmm lists are not empty. Opposing that max prio is NO_PKT, which
      means "skip this wmm queue, it has no packets". The infinite loop
      results, because the main loop checks the wmm lists for not empty
      via tx_pkts_queued, but for dequeing it uses max_prio to see if it
      can skip current list. This will never end, unless a new packet is
      added which will restore max prio to the level of the trapped packet.
      
      The solution here is to rely on tx_pkts_queued solely for checking
      wmm queue to be empty, and drop the NO_PKT define. It does not
      address the locking issue.
      Signed-off-by: NAndreas Fenkart <andreas.fenkart@streamunlimited.com>
      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>
      333f6b22