From patchwork Thu Jun 8 08:01:59 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 772902 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 3wjyZ3557nz9s7f for ; Thu, 8 Jun 2017 18:02:03 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="gS2K9eZk"; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751516AbdFHICC (ORCPT ); Thu, 8 Jun 2017 04:02:02 -0400 Received: from mail-oi0-f68.google.com ([209.85.218.68]:34504 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751470AbdFHICA (ORCPT ); Thu, 8 Jun 2017 04:02:00 -0400 Received: by mail-oi0-f68.google.com with SMTP id d99so2318132oic.1; Thu, 08 Jun 2017 01:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=KBoB3A1fqrPnfbmLsfajK9Ucm0hOWvz1iKVhoJ0WcUk=; b=gS2K9eZkQcFhvHZJryUd+04ueiCh7ol+lVRszrqIhkokTkjopbSEEQuLjd0ViT1OX7 9vfgbOAIYF2VxtbzZ6sB10CkEk2wXxngctdPP1q8wi6Ec/z3BiuPdKIVOko5dO71plPP oqmaeIiUxb8w0ncbMyQBooW5QPCEtk87Ehi4ZAMbjo9GrdqzyyAVlwfUETnsbydPf7PR +tht0/gh47u+RWJg0zxoNtOXLage/T7i8Dfb4mjKkijiWkJ4COP6LOH/lcpNlLaacej+ a3evgplBX/cno4OQGmBAMxycBrIcaZKFFvOzwEMkc1/Oy08/llDILa1hZN8f3WclsQt4 ZyzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=KBoB3A1fqrPnfbmLsfajK9Ucm0hOWvz1iKVhoJ0WcUk=; b=Y0t0orI05zcIq4q7ZF2DLqcVVLpXh8bd+zPkN+hHX2RwJ8MXTHZfwmfS5RLMlwTaUv OEqwdkEAY8YzF0lurxgR41OnInDOUBxBuHUQ1wwdS131qZSooh2owzDNtnqdD6xLMM/F PCAexkOeGSsBdrTSLb0DTjm/4uvbWKr1WO5MJy/4VoloQqpxjDSHgVV/soRhQ45eveqi coJ/Z+PUx/Vohbw9u3yOZ531HKTNgDktFspsYjRajhx62sUru6Sbj5QRRPIDlRim8Dhb cD2vS1WLp1NXOEy429Jz8G8mhf3zFibnBOyhLWqTQEq8YPBmMZ0Hmai2bRAD2Sc4xgQe eIcA== X-Gm-Message-State: AODbwcA1w7VcMOI71UwMb1dsZ5M2iv86fw1so29Y/q+hjMQaDnR1rpk9 ft9gIiWmf1ELb3cGsj2YSKZoiqSFyA== X-Received: by 10.202.206.23 with SMTP id e23mr18643114oig.168.1496908919691; Thu, 08 Jun 2017 01:01:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.51.139 with HTTP; Thu, 8 Jun 2017 01:01:59 -0700 (PDT) In-Reply-To: <28d6c874-4653-b15d-39b7-57a032abc9c6@oracle.com> References: <87a85v7to2.fsf@concordia.ellerman.id.au> <877f0z6oig.fsf@concordia.ellerman.id.au> <28d6c874-4653-b15d-39b7-57a032abc9c6@oracle.com> From: Arnd Bergmann Date: Thu, 8 Jun 2017 10:01:59 +0200 X-Google-Sender-Auth: -FYxCCN9aKOnCM15SjNtjeP0GZY Message-ID: Subject: Re: CPU_BIG_ENDIAN in generic code (was: Re: [PATCH v3 3/7] arch/sparc: Define config parameter CPU_BIG_ENDIAN) To: Babu Moger Cc: Michael Ellerman , Geert Uytterhoeven , "David S. Miller" , Peter Zijlstra , Ingo Molnar , sparclinux , "linux-kernel@vger.kernel.org" , Linux-Arch , "devicetree@vger.kernel.org" , "linux-serial@vger.kernel.org" Sender: sparclinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: sparclinux@vger.kernel.org On Thu, Jun 8, 2017 at 1:07 AM, Babu Moger wrote: > > On 5/29/2017 9:56 PM, Michael Ellerman wrote: >> >> Geert Uytterhoeven writes: >> >>> Hi Michael, >>> >>> On Mon, May 29, 2017 at 2:07 PM, Michael Ellerman >>> wrote: >>>> >>>> Geert Uytterhoeven writes: >>>>> >>>>> On Tue, May 23, 2017 at 11:45 PM, Babu Moger >>>>> wrote: >>> >>> So far we tried always doing that, but a few checks for the semi-existing >>> Kconfig symbol crept in in generic code. Those could be replaced by the >>> __*__ >>> variants, but consistently having the Kconfig symbols would be useful >>> anyway >>> (e.g. to avoid building the broken-on-big-endian ISDN drivers). >> >> Ah OK, the original mail was citing C code, but yeah I guess it would be >> handy in Makefiles etc. > > > Thanks for all the responses. I see couple of options here. > > 1. Fix the c code in include/asm-generic/qrwlock.h using ifdef > __BIG_ENDIAN__ > This will fix the issue for us. > > 2. Define CPU_BIG_ENDIAN for all the missing fixed endian architectures. > Because the problem is only for fixed big endian archs. > > I prefer the option 1. What do you guys think ? I would prefer option 2. If we leave out CONFIG_CPU_LITTLE_ENDIAN, then the patch becomes much easier than what we had discussed earlier, and we just need to patch a few Kconfig files to add config CPU_BIG_ENDIAN def_bool y I would also suggest adding a sanity check like Fixing xtensa properly might still be tricky, but with that change, at least we detect when things go wrong in this area. Arnd --- To unsubscribe from this list: send the line "unsubscribe sparclinux" 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/include/linux/byteorder/big_endian.h b/include/linux/byteorder/big_endian.h index 392041475c72..18a1ab5b0260 100644 --- a/include/linux/byteorder/big_endian.h +++ b/include/linux/byteorder/big_endian.h @@ -3,5 +3,9 @@ #include +#ifndef CONFIG_CPU_BIG_ENDIAN +#warning inconsistent configuration, need CONFIG_CPU_BIG_ENDIAN +#endif + #include #endif /* _LINUX_BYTEORDER_BIG_ENDIAN_H */ diff --git a/include/linux/byteorder/little_endian.h b/include/linux/byteorder/little_endian.h index 08057377aa23..ba910bb9aad0 100644 --- a/include/linux/byteorder/little_endian.h +++ b/include/linux/byteorder/little_endian.h @@ -3,5 +3,9 @@ #include +#ifdef CONFIG_CPU_BIG_ENDIAN +#warning inconsistent configuration, CONFIG_CPU_BIG_ENDIAN is set +#endif + #include #endif /* _LINUX_BYTEORDER_LITTLE_ENDIAN_H */