From patchwork Wed Nov 12 22:58:23 2008 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Roland Dreier X-Patchwork-Id: 8464 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.176.167]) by ozlabs.org (Postfix) with ESMTP id 8DA0BDDDEF for ; Thu, 13 Nov 2008 09:58:31 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753168AbYKLW61 (ORCPT ); Wed, 12 Nov 2008 17:58:27 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752160AbYKLW60 (ORCPT ); Wed, 12 Nov 2008 17:58:26 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]:27860 "EHLO sj-iport-6.cisco.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752042AbYKLW6Z (ORCPT ); Wed, 12 Nov 2008 17:58:25 -0500 X-IronPort-AV: E=Sophos;i="4.33,592,1220227200"; d="scan'208";a="193633849" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 12 Nov 2008 22:58:24 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id mACMwOcf019427; Wed, 12 Nov 2008 14:58:24 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id mACMwOcS010026; Wed, 12 Nov 2008 22:58:24 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Nov 2008 14:58:24 -0800 Received: from roland-conroe ([171.71.26.194]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Nov 2008 14:58:24 -0800 Received: by roland-conroe (Postfix, from userid 33217) id B9D67E7206; Wed, 12 Nov 2008 14:58:23 -0800 (PST) From: Roland Dreier To: David Miller Cc: bhutchings@solarflare.com, jdb@comx.dk, netdev@vger.kernel.org Subject: Re: NIU driver: Sun x8 Express Quad Gigabit Ethernet Adapter References: <1226494493.3016.3.camel@achroite> <20081112.134618.30673281.davem@davemloft.net> <1226526657.3016.10.camel@achroite> <20081112.142625.120012106.davem@davemloft.net> X-Message-Flag: Warning: May contain useful information Date: Wed, 12 Nov 2008 14:58:23 -0800 In-Reply-To: <20081112.142625.120012106.davem@davemloft.net> (David Miller's message of "Wed, 12 Nov 2008 14:26:25 -0800 (PST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 X-OriginalArrivalTime: 12 Nov 2008 22:58:24.0079 (UTC) FILETIME=[2A78B5F0:01C9451A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1862; t=1226530704; x=1227394704; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdreier@cisco.com; z=From:=20Roland=20Dreier=20 |Subject:=20Re=3A=20NIU=20driver=3A=20Sun=20x8=20Express=20 Quad=20Gigabit=20Ethernet=20Adapter |Sender:=20; bh=y0LCSNPgtZgp6GAyWRrno/FTn//LzCXnd8rOeHLVuh4=; b=GMkzTKfkTamNdkcG+iBnt3UAES2FCezKdrIEFh0XC843G4mbjsNzew0oCi FZX6E/oUadwHviUi+JYtA23dQpba9jYJo6NSQ28Md/EtxIJLEhwVNl9Im6K/ /rjc6akrDi; Authentication-Results: sj-dkim-3; header.From=rdreier@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > Just google "C order of evaluation" and you will get hundreds > of tables, and all of them will have an entry for "|" (not > just "||") which says that operands are evaluated left to > right. You're talking about associativity, which says how an expression like "a | b | c" is implicitly parenthesized. The order of evaluation is undefined -- in fact the C standard I have says: Except as specified later (for the function-call (), &&, ||, ?:, and comma operators), the order of evaluation of subexpressions and the order in which side effects take place are both unspecified. So there is no rule about which subexpression is evaluated first in an expression like "a | b". > And since these MMIO reads are volatile operations, there is > no way the compiler can execute them out of order. "volatile" just means that accessing a volatile expression is considered a side effect -- and side effects are only ordered with respect to sequence points. So according to my understanding of the C standard, there is no required on which readl() is done first in an expression like "readl(a) | readl(b)". > And the plain truth is that no compiler does, and that is what > matters in the end. I think it's cleaner to avoid relying on undefined behavior (eg gcc 4.5 will probably break things), especially when the fix is so simple -- something the following should work fine: --- 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 diff --git a/drivers/net/niu.c b/drivers/net/niu.c index 9acb5d7..1fb0d2f 100644 --- a/drivers/net/niu.c +++ b/drivers/net/niu.c @@ -51,8 +51,8 @@ MODULE_VERSION(DRV_MODULE_VERSION); #ifndef readq static u64 readq(void __iomem *reg) { - return (((u64)readl(reg + 0x4UL) << 32) | - (u64)readl(reg)); + u64 v = readl(reg); + return v | (u64) readl(reg + 0x4UL) << 32; } static void writeq(u64 val, void __iomem *reg)