1. 16 12月, 2011 2 次提交
    • E
      iwlwifi: don't rely on the wr / rd pointers in DELBA flow · 1f40e145
      Emmanuel Grumbach 提交于
      In the same spirit as the previous patch. Eventually this will
      allow us to remove the tid_data knowledge from the transport layer.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      1f40e145
    • E
      iwlwifi: don't count the tfds in HW queue any more · eb9a372a
      Emmanuel Grumbach 提交于
      Since packets sent to an RA / TID in AGG are sent from a
      separate HW Tx queue, we may get into a race:
      the regular queue isn't empty while we already begin to
      send packets from the AGG queue. This would result in sending
      packets out of order.
      
      In order to cope with this, mac80211 waits until the driver
      reports that the legacy queue is drained before it can send
      packets to the AGG queue. During that time, mac80211 buffers
      packets for the driver. These packets will be sent in order
      after the driver reports it is ready.
      
      The way this was implemented in the driver is as follows:
      We held a counter that monitors the number of packets for
      an RA / TID in the HW queues. When this counter reached 0,
      we knew that the HW queues were drained and we reported to
      mac80211 that were ready to proceed.
      
      This patch changes the implementation described above. We
      now remember what is the wifi sequence number of the first
      packet that will be sent in the AGG queue (lets' call it
      ssn). When we reclaim the packet before ssn, we know that
      the queue is drained, and we are ready to proceed.
      
      This will allow us to move this logic in the upper layer and
      eventually remove the tid_data from the shared area.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      eb9a372a
  2. 22 11月, 2011 2 次提交
  3. 18 11月, 2011 2 次提交
  4. 12 11月, 2011 4 次提交
  5. 15 10月, 2011 6 次提交
  6. 22 9月, 2011 2 次提交
  7. 20 9月, 2011 6 次提交
    • W
      iwlagn: signedness bug · 143bb15d
      Wey-Yi Guy 提交于
      re-apply the unsigned shorts bug fixed by Dan Carpenter but get lost
      after the file move.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      143bb15d
    • J
      iwlagn: do not use interruptible waits · effd4d9a
      Johannes Berg 提交于
      Since the dawn of its time, iwlwifi has used
      interruptible waits to wait for synchronous
      commands and firmware loading.
      
      This leads to "interesting" bugs, because it
      can't actually handle the interruptions; for
      example when a command sending is interrupted
      it will assume the command completed fully,
      and then leave it pending, which leads to all
      kinds of trouble when the command finishes
      later.
      
      Since there's no easy way to gracefully deal
      with interruptions, fix the driver to not use
      interruptible waits.
      
      This at least fixes the error
      iwlagn 0000:02:00.0: Error: Response NULL in  'REPLY_SCAN_ABORT_CMD'
      
      I have seen in P2P testing, but it is likely
      that there are other errors caused by this.
      
      Cc: Stanislaw Gruszka <sgruszka@redhat.com>
      Cc: stable@kernel.org [2.6.24+]
      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>
      effd4d9a
    • J
      iwlagn: generically provide iwl_trans_send_cmd_pdu · 370ad313
      Johannes Berg 提交于
      There's no need to have the transport layer have a
      callback for iwl_trans_send_cmd_pdu() since it is
      just a generic wrapper around iwl_trans_send_cmd().
      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>
      370ad313
    • J
      iwlagn: move PCI-E transport files · c17d0681
      Johannes Berg 提交于
      Move all the PCI-E specific transport files to
      be iwl-trans-pcie*; specifically iwl-trans.c
      which is really iwl-trans-pcie.c.
      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>
      c17d0681
    • E
      iwlagn: free the Tx cmd when a non empty Tx queue is freed · 909e9b23
      Emmanuel Grumbach 提交于
      When a non-empty Tx queueis freed, the buffer it contains must be
      freed too. Since the Tx cmd are now allocated from a pool, the Tx
      cmd must be freed too.
      
      This patch avoids to destroy a non-empty pool of Tx cmd.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      909e9b23
    • E
      iwlagn: unmap cmd queue's tfds as BIDI · 39644e9a
      Emmanuel Grumbach 提交于
      If the driver is unloaded while there is still a host command in
      flight, its tfd will be freed by iwl_tx_queue_free.
      This function is called for both types of queues: Tx queues and cmd
      queue. This didn't take in count the fact that in Tx queues, tfds are
      mapped as TO_DEVICE (besides the first TB), whereas in cmd queue, all
      TBs are mapped as BIDI.
      
      Hence, tx_queue_free unmapped the second (and higher) TB of each tfd
      in the cmd queue as TO_DEVICE, whereas they must be freed as BIDI.
      This means that if a multi TFD is in flight while we unload the
      driver (which is quite unlikely but can happen), we will get the
      warning below.
      
      This patch fixes this.
      
      [  445.234060] ------------[ cut here ]------------
      [  445.236273] WARNING: at lib/dma-debug.c:861 check_unmap+0x337/0x780()
      [  445.236654] iwlagn 0000:02:00.0: DMA-API: device driver frees DMA memory with different direction [device address=0x0000000126950540] [size=8 bytes] [mapped with DMA_BIDIRECTIONAL] [unmapped with DMA_TO_DEVICE]
      [  445.236654] Modules linked in: ...
      [  445.236654] Pid: 1415, comm: modprobe Not tainted 3.1.0-rc4-wl-65912-g5215ff1-dirty #79
      [  445.236654] Call Trace:
      [  445.236654]  [<ffffffff81043a51>] warn_slowpath_common+0x71/0xa0
      [  445.236654]  [<ffffffff81043b37>] warn_slowpath_fmt+0x47/0x50
      [  445.236654]  [<ffffffff8121e687>] check_unmap+0x337/0x780
      [  445.236654]  [<ffffffff810e9136>] ? free_one_page+0x156/0x320
      [  445.236654]  [<ffffffff8121ec5a>] debug_dma_unmap_page+0x5a/0x60
      [  445.236654]  [<ffffffffa021d701>] iwlagn_unmap_tfd.isra.11+0x121/0x1c0 [iwlagn]
      [  445.236654]  [<ffffffffa021ddf2>] iwlagn_txq_free_tfd+0x42/0x70 [iwlagn]
      [  445.236654]  [<ffffffffa02121de>] iwl_tx_queue_unmap+0x4e/0x70 [iwlagn]
      [  445.236654]  [<ffffffffa0212fad>] iwl_trans_pcie_tx_free+0x10d/0x440 [iwlagn]
      [  445.236654]  [<ffffffff81064959>] ? destroy_workqueue+0xb9/0x1e0
      [  445.236654]  [<ffffffffa021330a>] iwl_trans_pcie_free+0x2a/0x2c0 [iwlagn]
      [  445.236654]  [<ffffffffa022f4f2>] iwl_remove+0x149/0x17e [iwlagn]
      [  445.236654]  [<ffffffffa022f546>] iwl_pci_remove+0x1f/0x65 [iwlagn]
      [  445.236654]  [<ffffffff81228337>] pci_device_remove+0x47/0x120
      [  445.236654]  [<ffffffff8134566c>] __device_release_driver+0x7c/0xe0
      [  445.236654]  [<ffffffff81345dc8>] driver_detach+0xc8/0xd0
      [  445.236654]  [<ffffffff813454c8>] bus_remove_driver+0x88/0xe0
      [  445.236654]  [<ffffffff81346572>] driver_unregister+0x62/0xa0
      [  445.236654]  [<ffffffff812271d4>] pci_unregister_driver+0x44/0xc0
      [  445.236654]  [<ffffffffa0211ce5>] iwl_pci_unregister_driver+0x15/0x20 [iwlagn]
      [  445.236654]  [<ffffffffa022f595>] iwl_exit+0x9/0xa74 [iwlagn]
      [  445.236654]  [<ffffffff810918f4>] sys_delete_module+0x184/0x240
      [  445.236654]  [<ffffffff81452ece>] ? retint_swapgs+0xe/0x13
      [  445.236654]  [<ffffffff8121098e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
      [  445.236654]  [<ffffffff81459e2b>] system_call_fastpath+0x16/0x1b
      [  445.236654] ---[ end trace 1fbc362b7dbe5d74 ]---
      [  445.236654] Mapped at:
      [  445.236654]  [<ffffffff8121d7cb>] debug_dma_map_page+0x8b/0x150
      [  445.236654]  [<ffffffffa021e7b7>] iwl_enqueue_hcmd+0x837/0xa40 [iwlagn]
      [  445.236654]  [<ffffffffa021f92d>] iwl_trans_pcie_send_cmd+0x8d/0x580 [iwlagn]
      [  445.236654]  [<ffffffffa01f7c75>] iwl_send_calib_results+0x75/0xd0 [iwlagn]
      [  445.236654]  [<ffffffffa01f21f6>] iwlagn_alive_notify+0x196/0x1f0 [iwlagn]
      [  445.386500] iwlagn 0000:02:00.0: PCI INT A disabled
      Reported-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      39644e9a
  8. 15 9月, 2011 2 次提交
  9. 14 9月, 2011 2 次提交
  10. 30 8月, 2011 12 次提交