From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:400c:c0c::243; helo=mail-wr0-x243.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wr0-x243.google.com (mail-wr0-x243.google.com [IPv6:2a00:1450:400c:c0c::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id D504222590E3F for ; Tue, 17 Apr 2018 06:26:54 -0700 (PDT) Received: by mail-wr0-x243.google.com with SMTP id s18so35518469wrg.9 for ; Tue, 17 Apr 2018 06:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=n+S4b0Yw0TC3TKPWXy58nzS0A+eiUROJVIxSgK4wYAA=; b=EYH3S7dvfbkBbxLnV+nvHTI+rYCYPwMahHLqrL9m++zbfeFSbtGzxOg04fE9tRAOZw 5/tRv7zucHNEis1YXQ9M51LqHghICNlRwMZ+ijkAc2tWooDn9E3443p33YVkU2P7jYH+ OrkgkAY1MZIVqfutCvCkObxThyqm6eQ2Lrb8U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=n+S4b0Yw0TC3TKPWXy58nzS0A+eiUROJVIxSgK4wYAA=; b=kMdG3dPCRLgcjMDe621o1oWAxTxqIW3E3xf8F9UH7oEW/rfl8EDaQgYi9yOQA3DLXy CNUpcG479Kbj+H4ZHg1LJAK3sHVGCxszTp4ILkL5pzlPLD2Q0eRqy4B+VK3lyzUMCY9r HVMVk20UkYgjbns5LcCi6ISV4wQ+jc6lmdNKjk7oSz9KSIrF34PmmSNJYCYN6Wl1a+h5 4CjPnM5KzXdq1hDY11riZnLOYBL7IG99TXZ0fAL0bmjYva93QWtZlN3eBOMDcPby102y XRPcD6pYnrL6Z5NjbbJSeyYD4vzsK2PeFTohw1OSLErq6ReWQTej8OPoUnw2RyLvHGg3 z87Q== X-Gm-Message-State: ALQs6tD5FMz2/Aw17Y6SqBmHyigN/A6nzQUn0UeUmmnYCnqLZMgIFEtZ 2MrLa89x+HizwhNS921+jMN1RA== X-Google-Smtp-Source: AIpwx48fSHaYfM9aUBwTiPtcxTNKWyILgU2DEZ5pc5sdsR4FkS3sL0WkQptN+X57mgdyL+/KOj4AaQ== X-Received: by 10.223.138.240 with SMTP id z45mr1551275wrz.150.1523971612858; Tue, 17 Apr 2018 06:26:52 -0700 (PDT) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id a139sm5842523wma.43.2018.04.17.06.26.51 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 17 Apr 2018 06:26:51 -0700 (PDT) Date: Tue, 17 Apr 2018 14:26:49 +0100 From: Leif Lindholm To: "Kinney, Michael D" , "Gao, Liming" , Laszlo Ersek Cc: "edk2-devel@lists.01.org" Message-ID: <20180417132649.wv7ql7xxfezzhxsl@bivouac.eciton.net> 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> MIME-Version: 1.0 In-Reply-To: <09cc135a-c3b7-bcbd-1a71-6454e3ba7623@redhat.com> User-Agent: NeoMutt/20170113 (1.7.2) 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 13:26:55 -0000 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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.  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?  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. Yes. I'm thinking that is a good enough solution for this type of situation and I overcomplicated things. Apologies for that. 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. So, Mike, Liming - would you be OK with a solution similar to https://www.mail-archive.com/edk2-devel@lists.01.org/msg36520.html. / Leif