[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160305115255.GA11846@gmail.com>
Date: Sat, 5 Mar 2016 12:52:55 +0100
From: Ingo Molnar <mingo@...nel.org>
To: "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc: paulmck@...ux.vnet.ibm.com, bp@...en8.de, tglx@...utronix.de,
hpa@...or.com, toshi.kani@...com, airlied@...hat.com,
benh@...nel.crashing.org, mst@...hat.com, vinod.koul@...el.com,
jgross@...e.com, daniel.vetter@...ll.ch, luto@...capital.net,
davem@...emloft.net, ben@...adent.org.uk,
benjamin.poirier@...il.com, linux-fbdev@...r.kernel.org,
linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
x86@...nel.org, linux-doc@...r.kernel.org, corbet@....net
Subject: Re: [PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on PAT
/ non-PAT systems"
* Luis R. Rodriguez <mcgrof@...nel.org> 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.
Thanks,
Ingo
Powered by blists - more mailing lists