From patchwork Mon Feb 22 14:02:07 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 62579 Delivered-To: patch@linaro.org Received: by 10.112.43.199 with SMTP id y7csp1253571lbl; Mon, 22 Feb 2016 06:02:43 -0800 (PST) X-Received: by 10.98.15.145 with SMTP id 17mr37715332pfp.19.1456149763330; Mon, 22 Feb 2016 06:02:43 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y77si39958315pfa.187.2016.02.22.06.02.43; Mon, 22 Feb 2016 06:02:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dkim=pass header.i=@linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932107AbcBVOCl (ORCPT + 30 others); Mon, 22 Feb 2016 09:02:41 -0500 Received: from mail-wm0-f43.google.com ([74.125.82.43]:35886 "EHLO mail-wm0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755082AbcBVOCQ (ORCPT ); Mon, 22 Feb 2016 09:02:16 -0500 Received: by mail-wm0-f43.google.com with SMTP id g62so174176494wme.1 for ; Mon, 22 Feb 2016 06:02:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=82UmIoJcuCHVxL7tcDK/VKTrQL47AvWM9X5vC0obJBw=; b=R44qlRPn8wB7HI8rnpmgorD2xhVkyEjsSTrvqVFpDqV3e3BruCGymuyMCBBTy6/5b1 o++jW72n2ESdij4mkOaOZcGYJjvuGn+nZWhnO5SY8JSl2tkHzaY51OPkdYNogZW8CV67 zft+1K4j5D5S7clrGqAVXgtmGuRVV30K76z+g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=82UmIoJcuCHVxL7tcDK/VKTrQL47AvWM9X5vC0obJBw=; b=KGRGDRCJx0Gg/7A/ovmjsAJN4bCgI1O56SGsdJKXabcb009cps8jNg64KZHyUzzW3/ 3bv00J/PXiCQLfhMUVKhacnXXDmtWwojWYzbqsCeT10wF7I453WP4QHzLEN0w2ICgT2l 4XXFbd2EiFNiFH5ROQ5tqWk1CrnDJa2cfMu7S+OCnqbCHFjT4vFM7iWHIXCbfiRFm09E nsgNd7vfzF2lZlCE796YqjVfn1PM1uB+WhJqw3Xh16HxEM1jPv0uTynAVRryOyQ+ZxaV Xf0bRQYAKO0/HIEoXcOuv4P8oteLA2fgd33wzNW2zw/IlgzNzRrAAF7zokLEsMFx0svC 37dg== X-Gm-Message-State: AG10YOSQUSunhk/C64P4bJoHTXY+Y77Tj/YsN3s7DO2nFQVX3GL5JHjyfMBT6R/1mLqtUrCY X-Received: by 10.28.1.9 with SMTP id 9mr11911042wmb.97.1456149735584; Mon, 22 Feb 2016 06:02:15 -0800 (PST) Received: from localhost.localdomain ([195.55.142.58]) by smtp.gmail.com with ESMTPSA id b5sm21269068wmh.15.2016.02.22.06.02.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 22 Feb 2016 06:02:14 -0800 (PST) From: Ard Biesheuvel To: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux@arm.linux.org.uk, dan.j.williams@intel.com Cc: arnd@arndb.de, nico@linaro.org, Ard Biesheuvel Subject: [RFC PATCH 1/2] memremap: add arch specific hook for MEMREMAP_WB mappings Date: Mon, 22 Feb 2016 15:02:07 +0100 Message-Id: <1456149728-16706-2-git-send-email-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.5.0 In-Reply-To: <1456149728-16706-1-git-send-email-ard.biesheuvel@linaro.org> References: <1456149728-16706-1-git-send-email-ard.biesheuvel@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Currently, the memremap code serves MEMREMAP_WB mappings directly from the kernel direct mapping, unless the region is in high memory, in which case it falls back to using ioremap_cache(). However, the semantics of ioremap_cache() are not unambiguously defined, and on ARM, it will actually result in a mapping type that differs from the attributes used for the linear mapping, and for this reason, the ioremap_cache() call fails if the region is part of the memory managed by the kernel. So instead, implement an optional hook 'arch_memremap_wb' whose default implementation calls ioremap_cache() as before, but which can be overridden by the architecture to do what is appropriate for it. Cc: Dan Williams Signed-off-by: Ard Biesheuvel --- kernel/memremap.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) -- 2.5.0 diff --git a/kernel/memremap.c b/kernel/memremap.c index 7a1b5c3ef14e..77c41648ba16 100644 --- a/kernel/memremap.c +++ b/kernel/memremap.c @@ -27,6 +27,13 @@ __weak void __iomem *ioremap_cache(resource_size_t offset, unsigned long size) } #endif +#ifndef arch_memremap_wb +static void *arch_memremap_wb(resource_size_t offset, unsigned long size) +{ + return (__force void *)ioremap_cache(offset, size); +} +#endif + static void *try_ram_remap(resource_size_t offset, size_t size) { struct page *page = pfn_to_page(offset >> PAGE_SHIFT); @@ -34,7 +41,7 @@ static void *try_ram_remap(resource_size_t offset, size_t size) /* In the simple case just return the existing linear address */ if (!PageHighMem(page)) return __va(offset); - return NULL; /* fallback to ioremap_cache */ + return arch_memremap_wb(offset, size); } /** @@ -80,8 +87,6 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags) */ if (is_ram == REGION_INTERSECTS) addr = try_ram_remap(offset, size); - if (!addr) - addr = ioremap_cache(offset, size); } /*