From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 D7AF41A1E69 for ; Thu, 8 Sep 2016 13:54:04 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id w12so56868225wmf.0 for ; Thu, 08 Sep 2016 13:54:04 -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:in-reply-to:user-agent; bh=eC2paSk9hr5Kot+p4a5m0VwgZgiZn1Wfk6WKEEy6P3E=; b=BuMK+jvAMUDTuXjGK6d/Uw7b7Gy2MhqWvs3pQGmVeL9rOCeRi+toS/4bigjyWk94l5 f1OJDWTRztCrsCtkGvzCHnObNi5KvXwV/gwffVaxoPEgMgMycJuooMxP+E0I7SYSwKqi /W1l795/3E8BJnlSW2t70MMlalkGFWmXyPkxY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=eC2paSk9hr5Kot+p4a5m0VwgZgiZn1Wfk6WKEEy6P3E=; b=e4MrIYfh03k1BujcIKw91ML3y6E0ziXvyGpc7nBlrN7HNwOY45KQkQUIxL1mlsLess t9SlwAhJii+3vLsA05j8PVFAkViRDuz0DBzjK4OndnVO0x6Hk+M3ux0YijolN2NdoRDg 8lTgCT2Tij3ykA03VmaVSyFlPgb1pDIPTXv/8OspwZdiF/ep8N4tfbsnlsrvUKXBh0v0 qmk9vk0MmTNWAoMNyj6OYCJEv9PcC2/6bmS6wSYdS2yMrhvzUnZ54PjaN0Ug8kt1FpPn QZjfe6IHLdQWNGaWRawWOINIvKDwtvnWRHDjUTnY+AgRLoVDIoe69sjbIlhRl/9qbzn0 dEXw== X-Gm-Message-State: AE9vXwOTNwMXeBXrM8jpw0e5ACzMiMcaBVYEBYfse/sp2pH3fv3JM7T3u0V99OTk/8OY24xc X-Received: by 10.194.81.106 with SMTP id z10mr1308190wjx.140.1473368043502; Thu, 08 Sep 2016 13:54:03 -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 ub8sm46169935wjc.39.2016.09.08.13.54.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Sep 2016 13:54:02 -0700 (PDT) Date: Thu, 8 Sep 2016 21:54:01 +0100 From: Leif Lindholm To: "Cohen, Eugene" Cc: Ard Biesheuvel , "edk2-devel@lists.01.org" Message-ID: <20160908205401.GK16080@bivouac.eciton.net> References: <1473322418-9158-1-git-send-email-ard.biesheuvel@linaro.org> <20160908092153.GH16080@bivouac.eciton.net> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [PATCH] ArmPlatformPkg: remove EFI_MEMORY_UC attribute from normal memory X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 20:54:05 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Sep 08, 2016 at 05:37:13PM +0000, Cohen, Eugene wrote: > > I think this is the right thing to do; Arguably, on the modern ARM > > architectures, UNCACHEABLE and WRITE_COMBINEABLE are mutually > > exclusive. I'll discuss with Charles whether we should codify this in > > the UEFI specification. > > Given the corresponding X86 semantics it makes sense for UNCACHEABLE > to map to Strongly Ordered and WRITE_COMBINEABLE to map to "Normal" > Uncacheable. It's useful to expose this separately in case a DMA > common buffer has semantics that require the strongly ordered > behavior. > > Since this is providing a list of capabilities I'm not sure what the > statement about mutual exclusivity refers to. Do note the weasly "arguably" I stuck in there. My point is basically the same as yours, with the clarification that for purposes of treating something like general-purpose memory, flagging a location as possible to map as either UNCACHEABLE (ARM: Strongly Ordered) or WRITE_COMBINEABLE (ARM: Normal uncached) generally does not make sense. Regards, Leif