Good catch. If I deselect kmod-ltq-deu-vr9, the issue is gone.
The driver is also [[https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=e85180d90ed01ef4fb89675702622a9cabf3b092|not compatible with kernel 5.10]]. Same cause? Maybe it should simply be removed (for now).
(copy of the comment in the commit to disable ltq-deu) I had a look at the driver in trunk and could reproduce the issue by using mac80211_hwsim on fritzbox 7490 even without a physical wifi. While removing the driver or commenting out AES makes this issue go away, the drivers AES methods (aes_set_key) are not even called when the error occurs. They are called, when the error does not occur, e.g. I added printk and dumpstack() to the methods in ifxmips_aes.c and in some cases the error went away and the virtual wlan0 and wlan1 initialized just fine. There is a 'netifd: radio0 (2354): Command failed: Invalid argument' error from netifd in the log (logread not dmesg), so to me it seems the actual error is caused before even calling the ltq-deu drivers set_key method:
Unfortunately I have no clue, which command and which argument failed.
The behaviour on real hardware might be different, since as mentioned sometimes I could bring up wlan0 and wlan1 just by adding printk to the aes_set_key method and there were cases, when commenting out the printk and rebuilding the initramfs image did not make the error appear again. For the log to capture I have to delete the ltq-deu directory in the build_dir in order to make the error appear again. I wonder if its a timing issue in the startup scripts or who knows.
The new driver seems to work, I screwed it up by copying an newer version of the driver over with an older timestamp and it was not build, due to the timestamp. I was confused by @Notupus reports that the new driver does not work.