1. 23 Nov, 2015 2 commits
  2. 16 Nov, 2015 2 commits
    • Vladimir Kondratiev's avatar
      wil6210: hold wil->mutex while managing vrings · 9b1ba7b2
      Vladimir Kondratiev authored
      To prevent race when connect flow may run in parallel with
      the disconnect event.
      
      Scenario leading to the bug is: while running connect flow on the AP,
      STA sends disconnect. log follows.
      
      <7>[  668.736269] wil6210 0000:01:00.0: wlan0: DBG[ WMI]Configure for connection CID 1
      <7>[  668.736269] wil6210 0000:01:00.0: wlan0: DBG[MISC]wil_vring_init_tx() max_mpdu_size 2048
      <7>[  668.736301] wil6210 0000:01:00.0: wlan0: DBG[MISC]wil_vring_alloc()
      <7>[  668.736363] wil6210 0000:01:00.0: wlan0: DBG[MISC]vring[1024] 0xffbe8000:d962ce08 0xdb244000
      <7>[  668.736394] wil6210 0000:01:00.0: wlan0: DBG[ WMI]Head 0x00880300 -> 0x00880308
      <7>[  668.736394] wil6210 0000:01:00.0: wlan0: DBG[ WMI]WMI command 0x0821 [28]
      <7>[  668.736426] DBG[ WMI]Cmd 00000000: 20 00 24 00 00 00 00 00 00 00 21 08 00 00 00 00   .$.......!.....
      <7>[  668.736426] DBG[ WMI]cmd 00000000: 00 00 00 00 00 00 5f 5c 00 00 00 00 00 04 00 08  ......_\........
      <7>[  668.736457] DBG[ WMI]cmd 00000010: 01 01 00 00 00 00 00 00 00 00 ff 0f              ............
      <7>[  668.736488] wil6210 0000:01:00.0: wlan0: DBG[ IRQ]Pseudo IRQ 0x00000004
      <7>[  668.736519] wil6210 0000:01:00.0: wlan0: DBG[ WMI]Handle WMI 0x1824 (reply_id 0x1821)
      <7>[  668.736519] wil6210 0000:01:00.0: wlan0: DBG[ IRQ]wil6210_mask_irq_pseudo()
      <7>[  668.736519] wil6210 0000:01:00.0: wlan0: DBG[ IRQ]ISR MISC 0x20000000
      <7>[  668.736551] wil6210 0000:01:00.0: wlan0: DBG[ WMI]Handle WMI 0x1003 (reply_id 0x1821)
      <7>[  668.736551] wil6210 0000:01:00.0: wlan0: DBG[ WMI]Disconnect 04:ce:14:00:07:70 reason [proto 3 wmi 4]
      <7>[  668.736582] wil6210 0000:01:00.0: wlan0: DBG[MISC]wil6210_disconnect()
      <7>[  668.736613] wil6210 0000:01:00.0: wlan0: DBG[ IRQ]Thread IRQ
      <7>[  668.736613] wil6210 0000:01:00.0: wlan0: DBG[ IRQ]Thread ISR MISC 0x20000000
      <7>[  668.736644] wil6210 0000:01:00.0: wlan0: DBG[ IRQ]MBOX event
      <7>[  668.736644] wil6210 0000:01:00.0: wlan0: DBG[ WMI]Mbox head 00880330 tail 00880328
      <7>[  668.736676] wil6210 0000:01:00.0: wlan0: DBG[ WMI]Mbox evt 001a 0010 0000 00
      <7>[  668.736676] wil6210 0000:01:00.0: wlan0: DBG[ WMI]WMI event 0x1821 MID 0 @3255145 msec
      <7>[  668.736707] DBG[ WMI]evt 00000000: 1a 00 10 00 00 00 00 10 00 00 21 18 69 ab 31 00  ..........!.i.1.
      <7>[  668.736707] DBG[ WMI]evt 00000010: 01 01 00 00 00 00 00 00                          ........
      <7>[  668.736738] wil6210 0000:01:00.0: wlan0: DBG[ WMI]queue_work -> 0
      <7>[  668.736738] wil6210 0000:01:00.0: wlan0: DBG[ WMI]wmi_recv_cmd -> 1 events queued
      <7>[  668.736769] wil6210 0000:01:00.0: wlan0: DBG[ IRQ]wil6210_unmask_irq_pseudo()
      <7>[  668.736832] wil6210 0000:01:00.0: wlan0: DBG[MISC]Disconnect 04:ce:14:00:07:70, CID=1, reason=3
      <7>[  668.736832] wil6210 0000:01:00.0: wlan0: DBG[MISC]wil_disconnect_cid(CID 1, status 1)
      <7>[  668.736894] wil6210 0000:01:00.0: wlan0: DBG[MISC]wil_vring_fini_tx() id=1
      <7>[  668.736894] wil6210 0000:01:00.0: wlan0: DBG[MISC]free Tx vring 1 [1024] 0xffbe8000:d962ce08 0xdb244000
      <7>[  668.736957] wil6210 0000:01:00.0: wlan0: DBG[ WMI]Handle WMI 0x1821 (reply_id 0x1821)
      <7>[  668.736988] wil6210 0000:01:00.0: wlan0: DBG[ WMI]Complete WMI 0x1821
      <7>[  668.737019] wil6210 0000:01:00.0: wlan0: DBG[ WMI]wmi_call(0x0821->0x1821) completed in 0 msec
      <3>[  668.737019] wil6210 0000:01:00.0: wlan0: Tx config failed, status 0x01
      <7>[  668.739518] wil6210 0000:01:00.0: wlan0: DBG[MISC]wil_cfg80211_del_station(04:ce:14:00:07:70, reason=2)
      <7>[  668.739550] wil6210 0000:01:00.0: wlan0: DBG[MISC]wil6210_disconnect()
      <7>[  668.739550] wil6210 0000:01:00.0: wlan0: DBG[MISC]_wil6210_disconnect(bssid=04:ce:14:00:07:70, reason=2, ev-)
      <7>[  668.739581] wil6210 0000:01:00.0: wlan0: DBG[MISC]Disconnect 04:ce:14:00:07:70, CID=-2, reason=2
      <7>[  668.742705] wil6210 0000:01:00.0: wlan0: DBG[MISC]free Tx vring 1 [1024] 0x  (null):d962ce08 0x  (null)
      <3>[  668.742736] __dma_free_remap: trying to free invalid coherent area:   (null)
      Signed-off-by: default avatarVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
      Signed-off-by: default avatarMaya Erez <qca_merez@qca.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      9b1ba7b2
    • Yanbo Li's avatar
      ath10k: fix the wrong RX rate idx report at 11G mode · 4b7f353b
      Yanbo Li authored
      The RX rate idx is not correct for 11G mode OFDM packet.
      Because the bitrate table start with CCK index instead of OFDM.
      Signed-off-by: default avatarYanbo Li <yanbol@qca.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      4b7f353b
  3. 12 Nov, 2015 3 commits
  4. 04 Nov, 2015 9 commits
  5. 29 Oct, 2015 20 commits
  6. 28 Oct, 2015 4 commits
    • Maharaja's avatar
      ath10k: enable adaptive CCA · 62f77f09
      Maharaja authored
      European Union has made it mandatory that all devices working in 2.4 GHz
      has to adhere to the ETSI specification (ETSI EN 300 328 V1.9.1)
      beginnig this year. The standard basically speaks about interferences
      in 2.4Ghz band.
      For example, when 802.11 device detects interference, TX must be stopped
      as long as interference is present.
      
      Adaptive CCA is a feature, when enabled the device learns from the
      environment and configures CCA levels adaptively. This will improve
      detecting interferences and the device can stop trasmissions till the
      interference is present eventually leading to good performances in
      varying interference conditions.
      
      The patch includes code for enabling adaptive CCA for 10.2.4 firmware on
      QCA988X.
      Signed-off-by: default avatarMaharaja <c_mkenna@qti.qualcomm.com>
      Signed-off-by: default avatarManikanta Pubbisetty <c_mpubbi@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      62f77f09
    • Rafał Miłecki's avatar
      ssb: add Kconfig entry for compiling SoC related code · 845da6e5
      Rafał Miłecki authored
      This allows saving a little of space when not using ssb on Broadcom SoC.
      Signed-off-by: default avatarRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      845da6e5
    • Rafał Miłecki's avatar
      ssb: move functions specific to SoC hosted bus to separated file · 830c7df4
      Rafał Miłecki authored
      This cleans main.c a bit and will allow us to compile SoC related code
      conditionally in the future.
      Signed-off-by: default avatarRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      830c7df4
    • Rafał Miłecki's avatar
      ssb: pick PCMCIA host code support from b43 driver · 399500da
      Rafał Miłecki authored
      ssb bus can be found on various "host" devices like PCI/PCMCIA/SDIO.
      Every ssb bus contains cores AKA devices.
      The main idea is to have ssb driver scan/initialize bus and register
      ready-to-use cores. This way ssb drivers can operate on a single core
      mostly ignoring underlaying details.
      
      For some reason PCMCIA support was split between ssb and b43. We got
      PCMCIA host device probing in b43, then bus scanning in ssb and then
      wireless core probing back in b43. The truth is it's very unlikely we
      will ever see PCMCIA ssb device with no 802.11 core but I still don't
      see any advantage of the current architecture.
      
      With proposed change we get the same functionality with a simpler
      architecture, less Kconfig symbols, one killed EXPORT and hopefully
      cleaner b43. Since b43 supports both: ssb & bcma I prefer to keep ssb
      specific code in ssb driver.
      
      This mostly moves code from b43's pcmcia.c to bridge_pcmcia_80211.c. We
      already use similar solution with b43_pci_bridge.c. I didn't use "b43"
      in name of this new file as in theory any driver can operate on wireless
      core.
      Signed-off-by: default avatarRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      399500da