Found something really strange...
The specific mdio reg 31 (reg_offset 31) requires some specific delay.
I notice this since still sometimes the mdio have some fail to detect the port (in the order of days)
So I investigate the regs and write operation with their return value...
I notice that right after any write to the reg_offset 31, the very next read produce garbage... (and unluckily the next read is every time the status of the port). The write to reg_offset 31 requires 16 more usec to the default delay of 8 (or 10... i still need to understand if it's safe to decrease the delay to 8)
Using the extra delay for reg 31 fix the problem...
To test all of this i simply repeated the read operation 5 times and check if every time the value was equal... And with my surprise, the value was correct and equal for every write/read except the one after the write of offset 31. (and after the normal init, offset 30 and 31 are the common one that are used)
From a very initial test (8 delay + extra for offset 31) it looks to work normally + i don't have random port dropping on the start
Anyway the major problem of the random port dropping (not considering the lost packet) is the fact that if for example one have a pppoe session and many service that are reloaded on wan reset (unbound, adblock, banip, hetunnel) the system overload and the wifi froze with lots of swba overrun error as the system can't handle the packet from the wifi... Sometimes this can even cause a crash of the wifi firmware and a simple downtime of 3-4 sec results in a downtime of 30-60 sec
an imagebuilder image for the r7500v2 for today had problems (reported here). In brief, the image won't build with the package block-mount and if i remove that, the resulting image boots but is essentially non functional. From the console, it looked like the device couldn't read its flash and all the prior configs/files weren't present.
Tftp flashing an image from late Jan. and restoring my configs got the device back.
ipq806x is about to move from swconfig to dsa switch drivers, see the kernel v5.10 PR and thread, it would probably be most useful if you could repeat your tests with dsa.
Edit: I would be rather surprised if anyone had tested EEE on QCA8337 (nor most other devices typically running OpenWrt), but the dsa drivers should offer you more insight with ethtool and iproute2 (EEE has been tested on the dsa based realtek target).
Contents of /proc/cpuinfo vary between architectures, mips and arm never displayed the CPU frequency - and just for the avoidance of doubt, the bogomips value is indeed bogus. If you want to know the current frequency, check cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq.