Users have been reporting that schedutil avoids the problem. This is coincidental as it just happens not to end up in the lowest operating point at the point the reset is asserted, so I wouldn't trust it too much and the behavior may change with future updates. Imho the best is to just
echo 437500 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
for now until the root-cause of the problem is solved.
Ideally we should do that by having ARM Trusted Firmware make sure CPU frequency and voltage are reset to default before jumping into DDR calibration. We build it from source and datasheet for MT7622 is de-facto public, so just needs someone to do it. And it would require everyone to update bl2 which is a bit dangerous.
Alternatively it could be solved by patching the Linux kernel so it would make sure to reset cpufreq to default before reboot. That's kinda ugly and most likely unacceptable for upstream, but then it's solved via normal sysupgrade and (other than updating bl2) there is no risk to brick the device if the update goes wrong.
To be on the super safe side, we could even do both of the above, so new users (and new devices using MT7622 with ATF built from source) would not suffer from that problem and existing users would still not have to replace bl2. However, you guess it, it's a bit of work.
So last but not least we could simply ignore what MediaTek engineer Sean Wang submitted to Linux and just raise the supply voltage on that lowest operating point to 1.0V or completely remove the (anyway obvious buggy as 30MHz in code but labeled more realistic sounding 300MHz) operating point from device tree. But both would be a last-resort if none of the above is implemented when we get close to 22.xx-rc1.