All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: "Shilimkar, Santosh" <santosh.shilimkar@ti.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	R Sricharan <r.sricharan@ti.com>
Subject: Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
Date: Wed, 9 May 2012 11:23:27 +0100	[thread overview]
Message-ID: <20120509102327.GF11099@arm.com> (raw)
In-Reply-To: <CAMQu2gzmZ1Af4sAxoT9WS_akY1gBrqffKE84rnbM_EUK8V8NHQ@mail.gmail.com>

On Wed, May 09, 2012 at 09:50:28AM +0100, Shilimkar, Santosh wrote:
> On Wed, May 9, 2012 at 3:25 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Tue, May 08, 2012 at 07:31:57PM +0530, Shilimkar, Santosh wrote:
> >> Ok. Assuming you mean " it's _not_ cleaner to have two domains where
> >> manager overrides XN attributes" Note that DRAM can be in the middle of
> >> 4GB address space, so we need to take care of bottom and top address
> >> space.
> >>
> >> Update patch end of the email. Is that fine with you ?
> >
> > This is certainly not cleaner because this will break non-ARMv7.
> 
> The only change done common code is  clearing 'XN' bit for DRAM
> region in page table entries. The other change of setting the DACR
> register is done in ARMv7 specific code.
> 
> So it should work as long as XN bit supported or that
> bit position is not used. I checked ARMv6(OMAP2) and that seems
> to be fine.
> 
> Can you please help me to understand which ARM version will
> be broken because of this change and how ? I only have access
> to ARMv6 and ARMv7 specs.

It's probably ARMv5 and earlier that didn't have an XN bit (introduced
with ARMv6).

I have an old ARM ARM on my desk and it looks like bit 4 is XN on ARMv6+
and Implementation Defined on ARMv5 and earlier.  It looks like we set
it all the time in the current decompressor.

Looking at the arch/arm/mm/mmu.c file, there is this PMD_BIT4 which is
always set on ARMv5 and earlier except Xscale and XSC3 (see the comment
in build_mem_type_table).

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
Date: Wed, 9 May 2012 11:23:27 +0100	[thread overview]
Message-ID: <20120509102327.GF11099@arm.com> (raw)
In-Reply-To: <CAMQu2gzmZ1Af4sAxoT9WS_akY1gBrqffKE84rnbM_EUK8V8NHQ@mail.gmail.com>

On Wed, May 09, 2012 at 09:50:28AM +0100, Shilimkar, Santosh wrote:
> On Wed, May 9, 2012 at 3:25 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Tue, May 08, 2012 at 07:31:57PM +0530, Shilimkar, Santosh wrote:
> >> Ok. Assuming you mean " it's _not_ cleaner to have two domains where
> >> manager overrides XN attributes" Note that DRAM can be in the middle of
> >> 4GB address space, so we need to take care of bottom and top address
> >> space.
> >>
> >> Update patch end of the email. Is that fine with you ?
> >
> > This is certainly not cleaner because this will break non-ARMv7.
> 
> The only change done common code is  clearing 'XN' bit for DRAM
> region in page table entries. The other change of setting the DACR
> register is done in ARMv7 specific code.
> 
> So it should work as long as XN bit supported or that
> bit position is not used. I checked ARMv6(OMAP2) and that seems
> to be fine.
> 
> Can you please help me to understand which ARM version will
> be broken because of this change and how ? I only have access
> to ARMv6 and ARMv7 specs.

It's probably ARMv5 and earlier that didn't have an XN bit (introduced
with ARMv6).

I have an old ARM ARM on my desk and it looks like bit 4 is XN on ARMv6+
and Implementation Defined on ARMv5 and earlier.  It looks like we set
it all the time in the current decompressor.

Looking at the arch/arm/mm/mmu.c file, there is this PMD_BIT4 which is
always set on ARMv5 and earlier except Xscale and XSC3 (see the comment
in build_mem_type_table).

-- 
Catalin

  reply	other threads:[~2012-05-09 10:28 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-07 13:42 [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space Santosh Shilimkar
2012-05-07 13:42 ` Santosh Shilimkar
2012-05-08 12:41 ` Catalin Marinas
2012-05-08 12:41   ` Catalin Marinas
2012-05-08 14:01   ` Shilimkar, Santosh
2012-05-08 14:01     ` Shilimkar, Santosh
2012-05-08 14:16     ` Catalin Marinas
2012-05-08 14:16       ` Catalin Marinas
2012-05-08 14:20       ` Santosh Shilimkar
2012-05-08 14:20         ` Santosh Shilimkar
2012-05-08 14:23         ` Catalin Marinas
2012-05-08 14:23           ` Catalin Marinas
2012-05-08 14:43           ` Santosh Shilimkar
2012-05-08 14:43             ` Santosh Shilimkar
2012-05-08 21:55     ` Russell King - ARM Linux
2012-05-08 21:55       ` Russell King - ARM Linux
2012-05-09  8:50       ` Shilimkar, Santosh
2012-05-09  8:50         ` Shilimkar, Santosh
2012-05-09 10:23         ` Catalin Marinas [this message]
2012-05-09 10:23           ` Catalin Marinas
2012-05-09 12:23         ` Russell King - ARM Linux
2012-05-09 12:23           ` Russell King - ARM Linux
2012-05-09 12:30           ` Shilimkar, Santosh
2012-05-09 12:30             ` Shilimkar, Santosh
2012-05-09 15:48             ` Russell King - ARM Linux
2012-05-09 15:48               ` Russell King - ARM Linux
2012-05-09 20:44               ` Buckley, Bryan
2012-05-09 20:44                 ` Buckley, Bryan
2012-05-09 21:40                 ` Russell King - ARM Linux
2012-05-09 21:40                   ` Russell King - ARM Linux
2012-05-15 18:55                   ` Buckley, Bryan
2012-05-15 18:55                     ` Buckley, Bryan
2012-05-10  7:11               ` Santosh Shilimkar
2012-05-10  7:11                 ` Santosh Shilimkar
2012-05-10  8:53                 ` Russell King - ARM Linux
2012-05-10  8:53                   ` Russell King - ARM Linux
2012-05-10  9:41                   ` Santosh Shilimkar
2012-05-10  9:41                     ` Santosh Shilimkar

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=20120509102327.GF11099@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=r.sricharan@ti.com \
    --cc=santosh.shilimkar@ti.com \
    /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.