|WARNING| pw169966 [PATCH] net/ixgbe: fix spurious MACsec event on E610

[checkpatch at dpdk.org]

Test-Label: checkpatch
Test-Status: WARNING
http://dpdk.org/patch/169966

_coding style issues_


WARNING:TYPO_SPELLING: 'ACI' may be misspelled - perhaps ''?
#80: 
(ACI) receive queue were never drained, so the cause was not cleared.
 ^^^

WARNING:TYPO_SPELLING: 'ACI' may be misspelled - perhaps ''?
#83: 
drain the ACI receive queue until empty; keep the MACsec handling for
          ^^^

WARNING:TYPO_SPELLING: 'ACI' may be misspelled - perhaps ''?
#149: FILE: drivers/net/intel/ixgbe/ixgbe_ethdev.c:4732:
+					"Failed to read FW event from ACI: %d",
 					                              ^^^

ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses
#181: FILE: drivers/net/intel/ixgbe/ixgbe_ethdev.h:31:
+#define IXGBE_FLAG_FW_EVENT         (uint32_t)(1 << 5)

BUT SEE:

   do {} while (0) advice is over-stated in a few situations:

   The more obvious case is macros, like MODULE_PARM_DESC, invoked at
   file-scope, where C disallows code (it must be in functions).  See
   $exceptions if you have one to add by name.

   More troublesome is declarative macros used at top of new scope,
   like DECLARE_PER_CPU.  These might just compile with a do-while-0
   wrapper, but would be incorrect.  Most of these are handled by
   detecting struct,union,etc declaration primitives in $exceptions.

   Theres also macros called inside an if (block), which "return" an
   expression.  These cannot do-while, and need a ({}) wrapper.

   Enjoy this qualification while we work to improve our heuristics.

total: 1 errors, 3 warnings, 0 checks, 77 lines checked