From 093a5038b8b68f316d976b7cb69609ca7f24f322 Mon Sep 17 00:00:00 2001 From: Markus Fritsche Date: Mon, 18 May 2026 11:27:40 +0200 Subject: [PATCH] bes2600: filter 5 GHz scans at the driver boundary (besser#1) The BES2600 firmware refuses WSM start-scan for 5 GHz with status 2 ("rejected by policy"). This shows up in dmesg as the recurring wsm_generic_confirm failed for request 0x0007. [SCAN] Scan failed (-22). pattern (besser issue #1, ~14-16/h on ohm/PineTab2 baseline). Trace shows every reject is the second of a back-to-back pair: mac80211 splits multi-band hw_scan requests per band when the driver does not set IEEE80211_HW_SINGLE_SCAN_ON_ALL_BANDS (we don't), then re-invokes drv_hw_scan from __ieee80211_scan_completed for each subsequent band. The 2.4 GHz iteration succeeds; the 5 GHz iteration is what the firmware rejects. See ieee80211_prep_hw_scan in net/mac80211/scan.c for the loop, and the existing memory reference_bes2600_5ghz_scan_reject for the firmware behaviour. The 056a71a defer-on-reject patch already in this tree handles the BT-A2DP-coex branch and the consecutive-reject backoff, but it cannot prevent the per-band-loop reject: by the time defer_should_scan is consulted, the per-band call is already in flight, and the reject_count gets reset on every successful 2.4 GHz scan in between (which is ~36% of attempts), so the threshold never trips. The fix: refuse the 5 GHz iteration upfront in bes2600_hw_scan. The 2.4 GHz scan still runs normally. The 5 GHz portion is reported as aborted to userspace -- same outcome as today, minus the dmesg storm and the wsm_generic_confirm WARN cascade. 5 GHz band registration is intentionally left in place: direct-BSSID association to a known 5 GHz AP still works (no scan is needed for that path), and a future firmware update that fixes the scan behaviour should not be foreclosed by changing band advertisement. Contract: per include/net/mac80211.h ieee80211_ops.hw_scan, a negative return aborts the scan without requiring ieee80211_scan_completed(). -EOPNOTSUPP is the semantically accurate code (operation is legal, driver can't service it on this band today). Phase 3 evidence: - baseline N=3: rate ~14.3-23.6/h converged at 14.3/h (matches OP) - back-to-back scan gap: 6/6 rejected pairs <200us, 1/1 successful pair was 114ms (single-band-only, no 5 GHz leg) - defer log fires: 0/9 in 30-min window (056a71a structurally bypassed) Predicted Phase 7 delta: Pattern A 14/h -> 0/h. --- bes2600/scan.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/bes2600/scan.c b/bes2600/scan.c index fb1d298..a81afb6 100644 --- a/bes2600/scan.c +++ b/bes2600/scan.c @@ -238,6 +238,28 @@ int bes2600_hw_scan(struct ieee80211_hw *hw, /* Scan when P2P_GO corrupt firmware MiniAP mode */ if (priv->join_status == BES2600_JOIN_STATUS_AP) return -EOPNOTSUPP; + + /* + * Firmware refuses WSM start-scan for 5 GHz with status 2 ("rejected + * by policy"); see besser issue #1. mac80211 splits multi-band + * hw_scan requests per-band when the driver does not set + * IEEE80211_HW_SINGLE_SCAN_ON_ALL_BANDS (we don't -- see + * ieee80211_hw_set() calls in bes2600_main.c), so each per-band call + * has req->channels[] from one band only (see ieee80211_prep_hw_scan + * in net/mac80211/scan.c). Refuse the 5 GHz iteration at the driver + * boundary so userspace gets a clean aborted-scan for that portion + * rather than waiting for the firmware reject to cascade up. 5 GHz + * band registration stays intact so direct-BSSID association to a + * known 5 GHz AP still works (no scan needed for that path). + * + * Contract: per include/net/mac80211.h struct ieee80211_ops.hw_scan + * documentation, a negative return aborts the scan without requiring + * ieee80211_scan_completed(). + */ + if (req->n_channels > 0 && + req->channels[0]->band == NL80211_BAND_5GHZ) + return -EOPNOTSUPP; + #if 0 if (work_pending(&priv->offchannel_work) || (hw_priv->roc_if_id != -1)) {