From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id AC6B2223C1765 for ; Wed, 21 Feb 2018 08:00:05 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A9B6C4040858; Wed, 21 Feb 2018 16:06:04 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-45.rdu2.redhat.com [10.10.120.45]) by smtp.corp.redhat.com (Postfix) with ESMTP id A7AD0213AEE2; Wed, 21 Feb 2018 16:06:03 +0000 (UTC) To: Leif Lindholm Cc: Meenakshi , michael.d.kinney@intel.com, edk2-devel@lists.01.org, ard.biesheuvel@linaro.org References: <1518771035-6733-1-git-send-email-meenakshi.aggarwal@nxp.com> <1518771035-6733-2-git-send-email-meenakshi.aggarwal@nxp.com> <20180221154601.nkbp2xmy3zb2xolm@bivouac.eciton.net> From: Laszlo Ersek Message-ID: Date: Wed, 21 Feb 2018 17:06:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180221154601.nkbp2xmy3zb2xolm@bivouac.eciton.net> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 21 Feb 2018 16:06:04 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 21 Feb 2018 16:06:04 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: [PATCH edk2-platforms 01/39] Silicon/NXP: Add support for Big Endian Mmio APIs X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 16:00:06 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 02/21/18 16:46, Leif Lindholm wrote: > Apologies for dropping the ball on this series during my sabbatical. > > For this particular patch, I would still like to see a core library > provide the needed functionality. I just sent out an RFC of a possible > implementation. > > Regardless, a key point is that this isn't about "big-endian", it is > about endianness opposite to the executing processor. I commented on just this aspect under your RFC. I think I disagree, for two reasons: - As long as the specs are LE-only, "endianness opposite to the executing processor" is needless complication / speculative generality in my eyes. - Even if we supported multiple endiannesses on the CPU front, the API names should reflect the *device* byte order, not the CPU byte order. Think of the case when the same platform device is integrated on board B1 whose CPU is LE, and on board B2 whose CPU is BE. If we name the APIs after the CPU byte order, then the same driver source code will be misleading on one of the boards. Whereas, if we name the APIs after device byte order, then the driver source code will be correct regardless of board / CPU, and only the internal workings of the APIs should change. For example, on a BE CPU / platform, the "normal" (LE) IoLib class should be resolved to an instance that byte-swaps internally, and the BE IoLib class should be resolved to an instance that is transparent internally. Thanks Laszlo