From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933668AbcCOWY2 (ORCPT ); Tue, 15 Mar 2016 18:24:28 -0400 Received: from mx2.suse.de ([195.135.220.15]:58745 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932180AbcCOWYY (ORCPT ); Tue, 15 Mar 2016 18:24:24 -0400 Date: Tue, 15 Mar 2016 23:24:22 +0100 From: "Luis R. Rodriguez" To: Ingo Molnar Cc: "Luis R. Rodriguez" , paulmck@linux.vnet.ibm.com, bp@alien8.de, tglx@linutronix.de, hpa@zytor.com, toshi.kani@hp.com, airlied@redhat.com, benh@kernel.crashing.org, mst@redhat.com, vinod.koul@intel.com, jgross@suse.com, daniel.vetter@ffwll.ch, luto@amacapital.net, davem@davemloft.net, ben@decadent.org.uk, benjamin.poirier@gmail.com, linux-fbdev@vger.kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, linux-doc@vger.kernel.org, corbet@lwn.net Subject: Re: [PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on PAT / non-PAT systems" Message-ID: <20160315222422.GH1990@wotan.suse.de> References: <20160304210900.GT3577@linux.vnet.ibm.com> <1457131501-14855-1-git-send-email-mcgrof@kernel.org> <20160305115255.GA11846@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160305115255.GA11846@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Mar 05, 2016 at 12:52:55PM +0100, Ingo Molnar wrote: > > * Luis R. Rodriguez wrote: > > > The current documentation refers to using set_memory_wc() as a > > possible hole strategy when you have overlapping ioremap() regions, > > The whole explanation should talk about virtual aliases over the same physical > address, not some 'overlapping regions'. > > I see where this talk about 'overlap' comes: the memtype rbtree in > arch/x86/mm/pat_rbtree.c indeed has memtype ranges that may overlap on the > physical side. But it is highly confusing to call this 'overlapping' on the driver > API documentation level without making it really clear what it's about. Alright thanks, I think I'll just stick to aliasing. I'll go over the threads and pick out only what is relevant. Luis From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Luis R. Rodriguez" Date: Tue, 15 Mar 2016 22:24:22 +0000 Subject: Re: [PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on PAT / non-PAT systems" Message-Id: <20160315222422.GH1990@wotan.suse.de> List-Id: References: <20160304210900.GT3577@linux.vnet.ibm.com> <1457131501-14855-1-git-send-email-mcgrof@kernel.org> <20160305115255.GA11846@gmail.com> In-Reply-To: <20160305115255.GA11846@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Ingo Molnar Cc: "Luis R. Rodriguez" , paulmck@linux.vnet.ibm.com, bp@alien8.de, tglx@linutronix.de, hpa@zytor.com, toshi.kani@hp.com, airlied@redhat.com, benh@kernel.crashing.org, mst@redhat.com, vinod.koul@intel.com, jgross@suse.com, daniel.vetter@ffwll.ch, luto@amacapital.net, davem@davemloft.net, ben@decadent.org.uk, benjamin.poirier@gmail.com, linux-fbdev@vger.kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, linux-doc@vger.kernel.org, corbet@lwn.net On Sat, Mar 05, 2016 at 12:52:55PM +0100, Ingo Molnar wrote: > > * Luis R. Rodriguez wrote: > > > The current documentation refers to using set_memory_wc() as a > > possible hole strategy when you have overlapping ioremap() regions, > > The whole explanation should talk about virtual aliases over the same physical > address, not some 'overlapping regions'. > > I see where this talk about 'overlap' comes: the memtype rbtree in > arch/x86/mm/pat_rbtree.c indeed has memtype ranges that may overlap on the > physical side. But it is highly confusing to call this 'overlapping' on the driver > API documentation level without making it really clear what it's about. Alright thanks, I think I'll just stick to aliasing. I'll go over the threads and pick out only what is relevant. Luis