1. 30 12月, 2016 4 次提交
    • 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
    • A
      ath10k: support dev_coredump for crash dump · 727000e6
      Arun Khandavalli 提交于
      Whenever firmware crashes, and both CONFIG_ATH10K_DEBUGFS and
      CONFIG_ALLOW_DEV_COREDUMP are enabled, dump information about the crash via a
      devcoredump device. Dump can be read from userspace for further analysis from:
      
      /sys/class/devcoredump/devcd*/data
      
      As until now we have provided the firmware crash dump file via fw_crash_dump
      debugfs keep it still available but deprecate and a warning print that the user
      should switch to using dev_coredump.
      
      Future improvement would be not to depend on CONFIG_ATH10K_DEBUGFS, as there
      might be systems which want to get the firmware crash dump but not enable
      debugfs. How to handle memory consumption is also something which needs to be
      taken into account.
      Signed-off-by: NArun Khandavalli <akhandav@qti.qualcomm.com>
      [kvalo@qca.qualcomm.com: rebase, fixes, improve commit log]
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      727000e6
    • 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
    • C
      ath10k: fix potential memory leak in ath10k_wmi_tlv_op_pull_fw_stats() · 097e46d2
      Christian Lamparter 提交于
      ath10k_wmi_tlv_op_pull_fw_stats() uses tb = ath10k_wmi_tlv_parse_alloc(...)
      function, which allocates memory. If any of the three error-paths are
      taken, this tb needs to be freed.
      Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      097e46d2
  2. 29 12月, 2016 5 次提交
  3. 15 12月, 2016 10 次提交
    • M
      ath10k: Avoid potential page alloc BUG_ON in tx free path · 02a9e08d
      Mohammed Shafi Shajakhan 提交于
      'ath10k_htt_tx_free_cont_txbuf' and 'ath10k_htt_tx_free_cont_frag_desc'
      have NULL pointer checks to avoid crash if they are called twice
      but this is as of now not sufficient as these pointers are not assigned
      to NULL once the contiguous DMA memory allocation is freed, fix this.
      Though this may not be hit with the explicity check of state variable
      'tx_mem_allocated' check, good to have this addressed as well.
      
      Below BUG_ON is hit when the above scenario is simulated
      with kernel debugging enabled
      
       page:f6d09a00 count:0 mapcount:-127 mapping:  (null)
      index:0x0
       flags: 0x40000000()
       page dumped because: VM_BUG_ON_PAGE(page_ref_count(page)
      == 0)
       ------------[ cut here ]------------
       kernel BUG at ./include/linux/mm.h:445!
       invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
       EIP is at put_page_testzero.part.88+0xd/0xf
       Call Trace:
        [<c118a2cc>] __free_pages+0x3c/0x40
        [<c118a30e>] free_pages+0x3e/0x50
        [<c10222b4>] dma_generic_free_coherent+0x24/0x30
        [<f8c1d9a8>] ath10k_htt_tx_free_cont_txbuf+0xf8/0x140
      
        [<f8c1e2a9>] ath10k_htt_tx_destroy+0x29/0xa0
      
        [<f8c143e0>] ath10k_core_destroy+0x60/0x80 [ath10k_core]
        [<f8acd7e9>] ath10k_pci_remove+0x79/0xa0 [ath10k_pci]
        [<c13ed7a8>] pci_device_remove+0x38/0xb0
        [<c14d3492>] __device_release_driver+0x72/0x100
        [<c14d36b7>] driver_detach+0x97/0xa0
        [<c14d29c0>] bus_remove_driver+0x40/0x80
        [<c14d427a>] driver_unregister+0x2a/0x60
        [<c13ec768>] pci_unregister_driver+0x18/0x70
        [<f8aced4f>] ath10k_pci_exit+0xd/0x2be [ath10k_pci]
        [<c1101e78>] SyS_delete_module+0x158/0x210
        [<c11b34f1>] ? __might_fault+0x41/0xa0
        [<c11b353b>] ? __might_fault+0x8b/0xa0
        [<c1001a4b>] do_fast_syscall_32+0x9b/0x1c0
        [<c178da34>] sysenter_past_esp+0x45/0x74
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      02a9e08d
    • T
      ath9k: Turn ath_txq_lock/unlock() into static inlines. · 5c4607eb
      Toke Høiland-Jørgensen 提交于
      These are one-line functions that just call spin_lock/unlock_bh(); turn
      them into static inlines to avoid the function call overhead.
      Signed-off-by: NToke Høiland-Jørgensen <toke@toke.dk>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      5c4607eb
    • T
      ath9k: Introduce airtime fairness scheduling between stations · 63fefa05
      Toke Høiland-Jørgensen 提交于
      This reworks the ath9k driver to schedule transmissions to connected
      stations in a way that enforces airtime fairness between them. It
      accomplishes this by measuring the time spent transmitting to or
      receiving from a station at TX and RX completion, and accounting this to
      a per-station, per-QoS level airtime deficit. Then, an FQ-CoDel based
      deficit scheduler is employed at packet dequeue time, to control which
      station gets the next transmission opportunity.
      
      Airtime fairness can significantly improve the efficiency of the network
      when station rates vary. The following throughput values are from a
      simple three-station test scenario, where two stations operate at the
      highest HT20 rate, and one station at the lowest, and the scheduler is
      employed at the access point:
      
                        Before   /   After
      Fast station 1:    19.17   /   25.09 Mbps
      Fast station 2:    19.83   /   25.21 Mbps
      Slow station:       2.58   /    1.77 Mbps
      Total:             41.58   /   52.07 Mbps
      
      The benefit of airtime fairness goes up the more stations are present.
      In a 30-station test with one station artificially limited to 1 Mbps,
      we have seen aggregate throughput go from 2.14 to 17.76 Mbps.
      Signed-off-by: NToke Høiland-Jørgensen <toke@toke.dk>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      63fefa05
    • M
      ath9k: define all EEPROM fields in Little Endian format · 4bca5303
      Martin Blumenstingl 提交于
      The ar9300_eeprom logic is already using only 8-bit (endian neutral),
      __le16 and __le32 fields to state explicitly how the values should be
      interpreted.
      All other EEPROM implementations (4k, 9287 and def) were using u16 and
      u32 fields with additional logic to swap the values (read from the
      original EEPROM) so they match the current CPUs endianness.
      
      The EEPROM format defaults to "all values are Little Endian", indicated
      by the absence of the AR5416_EEPMISC_BIG_ENDIAN in the u8 EEPMISC
      register. If we detect that the EEPROM indicates Big Endian mode
      (AR5416_EEPMISC_BIG_ENDIAN is set in the EEPMISC register) then we'll
      swap the values to convert them into Little Endian. This is done by
      activating the EEPMISC based logic in ath9k_hw_nvram_swap_data even if
      AH_NO_EEP_SWAP is set (this makes ath9k behave like the FreeBSD driver,
      which also does not have a flag to enable swapping based on the
      AR5416_EEPMISC_BIG_ENDIAN bit). Before this logic was only used to
      enable swapping when "current CPU endianness != EEPROM endianness".
      
      After changing all relevant fields to __le16 and __le32 sparse was used
      to check that all code which reads any of these fields uses
      le{16,32}_to_cpu.
      Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      4bca5303
    • M
      ath9k: Make the EEPROM swapping check use the eepmisc register · 68fbe792
      Martin Blumenstingl 提交于
      There are two ways of swapping the EEPROM data in the ath9k driver:
      1) swab16 based on the first two EEPROM "magic" bytes (same for all
         EEPROM formats)
      2) field and EEPROM format specific swab16/swab32 (different for
         eeprom_def, eeprom_4k and eeprom_9287)
      
      The result of the first check was used to also enable the second swap.
      This behavior seems incorrect, since the data may only be byte-swapped
      (afterwards the data could be in the correct endianness).
      Thus we introduce a separate check based on the "eepmisc" register
      (which is part of the EEPROM data). When bit 0 is set, then the EEPROM
      format specific values are in "big endian". This is also done by the
      FreeBSD kernel, see [0] for example.
      
      This allows us to parse EEPROMs with the "correct" magic bytes but
      swapped EEPROM format specific values. These EEPROMs (mostly found in
      lantiq and broadcom based big endian MIPS based devices) only worked
      due to platform specific "hacks" which swapped the EEPROM so the
      magic was inverted, which also enabled the format specific swapping.
      With this patch the old behavior is still supported, but neither
      recommended nor needed anymore.
      
      [0]
      https://github.com/freebsd/freebsd/blob/50719b56d9ce8d7d4beb53b16e9edb2e9a4a7a18/sys/dev/ath/ath_hal/ah_eeprom_9287.c#L351Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      68fbe792
    • M
      ath9k: consistently use get_eeprom_rev(ah) · 9bff7428
      Martin Blumenstingl 提交于
      The AR5416_VER_MASK macro does the same as get_eeprom_rev, except that
      one has to know the actual EEPROM type (and providing a reference to
      that in a variable named "eep"). Additionally the eeprom_*.c
      implementations used the same shifting logic multiple times to get the
      eeprom revision which was also unnecessary duplication of
      get_eeprom_rev.
      
      Also use the AR5416_EEP_VER_MINOR_MASK macro where needed and introduce
      a similar macro (AR5416_EEP_VER_MAJOR_MASK) for the major version.
      Finally drop AR9287_EEP_VER_MINOR_MASK since it simply duplicates the
      already defined AR5416_EEP_VER_MINOR_MASK.
      Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      9bff7428
    • M
      ath9k: replace eeprom_param EEP_MINOR_REV with get_eeprom_rev · 7d7dc538
      Martin Blumenstingl 提交于
      get_eeprom(ah, EEP_MINOR_REV) and get_eeprom_rev(ah) are both doing the
      same thing: returning the EEPROM revision (12 lowest bits). Make the
      code consistent by using get_eeprom_rev(ah) everywhere.
      Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      7d7dc538
    • M
      ath9k: Add an eeprom_ops callback for retrieving the eepmisc value · d8ec2e2a
      Martin Blumenstingl 提交于
      This allows deciding if we have to swap the EEPROM data (so it matches
      the system's native endianness) even if no byte-swapping (swab16, based on
      the first two bytes in the EEPROM) is needed.
      Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      d8ec2e2a
    • M
      ath9k: indicate that the AR9003 EEPROM template values are little endian · 291478b7
      Martin Blumenstingl 提交于
      The eepMisc field was not set explicitly. The default value of 0 means
      that the values in the EEPROM (template) should be interpreted as little
      endian. However, this is not clear until comparing the AR9003 code with
      the other EEPROM formats.
      To make the code easier to understand we explicitly state that the values
      are little endian - there are no functional changes with this patch.
      Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      291478b7
    • M
      ath9k: Add a #define for the EEPROM "eepmisc" endianness bit · 81a834e3
      Martin Blumenstingl 提交于
      This replaces a magic number with a named #define. Additionally it
      removes two "eeprom format" specific #defines for the "big endianness"
      bit which are the same on all eeprom formats.
      Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      81a834e3
  4. 01 12月, 2016 12 次提交
    • G
      ath5k: drop duplicate header vmalloc.h · 384abd33
      Geliang Tang 提交于
      Drop duplicate header vmalloc.h from ath5k/debug.c.
      Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      384abd33
    • L
      wil6210: align to latest auto generated wmi.h · 8ae5d62c
      Lior David 提交于
      Align to latest version of the auto generated wmi file
      describing the interface with FW.
      Signed-off-by: NLior David <qca_liord@qca.qualcomm.com>
      Signed-off-by: NMaya Erez <qca_merez@qca.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      8ae5d62c
    • L
      wil6210: add debugfs blobs for UCODE code and data · 61578820
      Lior David 提交于
      Added new areas to fw_mappings area for UCODE code
      and data areas.
      The new areas are only exposed through debugfs blobs,
      and mainly needed to access UCODE logs.
      The change does not affect crash dumps because the
      newly added areas overlap with the "upper" area which
      is already dumped.
      Signed-off-by: NLior David <qca_liord@qca.qualcomm.com>
      Signed-off-by: NMaya Erez <qca_merez@qca.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      61578820
    • M
      wil6210: validate wil_pmc_alloc parameters · 1db226ff
      Maya Erez 提交于
      num_descriptors and descriptor_size needs to be
      checked for:
      1) not being negative values
      2) no overflow occurs when these are multiplied
      together as done in wil_pmc_read.
      An overflow of two signed integers is undefined
      behavior.
      Signed-off-by: NMaya Erez <qca_merez@qca.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      1db226ff
    • L
      wil6210: delay remain on channel when scan is active · bb6743f7
      Lior David 提交于
      Currently it was possible to call remain_on_channel(ROC)
      while scan was active and this caused a crash in the FW.
      In order to fix this problem and make the behavior
      consistent with other drivers, queue the ROC in case
      a scan is active and try it again when scan is done.
      As part of the fix, clean up some locking issues and
      return error if scan is called while ROC is active.
      Signed-off-by: NLior David <qca_liord@qca.qualcomm.com>
      Signed-off-by: NMaya Erez <qca_merez@qca.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      bb6743f7
    • A
      ath9k_htc: don't use HZ for usb msg timeouts · 982a6151
      Anthony Romano 提交于
      The usb_*_msg() functions expect a timeout in msecs but are given HZ,
      which is ticks per second. If HZ=100, firmware download often times out
      when there is modest USB utilization and the device fails to initialize.
      
      Replaces HZ in usb_*_msg timeouts with 1000 msec since HZ is one second
      for timeouts in jiffies.
      Signed-off-by: NAnthony Romano <anthony.romano@coreos.com>
      Acked-by: NOleksij Rempel <linux@rempel-privat.de>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      982a6151
    • B
      ath9k: constify ath_bus_ops structure · 8ca5a607
      Bhumika Goyal 提交于
      Declare the structure ath_bus_ops as const as it is only passed as an
      argument to the function ath9k_init_device. This argument is of type
      const struct ath_bus_ops *, so ath_bus_ops structures with this property
      can be declared as const.
      Done using Coccinelle:
      @r1 disable optional_qualifier @
      identifier i;
      position p;
      @@
      static struct ath_bus_ops i@p = {...};
      
      @ok1@
      identifier r1.i;
      position p;
      expression e1,e2;
      @@
      ath9k_init_device(e1,e2,&i@p)
      
      @bad@
      position p!={r1.p,ok1.p};
      identifier r1.i;
      @@
      i@p
      
      @depends on !bad disable optional_qualifier@
      identifier r1.i;
      @@
      static
      +const
      struct ath_bus_ops i={...};
      
      @depends on !bad disable optional_qualifier@
      identifier r1.i;
      @@
      +const
      struct ath_bus_ops i;
      
      File size before:
         text	   data	    bss	    dec	    hex	filename
         1295	    232	      0	   1527	    5f7	ath/ath9k/ahb.o
      
      File size after:
         text	   data	    bss	    dec	    hex	filename
         1359	    176	      0	   1535	    5ff	ath/ath9k/ahb.o
      Signed-off-by: NBhumika Goyal <bhumirks@gmail.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      8ca5a607
    • B
      ath10k: wmi-alloc-chunk should use DMA_BIDIRECTIONAL · 43ca92d3
      Ben Greear 提交于
      These memory chunks are often used as 'swap' by the NIC,
      so it will be both reading and writing to these areas.
      
      This seems to fix errors like this on my x86-64 machine:
      
      kernel: DMAR: DMAR:[DMA Write] Request device [05:00.0] fault addr ff5de000
              DMAR:[fault reason 05] PTE Write access is not set
      Tested-by: NMarek Behun <kabel@blackhole.sk>
      Signed-off-by: NBen Greear <greearb@candelatech.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      43ca92d3
    • M
      ath10k: fix Tx DMA alloc failure during continuous wifi down/up · 9ec34a86
      Mohammed Shafi Shajakhan 提交于
      With maximum number of vap's configured in a two radio supported
      systems of ~256 Mb RAM, doing a continuous wifi down/up and
      intermittent traffic streaming from the connected stations results
      in failure to allocate contiguous memory for tx buffers. This results
      in the disappearance of all VAP's and a manual reboot is needed as
      this is not a crash (or) OOM(for OOM killer to be invoked). To address
      this allocate contiguous memory for tx buffers one time and re-use them
      until the modules are unloaded but this results in a slight increase in
      memory footprint of ath10k when the wifi is down, but the modules are
      still loaded. Also as of now we use a separate bool 'tx_mem_allocated'
      to keep track of the one time memory allocation, as we cannot come up
      with something like 'ath10k_tx_{register,unregister}' before
      'ath10k_probe_fw' is called as 'ath10k_htt_tx_alloc_cont_frag_desc'
      memory allocation is dependent on the hw_param 'continuous_frag_desc'
      
      a) memory footprint of ath10k without the change
      
      lsmod | grep ath10k
      ath10k_core           414498  1 ath10k_pci
      ath10k_pci             38236  0
      
      b) memory footprint of ath10k with the change
      
      ath10k_core           414980  1 ath10k_pci
      ath10k_pci             38236  0
      
      Memory Failure Call trace:
      
      hostapd: page allocation failure: order:6, mode:0xd0
       [<c021f150>] (__dma_alloc_buffer.isra.23) from
      [<c021f23c>] (__alloc_remap_buffer.isra.26+0x14/0xb8)
      [<c021f23c>] (__alloc_remap_buffer.isra.26) from
      [<c021f664>] (__dma_alloc+0x224/0x2b8)
      [<c021f664>] (__dma_alloc) from [<c021f810>]
      (arm_dma_alloc+0x84/0x90)
      [<c021f810>] (arm_dma_alloc) from [<bf954764>]
      (ath10k_htt_tx_alloc+0xe0/0x2e4 [ath10k_core])
      [<bf954764>] (ath10k_htt_tx_alloc [ath10k_core]) from
      [<bf94e6ac>] (ath10k_core_start+0x538/0xcf8 [ath10k_core])
      [<bf94e6ac>] (ath10k_core_start [ath10k_core]) from
      [<bf947eec>] (ath10k_start+0xbc/0x56c [ath10k_core])
      [<bf947eec>] (ath10k_start [ath10k_core]) from
      [<bf8a7a04>] (drv_start+0x40/0x5c [mac80211])
      [<bf8a7a04>] (drv_start [mac80211]) from [<bf8b7cf8>]
      (ieee80211_do_open+0x170/0x82c [mac80211])
      [<bf8b7cf8>] (ieee80211_do_open [mac80211]) from
      [<c056afc8>] (__dev_open+0xa0/0xf4)
      [21053.491752] Normal: 641*4kB (UEMR) 505*8kB (UEMR) 330*16kB (UEMR)
      126*32kB (UEMR) 762*64kB (UEMR) 237*128kB (UEMR) 1*256kB (M) 0*512kB
      0*1024kB 0*2048kB 0*4096kB = 95276kB
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      9ec34a86
    • 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
    • E
      ath10k: fix TLV set regdomain command · 4e322f7d
      Erik Stromdahl 提交于
      There is a typo bug in the current implementation of
      ath10k_wmi_tlv_op_gen_pdev_set_rd.
      The conformance test limits are not set up properly.
      
      The two arguments ctl2g and ctl5g were not used at all.
      Instead, the regdomain arguments rd2g and rd5g were used
      for the ctl settings as well.
      Signed-off-by: NErik Stromdahl <erik.stromdahl@gmail.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      4e322f7d
    • Z
      ath9k: feed only active spectral / dfs-detector · 87fedb97
      Zefir Kurtisi 提交于
      Radar pulse and spectral scan reports are provided by the HW
      with the ATH9K_RXERR_PHY flag set. Those are forwarded to
      the dfs-detector and spectral module for further processing.
      
      For some older chips, the pre-conditions checked in those
      modules are ambiguous, since ATH9K_PHYERR_RADAR is used to
      tag both types. As a result, spectral frames are fed into
      the dfs-detector and vice versa.
      
      This could lead to a false radar detection on a non-DFS
      channel (which is uncritical), but more relevant it causes
      useless CPU load for processing invalid frames.
      
      This commit ensures that the dfs-detector and spectral
      collector are only fed when they are active.
      Signed-off-by: NZefir Kurtisi <zefir.kurtisi@neratec.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      87fedb97
  5. 24 11月, 2016 3 次提交
  6. 23 11月, 2016 6 次提交