From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Ungerer Date: Wed, 26 Jun 2019 07:23:11 +0000 Subject: Re: [PATCH 08/17] binfmt_flat: consolidate two version of flat_v2_reloc_t Message-Id: List-Id: References: <20190613070903.17214-1-hch@lst.de> <20190613070903.17214-9-hch@lst.de> <20190625222941.GA1343@ZenIV.linux.org.uk> In-Reply-To: <20190625222941.GA1343@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Al Viro , Christoph Hellwig Cc: uclinux-h8-devel@lists.sourceforge.jp, linux-xtensa@linux-xtensa.org, Michal Simek , linux-c6x-dev@linux-c6x.org, linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-riscv@lists.infradead.org, linux-arm-kernel@lists.infradead.org On 26/6/19 8:29 am, Al Viro wrote: > On Thu, Jun 13, 2019 at 09:08:54AM +0200, Christoph Hellwig wrote: >> Two branches of the ifdef maze actually have the same content, so merge >> them. >> >> Signed-off-by: Christoph Hellwig >> --- >> include/linux/flat.h | 6 ++---- >> 1 file changed, 2 insertions(+), 4 deletions(-) >> >> diff --git a/include/linux/flat.h b/include/linux/flat.h >> index 2b7cda6e9c1b..19c586b74b99 100644 >> --- a/include/linux/flat.h >> +++ b/include/linux/flat.h >> @@ -69,15 +69,13 @@ struct flat_hdr { >> typedef union { >> unsigned long value; >> struct { >> -# if defined(mc68000) && !defined(CONFIG_COLDFIRE) >> +#if defined(__LITTLE_ENDIAN_BITFIELD) || \ >> + (defined(mc68000) && !defined(CONFIG_COLDFIRE)) >> signed long offset : 30; >> unsigned long type : 2; >> # elif defined(__BIG_ENDIAN_BITFIELD) >> unsigned long type : 2; >> signed long offset : 30; >> -# elif defined(__LITTLE_ENDIAN_BITFIELD) >> - signed long offset : 30; >> - unsigned long type : 2; >> # else >> # error "Unknown bitfield order for flat files." >> # endif >> -- >> 2.20.1 >> > > FWIW, I wonder if keeping that type is worth bothering. > Something like > old_reloc(__be32 reloc) > { > u32 v = be32_to_cpu(reloc); > int offset, type; > > #if (defined(mc68000) && !defined(CONFIG_COLDFIRE)) > /* old m68k uses unusual format - type is in lower bits of octet 3 */ > type = v % 4; > offset = (int)v / 4; > #else > /* everything else (including coldfire) has it in upper bits of octet 0 */ > type = v >> 30; > offset = (int)(v << 2) >> 2; /* or (v & 0x1fffffff) - (v & 0x20000000) * 4 */ > #endif > ... > > and to hell with bitfields, aliasing unions, etc. Unless I'm misreading > the whole thing, that is... Greg? I think you are right. This is much better. The old mc6800 is the odd one out, the rest have it in network order, and this makes that much clearer. Regards Greg From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE96BC48BD3 for ; Wed, 26 Jun 2019 07:23:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 77C06208E3 for ; Wed, 26 Jun 2019 07:23:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726930AbfFZHXR (ORCPT ); Wed, 26 Jun 2019 03:23:17 -0400 Received: from mail.kernel.org ([198.145.29.99]:32970 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725954AbfFZHXQ (ORCPT ); Wed, 26 Jun 2019 03:23:16 -0400 Received: from [10.44.0.22] (unknown [103.48.210.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1008020665; Wed, 26 Jun 2019 07:23:13 +0000 (UTC) Subject: Re: [PATCH 08/17] binfmt_flat: consolidate two version of flat_v2_reloc_t To: Al Viro , Christoph Hellwig Cc: Michal Simek , linux-arm-kernel@lists.infradead.org, linux-c6x-dev@linux-c6x.org, uclinux-h8-devel@lists.sourceforge.jp, linux-m68k@lists.linux-m68k.org, linux-riscv@lists.infradead.org, linux-sh@vger.kernel.org, linux-xtensa@linux-xtensa.org, linux-kernel@vger.kernel.org References: <20190613070903.17214-1-hch@lst.de> <20190613070903.17214-9-hch@lst.de> <20190625222941.GA1343@ZenIV.linux.org.uk> From: Greg Ungerer Message-ID: Date: Wed, 26 Jun 2019 17:23:11 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <20190625222941.GA1343@ZenIV.linux.org.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 26/6/19 8:29 am, Al Viro wrote: > On Thu, Jun 13, 2019 at 09:08:54AM +0200, Christoph Hellwig wrote: >> Two branches of the ifdef maze actually have the same content, so merge >> them. >> >> Signed-off-by: Christoph Hellwig >> --- >> include/linux/flat.h | 6 ++---- >> 1 file changed, 2 insertions(+), 4 deletions(-) >> >> diff --git a/include/linux/flat.h b/include/linux/flat.h >> index 2b7cda6e9c1b..19c586b74b99 100644 >> --- a/include/linux/flat.h >> +++ b/include/linux/flat.h >> @@ -69,15 +69,13 @@ struct flat_hdr { >> typedef union { >> unsigned long value; >> struct { >> -# if defined(mc68000) && !defined(CONFIG_COLDFIRE) >> +#if defined(__LITTLE_ENDIAN_BITFIELD) || \ >> + (defined(mc68000) && !defined(CONFIG_COLDFIRE)) >> signed long offset : 30; >> unsigned long type : 2; >> # elif defined(__BIG_ENDIAN_BITFIELD) >> unsigned long type : 2; >> signed long offset : 30; >> -# elif defined(__LITTLE_ENDIAN_BITFIELD) >> - signed long offset : 30; >> - unsigned long type : 2; >> # else >> # error "Unknown bitfield order for flat files." >> # endif >> -- >> 2.20.1 >> > > FWIW, I wonder if keeping that type is worth bothering. > Something like > old_reloc(__be32 reloc) > { > u32 v = be32_to_cpu(reloc); > int offset, type; > > #if (defined(mc68000) && !defined(CONFIG_COLDFIRE)) > /* old m68k uses unusual format - type is in lower bits of octet 3 */ > type = v % 4; > offset = (int)v / 4; > #else > /* everything else (including coldfire) has it in upper bits of octet 0 */ > type = v >> 30; > offset = (int)(v << 2) >> 2; /* or (v & 0x1fffffff) - (v & 0x20000000) * 4 */ > #endif > ... > > and to hell with bitfields, aliasing unions, etc. Unless I'm misreading > the whole thing, that is... Greg? I think you are right. This is much better. The old mc6800 is the odd one out, the rest have it in network order, and this makes that much clearer. Regards Greg From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BB80AC4646B for ; Wed, 26 Jun 2019 07:24:16 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 93E89208E3 for ; Wed, 26 Jun 2019 07:24:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="QUbBw66w" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 93E89208E3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-riscv-bounces+infradead-linux-riscv=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=/i5HwRim4rse2/XkybRRhPEGeZDtoEAa5jizMkvg6kY=; b=QUbBw66wunZnNDP9qGF7Ylf28 DiJgZ6AGvkAs30cANyKXTOr6hYuSGCdK8uLr6s/fbdz+vLvyh0aT7nC+iUHJzgxnV0qbegAPsgWiU ZdsUF82G3YQ9W5hmPTxas0ReCH6ORiBHuB17Ly2tRB8lnmStl5byCKyADh6sx4lu+mVO4El4b8pjq B6kEzEKypcZyBTh8VppCrdvLRpizhbLwcnZWo5S9f3kT06kH+v80R+Sdc/hmHbCGomGojGp7oO/q5 RKF9BSItKiMhZz5+GHBaFYFExbC8QPxavxywTotfyXo1T26EoFXZaBrlHhml3LkAeNFg0nPGlL/DM YKN5WTDUQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hg2Hq-0002sy-6X; Wed, 26 Jun 2019 07:24:10 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hg2Gz-0002Ly-Bu; Wed, 26 Jun 2019 07:23:20 +0000 Received: from [10.44.0.22] (unknown [103.48.210.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1008020665; Wed, 26 Jun 2019 07:23:13 +0000 (UTC) Subject: Re: [PATCH 08/17] binfmt_flat: consolidate two version of flat_v2_reloc_t To: Al Viro , Christoph Hellwig References: <20190613070903.17214-1-hch@lst.de> <20190613070903.17214-9-hch@lst.de> <20190625222941.GA1343@ZenIV.linux.org.uk> From: Greg Ungerer Message-ID: Date: Wed, 26 Jun 2019 17:23:11 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <20190625222941.GA1343@ZenIV.linux.org.uk> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190626_002317_761114_D17EE4F5 X-CRM114-Status: GOOD ( 15.77 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: uclinux-h8-devel@lists.sourceforge.jp, linux-xtensa@linux-xtensa.org, Michal Simek , linux-c6x-dev@linux-c6x.org, linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-riscv@lists.infradead.org, linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-riscv" Errors-To: linux-riscv-bounces+infradead-linux-riscv=archiver.kernel.org@lists.infradead.org On 26/6/19 8:29 am, Al Viro wrote: > On Thu, Jun 13, 2019 at 09:08:54AM +0200, Christoph Hellwig wrote: >> Two branches of the ifdef maze actually have the same content, so merge >> them. >> >> Signed-off-by: Christoph Hellwig >> --- >> include/linux/flat.h | 6 ++---- >> 1 file changed, 2 insertions(+), 4 deletions(-) >> >> diff --git a/include/linux/flat.h b/include/linux/flat.h >> index 2b7cda6e9c1b..19c586b74b99 100644 >> --- a/include/linux/flat.h >> +++ b/include/linux/flat.h >> @@ -69,15 +69,13 @@ struct flat_hdr { >> typedef union { >> unsigned long value; >> struct { >> -# if defined(mc68000) && !defined(CONFIG_COLDFIRE) >> +#if defined(__LITTLE_ENDIAN_BITFIELD) || \ >> + (defined(mc68000) && !defined(CONFIG_COLDFIRE)) >> signed long offset : 30; >> unsigned long type : 2; >> # elif defined(__BIG_ENDIAN_BITFIELD) >> unsigned long type : 2; >> signed long offset : 30; >> -# elif defined(__LITTLE_ENDIAN_BITFIELD) >> - signed long offset : 30; >> - unsigned long type : 2; >> # else >> # error "Unknown bitfield order for flat files." >> # endif >> -- >> 2.20.1 >> > > FWIW, I wonder if keeping that type is worth bothering. > Something like > old_reloc(__be32 reloc) > { > u32 v = be32_to_cpu(reloc); > int offset, type; > > #if (defined(mc68000) && !defined(CONFIG_COLDFIRE)) > /* old m68k uses unusual format - type is in lower bits of octet 3 */ > type = v % 4; > offset = (int)v / 4; > #else > /* everything else (including coldfire) has it in upper bits of octet 0 */ > type = v >> 30; > offset = (int)(v << 2) >> 2; /* or (v & 0x1fffffff) - (v & 0x20000000) * 4 */ > #endif > ... > > and to hell with bitfields, aliasing unions, etc. Unless I'm misreading > the whole thing, that is... Greg? I think you are right. This is much better. The old mc6800 is the odd one out, the rest have it in network order, and this makes that much clearer. Regards Greg _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 252D4C4646B for ; Wed, 26 Jun 2019 07:23:48 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EC920208E3 for ; Wed, 26 Jun 2019 07:23:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="PRjwjnPd" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EC920208E3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=d8Es0fskiXrwTzrrp8XexphQd/751BfSHvuvj3psUv0=; b=PRjwjnPdLAW5A5jBqo77ZPcha OuNxRmiClb146I3puyCeu5lOYUaB23u82XIpd2C33uiQbNbJVVsCUyu2Y4n9oaHD1+fZyHrCuMyBv uhOyvoLxbrQae4eW9yyw1gJ5cl8stFiH3OHc6D1uroPJ6lksFpdIVChjINquxzPXwK1fUHq+Vi1ge LJmDnocgWLQANXpAZWDd/bLo4wSBJP0PTHCX4vW7IIMjWR1ZNktPg2P7Ukko4jD0xFVhSSzDAfyeG Ihcn5uFxK9RwLskHCy3DLY9bB7fVkHm02nzDj8fCts9p/ABSAm51rHFunvB4nomkCSfeKWWCpMKYi 03hqw4XXg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hg2HR-0002dT-23; Wed, 26 Jun 2019 07:23:45 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hg2Gz-0002Ly-Bu; Wed, 26 Jun 2019 07:23:20 +0000 Received: from [10.44.0.22] (unknown [103.48.210.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1008020665; Wed, 26 Jun 2019 07:23:13 +0000 (UTC) Subject: Re: [PATCH 08/17] binfmt_flat: consolidate two version of flat_v2_reloc_t To: Al Viro , Christoph Hellwig References: <20190613070903.17214-1-hch@lst.de> <20190613070903.17214-9-hch@lst.de> <20190625222941.GA1343@ZenIV.linux.org.uk> From: Greg Ungerer Message-ID: Date: Wed, 26 Jun 2019 17:23:11 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <20190625222941.GA1343@ZenIV.linux.org.uk> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190626_002317_761114_D17EE4F5 X-CRM114-Status: GOOD ( 15.77 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: uclinux-h8-devel@lists.sourceforge.jp, linux-xtensa@linux-xtensa.org, Michal Simek , linux-c6x-dev@linux-c6x.org, linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-riscv@lists.infradead.org, linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 26/6/19 8:29 am, Al Viro wrote: > On Thu, Jun 13, 2019 at 09:08:54AM +0200, Christoph Hellwig wrote: >> Two branches of the ifdef maze actually have the same content, so merge >> them. >> >> Signed-off-by: Christoph Hellwig >> --- >> include/linux/flat.h | 6 ++---- >> 1 file changed, 2 insertions(+), 4 deletions(-) >> >> diff --git a/include/linux/flat.h b/include/linux/flat.h >> index 2b7cda6e9c1b..19c586b74b99 100644 >> --- a/include/linux/flat.h >> +++ b/include/linux/flat.h >> @@ -69,15 +69,13 @@ struct flat_hdr { >> typedef union { >> unsigned long value; >> struct { >> -# if defined(mc68000) && !defined(CONFIG_COLDFIRE) >> +#if defined(__LITTLE_ENDIAN_BITFIELD) || \ >> + (defined(mc68000) && !defined(CONFIG_COLDFIRE)) >> signed long offset : 30; >> unsigned long type : 2; >> # elif defined(__BIG_ENDIAN_BITFIELD) >> unsigned long type : 2; >> signed long offset : 30; >> -# elif defined(__LITTLE_ENDIAN_BITFIELD) >> - signed long offset : 30; >> - unsigned long type : 2; >> # else >> # error "Unknown bitfield order for flat files." >> # endif >> -- >> 2.20.1 >> > > FWIW, I wonder if keeping that type is worth bothering. > Something like > old_reloc(__be32 reloc) > { > u32 v = be32_to_cpu(reloc); > int offset, type; > > #if (defined(mc68000) && !defined(CONFIG_COLDFIRE)) > /* old m68k uses unusual format - type is in lower bits of octet 3 */ > type = v % 4; > offset = (int)v / 4; > #else > /* everything else (including coldfire) has it in upper bits of octet 0 */ > type = v >> 30; > offset = (int)(v << 2) >> 2; /* or (v & 0x1fffffff) - (v & 0x20000000) * 4 */ > #endif > ... > > and to hell with bitfields, aliasing unions, etc. Unless I'm misreading > the whole thing, that is... Greg? I think you are right. This is much better. The old mc6800 is the odd one out, the rest have it in network order, and this makes that much clearer. Regards Greg _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel