]> git.baikalelectronics.ru Git - kernel.git/commit
Merge branch 'gfar-ethtool-atomic' of git://git.kernel.org/pub/scm/linux/kernel/git...
authorDavid S. Miller <davem@davemloft.net>
Wed, 13 Feb 2013 18:18:20 +0000 (13:18 -0500)
committerDavid S. Miller <davem@davemloft.net>
Wed, 13 Feb 2013 18:18:20 +0000 (13:18 -0500)
commite60e44d6cb24bb5a357ff3e3060b2cea2b88ce83
tree8a821bff0bc791e23441e90835db6e348ffa407e
parent1ecd342f7c9b5d8ab63e12fc33cf985e39e610a1
parentd197cc937c9f89451897054195451d0cf9719ba2
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>