tree 8a821bff0bc791e23441e90835db6e348ffa407e
parent 959d5fdee7aa32fa04bc2c37e3d3871ad266fe97
parent 212079df6d77c0daada96b1d906f4b7749871411
author David S. Miller <davem@davemloft.net> 1360779500 -0500
committer David S. Miller <davem@davemloft.net> 1360779500 -0500

Merge branch 'gfar-ethtool-atomic' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux

Paul Gortmaker says:

====================
Eric noticed that the handling of local u64 ethtool counters for
this driver commonly found on Freescale ppc-32 boards was racy.

However, before converting them over to atomic64_t, I noticed
that an internal struct was being used to determine the offsets
for exporting this data into the ethtool buffer, and in doing
so, it assumed that the counters would always be u64.  Rather
than keep this implicit assumption, a simple code cleanup gets
rid of the struct completely, and leaves less conversion sites.

The alternative solution would have been to take advantage of
the fact that the counters are all relating to error conditions,
and hence make them internally u32.  In doing so, we'd be assuming
that U32_MAX of any particular error condition is highly unlikely.
This might have made sense if any increments were in a hot path.

Tested with "ethtool -S eth0" on sbc8548 board.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>