From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3FCC62C00A6 for ; Tue, 24 Dec 2013 15:37:15 +1100 (EST) Message-ID: <1387859821.4373.10.camel@pasglop> Subject: Re: [PATCH] ibmveth: Fix more little endian issues From: Benjamin Herrenschmidt To: Joe Perches Date: Tue, 24 Dec 2013 15:37:01 +1100 In-Reply-To: <1387810329.22671.66.camel@joe-AO722> References: <1387762163-39662-1-git-send-email-agraf@suse.de> <20131223173833.0a9a6705@kryten> <1387810329.22671.66.camel@joe-AO722> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Cc: netdev@vger.kernel.org, Dinar Valeev , linuxppc-dev@lists.ozlabs.org, Alexander Graf , Anton Blanchard , Santiago Leon List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, 2013-12-23 at 06:52 -0800, Joe Perches wrote: > On Mon, 2013-12-23 at 17:38 +1100, Anton Blanchard wrote: > > The hypervisor expects MAC addresses passed in registers to be big > > endian u64. > > So maybe use __be64 declarations? > > > +static unsigned long ibmveth_encode_mac_addr(char *mac) > > static __be64 ibmveth_encode_mac_addr(const char *mac) A register value has no endianness. Only memory content does. Especially talking of a MAC address which is really a byte stream.... (Yes, our __beXX types used without a * are borderline, but we've got used to it). In fact I find the use of memcpy(((char *)&encoded) + 2, mac, ETH_ALEN); Really gross :-) Yes it works with the added cpu_to_be64() but in that specific case, I think it would be nicer to simply load & shift into position the 6 bytes and avoid the endianness issue completely. Cheers, Ben.