Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. Nov 03, 2020
    • Bryan O'Donoghue's avatar
      wcn36xx: Fix beacon loss detection during sw scan · 726d81ca
      Bryan O'Donoghue authored 
      
Testing on Android - which has a tendency to hammer away at WiFi scanning
I've found that if I disconnect an AP - literally pull the power out during
a scan that a loss of beacon indication is not generated by the firmware.

Instead the undocumented result code '29' is returned. The set of declared
response codes in downstream prima is.

typedef enum
{
   WDI_STATUS_SUCCESS,
   WDI_STATUS_SUCCESS_SYNC,
   WDI_STATUS_PENDING,
   WDI_STATUS_E_FAILURE,
   WDI_STATUS_RES_FAILURE,
   WDI_STATUS_MEM_FAILURE,
   WDI_STATUS_E_NOT_ALLOWED,
   WDI_STATUS_E_NOT_IMPLEMENT,
   WDI_STATUS_DEV_INTERNAL_FAILURE,
   WDI_STATUS_MAX
}WDI_Status;

No sign of 29 in this list, let alone what it indicates.

What we see when a scan is not in progress is the firmware generate a
beacon loss indication which then flows down into
wcn36xx_smd_missed_beacon_ind().

This patch addresses this difference in behavior by:

1. Capturing the result code of wcn36xx_smd_init_scan()
2. If and only if a software scan is in progress and we are associated with
   an AP triggering ieee80211_connection_loss()

Once done I can reliably capture beacon loss both on the scan and non-scan
paths.

Signed-off-by: default avatarBryan O'Donoghue <bryan.odonoghue@linaro.org>
      ath.master-03-11-20+wcn36xx-fw-offload-suspend-resume-t1
      726d81ca
    • Bryan O'Donoghue's avatar
      wcn36xx: Don't run scan_init multiple times · f5bff6fe
      Bryan O'Donoghue authored 
      
Run scan_init only once. There's no need to run this command multiple times
if it has already been run once.

Signed-off-by: default avatarBryan O'Donoghue <bryan.odonoghue@linaro.org>
      f5bff6fe
    • Bryan O'Donoghue's avatar
      wcn36xx: Send NULL data packet when exiting BMPS · 35571ae0
      Bryan O'Donoghue authored 
      
This commit updates the BMPS exit path to be consistent with downstream in
terms of exiting BMPS mode. Downstream sets the flag to send a NULL data
frame to the host on exiting BMPS.

Doing so will immediately indicate to the host that the device is alive.
This is the right thing to do when doing firmware offloaded keepalive since
we may have been off channel when the firmware's timer to send the NULL
data-frame expired.

Signed-off-by: default avatarBryan O'Donoghue <bryan.odonoghue@linaro.org>
      35571ae0
    • Bryan O'Donoghue's avatar
      wcn36xx: Enable firmware offloaded keepalive · 8b28bf54
      Bryan O'Donoghue authored 
      
This patch calls wcn36xx_smd_keep_alive_req() on the STA patch immediately
after associating with an AP.

This will cause the firmware to send a NULL packet out to the AP every 30
seconds, thus offloading keep-alive processing from the SoC to the
firmware.

Signed-off-by: default avatarBryan O'Donoghue <bryan.odonoghue@linaro.org>
      ath.master-03-11-20+wcn36xx-fw-offload-suspend-resume-t0
      8b28bf54
    • Bryan O'Donoghue's avatar
      wcn36xx: Enable firmware link monitoring · 19ce357f
      Bryan O'Donoghue authored 
      
This patch switches on CONNECTION_MONITOR. Once done it is up to the
firmware to send keep alive and to monitor the link state.

Signed-off-by: default avatarBryan O'Donoghue <bryan.odonoghue@linaro.org>
      19ce357f
    • Bryan O'Donoghue's avatar
      wcn36xx: Set LINK_FAIL_TX_CNT to 1000 on all wcn36xx · 1703fcb6
      Bryan O'Donoghue authored 
      
The firmware parameter LINK_FAIL_TX_CNT maps to the prima configuration
file parameter gLinkFailTxCnt and is described as:

quote: " If within gLinkFailTimeout period(values is mentioned in msec) if
         FW doesn't receive acks for gLinkFailTxCnt number of packets, then
         link will be disconnected."

The downstream description sets a minimum value of 1000 a maximum value of
60000 and a default value of 6000, however it appears that unless we
actually set this value deliberately firmware defaults it to 0.

Setting this value to non-zero results in the firmware doing link
monitoring. The working example from downstream paradoxically sets the
value to 200, here we opt to set the value to the minimum stipulated in the
configuration file 1000.

In conjunction with ieee80211_hw_set(wcn->hw, CONNECTION_MONITOR); this
change effects offload of link monitoring to the firmware.

Tested with:
'CNSS-PR-2-0-1-2-c1-74-130449-3' wcn3620
'CNSS-PR-2-0-1-2-c1-00083'       wcn3680

Signed-off-by: default avatarBryan O'Donoghue <bryan.odonoghue@linaro.org>
      1703fcb6
  3. Oct 30, 2020
  5. Oct 29, 2020