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::22f; helo=mail-wr0-x22f.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 7D5D62034D8C0 for ; Wed, 21 Feb 2018 10:52:23 -0800 (PST) Received: by mail-wr0-x22f.google.com with SMTP id f14so7404032wre.8 for ; Wed, 21 Feb 2018 10:58:23 -0800 (PST) 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:in-reply-to:user-agent; bh=vlmdEx5+y1eFfvz18y/Q9e/jeTT8RoCsD4pOkLqIOjU=; b=NPOYUaKbWf4RKwiFx3IqmVVoiEg5hDcaJgqfPxLNmI7ZMwV2wTEcEoz56loAq7BuqW PHLm31B5T4rhc0Vsx3dIBMSn255ci6FPd8mxloifMOd7UMKlHgcE6B33OavZbOwb5/b9 /sS5UosQ5v7aIq5f4Jxj1iMVh695XKCx5TbKI= 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:in-reply-to:user-agent; bh=vlmdEx5+y1eFfvz18y/Q9e/jeTT8RoCsD4pOkLqIOjU=; b=UGkXiLcHmw4goDk31IPl2Fthj+J2dLxv3sleBqBGlQkNEx76fo989laY/EgERDNThG M+B3LyA5NIobfsuwM1JJnTglimhMieaMk8lEWsfvjfNFLtFqM5mCuoYa1hJymMY1zwh2 hDGVzvrvFDqVJqnB/fvi6ssYhC3mLi5xDaiY7+Ov3uNp/6qNTS/jpsZu7IcUcmCcenXW jr8NP0HX7iNjCcHbw+apFSrBUgQYV3k6Z7PdzPHZahuIa0aVetkOSzO9wA9NSIw6bL8G 2N7FVyx4pZ6PiQinSzApmvRgZutApu7XJzIQz9r7XMnqNOAsB1v8H8vDnW+ZJwGzP5Zg JOyQ== X-Gm-Message-State: APf1xPAfpNU3yx9lk0SrIU1xKiEbmLmrrPHmfH5k4pIUE4aeP2OI/a/j CitYFXAQMMvYLHwhQd5euPvqkQ== X-Google-Smtp-Source: AH8x225/C5Sp6PA4ISnZIB/IdhxRbRlhaJWJhKGmJlikiKS1SgiubVIa2PVInG+Mg90jrfpFCFMAEw== X-Received: by 10.223.134.170 with SMTP id 39mr3756937wrx.221.1519239501663; Wed, 21 Feb 2018 10:58:21 -0800 (PST) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id u63sm23108311wrc.26.2018.02.21.10.58.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 21 Feb 2018 10:58:20 -0800 (PST) Date: Wed, 21 Feb 2018 18:58:18 +0000 From: Leif Lindholm To: Laszlo Ersek Cc: Meenakshi , michael.d.kinney@intel.com, edk2-devel@lists.01.org, ard.biesheuvel@linaro.org Message-ID: <20180221185818.arwfhombntutnt23@bivouac.eciton.net> 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> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) 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 18:52:24 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Feb 21, 2018 at 05:06:02PM +0100, Laszlo Ersek wrote: > 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. HTON/NTOH? The specs are not LE-only. PI _is_ (at this point in time) LE-only. UEFI leaves this entirely to architectural bindings. For PI, this is mentioned in a single paragraph, repeated 4 times in the PI 1.6 specification (due to it merging what was previously separate documents). > - 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. The actual watchdog code in this series, and comments made on the list, suggests that there exists variants of this _device_ with BE or LE byte order. If this is not the case, then yes, I agree that BE-naming makes sense. So, Meenakshi - can you confirm that the Watchdog driver is expected to be used against devices in both BE and LE mode? If it is the case, maybe this library would make more sense as the non-standard protocol you suggested in https://www.mail-archive.com/edk2-devel@lists.01.org/msg17869.html ? > 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. Right. But that brings back the complication as to how we have a driver that needs an LE IO library to write output, and a BE IO library to manipulate the hardware. / Leif