summaryrefslogtreecommitdiff
path: root/include/soc/arc
diff options
context:
space:
mode:
authorJon Cooper <jcooper@solarflare.com>2017-02-08 16:50:40 +0000
committerDavid S. Miller <davem@davemloft.net>2017-02-09 16:47:53 -0500
commita0ee3541483767e82bf26b8269693eec25c01cba (patch)
tree73becaf6025a2abe25fb9978b75131ea72bd5c26 /include/soc/arc
parentdf6dd79be8d85ee098433bca23678fab508db541 (diff)
sfc: process RX event inner checksum flags
Add support for RX checksum offload of encapsulated packets. This essentially just means paying attention to the inner checksum flags in the RX event, and if *either* checksum flag indicates a fail then don't tell the kernel that checksum offload was successful. Also, count these checksum errors and export the counts to ethtool -S. Test the most common "good" case of RX events with a single bitmask instead of a series of ifs. Move the more specific error checking in to a separate function for clarity, and don't use unlikely() there since we know at least one of the bits is bad. Signed-off-by: Edward Cree <ecree@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'include/soc/arc')
0 files changed, 0 insertions, 0 deletions
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-12-15 01:07:34 +0000
chan_resources' and `pl330_free_chan_resources'. This avoids the double-lock by acquiring a different lock than `dma_pl330_rqcb'. NOTE that, as a result, `pl330_free_chan_resources' executes `list_splice_tail_init' on `pch->work_list' under lock `pl330->lock', whereas in the rest of the code `pch->work_list' is protected by `pch->lock'. I don't know if this may cause race conditions. Similarly `pch->cyclic' is written by `pl330_alloc_chan_resources' under `pl330->lock' but read by `pl330_tx_submit' under `pch->lock'. Second, I have removed locking from `pl330_request_channel' and `pl330_release_channel' functions. Function `pl330_request_channel' is only called from `pl330_alloc_chan_resources', so the lock is already held. Function `pl330_release_channel' is called from `pl330_free_chan_resources', which already holds the lock, and from `pl330_del'. Function `pl330_del' is called in an error path of `pl330_probe' and at the end of `pl330_remove', but I assume that there cannot be concurrent accesses to the protected data at those points. Signed-off-by: Iago Abal <mail@iagoabal.eu> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Diffstat (limited to 'include/net/sctp/ulpqueue.h')