[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 06 Jun 2017 08:24:24 -0700
From: Joe Perches <joe@...ches.com>
To: Ioana Radulescu <ruxandra.radulescu@....com>,
gregkh@...uxfoundation.org
Cc: devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org,
agraf@...e.de, arnd@...db.de, linux-arm-kernel@...ts.infradead.org,
bogdan.purcareata@....com, stuyoder@...il.com,
laurentiu.tudor@....com, Bharat.Bhushan@....com
Subject: Re: [PATCH 16/18] staging: fsl-dpaa2/eth: Errors checking update
On Tue, 2017-06-06 at 10:00 -0500, Ioana Radulescu wrote:
> On the egress path, frame errors are reported using both a FD control
> field and the frame annotation status. The current code only handles
> FAS errors. Update to look at both fields when accounting Tx errors.
[]
> Note: Checkpatch complains about a macro(DPAA2_FAS_RX_ERR_MASK) being
> too complex. It's just a bitmask with all possible Rx FAS error bits
> and I'm not sure how the extra parantheses recommended by checkpatch
> would help, so leaving it as is.
Ignoring the checkpatch message is the right thing to do.
It's just a false positive caused by the incomplete context
around the macro definition.
> @@ -177,7 +190,7 @@ struct dpaa2_fas {
> /* L4 csum error */
> #define DPAA2_FAS_L4CE 0x00000001
> /* Possible errors on the ingress path */
> -#define DPAA2_ETH_RX_ERR_MASK (DPAA2_FAS_KSE | \
> +#define DPAA2_FAS_RX_ERR_MASK (DPAA2_FAS_KSE | \
> DPAA2_FAS_EOFHE | \
> DPAA2_FAS_MNLE | \
> DPAA2_FAS_TIDE | \
> @@ -191,7 +204,7 @@ struct dpaa2_fas {
Powered by blists - more mailing lists