linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 10/17] ARM: LPAE: use phys_addr_t in switch_mm()
Date: Fri, 21 Sep 2012 19:41:43 +0100	[thread overview]
Message-ID: <20120921184143.GH15609@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <alpine.LFD.2.02.1209211433110.6667@xanadu.home>

On Fri, Sep 21, 2012 at 02:33:43PM -0400, Nicolas Pitre wrote:
> On Tue, 11 Sep 2012, Cyril Chemparathy wrote:
> 
> > This patch modifies the switch_mm() processor functions to use phys_addr_t.
> > On LPAE systems, we now honor the upper 32-bits of the physical address that
> > is being passed in, and program these into TTBR as expected.
> > 
> > Signed-off-by: Cyril Chemparathy <cyril@ti.com>
> > Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
> 
> Reviewed-by: Nicolas Pitre <nico@linaro.org>

Err... you may have reviewed it but did you read it?

> > diff --git a/arch/arm/include/asm/proc-fns.h b/arch/arm/include/asm/proc-fns.h
> > index f3628fb..75b5f14 100644
> > --- a/arch/arm/include/asm/proc-fns.h
> > +++ b/arch/arm/include/asm/proc-fns.h
> > @@ -60,7 +60,7 @@ extern struct processor {
> >  	/*
> >  	 * Set the page table
> >  	 */
> > -	void (*switch_mm)(unsigned long pgd_phys, struct mm_struct *mm);
> > +	void (*switch_mm)(phys_addr_t pgd_phys, struct mm_struct *mm);
> >  	/*
> >  	 * Set a possibly extended PTE.  Non-extended PTEs should
> >  	 * ignore 'ext'.
> > @@ -82,7 +82,7 @@ extern void cpu_proc_init(void);
> >  extern void cpu_proc_fin(void);
> >  extern int cpu_do_idle(void);
> >  extern void cpu_dcache_clean_area(void *, int);
> > -extern void cpu_do_switch_mm(unsigned long pgd_phys, struct mm_struct *mm);
> > +extern void cpu_do_switch_mm(phys_addr_t pgd_phys, struct mm_struct *mm);

phys_addr_t can be either 64-bit or 32-bit.  Which it ends up depends on
a configuration option.  If it's 32-bit, then mm is in r1, otherwise it
is in r2...

> >  #ifdef CONFIG_MMU
> > -	ldr	r1, [r1, #MM_CONTEXT_ID]	@ get mm->context.id
> > -	and	r3, r1, #0xff
> > -	mov	r3, r3, lsl #(48 - 32)		@ ASID
> > -	mcrr	p15, 0, r0, r3, c2		@ set TTB 0
> > +	ldr	r2, [r2, #MM_CONTEXT_ID]	@ get mm->context.id

which breaks this when phys_addr_t is 32-bit.

Doing it this way means we have to have similar conditionals in other
files which make use of the 'mm' argument.

Moving the 'mm' argument into arg0 would mean that stays as r0, but
then the pgd_phys argument is passed in either r1 when 32-bit, or
r2,r3 when 64-bit on EABI and r1,r2 on OABI.  That's hardly desirable
behaviour either, because it all too easily allows bugs to creap in.

The easiest solution would be to just change pgd_phys to be uint64_t
and be done with it.  Then you always know in assembly what registers
values are going to be passed in (except for the LE/BE issue with r0/r1).

  reply	other threads:[~2012-09-21 18:41 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-11 17:38 [PATCH v3 00/17] LPAE fixes and extensions for Keystone Cyril Chemparathy
2012-09-11 17:38 ` [PATCH v3 01/17] ARM: add mechanism for late code patching Cyril Chemparathy
2012-09-21 18:09   ` Nicolas Pitre
2012-09-21 22:30     ` Cyril Chemparathy
2012-09-11 17:39 ` [PATCH v3 02/17] ARM: add self test for runtime patch mechanism Cyril Chemparathy
2012-09-21 17:40   ` Nicolas Pitre
2012-09-21 22:25     ` Cyril Chemparathy
2012-09-11 17:39 ` [PATCH v3 03/17] ARM: use late patch framework for phys-virt patching Cyril Chemparathy
2012-09-21 18:15   ` Nicolas Pitre
2012-09-11 17:39 ` [PATCH v3 04/17] ARM: LPAE: use phys_addr_t on virt <--> phys conversion Cyril Chemparathy
2012-09-11 17:39 ` [PATCH v3 05/17] ARM: LPAE: support 64-bit virt_to_phys patching Cyril Chemparathy
2012-09-11 17:39 ` [PATCH v3 06/17] ARM: LPAE: use signed arithmetic for mask definitions Cyril Chemparathy
2012-09-11 17:39 ` [PATCH v3 07/17] ARM: LPAE: use phys_addr_t in alloc_init_pud() Cyril Chemparathy
2012-09-11 17:39 ` [PATCH v3 08/17] ARM: LPAE: use phys_addr_t in free_memmap() Cyril Chemparathy
2012-09-11 17:39 ` [PATCH v3 09/17] ARM: LPAE: use phys_addr_t for initrd location and size Cyril Chemparathy
2012-09-21 18:30   ` Nicolas Pitre
2012-09-11 17:39 ` [PATCH v3 10/17] ARM: LPAE: use phys_addr_t in switch_mm() Cyril Chemparathy
2012-09-21 18:33   ` Nicolas Pitre
2012-09-21 18:41     ` Russell King - ARM Linux [this message]
2012-09-21 18:53       ` Nicolas Pitre
2012-09-11 17:39 ` [PATCH v3 11/17] ARM: LPAE: use 64-bit accessors for TTBR registers Cyril Chemparathy
2012-09-11 17:39 ` [PATCH v3 12/17] ARM: LPAE: define ARCH_LOW_ADDRESS_LIMIT for bootmem Cyril Chemparathy
2012-09-11 17:39 ` [PATCH v3 13/17] ARM: LPAE: factor out T1SZ and TTBR1 computations Cyril Chemparathy
2012-09-11 17:39 ` [PATCH v3 14/17] ARM: LPAE: accomodate >32-bit addresses for page table base Cyril Chemparathy
2012-09-11 17:39 ` [PATCH v3 15/17] ARM: mm: use physical addresses in highmem sanity checks Cyril Chemparathy
2012-09-11 17:39 ` [PATCH v3 16/17] ARM: mm: cleanup checks for membank overlap with vmalloc area Cyril Chemparathy
2012-09-11 17:39 ` [PATCH v3 17/17] ARM: mm: clean up membank size limit checks Cyril Chemparathy
2012-09-21 18:42   ` Nicolas Pitre
2012-09-21 22:49     ` Cyril Chemparathy

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=20120921184143.GH15609@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).