1. 14 9月, 2014 1 次提交
  2. 04 9月, 2014 3 次提交
  3. 25 6月, 2014 1 次提交
  4. 07 5月, 2014 2 次提交
  5. 13 4月, 2014 4 次提交
  6. 10 3月, 2014 1 次提交
  7. 13 2月, 2014 1 次提交
  8. 01 1月, 2014 2 次提交
  9. 22 12月, 2013 1 次提交
  10. 18 12月, 2013 4 次提交
  11. 26 11月, 2013 1 次提交
  12. 16 7月, 2013 1 次提交
  13. 13 6月, 2013 1 次提交
  14. 28 2月, 2013 1 次提交
    • J
      iwlwifi: use coherent DMA memory for command header · 38c0f334
      Johannes Berg 提交于
      Recently in commit 8a964f44
      ("iwlwifi: always copy first 16 bytes of commands") we fixed
      the problem that the hardware writes back to the command and
      that could overwrite parts of the data that was still needed
      and would thus be corrupted.
      
      Investigating this problem more closely we found that this
      write-back isn't really ordered very well with respect to
      other DMA traffic. Therefore, it sometimes happened that the
      write-back occurred after unmapping the command again which
      is clearly an issue and could corrupt the next allocation
      that goes to that spot, or (better) cause IOMMU faults.
      
      To fix this, allocate coherent memory for the first 16 bytes
      of each command, containing the write-back part, and use it
      for all queues. All the dynamic DMA mappings only need to be
      TO_DEVICE then. This ensures that even when the write-back
      happens "too late" it can't hit memory that has been freed
      or a mapping that doesn't exist any more.
      
      Since now the actual command is no longer modified, we can
      also remove CMD_WANT_HCMD and get rid of the DMA sync that
      was necessary to update the scratch pointer.
      Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      38c0f334
  15. 27 2月, 2013 1 次提交
    • J
      iwlwifi: always copy first 16 bytes of commands · 8a964f44
      Johannes Berg 提交于
      The FH hardware will always write back to the scratch field
      in commands, even host commands not just TX commands, which
      can overwrite parts of the command. This is problematic if
      the command is re-used (with IWL_HCMD_DFL_NOCOPY) and can
      cause calibration issues.
      
      Address this problem by always putting at least the first
      16 bytes into the buffer we also use for the command header
      and therefore make the DMA engine write back into this.
      
      For commands that are smaller than 16 bytes also always map
      enough memory for the DMA engine to write back to.
      
      Cc: stable@vger.kernel.org
      Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8a964f44
  16. 05 2月, 2013 1 次提交
    • J
      iwlwifi: use threaded interrupt handler · 2bfb5092
      Johannes Berg 提交于
      With new transports coming up, move to threaded
      interrupt handling now. This has the advantage
      that we can use the same locking scheme with all
      different transports we may need to implement.
      
      Note that the TX path obviously still runs in a
      tasklet, so some spin_lock() calls need to change
      to spin_lock_bh() calls to properly lock out the
      TX path.
      
      In my test on a Calpella platform this has no
      impact on throughput or latency.
      
      Also add lockdep annotations to avoid lockups due
      to catch sending synchronous commands or using
      locks that connect with them from the irq thread.
      Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      2bfb5092
  17. 01 2月, 2013 1 次提交
  18. 24 1月, 2013 1 次提交
  19. 16 1月, 2013 1 次提交
  20. 03 1月, 2013 2 次提交
  21. 19 11月, 2012 6 次提交
  22. 10 11月, 2012 1 次提交
  23. 01 11月, 2012 1 次提交
    • E
      iwlwifi: handle RFKILL logic in the transport layer · f946b529
      Emmanuel Grumbach 提交于
      No HCMD can be sent while RFKILL is asserted. If a SYNC
      command is running while RFKILL is asserted the fw will
      silently discard it. This means that the driver needs to
      wake the process that sleeps on the CMD_SYNC.
      
      Since the RFKILL interrupt is handled in the transport layer
      and the code that sleeps in CMD_SYNC is also in the transport
      layer, all this logic can be handled there.
      This simplifies the work of the op_mode.
      
      So the transport layer will now return -ERFKILL when a CMD
      is sent and RFKILL is asserted. This will be the case even
      when the CMD is SYNC. The transport layer will return
      -ERFKILL straight away.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f946b529
  24. 29 10月, 2012 1 次提交