1. 16 9月, 2014 4 次提交
  2. 15 9月, 2014 9 次提交
  3. 14 9月, 2014 20 次提交
  4. 12 9月, 2014 7 次提交
    • S
      ath9k: Fix beacon miss handling · 167bf96d
      Sujith Manoharan 提交于
      The NoA duration for a GO is half the beacon interval
      and a concurrent context like a STA can be active only
      for that duration, before switching back to the GO's
      operating channel.
      
      Currently, when multiple beacons are missed, the dwell
      time for the STA context is extended to improve the
      chances of receiving a beacon. But the NoA is not updated
      and this will cause problems since the GO is offline
      for a period that is longer than the advertised duration.
      
      Fix this by ensuring that the NoA is updated first before
      extending the time slot for the STA context. Also make
      sure that non-periodic NoA is used for a one-time, longer
      absence period.
      Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      167bf96d
    • S
      ath9k: Fix channel switch time duration · 4899827d
      Sujith Manoharan 提交于
      Since the NoA duration is the maximum time the GO interface
      can be offline, it needs to include the time take to
      switch channels in the HW.
      Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4899827d
    • S
      ath9k: Clear offchannel duration properly · 124130d7
      Sujith Manoharan 提交于
      Clearing the offchannel duration value in the
      scheduler unconditionally breaks NoA when
      multiple contexts are active and an offchannel
      request is deferred, for example, in a scan run.
      
      Fix this by clearing the duration only if there
      is no pending offchannel request.
      Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      124130d7
    • S
      ath9k: Fix Notice of Absence issues · d0975edd
      Sujith Manoharan 提交于
      * The index has to incremented only when advertising
        a new NoA schedule.
      
      * Switch to non-periodic NoA when starting a scan operation
        and multiple channel contexts are active.
      
      * Make sure that periodic NoA is advertised again when
        scan ends. Since the offchannel timer moves the offchannel
        state to IDLE after the GO operating channel becomes
        active, use a flag "force_noa_update" to update the
        NoA contents.
      Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d0975edd
    • S
      ath9k: Assign offchannel duration properly · cbc775db
      Sujith Manoharan 提交于
      In multi-channel mode, an offchannel request will
      be deferred if both contexts are active. The duration
      of the offchannel operation is calculated but is
      not stored in the scheduler state. Fix this.
      Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      cbc775db
    • V
      wil6210: fix PTR_ERR() usage after initialization to constant · 867fa0d4
      Vladimir Kondratiev 提交于
      Reported by coccinelle:
      
      tree:   git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git master
      head:   6a5d088a
      commit: b7cde470 [18/80] wil6210: convert debugfs to the table mode
      
      coccinelle warnings: (new ones prefixed by >>)
      
      >> drivers/net/wireless/ath/wil6210/debugfs.c:327:17-24: ERROR: PTR_ERR applied after initialization to constant on line 304
      
      vim +327 drivers/net/wireless/ath/wil6210/debugfs.c
      
         298                                          struct dentry *dbg, void *base,
         299                                          const struct dbg_off * const tbl)
         300  {
         301          int i;
         302
         303          for (i = 0; tbl[i].name; i++) {
      
       > 304                  struct dentry *f = NULL;
         305
         306                  switch (tbl[i].type) {
         307                  case doff_u32:
         308                          f = debugfs_create_u32(tbl[i].name, tbl[i].mode, dbg,
         309                                                 base + tbl[i].off);
         310                          break;
         311                  case doff_x32:
         312                          f = debugfs_create_x32(tbl[i].name, tbl[i].mode, dbg,
         313                                                 base + tbl[i].off);
         314                          break;
         315                  case doff_ulong:
         316                          f = wil_debugfs_create_ulong(tbl[i].name, tbl[i].mode,
         317                                                       dbg, base + tbl[i].off);
         318                          break;
         319                  case doff_io32:
         320                          f = wil_debugfs_create_iomem_x32(tbl[i].name,
         321                                                           tbl[i].mode, dbg,
         322                                                           base + tbl[i].off);
         323                          break;
         324                  }
         325                  if (IS_ERR_OR_NULL(f))
         326                          wil_err(wil, "Create file \"%s\": err %ld\n",
      
       > 327                                  tbl[i].name, PTR_ERR(f));
         328          }
         329  }
         330
      Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      867fa0d4
    • V
      wil6210: fix for oops while stopping interface · 73d839ae
      Vladimir Kondratiev 提交于
      When interface stopped while running intensive Rx traffic, the following oops
      observed:
      
      [89846.734683] Call trace:
      [89846.737117] [<ffffffc00083aa64>] dev_gro_receive+0xac/0x358
      [89846.742674] [<ffffffc00083ae94>] napi_gro_receive+0x24/0xa4
      [89846.748251] [<ffffffbffc1c2f88>] $x+0xec/0x1f8 [wil6210]         wil_netif_rx_any
      [89846.753547] [<ffffffbffc1c4830>] $x+0x34/0x54 [wil6210]          wil_release_reorder_frame
      [89846.758755] [<ffffffbffc1c48ac>] wil_release_reorder_frames+0x5c/0x78 [wil6210]
      [89846.766044] [<ffffffbffc1c4bf8>] wil_tid_ampdu_rx_free+0x20/0x48 [wil6210]
      [89846.772901] [<ffffffbffc1bedc8>] $x+0x190/0x1e8 [wil6210]
      [89846.778285] [<ffffffbffc1c0ed4>] wmi_event_worker+0x230/0x2f8 [wil6210]
      [89846.784865] [<ffffffc0000b0bc8>] process_one_work+0x278/0x3fc
      [89846.790591] [<ffffffc0000b1218>] worker_thread+0x200/0x330
      [89846.796060] [<ffffffc0000b6664>] kthread+0xac/0xb8
      [89846.800836] Code: b940c661 f9406a62 8b010041 f9400026 (f8636882)
      [89846.807008] ---[ end trace d6fdc17cd27d18f6 ]---
      
      Reason is the following: when removing Rx vring
      (wil_netdev_ops.ndo_stop -> wil_stop -> wil_down -> __wil_down -> wil_rx_fini),
      Rx interrupt occurs. It trigger Rx NAPI, calling wil_rx_handle() that reaps
      (already cleaned) buffer, causing skb referring to garbage memory being set into reorder buffer.
      Then, network stack trying to access this buffer and fails.
      
      Prevent Rx NAPI from being scheduled if device going to stop. Bit wil_status_napi_en reflects
      NAPI enablement state, check it when triggering Rx NAPI.
      
      Testing shows that check for wil_status_napi_en sometimes gets negative, and new error message
      get printed - in this case kernel oops would be observed. Original oops is no more reproducible.
      
      This change requires also changes in the AP flows.
      Properly enable/disable NAPI for the AP. Make sure Rx VRING is disabled
      when resetting target.
      
      For this, promote __wil_up() and __wil_down() to the module scope, and use it
      in the relevant flows.
      Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      73d839ae