1. 16 6月, 2017 1 次提交
    • J
      networking: introduce and use skb_put_data() · 59ae1d12
      Johannes Berg 提交于
      A common pattern with skb_put() is to just want to memcpy()
      some data into the new space, introduce skb_put_data() for
      this.
      
      An spatch similar to the one for skb_put_zero() converts many
      of the places using it:
      
          @@
          identifier p, p2;
          expression len, skb, data;
          type t, t2;
          @@
          (
          -p = skb_put(skb, len);
          +p = skb_put_data(skb, data, len);
          |
          -p = (t)skb_put(skb, len);
          +p = skb_put_data(skb, data, len);
          )
          (
          p2 = (t2)p;
          -memcpy(p2, data, len);
          |
          -memcpy(p, data, len);
          )
      
          @@
          type t, t2;
          identifier p, p2;
          expression skb, data;
          @@
          t *p;
          ...
          (
          -p = skb_put(skb, sizeof(t));
          +p = skb_put_data(skb, data, sizeof(t));
          |
          -p = (t *)skb_put(skb, sizeof(t));
          +p = skb_put_data(skb, data, sizeof(t));
          )
          (
          p2 = (t2)p;
          -memcpy(p2, data, sizeof(*p));
          |
          -memcpy(p, data, sizeof(*p));
          )
      
          @@
          expression skb, len, data;
          @@
          -memcpy(skb_put(skb, len), data, len);
          +skb_put_data(skb, data, len);
      
      (again, manually post-processed to retain some comments)
      Reviewed-by: NStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      59ae1d12
  2. 05 4月, 2017 3 次提交
  3. 20 3月, 2017 1 次提交
    • K
      ath10k: fix warnings from an earlier commit · 46bc92be
      Kalle Valo 提交于
      I failed to notice that commit 523f6701 ("ath10k: update available channel
      list for 5G radio") added two new warnings:
      
      drivers/net/wireless/ath/ath10k/mac.c:3129:6: warning: symbol 'ath10k_mac_update_channel_list' was not declared. Should it be static?
      drivers/net/wireless/ath/ath10k/mac.c:3170: Alignment should match open parenthesis
      
      Fix those.
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      46bc92be
  4. 16 3月, 2017 1 次提交
    • T
      ath10k: update available channel list for 5G radio · 523f6701
      Tamizh chelvam 提交于
      If a 5 GHz radio is calibrated for operation in both
      the low band (channels 36 to 64) and high band(channels 100 to 169),
      hardware allows operations in all the listed channels. However,
      if the chip has been calibrated only for the low/high band and
      a high/low band channel is configured, due to lack of calibration
      there will be potentially invalid signal on those non calibrated channels.
      To avoid this problem this patch sets IEEE80211_CHAN_DISABLED flag for
      those non calibrated channels by using low_5ghz_chan and high_5ghz_chan
      values which we get from target through wmi service ready event.
      
      Driver initialized flags are getting re initialized in handle_channel
      in cfg80211. So calling the function to disable the non supported channel
      from reg_notifier().
      Signed-off-by: NTamizh chelvam <c_traja@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      523f6701
  5. 09 3月, 2017 1 次提交
    • M
      ath10k: fix a warning during channel switch with multiple vaps · c73f8c00
      Mohammed Shafi Shajakhan 提交于
      Doing a channel switch via hostapd_cli seems to update
      the new channel context for each VAP's appropriately as below
      in 'ath10k_mac_update_vif_chan', hence we can safely suppress the
      warning that shows up during this operation and dump the warning only
      if no vaps are available for channel switch
      
      hostapd_cli -i wlan0 chan_switch 5 5200
      OK
      
      ath10k_pci : mac chanctx switch n_vifs 3 mode 1
      ath10k_pci : mac chanctx switch vdev_id 2 freq 5180->5200 width 0->0
      ath10k_pci : mac chanctx switch vdev_id 1 freq 5180->5200 width 0->0
      ath10k_pci : mac chanctx switch vdev_id 0 freq 5180->5200 width 0->0
      
      Call Trace:
      
      WARNING: backports-20161201-3.14.77-9ab3068/drivers/net/wireless/ath/ath10k/mac.c:7126
      [<c022f2d4>] (warn_slowpath_null) from [<bf7f150c>]
      (ath10k_reconfig_complete+0xe4/0x25c [ath10k_core])
      [<bf7f150c>] (ath10k_reconfig_complete [ath10k_core])
      [<bf7f35f0>] (ath10k_mac_vif_ap_csa_work+0x214/0x370 [ath10k_core])
      [<bf7f38b8>] (ath10k_mac_op_change_chanctx+0x108/0x128 [ath10k_core])
      [<bf782ac0>] (ieee80211_recalc_chanctx_min_def+0x30c/0x430 [mac80211])
      [<bf7830a4>] (ieee80211_recalc_smps_chanctx+0x2ec/0x840 [mac80211])
      [<bf7843e8>] (ieee80211_vif_use_reserved_context+0x7c/0xf8 [mac80211])
      [<bf7843e8>] (ieee80211_vif_use_reserved_context [mac80211])
      [<bf76e5d4>] (ieee80211_csa_finalize_work+0x5c/0x88 [mac80211])
      
      Fixes: d7bf4b4a ("ath10k: fix ar->rx_channel updating logic")
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      c73f8c00
  6. 06 3月, 2017 1 次提交
  7. 15 2月, 2017 1 次提交
  8. 19 1月, 2017 1 次提交
    • M
      ath10k: prevent sta pointer rcu violation · 0a744d92
      Michal Kazior 提交于
      Station pointers are RCU protected so driver must
      be extra careful if it tries to store them
      internally for later use outside of the RCU
      section it obtained it in.
      
      It was possible for station teardown to race with
      some htt events. The possible outcome could be a
      use-after-free and a crash.
      
      Only peer-flow-control capable firmware was
      affected (so hardware-wise qca99x0 and qca4019).
      
      This could be done in sta_state() itself via
      explicit synchronize_net() call but there's
      already a convenient sta_pre_rcu_remove() op that
      can be hooked up to avoid extra rcu stall.
      
      The peer->sta pointer itself can't be set to
      NULL/ERR_PTR because it is later used in
      sta_state() for extra sanity checks.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      0a744d92
  9. 13 1月, 2017 2 次提交
  10. 30 12月, 2016 4 次提交
    • M
      ath10k: enable advertising support for channel 169, 5Ghz · 34c30b0a
      Mohammed Shafi Shajakhan 提交于
      Enable advertising support for channel 169, 5Ghz so that
      based on the regulatory domain(country code) this channel
      shall be active for use. For example in countries like India
      this channel shall be available for use with latest regulatory updates
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      34c30b0a
    • M
      ath10k: Remove passing unused argument for ath10k_mac_tx · a7773b5d
      Mohammed Shafi Shajakhan 提交于
      'ath10k_mac_tx' does not seems to use the per station table
      entry pointer 'sta' (struct ieee80211_sta), hence remove passing
      this unused argument
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      a7773b5d
    • R
      ath10k: recal the txpower when removing interface · d679fa1b
      Ryan Hsu 提交于
      The txpower is being recalculated when adding interface to make sure
      txpower won't overshoot the spec, and when removing the interface,
      the txpower should again to be recalculated to restore the correct value
      from the active interface list.
      
      Following is one of the scenario
      	vdev0 is created as STA and connected: txpower:23
      	vdev1 is created as P2P_DEVICE for control interface: txpower:0
      	vdev2 is created as p2p go/gc interface: txpower is 21
      
      So the vdev2@txpower:21 will be set to firmware when vdev2 is created.
      When we tear down the vdev2, the txpower needs to be recalculated to
      re-set it to vdev0@txpower:23 as vdev0/vdev1 are the active interface.
      
      	ath10k_pci mac vdev 0 peer create 8c:fd:f0:01:62:98
      	ath10k_pci mac vdev_id 0 txpower 23
      	... (adding interface)
      	ath10k_pci mac vdev create 2 (add interface) type 1 subtype 3
      	ath10k_pci mac vdev_id 2 txpower 21
      	ath10k_pci mac txpower 21
      	... (removing interface)
      	ath10k_pci mac vdev 2 delete (remove interface)
      	ath10k_pci vdev 1 txpower 0
      	ath10k_pci vdev 0 txpower 23
      	ath10k_pci mac txpower 23
      Signed-off-by: NRyan Hsu <ryanhsu@qca.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      d679fa1b
    • R
      ath10k: fix incorrect txpower set by P2P_DEVICE interface · 88407beb
      Ryan Hsu 提交于
      Ath10k reports the phy capability that supports P2P_DEVICE interface.
      
      When we use the P2P supported wpa_supplicant to start connection, it'll
      create two interfaces, one is wlan0 (vdev_id=0) and one is P2P_DEVICE
      p2p-dev-wlan0 which is for p2p control channel (vdev_id=1).
      
      	ath10k_pci mac vdev create 0 (add interface) type 2 subtype 0
      	ath10k_add_interface: vdev_id: 0, txpower: 0, bss_power: 0
      	...
      	ath10k_pci mac vdev create 1 (add interface) type 2 subtype 1
      	ath10k_add_interface: vdev_id: 1, txpower: 0, bss_power: 0
      
      And the txpower in per vif bss_conf will only be set to valid tx power when
      the interface is assigned with channel_ctx.
      
      But this P2P_DEVICE interface will never be used for any connection, so
      that the uninitialized bss_conf.txpower=0 is assinged to the
      arvif->txpower when interface created.
      
      Since the txpower configuration is firmware per physical interface.
      So the smallest txpower of all vifs will be the one limit the tx power
      of the physical device, that causing the low txpower issue on other
      active interfaces.
      
      	wlan0: Limiting TX power to 21 (24 - 3) dBm
      	ath10k_pci mac vdev_id 0 txpower 21
      	ath10k_mac_txpower_recalc: vdev_id: 1, txpower: 0
      	ath10k_mac_txpower_recalc: vdev_id: 0, txpower: 21
      	ath10k_pci mac txpower 0
      
      This issue only happens when we use the wpa_supplicant that supports
      P2P or if we use the iw tool to create the control P2P_DEVICE interface.
      Signed-off-by: NRyan Hsu <ryanhsu@qca.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      88407beb
  11. 29 12月, 2016 2 次提交
    • B
      ath10k: add debug trace to rts/cts set function · 86176901
      Bartosz Markowski 提交于
      Align it with the cts protection call.
      Signed-off-by: NBartosz Markowski <bartosz.markowski@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      86176901
    • B
      ath10k: set CTS protection VDEV param only if VDEV is up · 7cfe0455
      Bartosz Markowski 提交于
      The cts protection vdev parameter, in new QCA9377 TF2.0 firmware,
      requires bss peer to be created for the STATION vdev type.
      bss peer is being allocated by the firmware after vdev_start/_up commands.
      mac80211 may call the cts protection setup at any time, so the
      we needs to track the situation and defer the cts configuration
      to prevent firmware asserts, like below:
      
      [00]: 0x05020001 0x000015B3 0x0099ACE2 0x00955B31
      [04]: 0x0099ACE2 0x00060730 0x00000004 0x00000000
      [08]: 0x0044C754 0x00412C10 0x00000000 0x00409C54
      [12]: 0x00000009 0x00000000 0x00952F6C 0x00952F77
      [16]: 0x00952CC4 0x00910712 0x00000000 0x00000000
      [20]: 0x4099ACE2 0x0040E858 0x00421254 0x004127F4
      [24]: 0x8099B9B2 0x0040E8B8 0x00000000 0xC099ACE2
      [28]: 0x800B75CB 0x0040E8F8 0x00000007 0x00005008
      [32]: 0x809B048A 0x0040E958 0x00000010 0x00433B10
      [36]: 0x809AFBBC 0x0040E9A8 0x0042BB74 0x0042BBBC
      [40]: 0x8091D252 0x0040E9C8 0x0042BBBC 0x00000001
      [44]: 0x809FFA45 0x0040EA78 0x0043D3E4 0x0042C2C8
      [48]: 0x809FCEF4 0x0040EA98 0x0043D3E4 0x00000001
      [52]: 0x80911210 0x0040EAE8 0x00000010 0x004041D0
      [56]: 0x80911154 0x0040EB28 0x00400000 0x00000000
      Signed-off-by: NBartosz Markowski <bartosz.markowski@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      7cfe0455
  12. 01 12月, 2016 1 次提交
    • M
      ath10k: fix soft lockup during firmware crash/hw-restart · c2cac2f7
      Mohammed Shafi Shajakhan 提交于
      During firmware crash (or) user requested manual restart
      the system gets into a soft lock up state because of the
      below root cause.
      
      During user requested hardware restart / firmware crash
      the system goes into a soft lockup state as 'napi_synchronize'
      is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
      bit) and it sleeps into infinite loop as it waits for
      'NAPI_STATE_SCHED' to be cleared. This condition is hit because
      'ath10k_hif_stop' is called twice as below (resulting in calling
      'napi_synchronize' after 'napi_disable')
      
      'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
      -> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
      'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)
      
      Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
      as it makes more sense before informing mac80211 to restart h/w
      Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'
      
      Fixes: 3c97f5de ("ath10k: implement NAPI support")
      Cc: <stable@vger.kernel.org> # v4.9
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      c2cac2f7
  13. 24 11月, 2016 1 次提交
  14. 23 11月, 2016 3 次提交
  15. 15 11月, 2016 1 次提交
  16. 19 10月, 2016 1 次提交
  17. 13 10月, 2016 1 次提交
    • V
      ath10k: fix kernel panic due to race in accessing arvif list · ebaa4b16
      Vasanthakumar Thiagarajan 提交于
      arvifs list is traversed within data_lock spin_lock in tasklet
      context to fill channel information from the corresponding vif.
      This means any access to arvifs list for add/del operations
      should also be protected with the same spin_lock to avoid the
      race. Fix this by performing list add/del on arvfis within the
      data_lock. This could fix kernel panic something like the below.
      
       LR is at ath10k_htt_rx_pktlog_completion_handler+0x100/0xb6c [ath10k_core]
       PC is at ath10k_htt_rx_pktlog_completion_handler+0x1c0/0xb6c [ath10k_core]
       Internal error: Oops: 17 [#1] PREEMPT SMP ARM
       [<bf4857f4>] (ath10k_htt_rx_pktlog_completion_handler+0x2f4/0xb6c [ath10k_core])
       [<bf487540>] (ath10k_htt_txrx_compl_task+0x8b4/0x1188 [ath10k_core])
       [<c00312d4>] (tasklet_action+0x8c/0xec)
       [<c00309a8>] (__do_softirq+0xdc/0x208)
       [<c0030d6c>] (irq_exit+0x84/0xe0)
       [<c005db04>] (__handle_domain_irq+0x80/0xa0)
       [<c00085c4>] (gic_handle_irq+0x38/0x5c)
       [<c0009640>] (__irq_svc+0x40/0x74)
      
      (gdb) list *(ath10k_htt_rx_pktlog_completion_handler+0x1c0)
      0x136c0 is in ath10k_htt_rx_h_channel (drivers/net/wireless/ath/ath10k/htt_rx.c:769)
      764		struct cfg80211_chan_def def;
      765
      766		lockdep_assert_held(&ar->data_lock);
      767
      768		list_for_each_entry(arvif, &ar->arvifs, list) {
      769			if (arvif->vdev_id == vdev_id &&
      770			    ath10k_mac_vif_chan(arvif->vif, &def) == 0)
      771				return def.chan;
      772		}
      773
      Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      ebaa4b16
  18. 04 10月, 2016 2 次提交
    • B
      ath10k: allow setting coverage class · ebee76f7
      Benjamin Berg 提交于
      Unfortunately ath10k does not generally allow modifying the coverage class
      with the stock firmware and Qualcomm has so far refused to implement this
      feature so that it can be properly supported in ath10k. If we however know
      the registers that need to be modified for proper operation with a higher
      coverage class, then we can do these modifications from the driver.
      
      This is a hack and might cause subtle problems but as it's not enabled by
      default (only when user space changes the coverage class explicitly) it should
      not cause new problems for existing setups. But still this should be considered
      as an experimental feature and used with caution.
      
      This patch implements the support for first generation cards (QCA9880, QCA9887
      and so on) which are based on a core that is similar to ath9k. The registers
      are modified in place and need to be re-written every time the firmware sets
      them. To achieve this the register status is verified after certain WMI events
      from the firmware.
      
      The coverage class may not be modified temporarily right after the card
      re-initializes the registers. This is for example the case during scanning.
      
      Thanks to Sebastian Gottschall <s.gottschall@dd-wrt.com> for initially
      working on a userspace support for this. This patch wouldn't have been
      possible without this documentation.
      Signed-off-by: NBenjamin Berg <benjamin@sipsolutions.net>
      Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      ebee76f7
    • B
      ath10k: add platform regulatory domain support · 209b2a68
      Bartosz Markowski 提交于
      This overrides whatever regulatory the device
      EEPROM contains and uses what the platform says
      instead - in this implementation the ACPI driver.
      
      In case the hint is not programmed or corrupted (0xffff)
      the device falls back to the eeprom programmed settings.
      Signed-off-by: NBartosz Markowski <bartosz.markowski@tieto.com>
      [kvalo@qca.qualcomm.com: remove ifdef, change error handling, change info messages to dbg]
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      209b2a68
  19. 27 9月, 2016 1 次提交
  20. 13 9月, 2016 1 次提交
  21. 09 9月, 2016 1 次提交
  22. 03 9月, 2016 1 次提交
  23. 02 9月, 2016 5 次提交
    • M
      ath10k: Fix broken NULL func data frame status for 10.4 · 2cdce425
      Mohammed Shafi Shajakhan 提交于
      Older firmware with HTT delivers incorrect tx status for null func
      frames to driver, but this fixed in 10.2 and 10.4 firmware versions.
      Also this workaround results in reporting of incorrect null func status
      for 10.4. Fix this is by introducing a firmware feature flag for 10.4
      so that this workaround is skipped and proper tx status for null func
      frames are reported
      Signed-off-by: NTamizh chelvam <c_traja@qti.qualcomm.com>
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      2cdce425
    • D
      ath10k: use complete() instead complete_all() · 881ed54e
      Daniel Wagner 提交于
      There is only one waiter for the completion, therefore there
      is no need to use complete_all(). Let's make that clear by
      using complete() instead of complete_all().
      
      The usage pattern of the completion is:
      
      waiter context                          waker context
      
      scan.started
      ------------
      
      ath10k_start_scan()
        lockdep_assert_held(conf_mutex)
        auth10k_wmi_start_scan()
        wait_for_completion_timeout(scan.started)
      
      					ath10k_wmi_event_scan_start_failed()
      					  complete(scan.started)
      
      					ath10k_wmi_event_scan_started()
      					  complete(scan.started)
      
      scan.completed
      --------------
      
      ath10k_scan_stop()
        lockdep_assert_held(conf_mutex)
        ath10k_wmi_stop_scan()
        wait_for_completion_timeout(scan.completed)
      
      					__ath10k_scan_finish()
      					  complete(scan.completed)
      
      scan.on_channel
      ---------------
      
      ath10k_remain_on_channel()
        mutex_lock(conf_mutex)
        ath10k_start_scan()
        wait_for_completion_timeout(scan.on_channel)
      
      					ath10k_wmi_event_scan_foreign_chan()
      					  complete(scan.on_channel)
      
      offchan_tx_completed
      --------------------
      
      ath10k_offchan_tx_work()
        mutex_lock(conf_mutex)
        reinit_completion(offchan_tx_completed)
        wait_for_completion_timeout(offchan_tx_completed)
      
      					ath10k_report_offchain_tx()
      					  complete(offchan_tx_completed)
      
      install_key_done
      ----------------
      ath10k_install_key()
        lockep_assert_held(conf_mutex)
        reinit_completion(install_key_done)
        wait_for_completion_timeout(install_key_done)
      
      				        ath10k_htt_t2h_msg_handler()
      					  complete(install_key_done)
      
      vdev_setup_done
      ---------------
      
      ath10k_monitor_vdev_start()
        lockdep_assert_held(conf_mutex)
         reinit_completion(vdev_setup_done)
        ath10k_vdev_setup_sync()
          wait_for_completion_timeout(vdev_setup_done)
      
      					ath10k_wmi_event_vdev_start_resp()
      					  complete(vdev_setup_done)
      
      ath10k_monitor_vdev_stop()
        lockdep_assert_held(conf_mutex)
        reinit_completion(vdev_setup_done()
        ath10k_vdev_setup_sync()
          wait_for_completion_timeout(vdev_setup_done)
      
      					ath10k_wmi_event_vdev_stopped()
      					 complete(vdev_setup_done)
      
      thermal.wmi_sync
      ----------------
      ath10k_thermal_show_temp()
        mutex_lock(conf_mutex)
        reinit_completion(thermal.wmi_sync)
        wait_for_completion_timeout(thermal.wmi_sync)
      
      					ath10k_thermal_event_temperature()
      					  complete(thermal.wmi_sync)
      
      bss_survey_done
      ---------------
      ath10k_mac_update_bss_chan_survey
        lockdep_assert_held(conf_mutex)
        reinit_completion(bss_survey_done)
        wait_for_completion_timeout(bss_survey_done)
      
      					ath10k_wmi_event_pdev_bss_chan_info()
      					  complete(bss_survey_done)
      
      All complete() calls happen while the conf_mutex is taken. That means
      at max one waiter is possible.
      Signed-off-by: NDaniel Wagner <daniel.wagner@bmw-carit.de>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      881ed54e
    • A
      ath10k: fix sending frame in management path in push txq logic · e4fd726f
      Ashok Raj Nagarajan 提交于
      In the wake tx queue path, we are not checking if the frame to be sent
      takes management path or not. For eg. QOS null func frame coming here will
      take the management path. Since we are not incrementing the descriptor
      counter (num_pending_mgmt_tx) w.r.t tx management, on tx completion it is
      possible to see negative values.
      
      When the above counter reaches a negative value, we will not be sending a
      probe response out.
      
          if (is_presp &&
      	ar->hw_params.max_probe_resp_desc_thres < htt->num_pending_mgmt_tx)
      
      For IPQ4019, max_probe_resp_desc_thres (u32) is 24 is compared against
      num_pending_mgmt_tx (int) and the above condtions comes true if the counter
      is negative and we drop the probe response.
      
      To avoid this, check on the wake tx queue path as well for the tx path of
      the frame and increment the appropriate counters
      
      Fixes: cac08552 "ath10k: move mgmt descriptor limit handle under mgmt_tx"
      Signed-off-by: NAshok Raj Nagarajan <arnagara@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      e4fd726f
    • R
      ath10k: improve wake_tx_queue ops performance · 83e164b7
      Rajkumar Manoharan 提交于
      txqs_lock is interfering with wake_tx_queue submitting more frames.
      so queues don't get filled in and don't keep firmware/hardware busy
      enough. This change helps to reduce the txqs_lock contention and
      wake_tx_queue() blockage to being possible in txrx_unref().
      
      To reduce turn around time of wake_tx_queue ops and to maintain fairness
      among all txqs, the callback is updated to push first txq alone from
      pending list for every wake_tx_queue call. Remaining txqs will be
      processed later upon tx completion.
      
      Below improvements are observed in push-only mode and validated on
      IPQ4019 platform. With this change, in AP mode ~10Mbps increase is
      observed in downlink (AP -> STA) traffic and approx. 5-10% of CPU
      usage is reduced.
      
      Major improvement is observed in 1-hop Mesh mode topology in 11ACVHT80.
      Compared to Infra mode, CPU overhead is higher in Mesh mode due to path
      lookup and no fast-xmit support. So reducing spin lock contention is
      helping in Mesh.
      
                   TOT       +change
                 --------    --------
      TCP DL     545 Mbps    595 Mbps
      TCP UL     555 Mbps    585 Mbps
      Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      83e164b7
    • M
      ath10k: hide kernel addresses from logs using %pK format specifier · 75b34800
      Maharaja Kennadyrajan 提交于
      With the %pK format specifier we hide the kernel addresses
      with the help of kptr_restrict sysctl.
      In this patch, %p is changed to %pK in the driver code.
      
      The sysctl is documented in Documentation/sysctl/kernel.txt.
      Signed-off-by: NMaharaja Kennadyrajan <c_mkenna@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      75b34800
  24. 04 8月, 2016 1 次提交
    • M
      tree-wide: replace config_enabled() with IS_ENABLED() · 97f2645f
      Masahiro Yamada 提交于
      The use of config_enabled() against config options is ambiguous.  In
      practical terms, config_enabled() is equivalent to IS_BUILTIN(), but the
      author might have used it for the meaning of IS_ENABLED().  Using
      IS_ENABLED(), IS_BUILTIN(), IS_MODULE() etc.  makes the intention
      clearer.
      
      This commit replaces config_enabled() with IS_ENABLED() where possible.
      This commit is only touching bool config options.
      
      I noticed two cases where config_enabled() is used against a tristate
      option:
      
       - config_enabled(CONFIG_HWMON)
        [ drivers/net/wireless/ath/ath10k/thermal.c ]
      
       - config_enabled(CONFIG_BACKLIGHT_CLASS_DEVICE)
        [ drivers/gpu/drm/gma500/opregion.c ]
      
      I did not touch them because they should be converted to IS_BUILTIN()
      in order to keep the logic, but I was not sure it was the authors'
      intention.
      
      Link: http://lkml.kernel.org/r/1465215656-20569-1-git-send-email-yamada.masahiro@socionext.comSigned-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Cc: Stas Sergeev <stsp@list.ru>
      Cc: Matt Redfearn <matt.redfearn@imgtec.com>
      Cc: Joshua Kinard <kumba@gentoo.org>
      Cc: Jiri Slaby <jslaby@suse.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: "Dmitry V. Levin" <ldv@altlinux.org>
      Cc: yu-cheng yu <yu-cheng.yu@intel.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Will Drewry <wad@chromium.org>
      Cc: Nikolay Martynov <mar.kolya@gmail.com>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
      Cc: Rafal Milecki <zajec5@gmail.com>
      Cc: James Cowgill <James.Cowgill@imgtec.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Alex Smith <alex.smith@imgtec.com>
      Cc: Adam Buchbinder <adam.buchbinder@gmail.com>
      Cc: Qais Yousef <qais.yousef@imgtec.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Mikko Rapeli <mikko.rapeli@iki.fi>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Brian Norris <computersforpeace@gmail.com>
      Cc: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Roland McGrath <roland@hack.frob.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Kalle Valo <kvalo@qca.qualcomm.com>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: Tony Wu <tung7970@gmail.com>
      Cc: Huaitong Han <huaitong.han@intel.com>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Andrea Gelmini <andrea.gelmini@gelma.net>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Rabin Vincent <rabin@rab.in>
      Cc: "Maciej W. Rozycki" <macro@imgtec.com>
      Cc: David Daney <david.daney@cavium.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      97f2645f
  25. 19 7月, 2016 1 次提交
  26. 08 7月, 2016 1 次提交