Josh Hobbs / writing
Forward-porting a frozen WiFi driver
Checkpoint, not a finished port — last verified 2026-08-10, 11:39 EDT. Read later, this is where it stood, not where it ended.
The GL.iNet GL-SFT1200 still gets firmware updates; what it does not get is a newer kernel. Its current release, 4.8.3, is listed as actively supported, and it is built on OpenWrt 18.06, which carries Linux 4.14.90 — a kernel line from late 2017, at a point release from late 2018.
That freeze is not GL.iNet's. Siflower, whose SF19A2890 is the SoC in this router, forked OpenWrt 18.06 into their own 1806_SDK and never moved past kernel 4.14.90, and the proprietary parts of that SDK live outside the mainline kernel it was forked from — welded to one particular fork. Upstream OpenWrt does not support this platform and is not expected to, owing to the SoC's CPU architecture, so there is no release from anyone else that eventually picks the device up.
What that leaves an owner with is a device under active support, taking feature and interface updates, sitting on a kernel seven years old. Every kernel-level fix since 2018 is somebody's backport rather than something that simply arrives.
Almost nobody has taken that on: the best community attempt so far merged kernel 4.14 LTS commits into the vendor tree and weighed a move to OpenWrt 19.07 — which is also kernel 4.14. This device has never been moved to a current kernel.
Where this is going: OpenWrt 24.10, kernel 6.6.144, mipsel_24kc+24kf — a kernel that still receives upstream fixes. The vendor driver, which builds as a kernel module named sf16a18_fmac (the driver family, not the chip) for board codename opal, is written against the older API. Roughly seven years of cfg80211/mac80211 change sits between the two, and that gap is the actual work.
| 4.x API | became |
|---|---|
| per-station calls | gained an MLO link_id argument |
station_parameters | link_sta_params |
STATION_INFO_* bitmask | BIT_ULL(NL80211_STA_INFO_*) |
mgmt_frame_register callback | update_mgmt_frame_registrations |
direct dev_addr assignment | eth_hw_addr_set() |
Patterns like these recur roughly seventy-one times in siwifi_main.c.
Patches were authored by parallel agents against a shared plan, one agent integrating; every edit is gated on LINUX_VERSION_CODE, so the 4.14 paths are preserved rather than replaced — no 4.14 build has been run to confirm that.
| check | result |
|---|---|
| cfg80211-surface files | 10 of 10 build to real MIPS objects (elf32-tradlittlemips, mips:isa32r2) |
| strict-signature rebuild | clean, with incompatible-pointer-types promoted to an error |
sparse, C=2 | 0 lock/context imbalances |
| coccicheck | 0 findings |
| checkpatch | 0 errors |
| modpost, whole driver | 198 unresolved symbols (10 named, 188 suppressed) |
In that harness the whole driver compiles and the module object (.o, before modpost) links — LD [M] sf16a18_fmac.o succeeds — and modpost then fails on the 198 above. Against the real target, kmod-sf_smac has never been built: no package, no image. The target itself does build — its own toolchain, kernel 6.6.144, kmod-cfg80211 from mac80211-backports 6.12.96 — so the compat layer expected to shrink that number is present, not assumed.
About the 198: modpost reports Module.symvers is missing, and the named symbols — free_irq, dma_pool_create, rtnl_unlock, eth_mac_addr, cfg80211_inform_bss_frame_data — plainly exist in any real kernel, so the count is probably a harness artifact rather than a port defect. Probably. A real symbol table has existed since roughly 02:00 on 2026-08-10, the driver has not been built against it, and that one unrun build is what separates probable from proven.
What none of this proves: it has never run on hardware — no serial console, no bring-up, runtime behavior unknown. The SoC layer beneath cfg80211 is less finished and more tangled: in the same harness, enabling CONFIG_VDR_HW everywhere cut hw_interface.c from 144 errors to 18 but regressed all ten cfg80211 files, so it needs per-file scoping. Firmware load is untouched.