Re: [PATCH] wcn36xx: Add hardware scan offload support

On Fri 08 Dec 01:35 PST 2017, Loic Poulain wrote:

Current hw_scan implementation does not trigger offloaded
hardware scan and seems to only put the device in a kind of
listening mode (beacon/probe-response) for software scan.
Since no probe request are generated by the software, current
scanning method is similar to a passive scan.

This patch introduces support for 'true' hardware offloaded scan.
Hardware scan is configured and started via the start-scan-offload
firmware message. Once scan has been completed a scan indicator
message is received from firmware.

Moreover, this patch includes support for directed probe-request,
allowing connection with hidden APs. It also fixes scan issues with
band-steering AP which are not 'visible' with passive scan (due to
hidden ssid in beacons).

I'm puzzled to why I didn't see this when I dumped the control channel
that lead up to the initial hw_scan patch. But this looks good and with
a related locking issue fixed this seems to work well.

Acked-by: Bjorn Andersson <redacted>

[..]

+static int wcn36xx_smd_hw_scan_ind(struct wcn36xx *wcn, void *buf, size_t len)
+{
+	struct wcn36xx_hal_scan_offload_ind *rsp = buf;
+	struct cfg80211_scan_info scan_info = {};
+
+	if (len != sizeof(*rsp)) {
+		wcn36xx_warn("Corrupted delete scan indication\n");
+		return -EIO;
+	}
+
+	wcn36xx_dbg(WCN36XX_DBG_HAL, "scan indication (type %x)", rsp->type);
+
+	switch (rsp->type) {
+	case WCN36XX_HAL_SCAN_IND_FAILED:
+		scan_info.aborted = true;
+	case WCN36XX_HAL_SCAN_IND_COMPLETED:
+		mutex_lock(&wcn->scan_lock);

Grabbing this mutex with DEBUG_ATOMIC_SLEEP causes issues, but that's
because the locking in ind_smd_work() is to excessive. Will reply with a
fix for this.

+		wcn->scan_req = NULL;
+		mutex_unlock(&wcn->scan_lock);
+		ieee80211_scan_completed(wcn->hw, &scan_info);
+		break;

Regards,
Bjorn