1. 09 3月, 2017 3 次提交
    • D
      wil6210: store bss object and use cfg80211_connect_bss() · bcdd49b0
      Dedy Lansky 提交于
      In a fast disconnect/connect sequence, cfg80211_connect_result() can
      fail to find the bss object which the driver is connecting to. Detailed
      sequence of events:
      * Driver is connected in STA mode
      * Disconnect request arrives from user space. Driver disconnects and
        calls cfg80211_disconnected() which adds new event to the
        cfg80211_wq worker thread
      * Connect request arrives from user space. cfg80211_connect() stores
        ssid/ssid_len and calls rdev_connect()
      * __cfg80211_disconnected() runs in worker thread and zero
        wdev->ssid_len
      * Connect succeeds. Driver calls cfg80211_connect_result() which fails
        to find the bss because wdev->ssid_len is zero
      
      To overcome this, upon connect request, store the bss object in the
      driver and upon connect completion pass it to kernel using
      cfg80211_connect_bss().
      Signed-off-by: NDedy Lansky <qca_dlansky@qca.qualcomm.com>
      Signed-off-by: NMaya Erez <qca_merez@qca.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      bcdd49b0
    • M
      wil6210: missing reinit_completion in HALP voting · 18618a9f
      Maya Erez 提交于
      After setting HALP ICR bit, we keep it set until HALP unvote.
      Masking HALP ICR should protect the driver from hitting the HALP ICR
      over and over again. However, in case there is another MISC ICR
      we will read the HALP ICR and issue a completion. This can lead to
      a case where HALP voting is completed immediately, as the completion
      is already set.
      Reinit the HALP completion before the actual vote will clear previous
      completions and protect from such cases.
      Signed-off-by: NMaya Erez <qca_merez@qca.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      18618a9f
    • L
      wil6210: bus_request platform operation refinement · 9953a782
      Lior David 提交于
      The driver uses the bus_request platform operation to
      request resources from the platform for a specific bandwidth.
      Currently the driver requests resources for the maximum
      theoretical bandwidth, when interface is brought up.
      Refine this process a bit: now the driver will request a
      small amount of resources when interface is up, and will only
      issue the maximum request when connected.
      This mechanism will be improved further in the future to make
      more refined requests based on actual bandwidth.
      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>
      9953a782
  2. 28 1月, 2017 5 次提交
  3. 01 12月, 2016 1 次提交
  4. 23 11月, 2016 4 次提交
  5. 31 8月, 2016 3 次提交
  6. 19 8月, 2016 5 次提交
  7. 06 7月, 2016 1 次提交
    • A
      nl80211: support beacon report scanning · 1d76250b
      Avraham Stern 提交于
      Beacon report radio measurement requires reporting observed BSSs
      on the channels specified in the beacon request. If the measurement
      mode is set to passive or active, it requires actually performing a
      scan (passive or active, accordingly), and reporting the time that
      the scan was started and the time each beacon/probe was received
      (both in terms of TSF of the BSS of the requesting AP). If the
      request mode is table, this information is optional.
      In addition, the radio measurement request specifies the channel
      dwell time for the measurement.
      
      In order to use scan for beacon report when the mode is active or
      passive, add a parameter to scan request that specifies the
      channel dwell time, and add scan start time and beacon received time
      to scan results information.
      
      Supporting beacon report is required for Multi Band Operation (MBO).
      Signed-off-by: NAssaf Krauss <assaf.krauss@intel.com>
      Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
      Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      1d76250b
  8. 12 5月, 2016 1 次提交
  9. 26 4月, 2016 2 次提交
  10. 07 3月, 2016 9 次提交
  11. 02 2月, 2016 2 次提交
  12. 26 1月, 2016 1 次提交
    • M
      wil6210: handle multiple connect/disconnect events · 0916d9f2
      Maya Erez 提交于
      In the current solution wil6210 configures the vring in a worker
      and holds only one pending CID. This implementation may lead to
      race conditions between connect and disconnect events of multiple
      stations or fast connect/disconnect events of the same station.
      
      In order to allow the removal of the connect worker and handling of
      WMI_VRING_CFG_DONE_EVENTID in the connect event, the WMI replies
      that provide the reply in a given buffer needs to be handled
      immediately in the WMI event interrupt thread.
      To prevent deadlocks, WMI replies that requires additional
      handling are still handled via the events list.
      Signed-off-by: NMaya Erez <qca_merez@qca.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      0916d9f2
  13. 31 12月, 2015 1 次提交
  14. 08 12月, 2015 1 次提交
  15. 17 11月, 2015 1 次提交
    • V
      wil6210: hold wil->mutex while managing vrings · 9b1ba7b2
      Vladimir Kondratiev 提交于
      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: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
      Signed-off-by: NMaya Erez <qca_merez@qca.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      9b1ba7b2