Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp4143276ybp; Sun, 13 Oct 2019 23:14:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqxufbXhaQxgJNcb1Yjxoszvi6YdRNoeszYsL4+yJAazFjVu/HwF5DKE86UZkGeQsw8USB/C X-Received: by 2002:a50:9f68:: with SMTP id b95mr26180713edf.301.1571033691053; Sun, 13 Oct 2019 23:14:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571033691; cv=none; d=google.com; s=arc-20160816; b=J+YzkGRyYe1s4e9TrQ01CzpSntexVV3E24x91BPF+4pLvxrb3Y4gTUrF1WU8mCr4ln K/94iCo5zXy7qYZCBRruuui5IPhS9sI15nIZ85SA+LMVoxiau44oNLqqCZkB2Qd7N35U zjKe6G+/I0DSmZ1rzEpGHLi1tYf4Ww6juqR8tilppGHL+SO6wSecuEsxMOIg0W2VaoGv dRV4Mp+OCKSVl8IvkPlyuGyytOeLq4LQNfxLYYIekGsfj8t5hPZ2aNQfg9xqO6r7h0Ho niPfiWQVJDNUw/VFujULFgN5scdRl6tw3ydVQgUebqswBwWuv6NDhSzi4Zgy2oP/NRjN nnWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=EueXe+GBBz0N44PeGkK+Z63qRjHOXGQH8i+YNA5EqDg=; b=Vcoa0bqFZGUqlD3jLB9yDHdyQvtuYI7JSNilVlMjSTZ0OsW/Ww24Z1P8Wx+JRHRw61 vR2vpV8u8NI+Te4g43qz0shkOwjLY8W0HlDgkMbaWxEuhXob2x0cUQEBQnnACo+wq1tD Xj+65/Jy2U6MxXbvlylZeenIKE2btAt0ZzuVbRppJ6u72hxSs6HZYiabzevaproysXmY MyxjtKBuTO7O4u0gBspDzeNr4pTrFWgbzwh+5jraz+ItPfmUAKIwIGSkMnrwO0FMQyLk WRM4GQgCWwssHsm3HZ3bDFLEcHkOr7VOpdNUrB1jtxyypbVH4K4gxhaS1HAMHkcymtRx jhnA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w11si10889756edi.442.2019.10.13.23.14.27; Sun, 13 Oct 2019 23:14:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729967AbfJNGNO (ORCPT + 99 others); Mon, 14 Oct 2019 02:13:14 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:3705 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725936AbfJNGNO (ORCPT ); Mon, 14 Oct 2019 02:13:14 -0400 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 92DBC18C626919661A6C; Mon, 14 Oct 2019 14:13:11 +0800 (CST) Received: from [127.0.0.1] (10.177.223.23) by DGGEMS413-HUB.china.huawei.com (10.3.19.213) with Microsoft SMTP Server id 14.3.439.0; Mon, 14 Oct 2019 14:13:03 +0800 Subject: Re: [PATCH 3/3] arm64: configs: unset CPU_BIG_ENDIAN To: Arnd Bergmann CC: Will Deacon , Anders Roxell , Catalin Marinas , John Garry , Linux Kernel Mailing List , Olof Johansson , Linux ARM References: <20190926193030.5843-1-anders.roxell@linaro.org> <20190926193030.5843-5-anders.roxell@linaro.org> <20191011102747.lpbaur2e4nqyf7sw@willie-the-truck> <73701e9f-bee1-7ae8-2277-7a3576171cd4@huawei.com> From: Hanjun Guo Message-ID: Date: Mon, 14 Oct 2019 14:12:03 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.223.23] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Arnd, On 2019/10/12 22:05, Arnd Bergmann wrote: > On Sat, Oct 12, 2019 at 9:33 AM Hanjun Guo wrote: >> >> On 2019/10/11 18:27, Will Deacon wrote: >> [...] >>> >>> Does anybody use BIG_ENDIAN? If we're not even building it then maybe we >>> should get rid of it altogether on arm64. I don't know of any supported >>> userspace that supports it or any CPUs that are unable to run little-endian >>> binaries. >> >> FWIW, massive telecommunication products (based on ARM64) form Huawei are using >> BIG_ENDIAN, and will use BIG_ENDIAN in the near future as well. > > Ok, thanks for the information -- that definitely makes it clear that > it cannot go > away anytime soon (though it doesn't stop us from change the > allmodconfig default > if we decide that's a good idea). I agree with you. > > Do you know if there are currently any patches against mainline to > make big-endian > work in products, or is everything working out of the box? We are not using mainline kernel for product, but LTS 4.4 is working fine, and also we tested LTS 4.19 kernel without any other big-endian patches, the latest big-endian bug we found is this: a6002ec5a8c6 arm64: opcodes.h: Add arm big-endian config options before including arm header The running kernel code covered but Huawei's telecommunication products is limited, but I think ARM64 arch code is working fine for big-endian. Thanks Hanjun