Initial: BESser umbrella for BES2600 driver mainlining

Sets up the BES2600 mainlining work tree with:

- README: project overview, hardware target, driver lineage
  (CW1200 -> Bestechnic -> arjan-vlek -> Mobian/danctnix), patch series
  status, repo map, build/deploy workflow.

- patches/: c1 patch generated by git format-patch from
  marfrit/bes2600-dkms branch bes2600/factory-request-firmware
  (checkpatch.pl --no-tree --strict: 0 errors / 0 warnings / 0 checks).

- scripts/: build-bes2600-on-ohm.sh, deploy-c1-to-ohm.sh,
  backup-ohm-kernel.sh - reproducible build + deploy + backup.

- fw-analysis/: per-blob strings.txt + fnnames.txt extracted from the
  4 firmware blobs pulled from ohm 2026-04-21. Source binaries NOT
  committed (Bestechnic-proprietary).

- notes/: observed-bugs.md (4 known bug surfaces with file:line +
  patch-series cross-reference), source-map.md (every public driver
  source variant + their canonical role).

Companion work tree: marfrit/bes2600-dkms (Mobian DKMS fork) at
git.reauktion.de.

Signed-off-by: Markus Fritsche <fritsche.markus@gmail.com>

notes/observed-bugs.md

@@ -0,0 +1,99 @@
+# Observed BES2600 driver bugs on PineTab2 (ohm)
+
+Compiled from on-device dmesg + Pine64 wiki + community reports. Cross-references the patch series.
+
+## Bug #1 — factory.txt path mismatch + filp_open antipattern (FIXED in c1)
+
+**File**: `bes2600_factory.c:148-170` (read), `:188-200` (create)
+
+**Symptom (pre-fix)**:
+```
+(NULL device *): read and check /lib/firmware/bes2600_factory.txt error
+```
+
+**Root cause**: hardcoded `FACTORY_PATH=/lib/firmware/bes2600_factory.txt` Makefile macro;
+real file ships at `/lib/firmware/bes2600/bes2600_factory.txt`. Worse, the read uses
+`filp_open` + `kernel_read` directly, bypassing the firmware-class infrastructure.
+
+**Fix**: c1 patch — `request_firmware()` for the read path, repointed Makefile macro
+to firmware-class name `bes2600/bes2600_factory.txt`.
+
+## Bug #1.5 — factory.txt parse failure (NEW, c5 to investigate)
+
+**File**: `bes2600_factory.c factory_parse()`
+
+**Symptom (post-c1)**:
+```
+bes2600_factory.txt parse fail
+read and check bes2600/bes2600_factory.txt error
+factory cali data get failed.
+```
+
+**How discovered**: c1 fix exposed a deeper bug — `factory_parse()` chokes on the data
+that `request_firmware()` now successfully returns. The original bug masked this
+because the read always failed first.
+
+**Hypotheses**: null-termination assumption mismatch (`request_firmware` doesn't
+null-terminate), `FACTORY_MEMBER_NUM=30/31` count discrepancy, kmalloc not
+zero-initialized, parser strict on trailing `%%\n` delimiter.
+
+**Status**: investigation pending (task c5). Driver falls back to defaults; WiFi
+functional but TX power is uncalibrated (all channels at 0x1400).
+
+## Bug #2 — PM low-power handshake timeout (recurring)
+
+**File**: `bes_pwr.c:470-558` — `bes2600_pwr_enter_lp_mode()`. Error at line 538.
+
+**Symptom**:
+```
+bes2600_wlan mmc2:0001:1: bes2600_pwr_enter_lp_mode, wait pm ind timeout
+```
+
+Fires every 5–10s in steady state when associated. Floods dmesg, likely
+correlates with bug #3 (SDIO TX stack splat) and bad battery life.
+
+**Root cause**: `wait_for_completion_timeout(&pm_enter_cmpl, 5*HZ)` waits
+for firmware to acknowledge a PM mode change; firmware never sends ACK.
+Driver proceeds to `bes2600_pwr_device_enter_lp_mode()` regardless.
+
+**Mobian == danctnix**: identical bes_pwr.c (1447 lines, 0-hunk diff). No
+upstream fix exists; we'd invent it (gate device-LP entry on completion +
+add retry).
+
+**Status**: task c2.
+
+## Bug #3 — SDIO TX scatter-gather panic / WARN
+
+**File**: `bes2600_sdio.c:952-1200` — `bes_sdio_memcpy_to_io_helper`,
+`sdio_tx_work`.
+
+**Symptom**:
+```
+[RX] Receive failure: 4.
+ bes_sdio_memcpy_to_io_helper+0x18c/0x288 [bes2600]
+ sdio_tx_work+0x2b4/0x4a0 [bes2600]
+Workqueue: bes_sdio sdio_tx_work [bes2600]
+```
+
+Recurring under TX load. Can wedge the chip irrecoverably (per Pine64 wiki:
+"Power/reset circuitry not properly implemented; hard reset impossible
+without board power-cycle").
+
+**Status**: task c3 (indirectly, via bes_chardev removal which currently
+gates the signal/nosignal mode switch path).
+
+## Bug #4 — scan_complete_cb constant loop
+
+**File**: `scan.c:883-909` — `bes2600_scan_complete_cb()`.
+
+**Symptom**:
+```
+ieee80211 phy0: bes2600_scan_complete_cb status: 0
+```
+
+Fires every 2–10s (status=0 = success, but the FREQUENCY suggests background
+scanning runs continuously when associated + idle).
+
+Most likely a NetworkManager scheduling artifact, not a driver bug. Low
+priority; suppress the wiphy_dbg print or skip scan-on-assoc'd if it
+matters.