From: u.kleine-koenig@pengutronix.de (Uwe Kleine-König)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH .36-rc8] arm: mm: allow, but warn, when issuing ioremap() on RAM
Date: Fri, 15 Oct 2010 16:23:10 +0200 [thread overview]
Message-ID: <20101015142310.GD16893@pengutronix.de> (raw)
In-Reply-To: <1287152120-7201-1-git-send-email-felipe.contreras@gmail.com>
On Fri, Oct 15, 2010 at 05:15:20PM +0300, Felipe Contreras wrote:
> From: Catalin Marinas <catalin.marinas@arm.com>
>
> Drivers have been relying on this behavior, but done so wrongly.
> However, rather than breaking drivers from .35 to .36, we should warn on
> .36 and only break on .37. This way we give a chance for contributors to
> fix the issues.
>
> According to ARM, the behavior of having multiple mappings is
> unspecified from ARMv6+. This causes real issues specially on modern
> hardware, and specially with speculative prefetching. So drivers need to
> be fixed.
>
> Also, since current hardware has palliative meassures to deal with
> multiple mappings with the same memory type but diferent cacheability
> attributes, ensure that such restriction is taking place.
>
> Cc: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Richard Woodruff <r-woodruff2@ti.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> arch/arm/mm/ioremap.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
> index ab50627..7dfd6dd 100644
> --- a/arch/arm/mm/ioremap.c
> +++ b/arch/arm/mm/ioremap.c
> @@ -202,10 +202,14 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,
> return NULL;
>
> /*
> - * Don't allow RAM to be mapped - this causes problems with ARMv6+
> + * This causes problems with ARMv6+. Will be disallowed soon.
s/soon/for 2.6.37/ ?
> + * Also avoid a second mapping with different shareability, which is
> + * not supposed to work anyway.
> */
> if (WARN_ON(pfn_valid(pfn)))
> - return NULL;
> + if (__LINUX_ARM_ARCH__ >= 6 &&
> + (mtype != MT_DEVICE_CACHED && mtype != MT_DEVICE_WC))
> + mtype = MT_DEVICE_WC;
>
> type = get_mem_type(mtype);
> if (!type)
> --
> 1.7.3.1.2.g7fe2b
>
>
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
WARNING: multiple messages have this Message-ID (diff)
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: linux-main <linux-kernel@vger.kernel.org>,
linux-arm <linux-arm-kernel@lists.infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Russell King <linux@arm.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Richard Woodruff <r-woodruff2@ti.com>
Subject: Re: [PATCH .36-rc8] arm: mm: allow, but warn, when issuing ioremap() on RAM
Date: Fri, 15 Oct 2010 16:23:10 +0200 [thread overview]
Message-ID: <20101015142310.GD16893@pengutronix.de> (raw)
In-Reply-To: <1287152120-7201-1-git-send-email-felipe.contreras@gmail.com>
On Fri, Oct 15, 2010 at 05:15:20PM +0300, Felipe Contreras wrote:
> From: Catalin Marinas <catalin.marinas@arm.com>
>
> Drivers have been relying on this behavior, but done so wrongly.
> However, rather than breaking drivers from .35 to .36, we should warn on
> .36 and only break on .37. This way we give a chance for contributors to
> fix the issues.
>
> According to ARM, the behavior of having multiple mappings is
> unspecified from ARMv6+. This causes real issues specially on modern
> hardware, and specially with speculative prefetching. So drivers need to
> be fixed.
>
> Also, since current hardware has palliative meassures to deal with
> multiple mappings with the same memory type but diferent cacheability
> attributes, ensure that such restriction is taking place.
>
> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Richard Woodruff <r-woodruff2@ti.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> arch/arm/mm/ioremap.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
> index ab50627..7dfd6dd 100644
> --- a/arch/arm/mm/ioremap.c
> +++ b/arch/arm/mm/ioremap.c
> @@ -202,10 +202,14 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,
> return NULL;
>
> /*
> - * Don't allow RAM to be mapped - this causes problems with ARMv6+
> + * This causes problems with ARMv6+. Will be disallowed soon.
s/soon/for 2.6.37/ ?
> + * Also avoid a second mapping with different shareability, which is
> + * not supposed to work anyway.
> */
> if (WARN_ON(pfn_valid(pfn)))
> - return NULL;
> + if (__LINUX_ARM_ARCH__ >= 6 &&
> + (mtype != MT_DEVICE_CACHED && mtype != MT_DEVICE_WC))
> + mtype = MT_DEVICE_WC;
>
> type = get_mem_type(mtype);
> if (!type)
> --
> 1.7.3.1.2.g7fe2b
>
>
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
next prev parent reply other threads:[~2010-10-15 14:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-15 14:15 [PATCH .36-rc8] arm: mm: allow, but warn, when issuing ioremap() on RAM Felipe Contreras
2010-10-15 14:15 ` Felipe Contreras
2010-10-15 14:23 ` Uwe Kleine-König [this message]
2010-10-15 14:23 ` Uwe Kleine-König
2010-10-15 14:25 ` Felipe Contreras
2010-10-15 14:25 ` Felipe Contreras
2010-10-15 14:30 ` Catalin Marinas
2010-10-15 14:30 ` Catalin Marinas
2010-10-15 19:42 ` Russell King - ARM Linux
2010-10-15 19:42 ` Russell King - ARM Linux
2010-10-15 20:00 ` Felipe Contreras
2010-10-15 20:00 ` Felipe Contreras
2010-10-15 20:14 ` Russell King - ARM Linux
2010-10-15 20:14 ` Russell King - ARM Linux
2010-10-17 12:06 ` Felipe Contreras
2010-10-17 12:06 ` Felipe Contreras
2010-10-17 12:33 ` Russell King - ARM Linux
2010-10-17 12:33 ` Russell King - ARM Linux
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101015142310.GD16893@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.