Commit-ID: 2baa891e42d84159b693eadd44f6fe1486285bdc Gitweb: http://git.kernel.org/tip/2baa891e42d84159b693eadd44f6fe1486285bdc Author: Luis R. Rodriguez <mcg...@suse.com> AuthorDate: Mon, 24 Aug 2015 12:13:33 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Fri, 28 Aug 2015 10:09:28 +0200
x86/mm/mtrr: Remove kernel internal MTRR interfaces: unexport mtrr_add() and mtrr_del() The effort to replace mtrr_add() with architecture agnostic arch_phys_wc_add() is complete, this will ensure write-combining implementations (PAT on x86) is taken advantage instead of using MTRR. With the effort done now, hide direct MTRR access for drivers. The legacy user-space /proc/mtrr ABI is not affected. Update x86 documentation on MTRR to reflect the completion of the phasing out of direct access to MTRR, also add a note on platform firmware code use of MTRRs based on the obituary discussion of MTRRs on Linux [0]. [0] http://lkml.kernel.org/r/1438991330.3109.196.ca...@hp.com Signed-off-by: Luis R. Rodriguez <mcg...@suse.com> Cc: <syrj...@sci.fi> Cc: Andy Lutomirski <l...@amacapital.net> Cc: Andy Walls <awa...@md.metrocast.net> Cc: Antonino Daplas <adap...@gmail.com> Cc: Borislav Petkov <b...@suse.de> Cc: Daniel Vetter <daniel.vet...@ffwll.ch> Cc: Dave Airlie <airl...@redhat.com> Cc: Dave Hansen <dave.han...@linux.intel.com> Cc: Davidlohr Bueso <dbu...@suse.de> Cc: Doug Ledford <dledf...@redhat.com> Cc: H. Peter Anvin <h...@zytor.com> Cc: Jean-Christophe Plagniol-Villard <plagn...@jcrosoft.com> Cc: Juergen Gross <jgr...@suse.com> Cc: Linus Torvalds <torva...@linux-foundation.org> Cc: Mel Gorman <mgor...@suse.de> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Suresh Siddha <sbsid...@gmail.com> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Tomi Valkeinen <tomi.valkei...@ti.com> Cc: Toshi Kani <toshi.k...@hp.com> Cc: Ville Syrjälä <syrj...@sci.fi> Cc: Vlastimil Babka <vba...@suse.cz> Cc: airl...@linux.ie Cc: b...@kernel.crashing.org Cc: bhelg...@google.com Cc: dan.j.willi...@intel.com Cc: konrad.w...@oracle.com Cc: linux-fb...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-me...@vger.kernel.org Cc: m...@redhat.com Cc: net...@vger.kernel.org Cc: vinod.k...@intel.com Cc: xen-de...@lists.xensource.com Link: http://lkml.kernel.org/r/1440443613-13696-12-git-send-email-mcg...@do-not-panic.com Signed-off-by: Ingo Molnar <mi...@kernel.org> --- Documentation/x86/mtrr.txt | 20 ++++++++++++++++---- arch/x86/kernel/cpu/mtrr/main.c | 2 -- 2 files changed, 16 insertions(+), 6 deletions(-) diff --git a/Documentation/x86/mtrr.txt b/Documentation/x86/mtrr.txt index 860bc3a..dc3e703 100644 --- a/Documentation/x86/mtrr.txt +++ b/Documentation/x86/mtrr.txt @@ -6,10 +6,22 @@ Luis R. Rodriguez <mcg...@do-not-panic.com> - April 9, 2015 =============================================================================== Phasing out MTRR use -MTRR use is replaced on modern x86 hardware with PAT. Over time the only type -of effective MTRR that is expected to be supported will be for write-combining. -As MTRR use is phased out device drivers should use arch_phys_wc_add() to make -MTRR effective on non-PAT systems while a no-op on PAT enabled systems. +MTRR use is replaced on modern x86 hardware with PAT. Direct MTRR use by +drivers on Linux is now completely phased out, device drivers should use +arch_phys_wc_add() in combination with ioremap_wc() to make MTRR effective on +non-PAT systems while a no-op but equally effective on PAT enabled systems. + +Even if Linux does not use MTRRs directly, some x86 platform firmware may still +set up MTRRs early before booting the OS. They do this as some platform +firmware may still have implemented access to MTRRs which would be controlled +and handled by the platform firmware directly. An example of platform use of +MTRRs is through the use of SMI handlers, one case could be for fan control, +the platform code would need uncachable access to some of its fan control +registers. Such platform access does not need any Operating System MTRR code in +place other than mtrr_type_lookup() to ensure any OS specific mapping requests +are aligned with platform MTRR setup. If MTRRs are only set up by the platform +firmware code though and the OS does not make any specific MTRR mapping +requests mtrr_type_lookup() should always return MTRR_TYPE_INVALID. For details refer to Documentation/x86/pat.txt. diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c index e7ed0d8..f891b47 100644 --- a/arch/x86/kernel/cpu/mtrr/main.c +++ b/arch/x86/kernel/cpu/mtrr/main.c @@ -448,7 +448,6 @@ int mtrr_add(unsigned long base, unsigned long size, unsigned int type, return mtrr_add_page(base >> PAGE_SHIFT, size >> PAGE_SHIFT, type, increment); } -EXPORT_SYMBOL(mtrr_add); /** * mtrr_del_page - delete a memory type region @@ -537,7 +536,6 @@ int mtrr_del(int reg, unsigned long base, unsigned long size) return -EINVAL; return mtrr_del_page(reg, base >> PAGE_SHIFT, size >> PAGE_SHIFT); } -EXPORT_SYMBOL(mtrr_del); /** * arch_phys_wc_add - add a WC MTRR and handle errors if PAT is unavailable -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
