I’m on 6.13-rc5 and have it (seemingly) running well, although I haven’t exhaustively tested it?
I forget everything I did, but if you’d just like to get it running in the meantime, the main thing is to edit the ieee80211_ops struct and add op pointers for the add / remove / change_chanctx functions. Point them to the mac80211 emulate add / change / remove chanctx functions:
struct ieee80211_ops mors_ops = {
... some mac ops
#ifdef CONFIG_MORSE_RC
.sta_statistics = morse_sta_tx_rate_stats,
.get_expected_throughput = morse_get_expected_throughput,
#endif
.add_chanctx = ieee80211_emulate_add_chanctx,
.remove_chanctx = ieee80211_emulate_remove_chanctx,
.change_chanctx = ieee80211_emulate_change_chanctx,
};
Without these, the driver will blow up when you probe it.
On previous versions, I think I had to do some pointer footsie with changing ieee80211 structure references that changed (i.e. bss_conf becomes vif->bss_conf ) type stuff; but I think that may have already been fixed up in 1.12.4.
I forget when they added MLO support to mac80211, that was something I had to patch in an earlier version of the driver to support 6.6, but I think 1.14.1 includes those “link_id” changes to the function signatures.
Make sure your MAC80211_VERSION_CODE and LINUX_VERSION_CODE are coming through correctly for the
#if KERNEL_VERSION(5, 9, 0) > MAC80211_VERSION_CODE
do_stuff()
#endif
type macro blocks.
lastly, i’m not sure when the change came in that broke it, because i jumped from 6.6 to 6.13-rc5 on bringup of the latest driver, but module BTF info verification might be bronken on really new kernels. Pass
CONFIG_MODULE_ALLOW_BTF_MISMATCH=y
in your kernel defconfig to allow the out-of-tree module build to be loaded in and verified. I still haven’t figured out why that one is breaking yet, but that’s a workaround.
I think those should at least get you going. I haven’t exhaustively tested everything yet, but the thing associates, does SAE, etc, and hasn’t panicked once so far.