gve: Do minor cleanup and bump version

[jtranoleary_google.com]

Summary

This commit fixes several minor issues:

• Removes an unnecessary function pointer parameter on gve_start_tx_ring
• Adds a presubmit check against style(9)
• Replaces mb() and rmb() macros with native atomic_thread_fence_seq_cst() and atomic_thread_fence_acq() respectively
• Fixes various typos throughout
• Increments the version number to 1.3.2

Co-authored-by: Vee Agarwal <[e-mail]>
Signed-off-by: Vee Agarwal <[e-mail]>
Signed-off-by: Jasper Tran O'Leary <[e-mail]>

[markj]

sys/dev/gve/gve_rx_dqo.c

975

Just a suggestion: I suspect it would be marginally cheaper to use a load-acquire to fetch the generation number from the descriptor instead of issuing an explicit barrier:

uint8_t gen;

gen = atomic_load_acq_8(&compl_desc->generation);
if (gen == rx.dqo.cur_gen_bit)
    break;
...

On amd64 this doesn't matter of course.

sys/dev/gve/gve_tx_dqo.c

1034

Same comment here.

[jtranoleary_google.com]

sys/dev/gve/gve_rx_dqo.c

975

This is a great idea and I would much rather use a load-acquire as opposed to a full fence. Unfortunately, the generation is a bit in a bitfield and trying out the code above yielded "error: address of bit-field requested." As a workaround, I think we could fetch a 1- or 2-byte chunk from the bitfield and bitmask it, but this is trickier and I'd like to be able to test it for a while first. I'll be sure to include this in a subsequent patch.

[markj]

sys/dev/gve/gve_rx_dqo.c

975

Oh, right, I was looking at the definition of cur_gen_bit by mistake. Postponing to a future patch makes perfect sense to me, thanks.