From patchwork Mon Aug 24 19:13:33 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "Luis R. Rodriguez" X-Patchwork-Id: 7066301 Return-Path: X-Original-To: patchwork-linux-fbdev@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 3A6D0C05AC for ; Mon, 24 Aug 2015 19:15:40 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 6C4E120570 for ; Mon, 24 Aug 2015 19:15:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2FDD6205F3 for ; Mon, 24 Aug 2015 19:15:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932490AbbHXTOq (ORCPT ); Mon, 24 Aug 2015 15:14:46 -0400 Received: from mail-pd0-f175.google.com ([209.85.192.175]:36709 "EHLO mail-pd0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755156AbbHXTOX (ORCPT ); Mon, 24 Aug 2015 15:14:23 -0400 Received: by pdbmi9 with SMTP id mi9so56607214pdb.3; Mon, 24 Aug 2015 12:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=vJtp2hLgqyKFcYkjyPvuyBHhmmnEofe2JZgv0OPtzN0=; b=pwuSbTucmhPcDiXRKAfEu+5ckd23otXIT3RqZ1evf3rHLxWpR5hqk8D0Wr9q37ZBkW 1nFagylSOas43WAFY6R1wCKsK6V6KZNFO0J/NAgNIheh0Mn8dDON3vuQQib0vdpR8yb0 m7BATjRv0NKXohSEawQyBnyA5qXt067RdziudO/iTY1De0/MveYR62uIyVR3Wxkh9y7F totoY/VZwGzMtuSHiS7jU5ie665JruUTdJJigpWsW+AMKmixCRDLZ48FZ1tck9hj0GNp EUgQKJda/+AL8B5FXnfkc64bCNb967Lva8VJeSOUbgQB7+yzt/tdV8vqqIhR7cgp0Dco /VVQ== X-Received: by 10.70.94.69 with SMTP id da5mr48447496pdb.95.1440443663062; Mon, 24 Aug 2015 12:14:23 -0700 (PDT) Received: from mcgrof@gmail.com ([2601:646:200:bc5b:ca60:ff:feda:57a7]) by smtp.gmail.com with ESMTPSA id ea13sm18363590pac.30.2015.08.24.12.14.19 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 24 Aug 2015 12:14:22 -0700 (PDT) Received: by mcgrof@gmail.com (sSMTP sendmail emulation); Mon, 24 Aug 2015 12:14:19 -0700 From: "Luis R. Rodriguez" To: mingo@kernel.org Cc: bp@suse.de, bhelgaas@google.com, tomi.valkeinen@ti.com, airlied@linux.ie, linux-fbdev@vger.kernel.org, luto@amacapital.net, vinod.koul@intel.com, dan.j.williams@intel.com, toshi.kani@hp.com, benh@kernel.crashing.org, mst@redhat.com, akpm@linux-foundation.org, daniel.vetter@ffwll.ch, konrad.wilk@oracle.com, x86@kernel.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, xen-devel@lists.xensource.com, "Luis R. Rodriguez" , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Dave Hansen , Suresh Siddha , Ingo Molnar , Juergen Gross , Dave Airlie , Antonino Daplas , Jean-Christophe Plagniol-Villard , =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= , Mel Gorman , Vlastimil Babka , Davidlohr Bueso , Doug Ledford , Andy Walls , netdev@vger.kernel.org, linux-media@vger.kernel.org Subject: [PATCH v4 11/11] mtrr: bury MTRR - unexport mtrr_add() and mtrr_del() Date: Mon, 24 Aug 2015 12:13:33 -0700 Message-Id: <1440443613-13696-12-git-send-email-mcgrof@do-not-panic.com> X-Mailer: git-send-email 2.1.4 In-Reply-To: <1440443613-13696-1-git-send-email-mcgrof@do-not-panic.com> References: <1440443613-13696-1-git-send-email-mcgrof@do-not-panic.com> MIME-Version: 1.0 Sender: linux-fbdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fbdev@vger.kernel.org X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: "Luis R. Rodriguez" The crusade 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 crusade done now, hide direct MTRR access for drivers. 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.camel@hp.com Cc: Toshi Kani Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Borislav Petkov Cc: Dave Hansen Cc: Suresh Siddha Cc: Ingo Molnar Cc: Juergen Gross Cc: Daniel Vetter Cc: Andy Lutomirski Cc: Dave Airlie Cc: Antonino Daplas Cc: Jean-Christophe Plagniol-Villard Cc: Tomi Valkeinen Cc: Ville Syrjälä Cc: Mel Gorman Cc: Vlastimil Babka Cc: Davidlohr Bueso Cc: Doug Ledford Cc: Andy Walls Cc: x86@kernel.org Cc: netdev@vger.kernel.org Cc: linux-media@vger.kernel.org Cc: linux-fbdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Luis R. Rodriguez --- 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 860bc3adc223..8a0bdb6e7370 100644 --- a/Documentation/x86/mtrr.txt +++ b/Documentation/x86/mtrr.txt @@ -6,10 +6,22 @@ Luis R. Rodriguez - 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 MTRR 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 +MTRR 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 e7ed0d8ebacb..f891b4750f04 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