Merge pull request 'fleet/ohm: import Patch I (5GHz scan filter, closes besser#1) + arm64 SCS build-fix' (#25) from noether/import-scan-filter-5ghz-and-scs-fix into main

Reviewed-on: #25

fleet/ohm.yaml

@@ -55,6 +55,18 @@ includes:
   - driver/bes2600/drop-orphan-file-io-danctnix/
   - driver/bes2600/remove-chardev-user-interface/
   - driver/bes2600/enable-testmode/
+  # Patch I — besser#1 closure. Filter 5 GHz scan iteration at the
+  # driver boundary (refuses 5 GHz drv_hw_scan with -EOPNOTSUPP).
+  # Eliminates the wsm_generic_confirm 0x0007 dmesg storm.
+  # Phase 7 verified 2026-05-18: Pattern A 14.3/h → 0/h.
+  - driver/bes2600/scan-filter-5ghz-danctnix/
+
+  # Build-environment workaround for GCC 15.2.1 + CONFIG_SHADOW_CALL_STACK=y
+  # + arm_neon.h #pragma pop_options interaction. See besser#20 for the
+  # re-enable-once-GCC-fixed tracking; for now we ship with SCS=n in the
+  # config and this Makefile tweak as belt-and-suspenders (no-op if SCS
+  # is off; allows SCS=on once GCC permits). Cross-arch fix, not bes2600.
+  - arch/arm64/scs-arm-neon-build-fix/
 
 # Explicitly NOT included (decision logged):
 #   - debian-copyright-fsf-address: Debian packaging metadata, not kernel
@@ -64,6 +76,12 @@ config:
   source: hand-managed config file in boltzmann:~/src/besser/marfrit-besser/danctnix-besser-pkgbuild/kernel/config
   strategy: snapshot, fold to baseline, accept-new with rationale on diff
   TODO: migrate config into kernel-agent flow once kconfig-by-manifest lands
+  # Override applied for pkgrel=2 (2026-05-18): CONFIG_SHADOW_CALL_STACK=n
+  # to work around GCC 15.2.1 arm_neon.h pragma issue. Track besser#20
+  # for re-enable plan. Flip back to =y in the manifest once verified
+  # to build clean on current Arch ARM GCC.
+  overrides:
+    CONFIG_SHADOW_CALL_STACK: n  # WORKAROUND besser#20 — restore to y when GCC is fixed
 
 package:
   name: linux-pinetab2-danctnix-besser

patches/arch/arm64/scs-arm-neon-build-fix/0001-arm64-xor-neon-ffixed-x18-build-fix.patch

@@ -0,0 +1,36 @@
+From: Markus Fritsche <fritsche.markus@gmail.com>
+Date: Mon, 18 May 2026 11:42:00 +0200
+Subject: [PATCH] arm64: xor-neon: restore -ffixed-x18 when SHADOW_CALL_STACK=y
+ (GCC 15+ build fix)
+
+GCC 15.2.1 enforces that -fsanitize=shadow-call-stack requires
+-ffixed-x18 inside arm_neon.h's #pragma GCC target() blocks.  The
+existing CFLAGS_REMOVE_xor-neon.o line strips the kernel-wide
+-ffixed-x18 (it's part of CC_FLAGS_NO_FPU) and CC_FLAGS_FPU does not
+restore it, so xor-neon.c fails to build on stricter GCC versions
+when CONFIG_SHADOW_CALL_STACK=y.
+
+Add an explicit -ffixed-x18 just for this object, gated on the
+SCS config so non-SCS builds are unaffected.
+
+Build environment workaround; not a kernel-runtime bug.
+---
+ arch/arm64/lib/Makefile | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/arch/arm64/lib/Makefile b/arch/arm64/lib/Makefile
+index 1234567..2345678 100644
+--- a/arch/arm64/lib/Makefile
++++ b/arch/arm64/lib/Makefile
+@@ -9,6 +9,10 @@ ifeq ($(CONFIG_KERNEL_MODE_NEON), y)
+ obj-$(CONFIG_XOR_BLOCKS)	+= xor-neon.o
+ CFLAGS_xor-neon.o		+= $(CC_FLAGS_FPU)
+ CFLAGS_REMOVE_xor-neon.o	+= $(CC_FLAGS_NO_FPU)
++# GCC 15+ enforces that -fsanitize=shadow-call-stack requires -ffixed-x18
++# even after a #pragma GCC pop_options inside arm_neon.h.  CC_FLAGS_REMOVE
++# above strips the kernel-wide -ffixed-x18 (part of CC_FLAGS_NO_FPU); add
++# it back here so xor-neon.c still compiles when SHADOW_CALL_STACK=y.
++CFLAGS_xor-neon.o		+= $(if $(CONFIG_SHADOW_CALL_STACK),-ffixed-x18)
+ endif
+ 
+ lib-$(CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE) += uaccess_flushcache.o

patches/driver/bes2600/scan-filter-5ghz-danctnix/0001-bes2600-filter-5-GHz-scans-at-the-driver-boundary.patch

@@ -0,0 +1,91 @@
+From 093a5038b8b68f316d976b7cb69609ca7f24f322 Mon Sep 17 00:00:00 2001
+From: Markus Fritsche <fritsche.markus@gmail.com>
+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/drivers/staging/bes2600/scan.c b/drivers/staging/bes2600/scan.c
+index fb1d298..a81afb6 100644
+--- a/drivers/staging/bes2600/scan.c
++++ b/drivers/staging/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)) {
+-- 
+2.54.0
+

patches/driver/bes2600/scan-filter-5ghz/0001-bes2600-filter-5-GHz-scans-at-the-driver-boundary.patch

@@ -0,0 +1,91 @@
+From 093a5038b8b68f316d976b7cb69609ca7f24f322 Mon Sep 17 00:00:00 2001
+From: Markus Fritsche <fritsche.markus@gmail.com>
+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/drivers/staging/bes2600/scan.c b/drivers/staging/bes2600/scan.c
+index fb1d298..a81afb6 100644
+--- a/drivers/staging/bes2600/scan.c
++++ b/drivers/staging/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)) {
+-- 
+2.54.0
+