Removed duplicate legacy gyro_lpf validation from msp.c

[etracer65]

Fixes #5039

Additional validation in interface/msp.c was resetting the gyro and pid denoms incorrectly under the assumption that any non-zero gyro_lpf value means the gyro is in 1KHz refresh rate. The correct validation is already been performed by fc/config.c so the extra legacy validtions are not needed.

[etracer65]

@mikeller - May want to cherry-pick this into the 3.2 maintenance branch if there any further releases planned.

[fujin]

good spotting, simple fix!

[mikeller]

@etracer65: No more 3.2 releases are planned. But thanks for noting it.

[ctzsnooze]

Good fix.

But @etracer65 identified and I agree that 'experimental' won't work on MPU 6000.

And I agree with @etracer65 that when in 32k mode it should be possible to select 3k and 8k filter options, and that the terminology 'set gyro_lpf = off' is confusing when actually it results in 'set gyro_lpf = 256'.

Since, as @etracer65 noted, hardware filter options of 5 and 10 would never be used, maybe the choices list should be 8k, 3k, 250, 176, 92, 41, 20.

This would work for any gyro; if the gyro doesn't support >250 it gets reset to 250 after the save when 8k or 3k is input. Or the user cannot see 8k or 3k if not available. Either is OK by me.

Should this suggestion be in a separate thread, or leave it here?

[mikeller]

@ctzsnooze: Probably start a new issue for the discussion, or continue on #5039. This pull request is just an architectural fix, and the discussion will probably not be found when it's tracked on here.