1. 14 1月, 2014 1 次提交
  2. 01 1月, 2014 1 次提交
  3. 29 10月, 2013 1 次提交
  4. 27 5月, 2013 1 次提交
  5. 20 3月, 2013 1 次提交
  6. 06 3月, 2013 1 次提交
  7. 24 1月, 2013 1 次提交
  8. 03 1月, 2013 2 次提交
  9. 07 12月, 2012 1 次提交
  10. 05 11月, 2012 1 次提交
  11. 11 9月, 2012 1 次提交
    • J
      iwlwifi: load firmware in chunks · 83f84d7b
      Johannes Berg 提交于
      Instead of allocating one big chunk of DMA-coherent
      memory for the firmware and keeping it around, only
      vmalloc() the firmware and copy it into a single
      page of DMA-coherent memory for the upload.
      
      The advantage is that we don't need DMA memory for
      the firmware image that is stored while the driver
      is operating, we only need it while uploading.
      
      This will make it easier for the driver to work if
      the system has fragmented memory.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      83f84d7b
  12. 25 6月, 2012 1 次提交
  13. 06 6月, 2012 3 次提交
  14. 24 4月, 2012 1 次提交
  15. 18 4月, 2012 2 次提交
  16. 17 4月, 2012 1 次提交
  17. 13 4月, 2012 1 次提交
    • J
      iwlwifi: move eeprom into priv · 11483b5c
      Johannes Berg 提交于
      The whole code around eeprom is distributed
      across whole bunch of different files, most
      of which belong to the to-be-DVM code. As a
      result, it is currently very hard to split
      out the EEPROM code to be generic. However,
      it is also quite unlikely that the current
      EEPROM code will be needed by the MVM code
      as that has different mechanisms to query
      the EEPROM (it does so through the uCode.)
      
      So, at least temporarily, move everything
      into priv. If it becomes necessary to use
      the code from MVM, we will have to split it
      out, but then it's also easier since we'll
      know what pieces we need.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      11483b5c
  18. 10 4月, 2012 5 次提交
  19. 13 3月, 2012 3 次提交
  20. 09 3月, 2012 2 次提交
    • S
      iwlwifi: make tx_cmd_pool kmem cache global · 354928dd
      Stanislaw Gruszka 提交于
      Otherwise we are not able to run more than one device per driver:
      
      [   24.743045] kmem_cache_create: duplicate cache iwl_dev_cmd
      [   24.743051] Pid: 3165, comm: NetworkManager Not tainted 3.3.0-rc2-wl+ #5
      [   24.743054] Call Trace:
      [   24.743066]  [<ffffffff811717d5>] kmem_cache_create+0x655/0x700
      [   24.743101]  [<ffffffffa03b9f8b>] iwl_alive_notify+0x1cb/0x1f0 [iwlwifi]
      [   24.743111]  [<ffffffffa03ba442>] iwl_load_ucode_wait_alive+0x1b2/0x220 [iwlwifi]
      [   24.743142]  [<ffffffffa03ba893>] iwl_run_init_ucode+0x73/0x100 [iwlwifi]
      [   24.743152]  [<ffffffffa03b8fa1>] __iwl_up+0x81/0x220 [iwlwifi]
      [   24.743161]  [<ffffffffa03b91c0>] iwlagn_mac_start+0x80/0x190 [iwlwifi]
      [   24.743188]  [<ffffffffa03307b3>] ieee80211_do_open+0x293/0x770 [mac80211]
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      354928dd
    • J
      iwlwifi: redesign PASSIVE_NO_RX workaround · e755f882
      Johannes Berg 提交于
      The PASSIVE_NO_RX workaround currently crosses
      through the op_mode and transport layers, which
      is a bit odd. This also isn't necessary, if the
      transport simply reports when queues are full
      (or no longer full) the op_mode can keep track
      of this state, and report to mac80211 only what
      *it* thinks is appropriate. What is appropriate
      can then be based on whether queues should be
      stopped to wait for RX or not.
      
      This significantly simplifies the transport API,
      it no longer needs to expose anything to stop a
      queue, nor to wake "any" queue, this can all be
      handled in the upper layer completely.
      
      Also simplify the handling to not be dependent
      on the context, that makes little sense as the
      queues are shared and both contexts have to be
      on the same channel anyway.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e755f882
  21. 08 3月, 2012 8 次提交
  22. 07 3月, 2012 1 次提交