I'll need some time to get set up and oriented but here are a few initial thoughts.
You've mentioned that you've tried both the "dsa" and the "normal" (switchdev?) driver. Unless dsa is going to be the new default in 5.4 for these devices, I'd like to stay with switchdev - at least for troubleshooting this issue. I'm willing to experiment with dsa but it will take time. I'm not sure how your repo is set up in this regard, but I'm sure I'll find out.
Also you mention some kernel flags need to be added... is this done? I bring it up as I saw this which looks like a bunch of kernel flags related to dsa.
Assuming I can get a functioning build on the r7500v2 and reproduce the symptoms, my thought is it to take a look for changes around netfilter (or other firewall related code in the kernel).
I asked other devs if they have some problem with 5.4 and they said that all works good. So i think is something target specific.
I tried dsa since it should be the upstream (and more compatible) version of the driver. To use dsa driver some changes needs to be done to the dts of the device (if you want i can post them here...)
Dsa flags are already enabled but since there is no support in the dts they don't get compiled and included in the final kernel.
About the kernel flags, i added some of them but leave some out as i think they should be included in the generic config file and not in the ipq one... (on compilation time just press enter on all of them as they are just N by default, and also should not be related to this problem, they should cause at most an increased kernel)
No, IPQ40xx uses a modified version of QCA8337N as its register space is actually memory-mapped into SoC-s.
So it acts differently, there is a modified qca8k for IPQ40xx as DSA, and completely custom driver used currently.
Do you maybe have a stack trace for the panic?
I think that that dst_release underflow error is generic for OpenWrt under 5.4 as this can also be found by googling.
Now that i think about it it should be trigged on wifi initialization (as the switch driver is broken, it's the one that start sending data). The strange thing is that other devs working on other target don't have this...
Not really, I did the migration to v4.19 for IPQ40xx and generic support for it was already done in RC releases.
I had the v4.19 PR as soon as generic support was merged, so this is rather slow compared to it.