From patchwork Wed Feb 13 00:24:22 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paul Gortmaker X-Patchwork-Id: 220015 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 1F9632C0091 for ; Wed, 13 Feb 2013 11:24:53 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759411Ab3BMAYs (ORCPT ); Tue, 12 Feb 2013 19:24:48 -0500 Received: from mail.windriver.com ([147.11.1.11]:43640 "EHLO mail.windriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759221Ab3BMAYp (ORCPT ); Tue, 12 Feb 2013 19:24:45 -0500 Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail.windriver.com (8.14.5/8.14.3) with ESMTP id r1D0OdUW026068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Feb 2013 16:24:39 -0800 (PST) Received: from yow-lpgnfs-02.corp.ad.wrs.com (128.224.149.8) by ALA-HCA.corp.ad.wrs.com (147.11.189.40) with Microsoft SMTP Server id 14.2.318.4; Tue, 12 Feb 2013 16:24:39 -0800 From: Paul Gortmaker To: David Miller CC: , Claudiu Manoil , Eric Dumazet , Paul Gortmaker Subject: [PATCH net-next 0/2] gianfar: make local stats atomic64 Date: Tue, 12 Feb 2013 19:24:22 -0500 Message-ID: <1360715064-2689-1-git-send-email-paul.gortmaker@windriver.com> X-Mailer: git-send-email 1.8.1.2 MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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. Paul. --- The following changes since commit 0790bbb68f9d483348c1d65381f3dd92602bfd05: netpoll: cleanup sparse warnings (2013-02-11 19:19:58 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux.git gfar-ethtool-atomic for you to fetch changes up to 212079df6d77c0daada96b1d906f4b7749871411: gianfar: convert u64 status counters to atomic64_t (2013-02-12 19:08:27 -0500) ---------------------------------------------------------------- Paul Gortmaker (2): gianfar: remove largely unused gfar_stats struct gianfar: convert u64 status counters to atomic64_t drivers/net/ethernet/freescale/gianfar.c | 26 ++++++++-------- drivers/net/ethernet/freescale/gianfar.h | 39 +++++++++++------------- drivers/net/ethernet/freescale/gianfar_ethtool.c | 17 +++++------ 3 files changed, 37 insertions(+), 45 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html