From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.120; helo=mga04.intel.com; envelope-from=michael.d.kinney@intel.com; receiver=edk2-devel@lists.01.org Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (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 F2F9822590E3A for ; Tue, 17 Apr 2018 08:20:34 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Apr 2018 08:20:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,464,1517904000"; d="scan'208";a="32641082" Received: from orsmsx109.amr.corp.intel.com ([10.22.240.7]) by fmsmga007.fm.intel.com with ESMTP; 17 Apr 2018 08:20:34 -0700 Received: from orsmsx152.amr.corp.intel.com (10.22.226.39) by ORSMSX109.amr.corp.intel.com (10.22.240.7) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 17 Apr 2018 08:20:33 -0700 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.55]) by ORSMSX152.amr.corp.intel.com ([169.254.8.130]) with mapi id 14.03.0319.002; Tue, 17 Apr 2018 08:20:33 -0700 From: "Kinney, Michael D" To: Leif Lindholm , "Gao, Liming" , Laszlo Ersek , "Kinney, Michael D" CC: "edk2-devel@lists.01.org" Thread-Topic: [edk2] [PATCH] MdePkg: add big-endian MMIO BaseBeIoLib Thread-Index: AQHT007FDvjdHbPkR0WQ38GOtMXuhKP/EwwggAB3ywD//8uvEIAETZUA///NthCAAHzeAIAAZucAgAEYn4D//6mwMA== Date: Tue, 17 Apr 2018 15:20:32 +0000 Message-ID: References: <20180413174211.858-1-leif.lindholm@linaro.org> <20180413193143.t45tua3yi7sopk4d@bivouac.eciton.net> <20180416100712.6v642ycksvmoffvt@bivouac.eciton.net> <52ea5684-380d-0519-2545-6ef7f62198ae@ipxe.org> <09cc135a-c3b7-bcbd-1a71-6454e3ba7623@redhat.com> <20180417132649.wv7ql7xxfezzhxsl@bivouac.eciton.net> In-Reply-To: <20180417132649.wv7ql7xxfezzhxsl@bivouac.eciton.net> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.22.254.140] MIME-Version: 1.0 Subject: Re: [PATCH] MdePkg: add big-endian MMIO BaseBeIoLib X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 15:20:35 -0000 Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Leif, Yes. I think the single swap lib is sufficient for the specific use case. We can wait until there is a request to add support=20 for a BE CPU to look at a more complete solution to reusing the same module sources for all combinations of CPU and I/O endianness. Thanks, Mike > -----Original Message----- > From: Leif Lindholm [mailto:leif.lindholm@linaro.org] > Sent: Tuesday, April 17, 2018 6:27 AM > To: Kinney, Michael D ; > Gao, Liming ; Laszlo Ersek > > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] [PATCH] MdePkg: add big-endian MMIO > BaseBeIoLib >=20 > On Mon, Apr 16, 2018 at 10:42:26PM +0200, Laszlo Ersek > wrote: > > On 04/16/18 16:34, Michael Brown wrote: > > > On 16/04/18 15:10, Kinney, Michael D wrote: > > >> I agree that the opposite use case is a BE CPU > > >> needing a LE operation. > > >> > > >> I think we only need a single lib class and lib > > >> Instance that does the byte swap and we should > > >> not use Le or Be in any of the names of the class, > > >> instance, or APIs.=A0 Just "Swap". > > > > > > I may have misunderstood, but wouldn't using "Swap" > within the API names > > > effectively encode knowledge of the endianness of > the _build_ platform > > > into the source code?=A0 This would prevent the same > source code being > > > built for both little-endian and big-endian CPUs. > > > > Under this scenario, all drivers meant to be portable > to both byte > > orders would have to: > > - link against both IoLib and IoSwapLib, > > - determine at device binding time, from CPU > endianness and device > > endianness combined, whether swapping was needed > for that device, > > - call the IoLib or IoSwapLib APIs through wrapper > functions, or > > function pointers. >=20 > Yes. I'm thinking that is a good enough solution for > this type of > situation and I overcomplicated things. Apologies for > that. >=20 > We are talking about the relatively unusual situation > where an > otherwise driver-compatible device can in some > platforms be of a > different endianness than in others. >=20 > So, Mike, Liming - would you be OK with a solution > similar to > https://www.mail-archive.com/edk2- > devel@lists.01.org/msg36520.html. >=20 > / > Leif